draft-ietf-dhc-3315id-for-v4-01.txt   draft-ietf-dhc-3315id-for-v4-02.txt 
DHC Working Group Ted Lemon DHC Working Group Ted Lemon
INTERNET DRAFT Nominum INTERNET DRAFT Nominum
Expires: July 2004 Bill Sommerfeld Expires: August 2004 Bill Sommerfeld
Internet Draft Sun Microsystems Internet Draft Sun Microsystems
Document: <draft-ietf-dhc-3315id-for-v4-01.txt> Document: <draft-ietf-dhc-3315id-for-v4-02.txt>
Category: Standards Track January, 2004 Category: Standards Track February, 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 2, line 51 skipping to change at page 2, line 51
Consider a DHCP client that has two network interfaces, one of Consider a DHCP client that has two network interfaces, one of
which is wired and one of which is wireless. There are three which is wired and one of which is 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 Briefly, in case (a), there is no obvious way to choose which of
scope of this document. However, it seems safe to point out that the two network interfaces represents the published identity of the
cases (b) and (c) are very common in practice, because many client, and since the two network interfaces are connected to
different network links, this could make a significant
difference. Also, if, as is likely, the two devices use two
different identifiers, but wish to be identified as the same
client in the sense of the domain name on which their A record is
published, they will compete for which interface identity gets the
single available published identity, and there is no obvious way
to write a DHCP client that produces the right result.
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
this writing have both wireless and wired network interfaces that this writing have both wireless and wired network interfaces that
are installed simultaneously. Both wired and wireless have are installed simultaneously. Both wired and wireless have
advantages - wired has the advantage of speed, and wireless the advantages - wired has the advantage of speed, and wireless the
advantage of mobility. advantage of mobility.
So it seems likely that there will be devices that are in states So it seems likely that there will be devices that are in states
(b) and (c) frequently, and indeed frequently make transitions (b) and (c) frequently, and indeed frequently make transitions
between these states. If the DHCP client that configures these between these states. If the DHCP client that configures these
devices uses the link-layer address of each device as an devices uses the link-layer address of each device as an
identifier, the two devices will appear to the DHCP server to be identifier, the two devices will appear to the DHCP server to be
different nodes, and thus will be assigned different IP addresses, different nodes, and thus will be assigned different IP addresses.
and, in state (b), only one of the two devices will be reachable
through the domain name registered by the DHCP server. As in state (a), in state (b) only one of the two devices will be
Furthermore, if a device in state (b) makes the transition to be able to acquire the public identity of the client, although this
state (c), it is quite possible that the lease for the device that is less of a problem in case (b) because both interfaces are at
has lost connectivity will remain valid for some time, and will be least connected to the same network link. Furthermore, if a device
the one that got the registered domain name. In this case, the in state (b) makes the transition to state (c), it is quite
client will not be reachable through its registered domain name. possible that the lease for the device that has lost connectivity
will remain valid for some time. If the public identity of the
client is associated with this now-defunct interface the client
will not be reachable through its published domain name.
2.3. RFC2131/2132 and RFC3315 identifiers are incompatible 2.3. RFC2131/2132 and RFC3315 identifiers are incompatible
The 'client identifier' option is used by DHCP clients and servers The 'client identifier' option is used by DHCP clients and servers
to identify clients. In some cases, the value of the 'client to identify clients. In some cases, the value of the 'client
identifier' option is used to mediate access to resources (for identifier' option is used to mediate access to resources (for
example, the client's domain name, as published through the DHCP example, the client's domain name, as published through the DHCP
server). RFC2132 and RFC3315 specify different methods for server). RFC2132 and RFC3315 specify different methods for
deriving client identifiers. These methods guarantee that the deriving client identifiers. These methods guarantee that the
DHCPv4 and DHCPv6 identifier will be different. This means that DHCPv4 and DHCPv6 identifier will be different. This means that
skipping to change at page 3, line 44 skipping to change at page 4, line 7
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 (2.1) is to use a DHCP client identifier The solution to problem 2.1 is to use a DHCP client identifier
that is persistent - not tied to a particular piece of removable that is persistent - not tied to a particular piece of removable
network hardware. Then, when network hardware is swapped in and network hardware. Then, when network hardware is swapped in and
out, the client identifier does not change, and thus the client has out, the client identifier does not change, and thus the client has
a consistent IP address and consistent use of whatever resources a consistent IP address and consistent use of whatever resources
have been associated with its identifier. have been associated with its identifier.
It is worth noting that in case (2.1), it is harmless for the This creates a new problem in case 2.2, however: if the two
device to use the same client identifier on both interfaces - in network interfaces are connected to the same link and use the same
this case, the DHCP server or servers serving these two links will identifier, then the server's IP address assignment algorithm will
see the two network interfaces as distinct because they are assign the same IP address to both interfaces. But if the DHCP
connected to different links, even though they use the same client state machines configuring the two interfaces are
identifier. sufficiently out of sync, the DHCPDISCOVER from the slower
interface may be sent after the DHCPACK for the faster
The solution to problem (2.2) is the same. Although it is beyond interface. In this case, the DHCP server will detect a conflict
the scope of this document to say how a DHCP client supporting two and abandon the IP address, because the faster interface is
network interfaces in this way would provide a smooth user responding to ICMP echo requests. So we can't just use the same
experience, it does seem safe to say that it will need to use a identifier on every interface.
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 The solution to problem 2.3 is to use the DHCP Unique Identifier as
as defined in RFC3315 as a client identifier. The DUID provides 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. This is also a valid way of
also solves problems (1) and (2). addressing problem 2.1.
To finish addressing problem 2.2, we modify the solution slightly.
In addition to the DUID, RFC3315 defines an Identity Association ID
(IAID). The IAID, in combination with the DUID, identifies a
particular identity with which to associate an IP address. So a
DHCP client has a single DUID, but has one IAID for each interface.
The DHCP server associates IP addresses with the combination of
(DUID, IAID), but uses the DUID to identify the client as a whole.
The solution to problem (2.4) is to deprecate the use of the The solution to problem (2.4) is to deprecate the use of the
contents of the chaddr field in the DHCP packet as a means of contents of the chaddr field in the DHCP packet as a means of
identifying the client. identifying the client.
4. Implementation Requirements 4. Implementation Requirements
Here we specify changes to the behavior of DHCP clients and Here we specify changes to the behavior of DHCP clients and
servers. We also specify changes to the wording in RFC2131 and servers. We also specify changes to the wording in RFC2131 and
RFC2132. DHCP clients, servers and relay agents that conform to RFC2132. DHCP clients, servers and relay agents that conform to
skipping to change at page 4, line 52 skipping to change at page 5, line 7
wording changes specified in sections 4.3 and 4.4. 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, except as allowed in ethernet MAC address) as suggested in RFC2131, except as allowed in
section 9.2 of RFC3315. DHCP clients MUST send a 'client section 9.2 of RFC3315. DHCP clients MUST send a 'client
identifier' option containing a DHCP Unique Identifier, as defined identifier' option containing an Identity Association Unique
in section 9 of RFC3315. Identifier, as defined in section 10 of RFC3315, and a DHCP Unique
Identifier, as defined in section 9 of RFC3315. These together
constitute an RFC3315-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. To send a defined in section 9.14 of RFC2132.
To send a DUID in a DHCPv4 'client identifier' option, the type of
the 'client identifier' option should be 255. The type field is To send an RFC3315-style binding identifiier in a DHCPv4 'client
immediately followed by the DUID. The format of the 'client identifier' option, the type of the 'client identifier' option is
set to 255. The type field is immediately followed by the IAID,
which is an opaque 32-bit quantity. The IAID is immediately
followed by the DUID, which consumes the remaining contents of the
'client identifier' option. The format of the 'client
identifier' option is as follows: identifier' option is as follows:
Code Len Type DHCP Unique Identifier Code Len Type IAID DUID
+-----+-----+-----+-----+-----+-----+-----+--- +----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | d1 | d2 | d3 | d4 | ... | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+-----+-----+-----+-----+-----+-----+-----+--- +----+----+-----+----+----+----+----+----+----+---
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 DHCP clients that support more than one network interface SHOULD
use the same client identifier on each interface. Such DHCP use the same DUID on every interface. DHCP clients that support
clients SHOULD be prepared for the possibility that the DHCP server more than one network interface SHOULD use a different IAID on
will allocate the same IP address to both interfaces. each interface.
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.
take into account the possibility that the same client identifier
may be used on separate links, and thus will behave incorrectly
when a DHCP client acquires leases on two different IP addresses on
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.
address is bound to a particular DHCP client identifier, all other
still-valid leases on IP addresses bound to that client identifier
are still in use.
DHCP servers MAY use administrator-supplied values for chaddr and DHCP 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 an client identifier option. This is ONLY permitted in the sends an client identifier option. This is ONLY permitted in the
case where the DHCP server administrator has provided the values case where the DHCP server administrator has provided the values
for chaddr and htype, because in this case if it causes a problem, for chaddr and htype, because in this case if it causes a problem,
the administrator can correct the problem by removing the offending the administrator can correct the problem by removing the offending
configuration information. configuration information.
 End of changes. 

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