draft-ietf-dhc-server-override-02.txt		draft-ietf-dhc-server-override-03.txt
	Network Working Group R. Johnson		Network Working Group R. Johnson
	Internet-Draft J. Jumarasamy		Internet-Draft J. Jumarasamy
	Expires: December 31, 2005 K. Kinnear		Expires: April 24, 2006 K. Kinnear
	M. Stapp		M. Stapp
	Cisco Systems, Inc.		Cisco Systems, Inc.
	June 29, 2005		October 21, 2005
	DHCP Server-ID Override Suboption		DHCP Server Identifier Override Suboption
	draft-ietf-dhc-server-override-02.txt		draft-ietf-dhc-server-override-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 36		skipping to change at page 1, line 36
	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 December 31, 2005.		This Internet-Draft will expire on April 24, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This memo defines a new suboption of the DHCP relay information		This memo defines a new suboption of the DHCP relay information
	option [6] which allows the DHCP relay to specify a new value for the		option which allows the DHCP relay to specify a new value for the
	Server-ID option, which is inserted by the DHCP Server. In some		Server Identifier option, which is inserted by the DHCP Server. This
	cases it is convenient for the DHCP relay to act as the actual DHCP		allows the DHCP relay to act as the actual DHCP server such that
	server such that DHCP RENEWAL requests will come to the relay instead		RENEW DHCPREQUESTs will come to the relay instead of going to the
	of going to the server directly. This gives the relay the		server directly. This gives the relay the opportunity to include the
	opportunity to include the Relay Agent option with appropriate		Relay Agent option with appropriate suboptions even on DHCP RENEW
	suboptions even on RENEWAL messages.		messages.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Server-ID Override Suboption Definition . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 5		3. Server Identifier Override Suboption Definition . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . 6
	5. Intellectual Property Rights and Copyright . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Intellectual Property Rights and Copyright . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
			Intellectual Property and Copyright Statements . . . . . . . 10
	1. Introduction		1. Introduction
	There are many situations where the DHCP relay is involved and can		There are many situations where the DHCP relay is involved and can
	insert a relay agent option with appropriate suboptions easily into		insert a relay agent option with appropriate suboptions easily into
	DHCP DISCOVER messages. Once the lease has been granted, however,		DHCP DISCOVER messages. Once the lease has been granted, however,
	future DHCP RENEWAL messages are sent directly to the DHCP Server as		future DHCP RENEWAL messages are sent directly to the DHCP Server as
	specified in the Server-ID option. This means that the relay may not		specified in the Server Identifier option. This means that the relay
	see the DHCP RENEWAL messages (depending upon network topology) and		may not see the DHCP RENEWAL messages (depending upon network
	thus can not provide the same relay agent option information in the		topology) and thus can not provide the same relay agent option
	RENEWAL messages.		information in the RENEWAL messages.
	This new DHCP relay agent suboption, Server-ID override, allows the		This new DHCP relay agent suboption, Server Identifier override,
	relay to tell the DHCP server what value to place into the Server-ID		allows the relay to tell the DHCP server what value to place into the
	option. Using this, the relay agent can force RENEWAL messages to		Server Identifier option. Using this, the relay agent can force
	come to it instead of the server. The relay may then insert the		RENEWAL messages to come to it instead of the server. The relay may
	relay agent option with appropriate suboptions and relay the request		then insert the relay agent option with appropriate suboptions and
	to the actual server. In this fashion the DHCP server will be		relay the DHCPREQUEST to the actual server. In this fashion the DHCP
	provided with the same relay agent information upon renewals (such as		server will be provided with the same relay agent information upon
	Circuit-ID, Remote-ID, Device Class, etc.) as was provided in the		renewals (such as Circuit-ID, Remote-ID, Device Class, etc.) as was
	initial DISCOVER message. In effect, this makes a RENEWAL into a		provided in the initial DISCOVER message. In effect, this makes a
	REBINDING.		RENEWAL into a REBINDING.
	This new suboption could also be used by the DHCP relay in order to		This new suboption could also be used by the DHCP relay in order to
	allow the relay to appear as the actual DHCP server to the client.		allow the relay to appear as the actual DHCP server to the client.
	This has the advantage that the relay can more easily keep up-to-date		This has the advantage that the relay can more easily keep up-to-date
	information about leases granted, etc.		information about leases granted, etc.
	In short, this new suboption allows the DHCPv4 relay to function in		In short, this new suboption allows the DHCPv4 relay to function in
	the same fashion as the DHCPv6 relay currently does.		the same fashion as the DHCPv6 relay currently does.
	2. Server-ID Override Suboption Definition		2. Conventions
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [1].
			3. Server Identifier Override Suboption Definition
	The format of the suboption is:		The format of the suboption is:
	Code Len Overriding Server-ID address		Code Len Overriding Server Identifier address
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	| TBD | n | a1 | a2 | a3 | a4 |		| TBD | n | a1 | a2 | a3 | a4 |
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	Figure 1		Figure 1
	The option length (n) is 4. The octets "a1" through "a4" specify the		The option length (n) is 4. The octets "a1" through "a4" specify the
	value which SHOULD be inserted into the Server-ID option by the DHCP		value which MUST be inserted into the Server Identifier option by the
	Server upon reply.		DHCP Server upon reply.
	DHCP Servers SHOULD use this value, if present, as the value to		DHCP Servers which implement this Relay Suboption MUST use this
	insert into the Server-ID option whenever responding to a DHCP		value, if present, as the value to insert into the Server Identifier
	Client.		option whenever responding to a DHCP Client.
			If a DHCP Server does not understand/implement this Relay Suboption,
			it will ignore the Suboption, and thus will insert it's own
			appropriate interface address as the Server Identifier address. In
			this case, the DHCP Relay will not receive RENEW DHCPREQUEST packets
			from the client. When configuring a DHCP Relay to use this
			Suboption, the administrator of the Relay should take into account
			whether or not the DHCP Server to which the packet will be relayed
			will correctly understand this Suboption.
	When servicing a DHCP REQUEST packet the DHCP Server would normally		When servicing a DHCP REQUEST packet the DHCP Server would normally
	look at the Server-ID option for verification that the address		look at the Server Identifier option for verification that the
	specified there is one of the addresses associated with the DHCP		address specified there is one of the addresses associated with the
	Server, silently ignoring the REQUEST if it does not match a		DHCP Server, silently ignoring the DHCPREQUEST if it does not match a
	configured DHCP Server interface address. If the REQUEST packet		configured DHCP Server interface address. If the DHCPREQUEST packet
	contains a Server-ID Override Suboption, however, comparison should		contains a Server Identifier Override Suboption, however, comparison
	be made between this suboption and the Server-ID option. If both of		should be made between this suboption and the Server Identifier
	the Server-ID Override Suboption and the Server-ID Option specify the		option. If both of the Server Identifier Override Suboption and the
	same address, then the Server should accept the REQUEST packet for		Server Identifier Option specify the same address, then the Server
	processing, regardless of whether or not the Server-ID Option matchs		should accept the DHCPREQUEST packet for processing, regardless of
	a DHCP Server interface.		whether or not the Server Identifier Option matchs a DHCP Server
			interface.
	3. Security Considerations		The DHCP Relay should fill in the giaddr field when relaying the
			packet just as it normally would do.
			4. Security Considerations
	Message authentication in DHCP for intradomain use where the out-of-		Message authentication in DHCP for intradomain use where the out-of-
	band exchange of a shared secret is feasible is defined in [3].		band exchange of a shared secret is feasible is defined in [3].
	Potential exposures to attack are discussed in section 7 of the DHCP		Potential exposures to attack are discussed in section 7 of the DHCP
	protocol specification in [2].		protocol specification in [2].
	The DHCP Relay Agent option depends on a trusted relationship between		The DHCP Relay Agent option depends on a trusted relationship between
	the DHCP relay agent and the server, as described in section 5 of RFC		the DHCP relay agent and the server, as described in section 5 of RFC
	3046. While the introduction of fraudulent relay-agent options can		3046. While the introduction of fraudulent relay-agent options can
	be prevented by a perimeter defense that blocks these options unless		be prevented by a perimeter defense that blocks these options unless
	the relay agent is trusted, a deeper defense using the authentication		the relay agent is trusted, a deeper defense using the authentication
	option for relay agent options [4] SHOULD be deployed as well.		option for relay agent options [4] SHOULD be deployed as well.
	If a rogue DHCP relay were inserted between the client and the		If a rogue DHCP relay were inserted between the client and the
	server, it could redirect clients to it using this suboption. This		server, it could redirect clients to it using this suboption. This
	would allow such a system to later deny renew requests and thus force		would allow such a system to later deny RENEW DHCPREQUEST and thus
	clients to discontinue use of their allocated address. This		force clients to discontinue use of their allocated address. This
	interception, however, would need to be done during the initial		interception, however, would need to be done during the initial
	DISCOVER and OFFER phase, since the suboption value SHOULD be ignored		DISCOVER and OFFER phase, since the suboption value SHOULD be ignored
	by the server during RENEWAL state. Either DHCP Authentication [3]		by the server during RENEWAL state. Either DHCP Authentication [3]
	or DHCP Relay Agent option authentication [4] would address this		or DHCP Relay Agent option authentication [4] would address this
	case.		case.
	4. IANA Considerations		5. IANA Considerations
	None.		IANA is requested to assign a suboption number for the Server
			Identifier Override Suboption from the DHCP Relay Agent Information
			Option [3] suboption number space. None.
	5. Intellectual Property Rights and Copyright		6. Intellectual Property Rights and Copyright
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights.		rights.
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights."		except as set forth therein, the authors retain all their rights."
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	6. References		7. References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, BCP 14, March 1997.		Levels", RFC 2119, BCP 14, March 1997.
	[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[3] Droms, R., "Authentication for DHCP Messages", RFC 3118,		[3] Droms, R., "Authentication for DHCP Messages", RFC 3118,
	June 2001.		June 2001.
	[4] Stapp, M., "The Authentication Suboption for the DHCP Relay		[4] Stapp, M., "The Authentication Suboption for the DHCP Relay
	Agent Option", RFC 4030, March 2005.		Agent Option", RFC 4030, March 2005.
	[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", RFC 2434, October 1998.		Considerations Section in RFCs", RFC 2434, October 1998.
	[6] Patrick, M., "DHCP Relay Agent Information Option", RFC 3096,		[6] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
	November 2004.		November 2004.
	Authors' Addresses		Authors' Addresses
	Richard A. Johnson		Richard A. Johnson
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134		San Jose, CA 95134
	US		US
End of changes. 20 change blocks.
	59 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/