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/