draft-ietf-dhc-3315id-for-v4-00.txt   draft-ietf-dhc-3315id-for-v4-01.txt 
DHC Working Group Ted Lemon DHC Working Group Ted Lemon
INTERNET DRAFT Nominum INTERNET DRAFT Nominum
Expires: May 2004 Bill Sommerfeld Expires: July 2004 Bill Sommerfeld
Internet Draft Internet Draft Sun Microsystems
Document: <draft-ietf-dhc-3315id-for-v4-00.txt> Document: <draft-ietf-dhc-3315id-for-v4-01.txt>
Category: Standards Track October, 2003 Category: Standards Track January, 2004
Node-Specific Client Identifiers for DHCPv4 Node-Specific Client Identifiers for DHCPv4
Status of this Memo Status of this Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcwg@ietf.org mailing list. should be submitted to the dhcwg@ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
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.
Abstract Abstract
This document specifies the format that is to be used for encoding This document specifies the format that is to be used for encoding
DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those
will be interchangeable with identifiers used in the DHCPv6 protocol identifiers will be interchangeable with identifiers used in the
(RFC3315). DHCPv6 protocol [RFC3315].
Introduction Introduction
This document specifies the way in which DHCPv4 clients should This document specifies the way in which DHCPv4 clients should
identify themselves. DHCPv4 client implementations that conform to identify themselves. DHCPv4 client implementations that conform to
this specification use a DHCPv6-style DHCP Unique Identifier (DUID) this specification use a DHCPv6-style DHCP Unique Identifier (DUID)
encapsulated in a DHCPv4 client identifier option. This supersedes encapsulated in a DHCPv4 client identifier option. This supersedes
the behaviour specified in RFC2131 and RFC2132. the behaviour specified in RFC2131 and RFC2132.
The reason for making this change is that as we make the transition The reason for making this change is that as we make the transition
from IPv4 to IPv6, there will be network devices that must use both from IPv4 to IPv6, there will be network devices that must use both
DHCPv4 and DHCPv6. For reasons we will explain later, users of DHCPv4 and DHCPv6. Users of these devices will have a smoother
these devices will have a smoother network experience if the network experience if the devices identify themselves consistently,
devices identify themselves consistently, regardless of the version regardless of the version of DHCP they are using at any given
of DHCP they are using at any given moment. This change also moment. Most obviously, DNS updates made by the DHCP server on
addresses certain limitations in the functioning of behalf of the client will not be handled correctly. This change
also addresses certain limitations in the functioning of
RFC2131/2132-style DHCP client identifiers. RFC2131/2132-style DHCP client identifiers.
This document first describes the problem to be solved. It then This document first describes the problem to be solved. It then
states the new technique that is to be used to solve the problem. states the new technique that is to be used to solve the problem.
Finally, it describes the specific changes that one would have to Finally, it describes the specific changes that one would have to
make to RFC2131 and RFC2132 in order for those documents not to make to RFC2131 and RFC2132 in order for those documents not to
contradict what is described in this document. contradict what is described in this document.
1.0 Applicability 1.0 Applicability
This document updates RFC2131 and RFC2132. DHCPv4 servers This document updates RFC2131 and RFC2132. DHCPv4 servers
implementations SHOULD conform to this document. DHCPv4 clients on implementations SHOULD conform to this document. DHCPv4 clients on
network devices that are expected to support DHCPv6 in the future network devices that are expected to support DHCPv6 in the future
SHOULD conform to this document. This document makes no changes to SHOULD conform to this document. This document makes no changes to
skipping to change at page 2, line 19 skipping to change at page 2, line 24
1.0 Applicability 1.0 Applicability
This document updates RFC2131 and RFC2132. DHCPv4 servers This document updates RFC2131 and RFC2132. DHCPv4 servers
implementations SHOULD conform to this document. DHCPv4 clients on implementations SHOULD conform to this document. DHCPv4 clients on
network devices that are expected to support DHCPv6 in the future network devices that are expected to support DHCPv6 in the future
SHOULD conform to this document. This document makes no changes to SHOULD conform to this document. This document makes no changes to
the behavior of DHCPv6 clients or servers. the behavior of DHCPv6 clients or servers.
DHCPv4 clients and servers that are implemented according to this DHCPv4 clients and servers that are implemented according to this
document should be implemented as if the changes specified in document should be implemented as if the changes specified in
section ??? have been made to RFC2131 and RFC2132. section 4.3 and 4.4 have been made to RFC2131 and RFC2132.
2.0 Problem Statement 2.0 Problem Statement
2.1. Client identities are ephemeral 2.1. Client identities are ephemeral
RFC2132 recommends that client identifiers be generated by using RFC2132 recommends that client identifiers be generated by using
the permanent link-layer address of the network interface that the the permanent link-layer address of the network interface that the
client is trying to configure. In cases where a network interface client is trying to configure. In cases where a network interface
is removed from the client computer and replaced with a different is removed from the client computer and replaced with a different
network interface with a different permanent link-layer address, network interface with a different permanent link-layer address,
the identity of the client changes. The client loses its IP the identity of the client changes. The client loses its IP
address and any other resources associated with its old identifier address and any other resources associated with its old identifier
- for example, its domain name as published through the DHCP - for example, its domain name as published through the DHCP
server. server.
2.2. Clients can accidentally present multiple identities 2.2. Clients can accidentally present multiple identities
Consider a DHCP client that has two network interfaces connected to Consider a DHCP client that has two network interfaces, one of
the same link, one of which is wired and one of which is which is wired and one of which is wireless. There are three
wireless. There are three interesting cases here: interesting cases here:
(a) Each network interface is attached to a different link. (a) Each network interface is attached to a different link.
(b) Both network interface are connected to the same link. (b) Both network interface are connected to the same link.
(c) Only one network interface is attached to a link. (c) Only one network interface is attached to a link.
Case (a) is problematic, and is beyond the scope of this document. Case (a) is problematic, and is beyond the scope of this document.
Even the full implications of cases (b) and (c) are beyond the Even the full implications of cases (b) and (c) are beyond the
scope of this document. However, it seems safe to point out that scope of this document. However, it seems safe to point out that
cases (b) and (c) are very common in practice, because many cases (b) and (c) are very common in practice, because many
devices such as laptop computers that are popular at the time of devices such as laptop computers that are popular at the time of
skipping to change at page 3, line 34 skipping to change at page 3, line 44
2.4. RFC2131 does not require the use of a client identifier 2.4. RFC2131 does not require the use of a client identifier
RFC2131 allows the DHCP server to identify clients either by RFC2131 allows the DHCP server to identify clients either by
using the client identifier option sent by the client, or, if the using the client identifier option sent by the client, or, if the
client did not send one, the client's link-layer address. Like client did not send one, the client's link-layer address. Like
the client identifier format recommended by RFC2131, this suffers the client identifier format recommended by RFC2131, this suffers
from the problems previously described in (2) and (3). from the problems previously described in (2) and (3).
3. Solutions 3. Solutions
The solution to problem (1) is to use a DHCP client identifier that The solution to problem (2.1) is to use a DHCP client identifier
is persistent - not tied to a particular piece of removable network that is persistent - not tied to a particular piece of removable
hardware. Then, when network hardware is swapped in and out, the network hardware. Then, when network hardware is swapped in and
client identifier does not change, and thus the client has a out, the client identifier does not change, and thus the client has
consistent IP address and consistent use of whatever resources have a consistent IP address and consistent use of whatever resources
been associated with its identifier. have been associated with its identifier.
The solution to problem (2) is the same. Although it is beyond the
scope of this document to say how a DHCP client supporting two
network interfaces in this way would provide a smooth user
experience, it does seem safe to say that it will need to use a
persistent DHCP client identifier that is the same across the
interfaces that it configures.
It is also worth noting that in case (a), it is harmless for the It is worth noting that in case (2.1), it is harmless for the
device to use the same client identifier on both interfaces - in device to use the same client identifier on both interfaces - in
this case, the DHCP server or servers serving these two links will this case, the DHCP server or servers serving these two links will
see the two network interfaces as distinct because they are see the two network interfaces as distinct because they are
connected to different links, even though they use the same connected to different links, even though they use the same
identifier. identifier.
The solution to problem (3) is to use the DHCP Unique Identifier as The solution to problem (2.2) is the same. Although it is beyond
defined in RFC3315 as a client identifier. The DUID provides the scope of this document to say how a DHCP client supporting two
network interfaces in this way would provide a smooth user
experience, it does seem safe to say that it will need to use a
persistent DHCP client identifier that is the same across the
interfaces that it configures.
In case (2.2), if both interfaces are connected to the same link,
the DHCP server will see requests sent by the client on each
interface as being from the same client, and will only allocate one
lease to that client. A DHCP client that sends the same client
identifier on two interfaces will need to be prepared for the
possibility that both interfaces will be assigned the same IP
address. It could do this either by shutting down one interface in
this case, or it could use some more complicated strategy. It is
beyond the scope of this document to describe the details of how
this should be done. Obviously, to get the benefit of this
strategy, transitions from one device to the other must go
unnoticed by the user.
The solution to problem (2.3) is to use the DHCP Unique Identifier
as defined in RFC3315 as a client identifier. The DUID provides
several different ways of producing persistent DHCP client several different ways of producing persistent DHCP client
identifiers, at least one of which is likely to be appropriate for identifiers, at least one of which is likely to be appropriate for
any particular sort of network device. So it turns out that this any particular sort of network device. So it turns out that this
also solves problems (1) and (2). also solves problems (1) and (2).
The solution to problem (4) is to deprecate the use of the contents The solution to problem (2.4) is to deprecate the use of the
of the chaddr field in the DHCP packet as a means of identifying contents of the chaddr field in the DHCP packet as a means of
the client. identifying the client.
4. Recommendations 4. Implementation Requirements
Here we specify changes to the behavior of DHCP clients and
servers. We also specify changes to the wording in RFC2131 and
RFC2132. DHCP clients, servers and relay agents that conform to
this specification must implement RFC2131 and RFC2132 with the
wording changes specified in sections 4.3 and 4.4.
4.1. DHCP Client behavior 4.1. DHCP Client behavior
DHCP clients conforming to this specification MUST use stable DHCP DHCP clients conforming to this specification MUST use stable DHCP
node identifiers in the dhcp-client-identifier option. DHCP node identifiers in the dhcp-client-identifier option. DHCP
clients MUST NOT use client identifiers based solely on layer two clients MUST NOT use client identifiers based solely on layer two
addresses that are hard-wired to the layer two device (e.g., the addresses that are hard-wired to the layer two device (e.g., the
ethernet MAC address) as suggested in RFC2131. DHCP clients MUST ethernet MAC address) as suggested in RFC2131, except as allowed in
send a 'client identifier' option containing a DHCP Unique section 9.2 of RFC3315. DHCP clients MUST send a 'client
Identifier, as defined in RFC3315. identifier' option containing a DHCP Unique Identifier, as defined
in section 9 of RFC3315.
The general format of the DHCPv4 'client identifier' option is The general format of the DHCPv4 'client identifier' option is
defined in section 9.14 of RFC2132. To send a defined in section 9.14 of RFC2132. To send a
To send a DUID in a DHCPv4 'client identifier' option, the type of To send a DUID in a DHCPv4 'client identifier' option, the type of
the 'client identifier' option should be 255. The type field is the 'client identifier' option should be 255. The type field is
immediately followed by the DUID. The format of the 'client immediately followed by the DUID. The format of the 'client
identifier' option is as follows: identifier' option is as follows:
Code Len Type DHCP Unique Identifier Code Len Type DHCP Unique Identifier
+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+---
| 61 | n | 255 | d1 | d2 | d3 | d4 | ... | 61 | n | 255 | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+---
skipping to change at page 4, line 42 skipping to change at page 5, line 22
+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+---
Any DHCPv4 or DHCPv6 client that conforms to this specification Any DHCPv4 or DHCPv6 client that conforms to this specification
SHOULD provide a means by which an operator can learn what DUID the SHOULD provide a means by which an operator can learn what DUID the
client has chosen. Such clients SHOULD also provide a means by client has chosen. Such clients SHOULD also provide a means by
which the operator can configure the DUID. A device that is which the operator can configure the DUID. A device that is
normally configured with both a DHCPv4 and DHCPv6 client SHOULD normally configured with both a DHCPv4 and DHCPv6 client SHOULD
automatically use the same DUID for DHCPv4 and DHCPv6 without any automatically use the same DUID for DHCPv4 and DHCPv6 without any
operator intervention. operator intervention.
DHCP clients that support more than one network interface SHOULD
use the same client identifier on each interface. Such DHCP
clients SHOULD be prepared for the possibility that the DHCP server
will allocate the same IP address to both interfaces.
4.2. DHCPv4 Server behavior 4.2. DHCPv4 Server behavior
This document does not require any change to DHCPv4 or DHCPv6 This document does not require any change to DHCPv4 or DHCPv6
servers that follow RFC2131 and RFC2132. However, some DHCPv4 servers that follow RFC2131 and RFC2132. However, some DHCPv4
servers can be configured not to conform to RFC2131 and RFC2131, in servers can be configured not to conform to RFC2131 and RFC2131, in
the sense that they ignore the 'client identifier' option and use the sense that they ignore the 'client identifier' option and use
the client's hardware address instead. Some DHCP servers do not the client's hardware address instead. Some DHCP servers do not
take into account the possibility that the same client identifier take into account the possibility that the same client identifier
may be used on separate links, and thus will behave incorrectly may be used on separate links, and thus will behave incorrectly
when a DHCP client acquires leases on two different IP addresses on when a DHCP client acquires leases on two different IP addresses on
two different links at the same time. two different links at the same time.
DHCP servers that conform to this specification MUST use the DHCP servers that conform to this specification MUST use the
'client identifier' option to identify the client if the client 'client identifier' option to identify the client if the client
sends it. DHCP servers MUST assume that when a lease on an IP sends it. DHCP servers MUST assume that when a lease on an IP
address is bound to a particular DHCP client identifier, all other address is bound to a particular DHCP client identifier, all other
still-valid leases on IP addresses bound to that client identifier still-valid leases on IP addresses bound to that client identifier
are still in use. are still in use.
4.3. Changes to RFC2131 DHCP servers MAY use administrator-supplied values for chaddr and
htype to identify the client in the case where the administrator is
assigning a fixed IP address to the client, even if the client
sends an client identifier option. This is ONLY permitted in the
case where the DHCP server administrator has provided the values
for chaddr and htype, because in this case if it causes a problem,
the administrator can correct the problem by removing the offending
configuration information.
4.3. Changes from RFC2131
In section 2 of RFC2131, on page 9, the text that reads "; for In section 2 of RFC2131, on page 9, the text that reads "; for
example, the 'client identifier' may contain a hardware address, example, the 'client identifier' may contain a hardware address,
identical to the contents of the 'chaddr' field, or it may contain identical to the contents of the 'chaddr' field, or it may contain
another type of identifier, such as a DNS name" is deleted. another type of identifier, such as a DNS name" is deleted.
In section 4.2 of RFC2131, the text "The client MAY choose to In section 4.2 of RFC2131, the text "The client MAY choose to
explicitly provide the identifier through the 'client identifier' explicitly provide the identifier through the 'client identifier'
option. If the client supplies a 'client identifier', the client option. If the client supplies a 'client identifier', the client
MUST use the same 'client identifier' in all subsequent messages, MUST use the same 'client identifier' in all subsequent messages,
skipping to change at page 6, line 5 skipping to change at page 6, line 53
Note that these changes do not relieve the DHCP server of the Note that these changes do not relieve the DHCP server of the
obligation to use 'chaddr' as an identifier if the client does not obligation to use 'chaddr' as an identifier if the client does not
send a 'client identifier' option. Rather, they oblige clients send a 'client identifier' option. Rather, they oblige clients
that conform with this document to send a 'client identifier' that conform with this document to send a 'client identifier'
option, and not rely on 'chaddr' for identification. DHCP servers option, and not rely on 'chaddr' for identification. DHCP servers
MUST use 'chaddr' as an identifier in cases where 'client 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 to 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 two-byte type field, followed
by the contents of the identifier. The two-byte type field and the by the contents of the identifier. The two-byte type field and the
format of the contents of the identifier are defined in RF3315, format of the contents of the identifier are defined in RF3315,
section 9." The text "its minimum length is 2" in the following section 9." The text "its minimum length is 2" in the following
paragraph is deleted. paragraph is deleted.
skipping to change at page 6, line 32 skipping to change at page 7, line 24
DHCPv6 protocol is discussed in section 23 of RFC3315. DHCPv6 protocol is discussed in section 23 of RFC3315.
6. IANA Considerations 6. IANA Considerations
This document defines no new name spaces that need to be This document defines no new name spaces that need to be
administered by the IANA. This document deprecates all 'client administered by the IANA. This document deprecates all 'client
identifier' type codes other than 255, and thus there is no need identifier' type codes other than 255, and thus there is no need
for the IANA to track possible values for the type field of the for the IANA to track possible values for the type field of the
'client identifier' option. 'client identifier' option.
7. Author's Addresses 7. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March, 1997
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, M., "Dynamic Host Configuration Protocol for
IPv6 (DHCPV6)", July, 2003
8. Informative References
[RFC3118] Droms, R., Arbaugh, W., "Authentication for DHCP
Messages", RFC3118, June, 2001
Author's Addresses
Ted Lemon Ted Lemon
Nominum Nominum
2385 Bay Road 2385 Bay Road
Redwood City, CA 94063 USA Redwood City, CA 94063 USA
+1 650 381 6000 +1 650 381 6000
mellon@nominum.com mellon@nominum.com
Bill Sommerfeld Bill Sommerfeld
Sun Microsystems
1 Network Drive
Burlington, MA 01824
+1 781 442 3458
sommerfeld@sun.com
8. Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society July 2003. All Rights Reserved. "Copyright (C) 2003, 2004 The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
skipping to change at page 7, line 15 skipping to change at page 8, line 32
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 This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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."
9. Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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