--- 1/draft-ietf-dhc-3315id-for-v4-01.txt 2006-02-04 23:00:40.000000000 +0100 +++ 2/draft-ietf-dhc-3315id-for-v4-02.txt 2006-02-04 23:00:40.000000000 +0100 @@ -1,17 +1,16 @@ - DHC Working Group Ted Lemon INTERNET DRAFT Nominum -Expires: July 2004 Bill Sommerfeld +Expires: August 2004 Bill Sommerfeld Internet Draft Sun Microsystems -Document: -Category: Standards Track January, 2004 +Document: +Category: Standards Track February, 2004 Node-Specific Client Identifiers for DHCPv4 Status of this Memo This document is a submission by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcwg@ietf.org mailing list. Distribution of this memo is unlimited. @@ -93,42 +92,54 @@ Consider a DHCP client that has two network interfaces, one of which is wired and one of which is wireless. There are three interesting cases here: (a) Each network interface is attached to a different link. (b) Both network interface are connected to the same link. (c) Only one network interface is attached to a link. Case (a) is problematic, and is beyond the scope of this document. - Even the full implications of cases (b) and (c) are beyond the - scope of this document. However, it seems safe to point out that - cases (b) and (c) are very common in practice, because many + Briefly, in case (a), there is no obvious way to choose which of + the two network interfaces represents the published identity of the + 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 this writing have both wireless and wired network interfaces that are installed simultaneously. Both wired and wireless have advantages - wired has the advantage of speed, and wireless the advantage of mobility. So it seems likely that there will be devices that are in states (b) and (c) frequently, and indeed frequently make transitions between these states. If the DHCP client that configures these devices uses the link-layer address of each device as an identifier, the two devices will appear to the DHCP server to be - 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. - Furthermore, if a device in state (b) makes the transition to - state (c), it is quite possible that the lease for the device that - has lost connectivity will remain valid for some time, and will be - the one that got the registered domain name. In this case, the - client will not be reachable through its registered domain name. + different nodes, and thus will be assigned different IP addresses. + + As in state (a), in state (b) only one of the two devices will be + be able to acquire the public identity of the client, although this + is less of a problem in case (b) because both interfaces are at + least connected to the same network link. Furthermore, if a device + in state (b) makes the transition to state (c), it is quite + 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 The 'client identifier' option is used by DHCP clients and servers to identify clients. In some cases, the value of the 'client identifier' option is used to mediate access to resources (for example, the client's domain name, as published through the DHCP server). RFC2132 and RFC3315 specify different methods for deriving client identifiers. These methods guarantee that the DHCPv4 and DHCPv6 identifier will be different. This means that @@ -139,60 +150,53 @@ 2.4. RFC2131 does not require the use of a client identifier RFC2131 allows the DHCP server to identify clients either by using the client identifier option sent by the client, or, if the client did not send one, the client's link-layer address. Like the client identifier format recommended by RFC2131, this suffers from the problems previously described in (2) and (3). 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 network hardware. Then, when network hardware is swapped in and out, the client identifier does not change, and thus the client has a consistent IP address and consistent use of whatever resources have been associated with its identifier. - 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 - this case, the DHCP server or servers serving these two links will - see the two network interfaces as distinct because they are - connected to different links, even though they use the same - identifier. - - The solution to problem (2.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. - - 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. + This creates a new problem in case 2.2, however: if the two + network interfaces are connected to the same link and use the same + identifier, then the server's IP address assignment algorithm will + assign the same IP address to both interfaces. But if the DHCP + client state machines configuring the two interfaces are + sufficiently out of sync, the DHCPDISCOVER from the slower + interface may be sent after the DHCPACK for the faster + interface. In this case, the DHCP server will detect a conflict + and abandon the IP address, because the faster interface is + responding to ICMP echo requests. So we can't just use the same + identifier on every interface. - The solution to problem (2.3) is to use the DHCP Unique Identifier - as defined in RFC3315 as a client identifier. The DUID provides + 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 identifiers, at least one of which is likely to be appropriate for - any particular sort of network device. So it turns out that this - also solves problems (1) and (2). + any particular sort of network device. This is also a valid way of + 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 contents of the chaddr field in the DHCP packet as a means of identifying the client. 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 @@ -200,66 +204,65 @@ wording changes specified in sections 4.3 and 4.4. 4.1. DHCP Client behavior DHCP clients conforming to this specification MUST use stable DHCP node identifiers in the dhcp-client-identifier option. DHCP clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC2131, except as allowed in section 9.2 of RFC3315. DHCP clients MUST send a 'client - identifier' option containing a DHCP Unique Identifier, as defined - in section 9 of RFC3315. + identifier' option containing an Identity Association Unique + 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 - defined in section 9.14 of RFC2132. To send a - To send a DUID in a DHCPv4 'client identifier' option, the type of - the 'client identifier' option should be 255. The type field is - immediately followed by the DUID. The format of the 'client + defined in section 9.14 of RFC2132. + + To send an RFC3315-style binding identifiier in a DHCPv4 '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: - Code Len Type DHCP Unique Identifier - +-----+-----+-----+-----+-----+-----+-----+--- - | 61 | n | 255 | d1 | d2 | d3 | d4 | ... - +-----+-----+-----+-----+-----+-----+-----+--- + Code Len Type IAID DUID + +----+----+-----+----+----+----+----+----+----+--- + | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |... + +----+----+-----+----+----+----+----+----+----+--- Any DHCPv4 or DHCPv6 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured with both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any 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. + use the same DUID on every interface. DHCP clients that support + more than one network interface SHOULD use a different IAID on + each interface. 4.2. DHCPv4 Server behavior This document does not require any change to DHCPv4 or DHCPv6 servers that follow RFC2131 and RFC2132. However, some DHCPv4 servers can be configured not to conform to RFC2131 and RFC2131, in the sense that they ignore the 'client identifier' option and use - the client's hardware address instead. Some DHCP servers do not - 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. + the client's hardware address instead. DHCP servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client - sends it. DHCP servers MUST assume that when a lease on an IP - 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. + sends it. 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.