draft-ietf-dhc-3315id-for-v4-05.txt   rfc4361.txt 
DHC Working Group Ted Lemon
INTERNET DRAFT Nominum
Expires: January 2006 Bill Sommerfeld
Internet Draft Sun Microsystems
Document: <draft-ietf-dhc-3315id-for-v4-05.txt>
Updates: 2131, 2132, 3315
Category: Standards Track June, 2005
Node-Specific Client Identifiers for DHCPv4 Network Working Group T. Lemon
Request for Comments: 4361 Nominum
Status of this Memo Updates: 2131, 2132, 3315 B. Sommerfield
Category: Standards Track Sun Microsystems
By submitting this Internet-Draft, each author represents that any February 2006
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is a submission by the Dynamic Host Configuration Node-specific Client Identifiers for
Working Group of the Internet Engineering Task Force (IETF). Comments Dynamic Host Configuration Protocol Version Four (DHCPv4)
should be submitted to the dhcwg@ietf.org mailing list.
Distribution of this memo is unlimited. Status of This Memo
Internet-Drafts are working documents of the Internet Engineering This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that Internet community, and requests discussion and suggestions for
other groups may also distribute working documents as improvements. Please refer to the current edition of the "Internet
Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six Copyright Notice
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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 client identifiers, so that those identifiers will be inter- Dynamic Host Configuration Protocol Version Four (DHCPv4) client
changeable with identifiers used in the DHCPv6 protocol. This identifiers, so that those identifiers will be interchangeable with
document also addresses and corrects some problems in RFC2131 and identifiers used in the DHCPv6 protocol. This document also
RFC2132 with respect to the handling of DHCP client identifiers. addresses and corrects some problems in RFC 2131 and RFC 2132 with
respect to the handling of DHCP client identifiers.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Applicability ...................................................2
4. Problem Statement ...............................................3
4.1. Client identities are ephemeral. ...........................3
4.2. Clients can accidentally present multiple identities. ......3
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
4.4. RFC 2131 does not require the use of a client identifier. ..4
5. Requirements ....................................................4
6. Implementation ..................................................6
6.1. DHCPv4 Client Behavior .....................................6
6.2. DHCPv6 Client Behavior .....................................7
6.3. DHCPv4 Server Behavior .....................................7
6.4. Changes from RFC 2131 ......................................8
6.5. Changes from RFC 2132 ......................................9
7. Notes on DHCP Clients in Multi-stage Network Booting ............9
8. Security Considerations ........................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
1. Introduction 1. Introduction
This document specifies the way in which DHCPv4 [RFC2131] clients This document specifies the way in which Dynamic Host Configuration
should identify themselves. DHCPv4 client implementations that Protocol Version 4 [RFC2131] clients should identify themselves.
conform to this specification use a DHCPv6-style DHCP Unique DHCPv4 client implementations that conform to this specification use
Identifier (DUID) [RFC3315] encapsulated in a DHCPv4 client a DHCP Unique Identifier (DUID) as specified in Dynamic Host
identifier option. This supersedes the behavior specified in Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. The DUID is
RFC2131 and RFC2132. encapsulated in a DHCPv4 client identifier option, as described in
"DHCP Options and BOOTP Vendor Extensions" [RFC2132]. The behaviour
described here supersedes the behavior 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. Users of these devices will have a smoother DHCPv4 and DHCPv6. Users of these devices will have a smoother
network experience if the devices identify themselves consistently, network experience if the devices identify themselves consistently,
regardless of the version of DHCP they are using at any given regardless of the version of DHCP they are using at any given moment.
moment. Most obviously, DNS updates made by the DHCP server on Most obviously, DNS updates made by the DHCP server on behalf of the
behalf of the client will be handled more correctly. This change client will be handled more correctly. This change also addresses
also addresses certain limitations in the functioning of certain limitations in the functioning of RFC 2131/2132-style DHCP
RFC2131/2132-style DHCP client identifiers. 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Applicability 3. Applicability
This document updates RFC2131 and RFC2132. This document also This document updates RFC2131 and RFC2132. This document also
specifies behavior that is required of DHCPv4 and DHCPv6 clients specifies behavior that is required of DHCPv4 and DHCPv6 clients that
that are intended to operate in a dual-stack configuration. are intended to operate in a dual-stack configuration. Finally, this
Finally, this document recommends behavior for host configurations document recommends behavior for host configurations where more than
where more than one DHCP client must operate in sequence in order one DHCP client must operate in sequence in order to fully configure
to fully configure the client - e.g., a network boot loader and the the client (e.g., a network boot loader and the operating system it
operating system it loads. loads).
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 6.3 and 6.4 have been made to RFC2131 and RFC2132. DHCPv4 sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132. DHCPv4
clients should, in addition, follow the behavior specified in clients should, in addition, follow the behavior specified in section
section 6.1. DHCPv6 clients should follow the behavior specified 6.1. DHCPv6 clients should follow the behavior specified in section
in section 6.2. DHCPv4 servers should additionally follow the 6.2. DHCPv4 servers should additionally follow the behavior
behavior specified in section 6.3. specified in section 6.3.
4. Problem Statement 4. Problem Statement
4.1. Client identities are ephemeral 4.1. Client identities are ephemeral.
RFC2132 recommends that client identifiers be generated by using RFC 2132 recommends that client identifiers be generated by using the
the permanent link-layer address of the network interface that the permanent link-layer address of the network interface that the client
client is trying to configure. One result of this recommendation is trying to configure. One result of this recommendation is that
is that when the network interface hardware on a client computer when the network interface hardware on a client computer is replaced,
is replaced, the identity of the client changes. The client loses the identity of the client changes. The client loses its IP address
its IP address and any other resources associated with its old and any other resources associated with its old identifier (for
identifier - for example, its domain name as published through the example, its domain name as published through the DHCPv4 server).
DHCPv4 server.
4.2. Clients can accidentally present multiple identities 4.2. Clients can accidentally present multiple identities.
Consider a DHCPv4 client that has two network interfaces, one of Consider a DHCPv4 client that has two network interfaces, one of
which is wired and one of which is wireless. The DHCPv4 client which is wired and one of which is wireless. The DHCPv4 client will
will succeed in configuring either zero, one, or two network succeed in configuring either zero, one, or two network interfaces.
interfaces. Under the current specification, each network Under the current specification, each network interface will receive
interface will receive a different IP address. The DHCPv4 server a different IP address. The DHCPv4 server will treat each network
will treat each network interface as a completely independent interface as a completely independent DHCPv4 client, on a completely
DHCPv4 client, on a completely independent host. independent host.
Thus, when the client presents some information to be updated in a Thus, when the client presents some information to be updated in a
network directory service, such as the DNS, the name that is network directory service, such as the DNS, the name that is
presented will be the same on both interfaces, but the identity presented will be the same on both interfaces, but the identity that
that is presented will be different. What will happen is that one is presented will be different. What will happen is that one of the
of the two interfaces will get the name, and will retain that name two interfaces will get the name, and will retain that name as long
as long as it has a valid lease, even if it loses its connection to as it has a valid lease, even if it loses its connection to the
the network, while the other network interface will never get the network, while the other network interface will never get the name.
name. In some cases, this will achieve the desired result - when In some cases, this will achieve the desired result; when only one
only one network interface is connected, sometimes its IP address network interface is connected, sometimes its IP address will be
will be published. In some cases, the one connected interface's IP published. In some cases, the one connected interface's IP address
address will not be the one that is published. When there are two will not be the one that is published. When there are two
interfaces, sometimes the correct one will be published, and interfaces, sometimes the correct one will be published, and
sometimes not. sometimes not.
This is likely to be a particular problem with modern laptops, This is likely to be a particular problem with modern laptops, which
which usually have built-in wireless ethernet and wired ethernet. usually have built-in wireless ethernet and wired ethernet. When the
When the user is near a wired outlet, he or she may want the user is near a wired outlet, he or she may want the additional speed
additional speed and privacy provided by a wired connection, but and privacy provided by a wired connection, but that same user may
that same user may unplug from the wired network and wander around, unplug from the wired network and wander around, still connected to
still connected to the wireless network. When a transition like the wireless network. When a transition like this happens, under the
this happens, under the current scheme, if the address of the wired current scheme, if the address of the wired interface is the one that
interface is the one that gets published, this client will be seen gets published, this client will be seen by hosts attempting to
by hosts attempting to connect to it as if it has intermittent connect to it as if it has intermittent connectivity, even though it
connectivity, even though it actually has continuous network actually has continuous network connectivity through the wireless
connectivity through the wireless port. port.
Another common case of a duplicate identity being presented occurs Another common case of a duplicate identity being presented occurs
when a boot monitor such as a PXE loader specifies one DHCP client when a boot monitor such as a Pre-Boot Execution Environment (PXE)
identifier, and then the operating system loaded by the boot loader loader specifies one DHCP client identifier, and then the operating
specifies a different identity. system loaded by the boot loader specifies a different identity.
4.3. RFC2131/2132 and RFC3315 identifiers are incompatible 4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible.
The 'client identifier' option is used by DHCPv4 clients and The 'client identifier' option is used by DHCPv4 clients and servers
servers to identify clients. In some cases, the value of the to identify clients. In some cases, the value of the 'client
'client identifier' option is used to mediate access to resources identifier' option is used to mediate access to resources (for
(for example, the client's domain name, as published through the example, the client's domain name, as published through the DHCPv4
DHCPv4 server). RFC2132 and RFC3315 specify different methods for server). RFC 2132 and RFC 3315 specify different methods for
deriving client identifiers. These methods guarantee that the deriving client identifiers. These methods guarantee that the DHCPv4
DHCPv4 and DHCPv6 identifier will be different. This means that and DHCPv6 identifiers will be different. This means that mediation
mediation of access to resources using these identifiers will not of access to resources using these identifiers will not work
work correctly in cases where a node may be configured using DHCPv4 correctly in cases where a node may be configured using DHCPv4 in
in some cases and DHCPv6 in other cases. some cases and DHCPv6 in other cases.
4.4. RFC2131 does not require the use of a client identifier 4.4. RFC 2131 does not require the use of a client identifier.
RFC2131 allows the DHCPv4 server to identify clients either by RFC 2131 allows the DHCPv4 server to identify clients either by using
using the client identifier option sent by the client, or, if the the client identifier option sent by the client or, if the client did
client did not send one, the client's link-layer address. Like the not send one, the client's link-layer address. Like the client
client identifier format recommended by RFC2131, this suffers from identifier format recommended by RFC 2131, this suffers from the
the problems previously described in sections 4.2 and 4.3. problems previously described in sections 4.2 and 4.3.
5. Requirements 5. Requirements
In order to address the problems stated in section 4, DHCPv4 client In order to address the problems stated in section 4, DHCPv4 client
identifiers must have the following characteristics: identifiers must have the following characteristics:
- 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
network hardware is added or removed. 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
with two network interfaces can express to the DHCPv4 server that two network interfaces can express to the DHCPv4 server that these
these two network interfaces are to receive different IP two network interfaces are to receive different IP addresses, even
addresses, even if they happen to be connected to the same link. if they happen to be connected to the same link.
- In cases where the DHCPv4 client is expressing more than one - In cases where the DHCPv4 client is expressing more than one
network identity at the same time, it must nevertheless be network identity at the same time, it must nevertheless be possible
possible for the DHCPv4 server to determine that the two network for the DHCPv4 server to determine that the two network identities
identities belong to the same host. belong to the same host.
- In some cases it may be desirable for a DHCP client to present - In some cases it may be desirable for a DHCP client to present the
the same identity on two interfaces, so that if they both happen same identity on two interfaces, so that if they both happen to be
to be connected to the same network, they will both receive the connected to the same network, they will both receive the same IP
same IP address. In such cases, it must be possible for the address. In such cases, it must be possible for the client to use
client to use exactly the same identifier for each interface. 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
must correctly handle client identifiers sent by clients that correctly handle client identifiers sent by clients that conform to
conform to this specification. this specification.
- DHCPv4 servers that do conform to this specification must - DHCPv4 servers that do conform to this specification must
interoperate correctly with DHCPv4 clients that do not conform to interoperate correctly with DHCPv4 clients that do not conform to
this specification, except that when configuring such clients, this specification, except that when configuring such clients,
behaviors such as those described in section two may occur. behaviors such as those described in section 2 may occur.
- The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet - The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet
as an identifier must be deprecated. as an identifier must be deprecated.
- DHCPv4 client identifiers used by dual-stack hosts that also use - DHCPv4 client identifiers used by dual-stack hosts that also use
DHCPv6 must use the same host identification string for both DHCPv6 must use the same host identification string for both DHCPv4
DHCPv4 and DHCPv6 - for example, a DHCPv4 server that uses the and DHCPv6. For example, a DHCPv4 server that uses the client's
client's identity to update the DNS on behalf of a DHCPv4 client identity to update the DNS on behalf of a DHCPv4 client must
must register the same client identity in the DNS that would be register the same client identity in the DNS that would be
registered by the DHCPv6 server on behalf of the DHCPv6 client registered by the DHCPv6 server on behalf of the DHCPv6 client
running on that host, and vice versa. running on that host, and vice versa.
In order to satisfy all but the last of these requirements, we need In order to satisfy all but the last of these requirements, we need
to construct a DHCPv4 client identifier out of two parts. One part to construct a DHCPv4 client identifier out of two parts. One part
must be unique to the host on which the client is running. The must be unique to the host on which the client is running. The other
other must be unique to the network identity being presented. The must be unique to the network identity being presented. The DHCP
DHCP Unique Identifier (DUID) and Identity Association Identifier Unique Identifier (DUID) and Identity Association Identifier (IAID)
(IAID) specified in RFC3315 satisfy these requirements. specified in RFC 3315 satisfy these requirements.
In order to satisfy the last requirement, we must use the DUID to In order to satisfy the last requirement, we must use the DUID to
identify the DHCPv4 client. So, taking all the requirements identify the DHCPv4 client. So, taking all the requirements
together, the DUID and IAID described in RFC3315 are the only together, the DUID and IAID described in RFC3315 are the only
possible solution. possible solution.
By following these rules, a compliant DHCPv4 client will By following these rules, a compliant DHCPv4 client will interoperate
interoperate correctly with both compliant and non-complient DHCPv4 correctly with both compliant and non-compliant DHCPv4 servers. A
servers. A non-compliant DHCPv4 client will also interoperate non-compliant DHCPv4 client will also interoperate correctly with a
correctly with a compliant DHCPv4 server. If either server or compliant DHCPv4 server. If either server or client is not
client is not compliant, the goals stated in the draft are not met, compliant, the goals stated in the document are not met, but there is
but there is no loss of functionality. no loss of functionality.
6. Implementation 6. Implementation
Here we specify changes to the behavior of DHCPv4 clients and Here we specify changes to the behavior of DHCPv4 clients and
servers. We also specify changes to the wording in RFC2131 and servers. We also specify changes to the wording in RFC 2131 and RFC
RFC2132. DHCPv4 clients, servers and relay agents that conform to 2132. DHCPv4 clients, servers, and relay agents that conform to this
this specification must implement RFC2131 and RFC2132 with the specification must implement RFC 2131 and RFC 2132 with the wording
wording changes specified in sections 6.3 and 6.4. changes specified in sections 6.3 and 6.4.
6.1. DHCPv4 client behavior 6.1. DHCPv4 Client Behavior
DHCPv4 clients conforming to this specification MUST use stable DHCPv4 clients conforming to this specification MUST use stable
DHCPv4 node identifiers in the dhcp-client-identifier option. DHCPv4 node identifiers in the dhcp-client-identifier option. DHCPv4
DHCPv4 clients MUST NOT use client identifiers based solely on clients MUST NOT use client identifiers based solely on layer two
layer two addresses that are hard-wired to the layer two device addresses that are hard-wired to the layer two device (e.g., the
(e.g., the ethernet MAC address) as suggested in RFC2131, except as ethernet MAC address) as suggested in RFC 2131, except as allowed in
allowed in section 9.2 of RFC3315. DHCPv4 clients MUST send a section 9.2 of RFC 3315. DHCPv4 clients MUST send a 'client
'client identifier' option containing an Identity Association identifier' option containing an Identity Association Unique
Unique Identifier, as defined in section 10 of RFC3315, and a DHCP Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique
Unique Identifier, as defined in section 9 of RFC3315. These Identifier, as defined in section 9 of RFC 3315. These together
together constitute an RFC3315-style binding identifier. constitute an RFC 3315-style binding identifier.
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. defined in section 9.14 of RFC2132.
To send an RFC3315-style binding identifiier in a DHCPv4 'client To send an RFC 3315-style binding identifier in a DHCPv4 'client
identifier' option, the type of the 'client identifier' option is identifier' option, the type of the 'client identifier' option is set
set to 255. The type field is immediately followed by the IAID, to 255. The type field is immediately followed by the IAID, which is
which is an opaque 32-bit quantity. The IAID is immediately an opaque 32-bit quantity. The IAID is immediately followed by the
followed by the DUID, which consumes the remaining contents of the DUID, which consumes the remaining contents of the 'client
'client identifier' option. The format of the 'client identifier' identifier' option. The format of the 'client identifier' option is
option is as follows: as follows:
Code Len Type IAID DUID Code Len Type IAID DUID
+----+----+-----+----+----+----+----+----+----+--- +----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |... | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+----+----+-----+----+----+----+----+----+----+--- +----+----+-----+----+----+----+----+----+----+---
Any DHCPv4 client that conforms to this specification SHOULD provide
Any DHCPv4 client that conforms to this specification SHOULD a means by which an operator can learn what DUID the client has
provide a means by which an operator can learn what DUID the client chosen. Such clients SHOULD also provide a means by which the
has chosen. Such clients SHOULD also provide a means by which the
operator can configure the DUID. A device that is normally operator can configure the DUID. A device that is normally
configured by both a DHCPv4 and DHCPv6 client SHOULD automatically configured by both a DHCPv4 and DHCPv6 client SHOULD automatically
use the same DUID for DHCPv4 and DHCPv6 without any operator use the same DUID for DHCPv4 and DHCPv6 without any operator
intervention. intervention.
DHCPv4 clients that support more than one network interface SHOULD DHCPv4 clients that support more than one network interface SHOULD
use the same DUID on every interface. DHCPv4 clients that support use the same DUID on every interface. DHCPv4 clients that support
more than one network interface SHOULD use a different IAID on more than one network interface SHOULD use a different IAID on each
each interface. interface.
A DHCPv4 client that generates a DUID and that has stable storage A DHCPv4 client that generates a DUID and that has stable storage
MUST retain this DUID for use in subsequent DHCPv4 messages, even MUST retain this DUID for use in subsequent DHCPv4 messages, even
after an operating system reboot. after an operating system reboot.
6.2 DHCPv6 client behavior 6.2. DHCPv6 Client Behavior
Any DHCPv6 client that conforms to this specification SHOULD Any DHCPv6 client that conforms to this specification SHOULD provide
provide a means by which an operator can learn what DUID the client a means by which an operator can learn what DUID the client has
has chosen. Such clients SHOULD also provide a means by which the chosen. Such clients SHOULD also provide a means by which the
operator can configure the DUID. A device that is normally operator can configure the DUID. A device that is normally
configured by both a DHCPv4 and DHCPv6 client SHOULD automatically configured by both a DHCPv4 and DHCPv6 client SHOULD automatically
use the same DUID for DHCPv4 and DHCPv6 without any operator use the same DUID for DHCPv4 and DHCPv6 without any operator
intervention. intervention.
6.3. DHCPv4 server behavior 6.3. 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
servers that follow RFC2131 and RFC2132. However, some DHCPv4 that follow RFC 2131 and RFC 2132. However, some DHCPv4 servers can
servers can be configured not to conform to RFC2131 and RFC2132, in be configured not to conform to RFC 2131 and RFC 2132, in the sense
the sense that they ignore the 'client identifier' option and use that they ignore the 'client identifier' option and use the client's
the client's hardware address instead. hardware address instead.
DHCPv4 servers that conform to this specification MUST use the DHCPv4 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
sends it. it.
DHCPv4 servers MAY use administrator-supplied values for chaddr and DHCPv4 servers MAY use administrator-supplied values for chaddr and
htype to identify the client in the case where the administrator is htype to identify the client in the case where the administrator is
assigning a fixed IP address to the client, even if the client assigning a fixed IP address to the client, even if the client sends
sends an client identifier option. This is ONLY permitted in the a client identifier option. This is ONLY permitted in the case where
case where the DHCPv4 server administrator has provided the values the DHCPv4 server administrator has provided the values for chaddr
for chaddr and htype, because in this case if it causes a problem, and htype, because in this case if it causes a problem, the
the administrator can correct the problem by removing the offending administrator can correct the problem by removing the offending
configuration information. configuration information.
6.4. Changes from RFC2131 6.4. 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, and
and the server MUST use that identifier to identify the client. If the server MUST use that identifier to identify the client. If the
the client does not provide a 'client identifier' option, the client does not provide a 'client identifier' option, the server MUST
server MUST use the contents of the 'chaddr' field to identify the use the contents of the 'chaddr' field to identify the client." is
client." is replaced by the text "The client MUST explicitly replaced by the text "The client MUST explicitly provide a client
provide a client identifier through the 'client identifier' identifier through the 'client identifier' option. The client MUST
option. The client MUST use the same 'client identifier' option use the same 'client identifier' option for all messages."
for all messages."
In the same section, the text "Use of 'chaddr' as the client's In the same section, the text "Use of 'chaddr' as the client's unique
unique identifier may cause unexpected results, as that identifier identifier may cause unexpected results, as that identifier may be
may be associated with a hardware interface that could be moved to associated with a hardware interface that could be moved to a new
a new client. Some sites may choose to use a manufacturer's serial client. Some sites may choose to use a manufacturer's serial number
number as the 'client identifier', to avoid unexpected changes in a as the 'client identifier', to avoid unexpected changes in a client's
clients network address due to transfer of hardware interfaces network address due to transfer of hardware interfaces among
among computers. Sites may also choose to use a DNS name as the computers. Sites may also choose to use a DNS name as the 'client
'client identifier', causing address leases to be associated with identifier', causing address leases to be associated with the DNS
the DNS name rather than a specific hardware box." is replaced by name rather than a specific hardware box." is replaced by the text
the text "The DHCP client MUST NOT rely on the 'chaddr' field to "The DHCP client MUST NOT rely on the 'chaddr' field to identify it."
identify it."
In section 4.4.1 of RFC2131, the text "The client MAY include a In section 4.4.1 of RFC2131, the text "The client MAY include a
different unique identifier" is replaced with "The client MUST different unique identifier" is replaced with "The client MUST
include a unique identifier". include a unique identifier".
In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where In section 3.1, items 4 and 6; section 3.2 item 3 and 4; and section
RFC2131 says that 'chaddr' may be used instead of the 'client 4.3.1, where RFC 2131 says that 'chaddr' may be used instead of the
identifier' option, the text that says "or 'chaddr'" and "'chaddr' 'client identifier' option, the text "or 'chaddr'" and "'chaddr' or"
or" is deleted. is deleted.
Note that these changes do not relieve the DHCPv4 server of the Note that these changes do not relieve the DHCPv4 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
that conform with this document to send a 'client identifier' conform with this document to send a 'client identifier' option, and
option, and not rely on 'chaddr' for identification. DHCPv4 not rely on 'chaddr' for identification. DHCPv4 servers MUST use
servers MUST use 'chaddr' as an identifier in cases where 'client 'chaddr' as an identifier in cases where 'client identifier' is not
identifier' is not sent, in order to support old clients that do sent, in order to support old clients that do not conform with this
not conform with this document. document.
6.5. Changes from RFC2132 6.5. 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 four-byte IA_ID field, followed value is normally 255, followed by a four-byte IA_ID field, followed
by the DUID for the client as defined in RF3315, section 9." The by the DUID for the client as defined in RFC 3315, section 9." The
text "its minimum length is 2" in the following paragraph is deleted. text "its minimum length is 2" in the following paragraph is deleted.
7. Notes on DHCP clients in multi-stage network booting 7. Notes on DHCP Clients in Multi-stage Network Booting
In some cases a single device may actually run more than one DHCP In some cases a single device may actually run more than one DHCP
client in sequence, in the process of loading an operating system client in sequence, in the process of loading an operating system
over the network. In such cases, it may be that the first stage over the network. In such cases, it may be that the first-stage boot
boot uses a different client identifier, or no client identifier, uses a different client identifier, or no client identifier, than the
than the subsequent stage or stages. subsequent stage or stages.
The effect of this, under the DHCPv4 protocol, is that the two (in The effect of this, under the DHCPv4 protocol, is that the two (in
some cases more than two!) boot stages will present different some cases more than two!) boot stages will present different
identities. A DHCPv4 server will therefore allocate two different identities. A DHCPv4 server will therefore allocate two different IP
IP addresses to the two different boot stages. addresses to the two different boot stages.
Some DHCP servers work around this problem for the common case Some DHCP servers work around this problem for the common case where
where the boot PROM presents no client identifier, and the the boot Programmable Read Only Memory (PROM) presents no client
operating system DHCP client presents a client identifier identifier, and the operating system DHCP client presents a client
constructed from the MAC address of the network interface - both identifier constructed from the Message Authentication Code (MAC)
are treated as the same identifier. This prevents the consumption address of the network interface -- both are treated as the same
of an extra IP address. identifier. This prevents the consumption of an extra IP address.
A compliant DHCPv4 client does not use a client identifier A compliant DHCPv4 client does not use a client identifier
constructed from the MAC address of the network interface, because constructed from the MAC address of the network interface, because
network interfaces are not stable. So a compliant DHCPv4 client network interfaces are not stable. So a compliant DHCPv4 client
can't be supported by a simple hack like the one described cannot be supported by a simple hack like the one described
previously; this may have some significant impact at some sites. previously; this may have some significant impact at some sites.
We can't state the solution to this problem as a set of We cannot state the solution to this problem as a set of
requirements, because the circumstances in which this occurs vary requirements, because the circumstances in which this occurs vary too
too widely. However, we can make some suggestions. widely. However, we can make some suggestions.
First, we suggest that DHCP clients in network boot loaders request First, we suggest that DHCP clients in network boot loaders request
short lease times, so that their IP addresses are not retained. short lease times, so that their IP addresses are not retained. Such
Such clients should send a DHCPRELEASE message to the DHCP server clients should send a DHCPRELEASE message to the DHCP server before
before moving on to the next stage of the boot process. Such moving on to the next stage of the boot process. Such clients should
clients should provide a way for the operating system DHCP client provide a way for the operating system DHCP client to configure a
to configure a DUID to use in subsequent boots. DHCP clients in DUID to use in subsequent boots. DHCP clients in the final stage
the final stage should, where possible, configure the DUID used by should, where possible, configure the DUID used by the boot PROM to
the boot PROM to be the same as the DUID used by the operating be the same as the DUID used by the operating system.
system.
Secondly, implementors of DHCPv4 clients that are expected to only Second, implementors of DHCPv4 clients that are expected to only be
be used in a multi-stage network boot configuration, and that are used in a multi-stage network boot configuration, that are not
not expected ever to network boot using DHCPv6, and that have a MAC expected ever to network boot using DHCPv6, and that have a MAC
address that can't be easily changed, may not need to implement the address that cannot be easily changed may not need to implement the
changes described in this specification. There is some danger in changes described in this specification. There is some danger in
making this assumption--the first solution suggested is definitely making this assumption--the first solution suggested is definitely
better. A compromise might be to have the final-stage DHCP client better. A compromise might be to have the final-stage DHCP client
detect whether it is running on legacy hardware; if it is, it uses detect whether it is running on legacy hardware; if it is, it uses
the old identifier; if it is not, it follows the scheme described the old identifier; if it is not, it follows the scheme described in
in the previous paragraph. the previous paragraph.
8. Security Considerations 8. 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 is discussed in section 7 of the DHCP
DHCP protocol specification [RFC2131] and in Authentication for protocol specification [RFC2131] and in Authentication for DHCP
DHCP messages [RFC3118]. Potential exposure to attack in the messages [RFC3118]. Potential exposure to attack in the DHCPv6
DHCPv6 protocol is discussed in section 23 of RFC3315. protocol is discussed in section 23 of RFC 3315.
9. IANA Considerations 9. References
None. 9.1. Normative References
10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Informative References [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3118] Droms, R., Arbaugh, W., "Authentication for DHCP [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
Messages", RFC3118, June, 2001 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Author's Addresses 9.2. Informative References
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
Authors' 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
mellon@nominum.com Phone: +1 650 381 6000
EMail: mellon@nominum.com
Bill Sommerfeld Bill Sommerfeld
Sun Microsystems Sun Microsystems
1 Network Drive 1 Network Drive
Burlington, MA 01824 Burlington, MA 01824
+1 781 442 3458
sommerfeld@sun.com Phone: +1 781 442 3458
EMail: sommerfeld@sun.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2006).
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 This document is subject to the rights, licenses and restrictions
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE contained in BCP 78, and except as set forth therein, the authors
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND retain all their rights.
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT This document and the information contained herein are provided on an
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
PARTICULAR PURPOSE. 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 11, line 11 skipping to change at page 12, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 72 change blocks. 
286 lines changed or deleted 294 lines changed or added

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