draft-ietf-dhc-container-opt-02.txt   draft-ietf-dhc-container-opt-03.txt 
dhc Working Group R. Droms dhc Working Group R. Droms
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track November 3, 2008 Intended status: Standards Track November 17, 2008
Expires: May 7, 2009 Expires: May 21, 2009
Container Option for Server Configuration Container Option for Server Configuration
draft-ietf-dhc-container-opt-02.txt draft-ietf-dhc-container-opt-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on May 21, 2009.
Abstract Abstract
In some DHCP service deployments, it is desirable for a DHCP server In some DHCP service deployments, it is desirable for a DHCP server
in one administrative domain to pass configuration options to a DHCP in one administrative domain to pass configuration options to a DHCP
server in a different administrative domain. This DHCP option server in a different administrative domain. This DHCP option
carries a set of DHCP options that can be used by another DHCP carries a set of DHCP options that can be used by another DHCP
server. server.
1. Introduction 1. Introduction
skipping to change at page 2, line 17 skipping to change at page 2, line 17
IPTV SP DHCP server to the consumer DHCP server located in the IPTV SP DHCP server to the consumer DHCP server located in the
Residential Gateway (RG), which can then be passed along to IPTV Residential Gateway (RG), which can then be passed along to IPTV
device(s) in the subscriber network. device(s) in the subscriber network.
Existing RGs may pass some configuration information received by the Existing RGs may pass some configuration information received by the
RG DHCP client to the RG server for configuration of devices attached RG DHCP client to the RG server for configuration of devices attached
to the consumer network. There are several motivations for this to the consumer network. There are several motivations for this
option: option:
o The devices attached to the consumer network may require different o The devices attached to the consumer network may require different
configuration information than the DHCP options provided to the RG configuration information than the DHCP options provided to the
RG.
o Existing RG DHCP clients are typically not be coded to process new o Existing RG DHCP clients are typically not coded to process new
DHCP options and, therefore, will be unable to pass those new DHCP options and, therefore, will be unable to pass those new
options to the RG DHCP server options to the RG DHCP server.
o Existing RG DHCP clients are typically coded to pass only a fixed o 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 list of DHCP options to the RG DHCP server and, therefore, will be
unable to pass newly defined options to the RG DHCP server. unable to pass newly defined options to the RG DHCP server.
The DHCP Container option defined in this document provides a The DHCP Container option defined in this document provides a
mechanism through which the RG DHCP client can pass DHCP options to mechanism through which the RG DHCP client can pass DHCP options to
the RG DHCP server without explicit knowledge of the semantics of the RG DHCP server without explicit knowledge of the semantics of
those options. With this option, the SP DHCP server can pass both those options. With this option, the SP DHCP server can pass both
current and future DHCP options to the RG DHCP server. current and future DHCP options to the RG DHCP server.
skipping to change at page 2, line 46 skipping to change at page 3, line 4
2. Terminology 2. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [RFC2119]. interpreted as described in RFC2119 [RFC2119].
The following terms and acronyms are used in this document: The following terms and acronyms are used in this document:
DHCPv4 "Dynamic Host Configuration Protocol" [RFC2131] DHCPv4 "Dynamic Host Configuration Protocol" [RFC2131]
DHCPv6 "Dynamic Host Configuration Protocol for IPv6" DHCPv6 "Dynamic Host Configuration Protocol for IPv6"
[RFC3315] [RFC3315]
DHCP DHCPv4 and/or DHCPv6 DHCP DHCPv4 and/or DHCPv6
RG "home gateway"; the device through which the RG "residential gateway"; the device through which
consumer network connects to the broadband WAN; the consumer network connects to the broadband
typically a layer 3 forwarding device WAN; typically a layer 3 forwarding device
RG DHCP client (or "RG client") the DHCP client in the RG RG DHCP client (or "RG client") the DHCP client in the RG
RG DHCP server (or "RG server") the DHCP server in the RG RG DHCP server (or "RG server") the DHCP server in the RG
SP DHCP server (or "SP server") the DHCP server managed by the SP DHCP server (or "SP server") the DHCP server managed by the
service provider (SP) service provider (SP)
This document uses other terminology for DHCPv4 and DHCPv6 as defined This document uses other terminology for DHCPv4 and DHCPv6 as defined
in RFC 2131 and RFC 3315, respectively. in RFC 2131 and RFC 3315, respectively.
skipping to change at page 3, line 42 skipping to change at page 3, line 45
the SP server to obtain its IP address and other configuration the SP server to obtain its IP address and other configuration
information. information.
The problem under consideration in this document is to transmit The problem under consideration in this document is to transmit
configuration information from the SP DHCP server to devices attached configuration information from the SP DHCP server to devices attached
to the consumer network. The problem solution has the following to the consumer network. The problem solution has the following
requirements: requirements:
o The SP server MUST be able to transmit different configuration o The SP server MUST be able to transmit different configuration
information to the consumer devices than the DHCP options provided information to the consumer devices than the DHCP options provided
to the RG to the RG.
o The SP server MUST be able to control which DHCP options are o The SP server MUST be able to control which DHCP options are
transmitted to the consumer device transmitted to the consumer device.
o There MUST be a way for the SP server to pass DHCP options to be o There MUST be a way for the SP server to pass DHCP options to be
defined in the future to consumer devices defined in the future to consumer devices.
4. Design alternatives 4. Design alternatives
The following three designs meet the solution requirements: The following three designs meet the solution requirements:
o SP server passes container option to RG client, which forwards o SP server passes container option to RG client, which forwards
contents to RG server; this alternative is the preferred solution contents to RG server; this alternative is the preferred solution
o RG server does direct DHCP info request to SP server; this o RG server does direct DHCP info request to SP server; this
alternative is not preferred: alternative is not preferred because it:
* requires that the RG server include a DHCP client * requires that the RG server include a DHCP client,
* requires that the SP server be able to differentiate between RG * requires that the SP server be able to differentiate between RG
client and server requests client and server requests, and it
* does not scale well, as it at least doubles the load on the SP * does not scale well, as it at least doubles the load on the SP
server server.
o RG server passes device requests to SP DHCP server; this o RG server passes device requests to SP DHCP server; this
alternative is not preferred: alternative is not preferred because it:
* requires that the RG also function as a DHCP relay * requires that the RG also function as a DHCP relay,
* requires that the RG relay function be configured with the IP * requires that the RG relay function be configured with the IP
addresses of the SP DHCP server(s) addresses of the SP DHCP server(s), and it
* requires that the RG relay function differentiate between DHCP * requires that the RG relay function differentiate between DHCP
messages that are processed by the RG server and DHCP messages messages that are processed by the RG server and DHCP messages
that are processes by the SP server that are processes by the SP server, which does not scale well.
A variant on the preferred design would allow the inclusion of A variant on the preferred design would allow the inclusion of
multiple sets of DHCP options intended for different classes of multiple sets of DHCP options intended for different classes of
devices in the consumer network; e.g., the design would allow for one 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 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 for VoIP MTAs. The variant would require the specification of rules
to be provided by the SP server through which the RG server would to be provided by the SP server through which the RG server would
differentiate its clients and send the appropriate set of options to differentiate its clients and send the appropriate set of options to
each device. At present, there is no requirement for differential each device. At present, there is no requirement for differential
configuration of consumer devices and this alternative is not defined configuration of consumer devices and this alternative is not defined
skipping to change at page 5, line 34 skipping to change at page 5, line 34
0 1 2 3 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 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 | | Code | len | DHCP Options for RG server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code OPTION_CONTAINER_V4 (TBD) Code OPTION_CONTAINER_V4 (TBDv4)
len Length of options for RG server, in octets len Length of options for RG server, in octets
5.2. DHCPv6 Container option 5.2. DHCPv6 Container option
The DHCPv6 Container option has the following format: The DHCPv6 Container option has the following format:
0 1 2 3 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 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 | | OPTION_CONTAINER_V6 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Options for RG server | | DHCP Options for RG server |
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CONTAINER_V6 (TBD). option-code OPTION_CONTAINER_V6 (TBDv6).
option-len Length of options for RG server, in octets option-len Length of options for RG server, in octets
5.3. SP server behavior 5.3. SP server behavior
The SP server MAY include the Container option in any DHCP message The SP server MAY include the Container option in any DHCP message
sent to an RG client. sent to an RG client.
The policy through which the SP server is instructed to include a The policy through which the SP server is instructed to include a
Container option for an RG client, and the policy determining the Container option for an RG client, and the policy determining the
skipping to change at page 6, line 30 skipping to change at page 6, line 30
The RG client MUST pass the contents of the received Container option The RG client MUST pass the contents of the received Container option
to the RG server without alteration. The details of the to the RG server without alteration. The details of the
implementation through which the RG client parses the content 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 Container option and passes the options to the RG server are out of
scope for this document and left unspecified. scope for this document and left unspecified.
5.5. RG server behavior 5.5. RG server behavior
The RG server MUST discard any options related to IP address The RG server MUST discard any options related to IP address
assignment, IPv6 prefix delegation or operation of the DHCP protocol assignment, IPv6 prefix delegation or operation of the DHCP protocol
itself. Appendices TBD give a list of DHCPv4 and DHCPv6 options that itself.
the RG server MUST discard.
The Container option provides a mechanism through which the SP might The Container option provides a mechanism through which the SP might
be able to unilaterally control the configuration settings passed be able to unilaterally control the configuration settings passed
from a CPE DHCP server to a CPE device. This configuration channel 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 must be handled with some care if the subscriber is to retain desired
control over the CPE configurations. The following behaviors limit control over the CPE configurations. The following behaviors limit
the degree to which the SP con control CPE configuration: the degree to which the SP con control CPE configuration:
o The RG server MAY discard any undesired options, as determined by o The RG server MAY discard any undesired options, as determined by
policy in the RG. policy in the RG.
skipping to change at page 7, line 21 skipping to change at page 7, line 16
Authentication of DHCP messages(RFC 3118 [RFC3118] for DHCPv4 or Authentication of DHCP messages(RFC 3118 [RFC3118] for DHCPv4 or
section 20 of RFC 3315 [RFC3315]) can be used to ensure that the section 20 of RFC 3315 [RFC3315]) can be used to ensure that the
contents of this option are not altered in transit between the DHCP contents of this option are not altered in transit between the DHCP
server and client. server and client.
7. IANA Considerations 7. IANA Considerations
When this document is published, IANA is asked to assign an option When this document is published, IANA is asked to assign an option
tag from the "BOOTP Vendor Extensions and DHCP Options" registry for tag from the "BOOTP Vendor Extensions and DHCP Options" registry for
OPTION_CONTAINER_V4. OPTION_CONTAINER_V4 (TBDv4).
When this document is published, IANA is asked to assign an option When this document is published, IANA is asked to assign an option
code from the "DHCPv6 Option Codes" registry for OPTION_CONTAINER_V6. code from the "DHCPv6 Option Codes" registry for OPTION_CONTAINER_V6
(TBDv6).
8. Change Log 8. Change Log
If this document is accepted for publication as an RFC, this change If this document is accepted for publication as an RFC, this change
log is to be removed before publication. log is to be removed before publication.
8.1. Revision -02
o Corrected a cut-and-paste error in section "DHCPv6 Container o Corrected a cut-and-paste error in section "DHCPv6 Container
option": The Time Protocol Servers option -> The DHCPv4 Container option": The Time Protocol Servers option -> The DHCPv4 Container
option option
o Added text to section "RG Server Behavior" to address policy o Added text to section "RG Server Behavior" to address policy
management concerns management concerns
8.2. Revision -03
Corrected several typos (thanks to Alfred Hoenes for his review).
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
 End of changes. 27 change blocks. 
28 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/