DHC Working Group Ted Lemon INTERNET DRAFT Nominum Expires:
August 2004January 2005 Bill Sommerfeld Internet Draft Sun Microsystems Document: <draft-ietf-dhc-3315id-for-v4-02.txt><draft-ietf-dhc-3315id-for-v4-03.txt> Category: Standards Track February,July, 2004 Node-Specific Client Identifiers for DHCPv4 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 firstname.lastname@example.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six 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 asa "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txtat http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html.at http://www.ietf.org/shadow.html Abstract This document specifies the format that is to be used for encoding DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol [RFC3315]. Introduction This document specifies the way in which DHCPv4 clients should identify themselves. DHCPv4 client implementations that conform to this specification use a DHCPv6-style DHCP Unique Identifier (DUID) encapsulated in a DHCPv4 client identifier option. This supersedes the behaviour specified in RFC2131 and RFC2132. 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 DHCPv4 and DHCPv6. Users of these devices will have a smoother network experience if the devices identify themselves consistently, regardless of the version of DHCP they are using at any given moment. Most obviously, DNS updates made by the DHCP server on 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. This document first describes the problem to be solved. It then states the new technique that is to be used to solve the problem. Finally, it describes the specific changes that one would have to make to RFC2131 and RFC2132 in order for those documents not to contradict what is described in this document. 1.0 Applicability This document updates RFC2131 and RFC2132. DHCPv4 serversserver implementations SHOULD conform to this document. DHCPv4 clients on network devices that are expected to support DHCPv6 in the future SHOULD conform to this document. This document makes no changes to the behavior of DHCPv6 clients or servers. DHCPv4 clients and servers that are implemented according to this document should be implemented as if the changes specified in section 4.3 and 4.4 have been made to RFC2131 and RFC2132. 2.0 Problem Statement 2.1. Client identities are ephemeral RFC2132 recommends that client identifiers be generated by using the permanent link-layer address of the network interface that the client is trying to configure. In cases where a network interface is removed from the client computer and replaced with a different network interface with a different permanent link-layer address, the identity of the client changes. The client loses its IP address and any other resources associated with its old identifier - for example, its domain name as published through the DHCPDHCPv4 server. 2.2. Clients can accidentally present multiple identities Consider a DHCPDHCPv4 client that has two network interfaces, one of which is wired and one of which is wireless. There are three interesting cases here: (a) EachThe DHCPv4 client will succeed in configuring either zero, one, or two network interfaces. Under the current specification, each network interface is attached towill receive a different link. (b) Both network interface are connected to the same link. (c) Only oneIP address. The DHCPv4 server will treat each network interface is attached toas a link. Case (a) is problematic, and is beyond the scope of this document. Briefly, in case (a), there is no obvious way to choose which of the two network interfaces represents the published identity of thecompletely independent DHCPv4 client, and since the two network interfaces are connected to different network links, this could makeon a significant difference. Also, if, as is likely,completely independent host. Thus, when the two devices use two different identifiers, but wishclient presents some information to be identified as the same clientupdated in a network directory service, such as the sense ofDNS, the domainname on which their A recordthat is published, theypresented 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 atbe the time of this writing havesame on both wireless and wired network interfaces that are installed simultaneously. Both wired and wireless have advantages - wired has the advantage of speed, and wirelessinterfaces, but the advantage of mobility. So it seems likelyidentity that thereis presented will be devices that are in states (b) and (c) frequently, and indeed frequently make transitions between these states. If the DHCP clientdifferent. What will happen is that configures these devices uses the link-layer addressone of each device as an identifier,the two devicesinterfaces will appear toget the DHCP server to be different nodes,name, and thuswill be assigned different IP addresses. As in state (a), in state (b)retain that name as long as it has a valid lease, even if it loses its connection to the network, while the other network interface will never get the name. In some cases, this will achieve the desired result - when only one of the two devicesnetwork interface is connected, sometimes its IP address will be published. In some cases, the one connected interface's IP address will not be able to acquirethe public identity ofone that is published. When there are two interfaces, sometimes the client, although thiscorrect one will be published, and sometimes not. This is less oflikely to be a particular problem in case (b) because both interfaces are at least connected towith modern laptops, which usually have built-in wireless ethernet and wired ethernet. When the same network link. Furthermore, ifuser is near a device in state (b) makeswired outlet, he or she may want the transition to state (c), it is quite possibleadditional speed and privacy provided by a wired connection, but that same user may unplug from the lease forwired network and wander around, still connected to the device that has lost connectivity will remain valid for some time. Ifwireless network. When a transition like this happens, under the public identitycurrent scheme, if the address of the client is associated with this now-defunctwired interface is the one that gets published, this client will notbe reachableseen by hosts attempting to connect to it as if it has intermittent connectivity, even though it actually has continuous network connectivity through its published domain name.the wireless port. 2.3. RFC2131/2132 and RFC3315 identifiers are incompatible The 'client identifier' option is used by DHCPDHCPv4 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 DHCPDHCPv4 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 mediation of access to resources using these identifiers will not work correctly in cases where a node may be configured using DHCPv4 in some cases and DHCPv6 in other cases. 2.4. RFC2131 does not require the use of a client identifier RFC2131 allows the DHCPDHCPv4 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 isRequirements In order to useaddress the problems stated in section 2, DHCPv4 client identifiers must have the following characteristics: - They must be persistent, in the sense that a DHCPparticular host's client identifier that is persistent -must not tied tochange simply because a particularpiece of removable network hardware. Then, whennetwork hardware is swapped in and out, the client identifier does not change, and thusadded or removed. - It must be possible for the client hasto represent itself as having more than one network identity - for example so that a consistent IP address and consistent use of whatever resources have been associatedclient with its identifier. This creates a new problem in case 2.2, however: iftwo network interfaces can express to the DHCPv4 server that these two network interfaces are to receive different IP addresses, even if they happen to be connected to the same link and use the same identifier, thenlink. - It must be possible, in cases where the server's IP address assignment algorithm will assignDHCPv4 client is expressing more than one network identity at the same IP address to both interfaces. But iftime, it must nevertheless be possible for the DHCP client state machines configuringDHCPv4 server to determine that the two interfaces are sufficiently out of sync, the DHCPDISCOVER fromnetwork identities belong to the slower interface maysame host. - It must be sent after the DHCPACKpossible for the faster interface. In this case, the DHCP server will detecta conflict and abandonclient that is prepared to handle the IP address, becausecase where two or more network interfaces have the faster interface is respondingsame IP address to ICMP echo requests. So we can't justuse exactly the same identifier on everyfor each interface. The solution to problem 2.3 is- DHCPv4 servers that do not conform to usethis specification, but that are compliant with the DHCP Unique Identifierolder client identifier specification, must correctly handle client identifiers sent by clients that conform to this specification. - DHCPv4 servers that do conform to this specification must interoperate correctly with DHCPv4 clients that do not conform to this specification, except that when configuring such clients, behaviors such as definedthose described in RFC3315section two may occur. - The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet as aan identifier must be deprecated. - DHCPv4 client identifier. The DUID provides several different waysidentifiers used by dual-stack hosts that also use DHCPv6 must use the same host identification string for both DHCPv4 and DHCPv6 - for example, a DHCPv4 server that uses the client's identity to update the DNS on behalf of producing persistent DHCPa DHCPv4 client identifiers, at least onemust register the same client identity in the DNS that would be registered by the DHCPv6 server on behalf of which is likelythe DHCPv6 client running on that host, and vice versa. In order to be appropriate for any particular sortsatisfy all but the last of network device. This is alsothese requirements, we need to construct a valid wayDHCPv4 client identifier out of addressing problem 2.1. To finish addressing problem 2.2, we modify the solution slightly. In additiontwo parts. One part must be unique to the DUID, RFC3315 defines an Identity Association ID (IAID).host on which the client is running. The IAID, in combination withother must be unique to the DUID, identifies a particularnetwork identity with which to associate an IP address. So a DHCP client has a single DUID, but has one IAID for each interface.being presented. The DHCP server associates IP addresses withUnique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC3315 satisfy these requirements. And in order to satisfy the combination of (DUID, IAID), but useslast requirement, we must use the DUID to identify the client as a whole. The solution to problem (2.4) is to deprecate the use ofDHCPv4 client. So, taking all the contents ofrequirements together, the chaddr fieldDUID and IAID described in RFC3315 are the DHCP packet as a means of identifying the client.only possible solution. 4. Implementation RequirementsHere we specify changes to the behavior of DHCPDHCPv4 clients and servers. We also specify changes to the wording in RFC2131 and RFC2132. DHCPDHCPv4 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. DHCPDHCPv4 Client behavior DHCPDHCPv4 clients conforming to this specification MUST use stable DHCPDHCPv4 node identifiers in the dhcp-client-identifier option. DHCPDHCPv4 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. DHCPDHCPv4 clients MUST send a 'client 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 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 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. DHCPDHCPv4 clients that support more than one network interface SHOULD use the same DUID on every interface. DHCPDHCPv4 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. DHCPDHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it. DHCPDHCPv4 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 DHCPDHCPv4 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 example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name" is deleted. In section 4.2 of RFC2131, the text "The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client." is replaced by the text "The client MUST explicitly provide a client identifier through the 'client identifier' option."option. The client MUST use the same 'client identifier' option for all messages." In the same section, the text "Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box." is replaced by the text "The DHCP client MUST NOT rely on the 'chaddr' field to identify it." In section 4.4.1 of RFC2131, the text "The client MAY include a different unique identifier" is replaced with "The client MUST include a unique identifier". In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where RFC2131 says that 'chaddr' may be used instead of the 'client identifier' option, the text that says "or 'chaddr'" and "'chaddr' or" is deleted. Note that these changes do not relieve the DHCPDHCPv4 server of the obligation to use 'chaddr' as an identifier if the client does not send a 'client identifier' option. Rather, they oblige clients that conform with this document to send a 'client identifier' option, and not rely on 'chaddr' for identification. DHCPDHCPv4 servers MUST use 'chaddr' as an identifier in cases where 'client identifier' is not sent, in order to support old clients that do not conform with this document. 4.4. Changes from RFC2132 The text in section 9.14, beginning with "The client identifier MAY consist of" through "that meet this requirement for uniqueness." is replaced with "the client identifier consists of a type field whose 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 format of the contents of the identifier are defined in RF3315, section 9." The text "its minimum length is 2" in the following paragraph is deleted. 5. Security Considerations This document raises no new security issues. Potential exposure to attack in the DHCPv4 protocol are discussed in section 7 of the DHCP protocol specification [RFC2131] and in Authentication for DHCP messages [RFC3118]. Potential exposure to attack in the DHCPv6 protocol is discussed in section 23 of RFC3315. 6. IANA Considerations This document defines no new name spaces that need to be administered by the IANA. This document deprecates all 'client identifier' type codes other than 255, and thus there is no need for the IANA to track additional possible values for the type field of the 'client identifier' option. 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 Nominum 2385 Bay Road Redwood City, CA 94063 USA +1 650 381 6000 email@example.com Bill Sommerfeld Sun Microsystems 1 Network Drive Burlington, MA 01824 +1 781 442 3458 firstname.lastname@example.org Full Copyright Statement "CopyrightCopyright (C) 2003, 2004The Internet Society. All Rights Reserved.Society (2003-2004). This document and translations of it may be copied and furnishedis subject to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided thatthe above copyright noticerights, licenses and this paragraph are included on all such copies and derivative works. However, this document itself may not be modifiedrestrictions contained in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78, and except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked byset forth therein, the Internet Society or its successors or assigns.authors retain all their rights. This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM 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."PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.