draft-ietf-dhc-3315id-for-v4-03.txt   draft-ietf-dhc-3315id-for-v4-04.txt 
DHC Working Group Ted Lemon DHC Working Group Ted Lemon
INTERNET DRAFT Nominum INTERNET DRAFT Nominum
Expires: January 2005 Bill Sommerfeld Expires: July 2005 Bill Sommerfeld
Internet Draft Sun Microsystems Internet Draft Sun Microsystems
Document: <draft-ietf-dhc-3315id-for-v4-03.txt> Document: <draft-ietf-dhc-3315id-for-v4-04.txt>
Category: Standards Track July, 2004 Category: Standards Track February, 2005
Node-Specific Client Identifiers for DHCPv4 Node-Specific Client Identifiers for DHCPv4
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
- They must be persistent, in the sense that a particular host's - They must be persistent, in the sense that a particular host's
client identifier must not change simply because a piece of client identifier must not change simply because a piece of
network hardware is added or removed. network hardware is added or removed.
- It must be possible for the client to represent itself as having - It must be possible for the client to represent itself as having
more than one network identity - for example so that a client more than one network identity - for example so that a client
with two network interfaces can express to the DHCPv4 server that with two network interfaces can express to the DHCPv4 server that
these two network interfaces are to receive different IP these two network interfaces are to receive different IP
addresses, even if they happen to be connected to the same link. addresses, even if they happen to be connected to the same link.
- It must be possible, in cases where the DHCPv4 client is - In cases where the DHCPv4 client is expressing more than one
expressing more than one network identity at the same time, it network identity at the same time, it must nevertheless be
must nevertheless be possible for the DHCPv4 server to determine possible for the DHCPv4 server to determine that the two network
that the two network identities belong to the same host. identities belong to the same host.
- It must be possible for a client that is prepared to handle the - It must be possible for a client that is prepared to handle the
case where two or more network interfaces have the same IP case where two or more network interfaces have the same IP
address to use exactly the same identifier for each interface. address to use exactly the same identifier for each interface.
- DHCPv4 servers that do not conform to this specification, but that - DHCPv4 servers that do not conform to this specification, but that
are compliant with the older client identifier specification, are compliant with the older client identifier specification,
must correctly handle client identifiers sent by clients that must correctly handle client identifiers sent by clients that
conform to this specification. conform to this specification.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
option, and not rely on 'chaddr' for identification. DHCPv4 option, and not rely on 'chaddr' for identification. DHCPv4
servers MUST use 'chaddr' as an identifier in cases where 'client servers MUST use 'chaddr' as an identifier in cases where 'client
identifier' is not sent, in order to support old clients that do identifier' is not sent, in order to support old clients that do
not conform with this document. not conform with this document.
4.4. Changes from RFC2132 4.4. Changes from RFC2132
The text in section 9.14, beginning with "The client identifier MAY The text in section 9.14, beginning with "The client identifier MAY
consist of" through "that meet this requirement for uniqueness." is consist of" through "that meet this requirement for uniqueness." is
replaced with "the client identifier consists of a type field whose replaced with "the client identifier consists of a type field whose
value is normally 255, followed by a two-byte type field, followed value is normally 255, followed by a four-byte IA_ID field, followed
by the contents of the identifier. The two-byte type field and the by the DUID for the client as defined in RF3315, section 9." The
format of the contents of the identifier are defined in RF3315, text "its minimum length is 2" in the following paragraph is deleted.
section 9." The text "its minimum length is 2" in the following
paragraph is deleted.
5. Security Considerations 5. Security Considerations
This document raises no new security issues. Potential exposure to This document raises no new security issues. Potential exposure to
attack in the DHCPv4 protocol are discussed in section 7 of the attack in the DHCPv4 protocol are discussed in section 7 of the
DHCP protocol specification [RFC2131] and in Authentication for DHCP protocol specification [RFC2131] and in Authentication for
DHCP messages [RFC3118]. Potential exposure to attack in the DHCP messages [RFC3118]. Potential exposure to attack in the
DHCPv6 protocol is discussed in section 23 of RFC3315. DHCPv6 protocol is discussed in section 23 of RFC3315.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 8, line 38 skipping to change at page 8, line 38
Bill Sommerfeld Bill Sommerfeld
Sun Microsystems Sun Microsystems
1 Network Drive 1 Network Drive
Burlington, MA 01824 Burlington, MA 01824
+1 781 442 3458 +1 781 442 3458
sommerfeld@sun.com sommerfeld@sun.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003-2004). This document is Copyright (C) The Internet Society (2003-2005). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/