One document matched: draft-droms-dhc-container-opt-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc3118 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml'>
<!ENTITY rfc2131 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY rfc2132 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
<?rfc toc="no" ?>
<?rfc compact="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="full3978"
docName="draft-droms-dhc-container-opt-01.txt">
<front>
<title abbrev="DHCP Container Option">
Container Option for Server Configuration
</title>
<author initials="R."
surname="Droms"
fullname="Ralph Droms">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<region>MA</region>
<country>USA</country>
<code>01719</code>
</postal>
<phone>+1 978.936.1674</phone>
<email>rdroms@cisco.com</email>
</address>
</author>
<date year="2007"/>
<area>internet</area>
<workgroup>dhc Working Group</workgroup>
<abstract>
<t>In some DHCP service deployments, it is desirable for a DHCP
server in one administrative domain to pass configuration
options to a DHCP server in a different administrative domain.
This DHCP option carries a set of DHCP options that can be used
by another DHCP server.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In some DHCP service deployments, it is desirable to pass
configuration options from a DHCP server in one administrative
domain to another DHCP server in a different administrative
domain. In one example of such a deployment, an IPTV service
provider (SP) may need to provide certain SP domain-specific
information to IPTV device(s) located in the consumer domain.
This information is sent from the IPTV SP DHCP server to the
consumer DHCP server located in the Residential Gateway (RG),
which can then be passed along to IPTV device(s) in the
subscriber network
<!-- a service provider
(SP) using DOCSIS and PacketCable may want to pass some
PacketCable configuration information from the SP DHCP service
to a subscriber DHCP server in the subscriber home gateway
device (HGW), which can then be passed along to PacketCable
devices in the subscriber network.
-->
</t>
<t>Existing RGs may pass some configuration information
received by the RG DHCP client to the RG server for
configuration of devices attached to the consumer network.
There are several motivations for this option:
<list style="symbols">
<t>The devices attached to the consumer network may require
different configuration information than the DHCP options
provided to the RG</t>
<t>Existing RG DHCP clients are typically not be coded to
process new DHCP options and, therefore, will be unable to
pass those new options to the RG DHCP server</t>
<t>Existing RG DHCP clients are typically coded to pass only
a fixed list of DHCP options to the RG DHCP server and,
therefore, will be unable to pass newly defined options to the
RG DHCP server.</t>
</list>
The DHCP Container option defined in this document provides a
mechanism through which the RG DHCP client can pass DHCP
options to the RG DHCP server without explicit knowledge of the
semantics of those options. With this option, the SP DHCP
server can pass both current and future DHCP options to the RG
DHCP server.</t>
<t>The DHCP Container option does not carry IP addresses IPv6
prefixes or other information about leases. It carries other
configuration information.</t>
</section>
<section title="Terminology">
<t> The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in <xref
target='RFC2119'>RFC2119</xref>.
</t>
<t>The following terms and acronyms are used in this document:
<list style='hanging' hangIndent='20'>
<t hangText="DHCPv4"><xref target="RFC2131">"Dynamic Host
Configuration Protocol"</xref></t>
<t hangText="DHCPv6"><xref target="RFC3315">"Dynamic Host
Configuration Protocol for IPv6"</xref></t>
<t hangText="DHCP">DHCPv4 and/or DHCPv6</t>
<t hangText="RG">"home gateway"; the device through which the
consumer network connects to the broadband WAN; typically a
layer 3 forwarding device</t>
<t hangText="RG DHCP client">(or "RG client") the DHCP
client in the RG</t>
<t hangText="RG DHCP server">(or "RG server") the DHCP
server in the RG</t>
</list>
</t>
</section>
<section title="Problem statement and requirements for RG DHCP
server configuration">
<t>The following diagram shows the components in a network
deployment using the DHCP Container option:
<artwork><![CDATA[
Client STB/CPE -+ +---------+ +------+
| | RG | | SP |
Client STB/CPE -+ | Client+--- ... ---+ DHCP |
+--+Server | |server|
Client STB/CPE -+ +---------+ +------+
]]></artwork>
In this diagram, the RG client engages in DHCP message
exchanges with the SP server to obtain its IP address and other
configuration information.</t>
<t>The problem under consideration in this document is to
transmit configuration information from the SP DHCP server to
devices attached to the consumer network. The problem
solution has the following requirements:
<list style='symbols'>
<t>The SP server MUST be able to transmit different
configuration information to the consumer devices than the
DHCP options provided to the RG</t>
<t>The SP server MUST be able to control which DHCP options
are transmitted to the consumer device</t>
<t>There MUST be a way for the SP server to pass DHCP options
to be defined in the future to consumer devices</t>
</list>
</t>
</section>
<section title="Design alternatives">
<t>The following three designs meet the solution requirements:
<list style="symbols">
<t>SP server passes container option to RG client, which
forwards contents to RG server; this alternative is the
preferred solution</t>
<t>RG server does direct DHCP info request to SP server; this
alternative is not preferred:
<list style='symbols'>
<t>requires that the RG server include a DHCP client</t>
<t>requires that the SP server be able to differentiate
between RG client and server requests</t>
<t>does not scale well, as it at least doubles the load on
the SP server</t>
</list>
</t>
<t>RG server passes device requests to SP DHCP server; this
alternative is not preferred:
<list style='symbols'>
<t>requires that the RG also function as a DHCP relay</t>
<t>requires that the RG relay function be configured with
the IP addresses of the SP DHCP server(s)</t>
<t>requires that the RG relay function differentiate
between DHCP messages that are processed by the RG server
and DHCP messages that are processes by the SP server</t>
</list>
</t>
</list>
</t>
<t> A variant on the preferred design would allow the inclusion
of multiple sets of DHCP options intended for different classes
of devices in the consumer network; e.g., the design would
allow for one set of options for video set-top boxes and a
second set of options for VoIP MTAs. The variant would require
the specification of rules to be provided by the SP server
through which the RG server would differentiate its clients and
send the appropriate set of options to each device. At present,
there is no requirement for differential configuration of
consumer devices and this alternative is not defined in this
document.</t>
</section>
<section title="Semantics and syntax of the Container option">
<t>Along with configuration information intended for the RG,
the SP server can include the DHCP Container option. When the
RG client receives the DHCP Container option, it passes the
contents of the option to the RG server. The means through
which the information is passed between the RG client and the
RG server is out of the scope of this document and left
unspecified.</t>
<t>The DHCP options in this container are carried in DHCP
message format (option-code/length/value). In this format, the
contained options can be passed through a DHCP client to a
co-located DHCP server without specific knowledge on the part of
the client or the server of the semantics of the options.</t>
<section title="DHCPv4 Container option">
<t>The DHCPv4 Container option has the following format:
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | len | DHCP Options for RG server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style='hanging' hangIndent='20'>
<t hangText='Code'>OPTION_CONTAINER_V4 (TBD)</t>
<t hangText='len'>Length of options for RG server, in octets</t>
</list>
</t>
</section>
<section title="DHCPv6 Container option">
<t>The DHCPv6 Container option has the following format:
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CONTAINER_V6 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Options for RG server |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style='hanging' hangIndent='20'>
<t hangText='option-code'>OPTION_CONTAINER_V6 (TBD).</t>
<t hangText='option-len'>Length of options for RG server, in octets</t>
</list>
</t>
</section>
<section title="SP server behavior">
<t>The SP server MAY include the Container option in any DHCP
message sent to an RG client.</t>
<t>The policy through which the SP server is instructed to
include a Container option for an RG client, and the policy
determining the contents of the Container object are out of
scope of this document and left unspecified.</t>
</section>
<section title="RG client behavior">
<t>The RG client MUST pass the contents of the received
Container option to the RG server without alteration. The
details of the implementation through which the RG client parses
the content of the Container option and passes the options to
the RG server are out of scope for this document and left
unspecified.</t>
</section>
<section title="RG server behavior">
<t>The RG server MUST discard any options related to IP address
assignment, IPv6 prefix delegation or operation of the DHCP
protocol itself. Appendices TBD give a list of DHCPv4 and
DHCPv6 options that the RG server MUST discard.</t>
<t>The Container option provides a mechanism through which the
SP might be able to unilaterally control the configuration
settings passed from a CPE DHCP server to a CPE device. This
configuration channel must be handled with some care if the
subscriber is to retain desired control over the CPE
configurations. The following behaviors limit the degree to
which the SP con control CPE configuration:
<list style='symbols'>
<t>The RG server MAY discard any undesired options, as
determined by policy in the RG.</t>
<t>The RG server MUST return to any DHCP client only those
options requested by the DHCP client in a Parameter Request
List option (DHCPv4 option code 55) or an Option Request
option (DHCPv6 option code 6).</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>A rogue server can use this option to pass invalid
information to the RG client, which would then be passed to the
Client STB/CPEs. This invalid information could be used to
mount a denial of service attack or a man-in-the-middle attack
against some applications.</t>
<t>Authentication of DHCP
messages(<xref target='RFC3118'>RFC 3118</xref> for DHCPv4 or
section 20 of <xref target='RFC3315'>RFC 3315</xref>) can be
used to ensure that the contents of this option are not
altered in transit between the DHCP server and client.</t>
</section>
<section title="IANA Considerations">
<t>When this document is published, IANA is asked to assign an
option tag from the "BOOTP Vendor Extensions and DHCP Options"
registry for OPTION_CONTAINER_V4.</t>
<t>When this document is published, IANA is asked to assign an
option code from the "DHCPv6 Option Codes" registry for
OPTION_CONTAINER_V6.</t>
</section>
<section title='Change Log'>
<t>If this document is accepted for publication as an RFC, this
change log is to be removed before publication.
<list style="symbols">
<t>Corrected a cut-and-paste error in section "DHCPv6
Container option": The Time Protocol Servers option -> The
DHCPv4 Container option</t>
<t>Added text to section "RG Server Behavior" to address
policy management concerns</t>
</list>
</t>
</section>
<!--
<section title="Acknowledgments">
<t>The Container option is based on the CableLabs eRouter DHCP
Container vendor-identifying vendor-specific option, as
defined in YYY.</t>
<t>The DHCP Container option will be submitted to ITU and ATIS
for possible adoption in specifications.</t>
-->
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2131;
&rfc2132;
&rfc3315;
&rfc3118;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:22 |