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/