draft-ietf-dhc-subnet-option-01.txt		draft-ietf-dhc-subnet-option-02.txt
	Network Working Group G. Waters		Network Working Group G. Waters
	INTERNET-DRAFT Nortel Networks		INTERNET-DRAFT Nortel Networks
	March 1999		June 1999
	The Subnet Selection Option for DHCP		The Subnet Selection Option for DHCP
	<draft-ietf-dhc-subnet-option-01.txt>		<draft-ietf-dhc-subnet-option-02.txt>
	Tuesday, March 23, 1999, 4:35 PM
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net (US East Coast), nic.nordu.net		Directories on ds.internic.net (US East Coast), nic.nordu.net
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).		(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (1999). All Rights Reserved.
	Abstract		Abstract
	This memo defines a new DHCP option for selecting the subnet on which		This memo defines a new DHCP option for selecting the subnet on which
	to allocate an address. This option would override a DHCP server's		to allocate an address. This option would override a DHCP server's
	normal methods of selecting which subnet on which to allocate an		normal methods of selecting the subnet on which to allocate an address
	address for a client.		for a client.
			Waters Expires: Jun 1999 + 6 months [Page 1]
	Table of Contents		Table of Contents
	1. Introduction......................................................2		1. Introduction......................................................2
	2. Subnet Selection Option...........................................3		2. Subnet Selection Option...........................................3
	3. Intellectual Property.............................................4		3. Intellectual Property.............................................4
	4. Acknowledgements..................................................4		4. Acknowledgements..................................................4
	5. Security Considerations...........................................4		5. Security Considerations...........................................4
	6. References........................................................4		6. References........................................................5
	7. Editor's Addresses................................................5		7. Editor's Addresses................................................5
	8. Full Copyright Statement..........................................5		8. Full Copyright Statement..........................................5
	1. Introduction		1. Introduction
	This memo was produced by the DHCP Working Group and defines a new		This memo was produced by the DHCP Working Group and defines a new
	DHCP option that specifies the subnet on which a DHCP server should		DHCP option that specifies the subnet that a DHCP server should use
	use when selecting an address. This option takes precedence over		when selecting an address. This option takes precedence over other
	other methods that the DHCP server may use to determine the subnet on		methods that the DHCP server may use to determine the subnet on which
	which to select an address. Two existing methods of determining the		to select an address. Two existing methods of determining the subnet
	subnet on which to select an address are:		on which to select an address are:
	o To use the subnet address of the giaddr field in the DHCP packet,		o To use the subnet address of the giaddr field in the DHCP packet,
	or if the giaddr field is zero;		or if the giaddr field is zero;
	o To use the subnet address of the local interface on which the		o To use the subnet address of the local interface on which the
	packet was received by the DHCP server.		packet was received by the DHCP server.
	Methods other than the two described above may exist.		Methods other than the two described above may exist.
	The subnet selection option is useful, but not limited to, the class		The subnet selection option is useful for, but not limited to, the
	of devices that have a packet-handling plane (e.g.: switching, routing		class of devices that have a packet-handling plane (e.g.: switching,
	functionality) and a control plane (e.g.: device management and		routing functionality) and a control plane (e.g.: device management
	control functionality). The control plane is network connected and		and control functionality). The control plane is network connected and
	there is a DHCP server connected to that network. The packet-handling		there is a DHCP server connected to that network. The packet-handling
	plane may or may not be network connected, however, in either case		plane may or may not be network connected, however, in either case
	there is no network connected DHCP server available to this plane. The		there is no network connected DHCP server available to this plane. The
	control plane is not network connected to the packet-handling plane,		control plane is not network connected to the packet-handling plane,
	although the two planes may communicate using some method (e.g.: an		although the two planes may communicate using some method (e.g.: an
	internal data bus).		internal data bus).
	For the networks to which the packet-handling plane is connected,		There is a requirement to allocate addresses for devices connected to
	there is a requirement to allocate addresses for devices connected to		the networks to which the packet-handling plane is connected.
	those networks.
	Since there is no network connectivity between the DHCP server and the		Since there is no network connectivity between the DHCP server and the
	packet-handling plane, the control plane must allocate addresses using		packet-handling plane, the control plane must allocate addresses using
	the DHCP on behalf of the packet-handling plane. Because the control		the DHCP on behalf of the packet-handling plane. Since the control
	plane is requesting the addresses, the DHCP server would normally have		plane is requesting the address, the DHCP server would normally
	the undesired result of allocating the address on the subnet on which
	the control plane is connected.		Waters Expires: Jun 1999 + 6 months [Page 2]
			allocate the address on the subnet on which the control plane is
			connected, which would not be the desired result.
	If the option specified by this memo is included in the		If the option specified by this memo is included in the
	DHCPDISCOVER/DHCPREQUEST message then the server should allocate an		DHCPDISCOVER/DHCPREQUEST message then the server should allocate an
	address on the subnet or network segment that is specified by this		address on the subnet or network segment that is specified by this
	option. The option would specify an address of one of the packet-		option. The option would specify an address on one of the packet-
	handling plane's subnets.		handling plane's subnets.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Subnet Selection Option		2. Subnet Selection Option
	The subnet selection option is a DHCP option. The option contains a		The subnet selection option is a DHCP option. The option contains a
	single IP address that is the address of a subnet. The value for the		single IP address that is the address of a subnet. The value for the
	subnet address is determined by taking any IP address on the subnet		subnet address is determined by taking any IP address on the subnet
	and ANDing that address with the subnet mask (i.e.: the network and		and ANDing that address with the subnet mask (i.e.: the network and
	subnet bits are left alone and the remaining (address) bits are set to		subnet bits are left alone and the remaining (address) bits are set to
	zero). When this option is present, the DHCP server MUST use either		zero). When this option is present, the DHCP server MUST use either:
	the:
	o The subnet specified in the option, or;		o The subnet specified in the option, or;
	o A subnet on the same network segment as the subnet specified in the		o A subnet on the same network segment as the subnet specified in the
	option;		option;
	on which to allocate an address.		on which to allocate an address.
	The format of the option is:		The format of the option is:
	Code Len IP Address		Code Len IP Address
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	| TBD | 4 | A1 | A2 | A3 | A4 |		| TBD | 4 | A1 | A2 | A3 | A4 |
	skipping to change at page 3, line 40		skipping to change at line 132
	The format of the option is:		The format of the option is:
	Code Len IP Address		Code Len IP Address
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	| TBD | 4 | A1 | A2 | A3 | A4 |		| TBD | 4 | A1 | A2 | A3 | A4 |
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	In order to ensure backwards compatibility of clients that do support		In order to ensure backwards compatibility of clients that do support
	this option when communicating with DHCP servers that do not support		this option when communicating with DHCP servers that do not support
	this option, the DHCP client SHOULD check that an allocated address in		this option, the DHCP client SHOULD check that an allocated address is
	on the requested subnet or network segment. The client SHOULD NOT		on the requested subnet or network segment. The client SHOULD NOT
	respond to a DHCPOFFER or DHCPACK of an address that is not on the		respond to a DHCPOFFER or DHCPACK of an address that is not on the
	requested subnet or network segment.		requested subnet or network segment.
	This option does not require any change to other operations or		Servers supporting this option MUST return the option to any client
	features of the DHCP server other than to select the subnet on which		that sends it, regardless of whether or not the client requests it in
	to allocate an address. For example, the handling of DHCPDISCOVER for		a parameter request list. Clients using this option must discard
	an unknown subnet may continue to operate unchanged.		DHCPOFFER or DHCPACK packets that do not contain this option.
			Waters Expires: Jun 1999 + 6 months [Page 3]
			This option does not require changes to operations or features of the
			DHCP server other than to select the subnet on which to allocate an
			address. For example, the handling of DHCPDISCOVER for an unknown
			subnet may continue to operate unchanged.
	When this option is present and the server supports this option, the		When this option is present and the server supports this option, the
	server MUST NOT offer an address that is not on the requested subnet		server MUST NOT offer an address that is not on the requested subnet
	or network segment.		or network segment.
	Existing methods for determining where to send a reply to a DHCP		The IP address to which a DHCP server sends a reply to MUST be the
	client are not changed when this option is present in a request.		same as it would chose when this option is not present.
	3. Intellectual Property		3. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to pertain		intellectual property or other rights that might be claimed to pertain
	to the implementation or use of the technology described in this		to the implementation or use of the technology described in this
	document or the extent to which any license under such rights might or		document or the extent to which any license under such rights might or
	might not be available; neither does it represent that it has made any		might not be available; neither does it represent that it has made any
	effort to identify any such rights. Information on the IETF's		effort to identify any such rights. Information on the IETF's
	procedures with respect to rights in standards-track and standards-		procedures with respect to rights in standards-track and standards-
	skipping to change at page 4, line 34		skipping to change at line 181
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	4. Acknowledgements		4. Acknowledgements
	This document is the result of work undertaken the by DHCP working		This document is the result of work undertaken the by DHCP working
	group. Thanks to Tim Aston and Ralph Droms for reviewing this memo.		group. Thanks to Ted Lemon, Tim Aston and Ralph Droms for their
			helpful comments in this work.
	5. Security Considerations		5. Security Considerations
	DHCP currently provides no authentication or security mechanisms.		DHCP currently provides no authentication or security mechanisms.
	Potential exposures to attack are discussed is section 7 of the		Potential exposures to attack are discussed is section 7 of the
	protocol specification [RFC2131].		protocol specification [RFC2131].
			Waters Expires: Jun 1999 + 6 months [Page 4]
	6. References		6. 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", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, March 1997.		Extensions", RFC 2132, March 1997.
	skipping to change at line 225		skipping to change at line 239
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN		NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
	WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Waters Expires: Jun 1999 + 6 months [Page 5]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/