draft-ietf-dhc-server-override-00.txt		draft-ietf-dhc-server-override-01.txt
	Internet Engineering Task Force Richard Johnson		Internet Engineering Task Force Richard Johnson
	Internet Draft Kim Kinnear		Internet Draft Kim Kinnear
	Expiration: August 2003 Mark Stapp		Expiration: March 2005 Mark Stapp
	File: draft-ietf-dhc-server-override-00.txt Jay Kumarasamy		File: draft-ietf-dhc-server-override-01.txt Jay Kumarasamy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	DHCP Server-ID Override Suboption		DHCP Server-ID Override Suboption
	<draft-ietf-dhc-server-override-00.txt>		<draft-ietf-dhc-server-override-01.txt>
	February 5, 2003		September 27, 2004
	Status of this Memo		Status of this Memo
			By submitting this Internet-Draft, I certify that any applicable
			patent or other IPR claims of which I am aware have been disclosed,
			or will be disclosed, and any of which I become aware will be
			disclosed, in accordance with RFC 3668.
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		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
	skipping to change at page 3, line 12		skipping to change at page 3, line 18
	Code Len Overridden Server-ID address		Code Len Overridden Server-ID address
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	| TBD | n | a1 | a2 | a3 | a4 |		| TBD | n | a1 | a2 | a3 | a4 |
	+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+
	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 SHOULD be inserted into the Server-ID option by the DHCP
	Server upon reply.		Server upon reply.
	DHCP Servers SHOULD use this value as the value to insert into the		DHCP Servers SHOULD use this value, if present, as the value to
	Server-ID option ONLY when the protocol is in the SELECTING and		insert into the Server-ID option whenever responding to a DHCP
	REQUESTING and REBINDING states. If this suboption appears in a DHCP		Client.
	request which is part of a lease RENEWAL, it SHOULD be ignored.
			When servicing a DHCP REQUEST packet the DHCP Server would normally
			look at the Server-ID option for verification that the address
			specified there is one of the addresses associated with the DHCP
			Server, silently ignoring the REQUEST if it does not match a
			configured DHCP Server interface address. If the REQUEST packet
			contains a Server-ID Override Suboption, however, comparison should
			be made between this suboption and the Server-ID option. If both of
			the Server-ID Override Suboption and the Server-ID Option specify the
			same address, then the Server should accept the REQUEST packet for
			processing, regardless of whether or not the Server-ID Option matchs
			a DHCP Server interface.
	3.0 IANA Considerations		3.0 IANA Considerations
	None.		None.
	4.0 Acknowledgements		4.0 Acknowledgements
	This document is the result of work done within Cisco Systems.		This document is the result of work done within Cisco Systems.
	Thanks to Jay Kumarasamy, Kim Kinnear, and Mark Stapp for their work		Thanks to Jay Kumarasamy, Kim Kinnear, and Mark Stapp for their work
	on this suboption definition and the other related work for which		on this suboption definition and the other related work for which
	skipping to change at page 3, line 42		skipping to change at page 4, line 12
	[5]. Potential exposures to attack are discussed in section 7 of the		[5]. Potential exposures to attack are discussed in section 7 of the
	DHCP protocol specification in RFC 2131 [2].		DHCP protocol specification in RFC 2131 [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 rouge 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 requests and thus force
	clients to discontinue use of their allocated address. This		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 [5]		by the server during RENEWAL state. Either DHCP Authentication [5]
	or DHCP Relay Agent option authentication [4] would address this		or DHCP Relay Agent option authentication [4] would address this
	case.		case.
			6.0 Intellectual Property Rights and Copyright
			The IETF has been notified of intellectual property rights claimed in
			regard to some or all of the specification contained in this
			document. For more information consult the online list of claimed
			rights.
			Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights."
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	References		References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] 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.
	[2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,		[2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[3] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor		[3] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/