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/ |