draft-ietf-dhc-container-opt-03.txt   draft-ietf-dhc-container-opt-04.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 17, 2008 Intended status: Standards Track November 28, 2008
Expires: May 21, 2009 Expires: June 1, 2009
Container Option for Server Configuration Container Option for Server Configuration
draft-ietf-dhc-container-opt-03.txt draft-ietf-dhc-container-opt-04.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 21, 2009. This Internet-Draft will expire on June 1, 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement and requirements for RG DHCP server
configuration . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Design alternatives . . . . . . . . . . . . . . . . . . . . . 5
5. Semantics and syntax of the Container option . . . . . . . . . 6
5.1. DHCPv4 Container option . . . . . . . . . . . . . . . . . 6
5.2. DHCPv6 Container option . . . . . . . . . . . . . . . . . 6
5.3. SP server behavior . . . . . . . . . . . . . . . . . . . . 7
5.4. RG client behavior . . . . . . . . . . . . . . . . . . . . 7
5.5. RG server behavior . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Revision -03 . . . . . . . . . . . . . . . . . . . . . . . 9
8.3. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 9
9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
In some DHCP service deployments, it is desirable to pass In some DHCP service deployments, it is desirable to pass
configuration options from a DHCP server in one administrative domain configuration options from a DHCP server in one administrative domain
to another DHCP server in a different administrative domain. In one to another DHCP server in a different administrative domain. In one
example of such a deployment, an IPTV service provider (SP) may need example of such a deployment, an IPTV service provider (SP) may need
to provide certain SP domain-specific information to IPTV device(s) to provide certain SP domain-specific information to IPTV device(s)
located in the consumer domain. This information is sent from the located in the consumer domain. This information is sent from the
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
skipping to change at page 3, line 28 skipping to change at page 4, line 31
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.
3. Problem statement and requirements for RG DHCP server configuration 3. Problem statement and requirements for RG DHCP server configuration
The following diagram shows the components in a network deployment The following diagram shows the components in a network deployment
using the DHCP Container option: using the DHCP Container option:
Client STB/CPE -+ +---------+ +------+ Client host -+ +---------+ +------+
| | RG | | SP | | | RG | | SP |
Client STB/CPE -+ | Client+--- ... ---+ DHCP | Client host -+ | Client+--- ... ---+ DHCP |
+--+Server | |server| +--+Server | |server|
Client STB/CPE -+ +---------+ +------+ Client host -+ +---------+ +------+
In this diagram, the RG client engages in DHCP message exchanges with In this diagram, the RG client engages in DHCP message exchanges with
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 hosts, such as
to the consumer network. The problem solution has the following computers and set-top boxes, attached to the consumer network. The
requirements: problem solution has the following 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.
skipping to change at page 6, line 34 skipping to change at page 7, line 46
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. itself.
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 RG DHCP server to a host in the subscriber network. This
must be handled with some care if the subscriber is to retain desired configuration channel must be handled with some care if the
control over the CPE configurations. The following behaviors limit subscriber is to retain desired control over the host configurations.
the degree to which the SP con control CPE configuration: The following behaviors limit the degree to which the SP can control
host 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.
o The RG server MUST return to any DHCP client only those options o The RG server MUST return to any DHCP client only those options
requested by the DHCP client in a Parameter Request List option requested by the DHCP client in a Parameter Request List option
(DHCPv4 option code 55) or an Option Request option (DHCPv6 option (DHCPv4 option code 55) or an Option Request option (DHCPv6 option
code 6). code 6).
6. Security Considerations 6. Security Considerations
A rogue server can use this option to pass invalid information to the 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 RG client, which would then be passed to the Client hosts. This
invalid information could be used to mount a denial of service attack invalid information could be used to mount a denial of service attack
or a man-in-the-middle attack against some applications. or a man-in-the-middle attack against some applications.
Authentication of DHCP messages(RFC 3118 [RFC3118] for DHCPv4 or Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of
section 20 of RFC 3315 [RFC3315]) can be used to ensure that the RFC 3315 [RFC3315]) can be used to ensure that the contents of this
contents of this option are not altered in transit between the DHCP 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 (TBDv4). 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). (TBDv6).
skipping to change at page 7, line 40 skipping to change at page 9, line 9
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 8.2. Revision -03
Corrected several typos (thanks to Alfred Hoenes for his review). Corrected several typos (thanks to Alfred Hoenes for his review).
9. Normative References 8.3. Revision -04
Corrected additional typos (again, thanks to Alfred Hoenes for his
review).
Added pointer to "CableLabs' DHCP Options Registry" as background for
this option.
9. Related Work
The Container option is based on the CableLabs eRouter DHCP Container
vendor-identifying vendor-specific option, as defined in "CableLabs'
DHCP Options Registry" [eRouter].
10. 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.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[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
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [eRouter] CableLabs, "CableLabs' DHCP Options Registry (CL-SP-CANN-
Messages", RFC 3118, June 2001. DHCP-Reg-I02-080306)", March 2008.
Author's Address Author's Address
Ralph Droms Ralph Droms
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978.936.1674 Phone: +1 978.936.1674
 End of changes. 14 change blocks. 
22 lines changed or deleted 63 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/