idnits 2.17.1 draft-ietf-dhc-3315id-for-v4-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. -- The draft header indicates that this document updates RFC2131, but the abstract doesn't seem to directly say this. It does mention RFC2131 though, so this could be OK. -- The draft header indicates that this document updates RFC2132, but the abstract doesn't seem to directly say this. It does mention RFC2132 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2131, updated by this document, for RFC5378 checks: 1994-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2132' is defined on line 448, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Ted Lemon 2 INTERNET DRAFT Nominum 3 Expires: January 2006 Bill Sommerfeld 4 Internet Draft Sun Microsystems 5 Document: 6 Updates: 2131, 2132, 3315 7 Category: Standards Track June, 2005 9 Node-Specific Client Identifiers for DHCPv4 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document is a submission by the Dynamic Host Configuration 19 Working Group of the Internet Engineering Task Force (IETF). Comments 20 should be submitted to the dhcwg@ietf.org mailing list. 22 Distribution of this memo is unlimited. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress". 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document specifies the format that is to be used for encoding 43 DHCPv4 client identifiers, so that those identifiers will be inter- 44 changeable with identifiers used in the DHCPv6 protocol. This 45 document also addresses and corrects some problems in RFC2131 and 46 RFC2132 with respect to the handling of DHCP client identifiers. 48 1. Introduction 50 This document specifies the way in which DHCPv4 [RFC2131] clients 51 should identify themselves. DHCPv4 client implementations that 52 conform to this specification use a DHCPv6-style DHCP Unique 53 Identifier (DUID) [RFC3315] encapsulated in a DHCPv4 client 54 identifier option. This supersedes the behavior specified in 55 RFC2131 and RFC2132. 57 The reason for making this change is that as we make the transition 58 from IPv4 to IPv6, there will be network devices that must use both 59 DHCPv4 and DHCPv6. Users of these devices will have a smoother 60 network experience if the devices identify themselves consistently, 61 regardless of the version of DHCP they are using at any given 62 moment. Most obviously, DNS updates made by the DHCP server on 63 behalf of the client will be handled more correctly. This change 64 also addresses certain limitations in the functioning of 65 RFC2131/2132-style DHCP client identifiers. 67 This document first describes the problem to be solved. It then 68 states the new technique that is to be used to solve the problem. 69 Finally, it describes the specific changes that one would have to 70 make to RFC2131 and RFC2132 in order for those documents not to 71 contradict what is described in this document. 73 2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 3. Applicability 81 This document updates RFC2131 and RFC2132. This document also 82 specifies behavior that is required of DHCPv4 and DHCPv6 clients 83 that are intended to operate in a dual-stack configuration. 84 Finally, this document recommends behavior for host configurations 85 where more than one DHCP client must operate in sequence in order 86 to fully configure the client - e.g., a network boot loader and the 87 operating system it loads. 89 DHCPv4 clients and servers that are implemented according to this 90 document should be implemented as if the changes specified in 91 section 6.3 and 6.4 have been made to RFC2131 and RFC2132. DHCPv4 92 clients should, in addition, follow the behavior specified in 93 section 6.1. DHCPv6 clients should follow the behavior specified 94 in section 6.2. DHCPv4 servers should additionally follow the 95 behavior specified in section 6.3. 97 4. Problem Statement 99 4.1. Client identities are ephemeral 101 RFC2132 recommends that client identifiers be generated by using 102 the permanent link-layer address of the network interface that the 103 client is trying to configure. One result of this recommendation 104 is that when the network interface hardware on a client computer 105 is replaced, the identity of the client changes. The client loses 106 its IP address and any other resources associated with its old 107 identifier - for example, its domain name as published through the 108 DHCPv4 server. 110 4.2. Clients can accidentally present multiple identities 112 Consider a DHCPv4 client that has two network interfaces, one of 113 which is wired and one of which is wireless. The DHCPv4 client 114 will succeed in configuring either zero, one, or two network 115 interfaces. Under the current specification, each network 116 interface will receive a different IP address. The DHCPv4 server 117 will treat each network interface as a completely independent 118 DHCPv4 client, on a completely independent host. 120 Thus, when the client presents some information to be updated in a 121 network directory service, such as the DNS, the name that is 122 presented will be the same on both interfaces, but the identity 123 that is presented will be different. What will happen is that one 124 of the two interfaces will get the name, and will retain that name 125 as long as it has a valid lease, even if it loses its connection to 126 the network, while the other network interface will never get the 127 name. In some cases, this will achieve the desired result - when 128 only one network interface is connected, sometimes its IP address 129 will be published. In some cases, the one connected interface's IP 130 address will not be the one that is published. When there are two 131 interfaces, sometimes the correct one will be published, and 132 sometimes not. 134 This is likely to be a particular problem with modern laptops, 135 which usually have built-in wireless ethernet and wired ethernet. 136 When the user is near a wired outlet, he or she may want the 137 additional speed and privacy provided by a wired connection, but 138 that same user may unplug from the wired network and wander around, 139 still connected to the wireless network. When a transition like 140 this happens, under the current scheme, if the address of the wired 141 interface is the one that gets published, this client will be seen 142 by hosts attempting to connect to it as if it has intermittent 143 connectivity, even though it actually has continuous network 144 connectivity through the wireless port. 146 Another common case of a duplicate identity being presented occurs 147 when a boot monitor such as a PXE loader specifies one DHCP client 148 identifier, and then the operating system loaded by the boot loader 149 specifies a different identity. 151 4.3. RFC2131/2132 and RFC3315 identifiers are incompatible 153 The 'client identifier' option is used by DHCPv4 clients and 154 servers to identify clients. In some cases, the value of the 155 'client identifier' option is used to mediate access to resources 156 (for example, the client's domain name, as published through the 157 DHCPv4 server). RFC2132 and RFC3315 specify different methods for 158 deriving client identifiers. These methods guarantee that the 159 DHCPv4 and DHCPv6 identifier will be different. This means that 160 mediation of access to resources using these identifiers will not 161 work correctly in cases where a node may be configured using DHCPv4 162 in some cases and DHCPv6 in other cases. 164 4.4. RFC2131 does not require the use of a client identifier 166 RFC2131 allows the DHCPv4 server to identify clients either by 167 using the client identifier option sent by the client, or, if the 168 client did not send one, the client's link-layer address. Like the 169 client identifier format recommended by RFC2131, this suffers from 170 the problems previously described in sections 4.2 and 4.3. 172 5. Requirements 174 In order to address the problems stated in section 4, DHCPv4 client 175 identifiers must have the following characteristics: 177 - They must be persistent, in the sense that a particular host's 178 client identifier must not change simply because a piece of 179 network hardware is added or removed. 181 - It must be possible for the client to represent itself as having 182 more than one network identity - for example so that a client 183 with two network interfaces can express to the DHCPv4 server that 184 these two network interfaces are to receive different IP 185 addresses, even if they happen to be connected to the same link. 187 - In cases where the DHCPv4 client is expressing more than one 188 network identity at the same time, it must nevertheless be 189 possible for the DHCPv4 server to determine that the two network 190 identities belong to the same host. 192 - In some cases it may be desirable for a DHCP client to present 193 the same identity on two interfaces, so that if they both happen 194 to be connected to the same network, they will both receive the 195 same IP address. In such cases, it must be possible for the 196 client to use exactly the same identifier for each interface. 198 - DHCPv4 servers that do not conform to this specification, but that 199 are compliant with the older client identifier specification, 200 must correctly handle client identifiers sent by clients that 201 conform to this specification. 203 - DHCPv4 servers that do conform to this specification must 204 interoperate correctly with DHCPv4 clients that do not conform to 205 this specification, except that when configuring such clients, 206 behaviors such as those described in section two may occur. 208 - The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet 209 as an identifier must be deprecated. 211 - DHCPv4 client identifiers used by dual-stack hosts that also use 212 DHCPv6 must use the same host identification string for both 213 DHCPv4 and DHCPv6 - for example, a DHCPv4 server that uses the 214 client's identity to update the DNS on behalf of a DHCPv4 client 215 must register the same client identity in the DNS that would be 216 registered by the DHCPv6 server on behalf of the DHCPv6 client 217 running on that host, and vice versa. 219 In order to satisfy all but the last of these requirements, we need 220 to construct a DHCPv4 client identifier out of two parts. One part 221 must be unique to the host on which the client is running. The 222 other must be unique to the network identity being presented. The 223 DHCP Unique Identifier (DUID) and Identity Association Identifier 224 (IAID) specified in RFC3315 satisfy these requirements. 226 In order to satisfy the last requirement, we must use the DUID to 227 identify the DHCPv4 client. So, taking all the requirements 228 together, the DUID and IAID described in RFC3315 are the only 229 possible solution. 231 By following these rules, a compliant DHCPv4 client will 232 interoperate correctly with both compliant and non-complient DHCPv4 233 servers. A non-compliant DHCPv4 client will also interoperate 234 correctly with a compliant DHCPv4 server. If either server or 235 client is not compliant, the goals stated in the draft are not met, 236 but there is no loss of functionality. 238 6. Implementation 240 Here we specify changes to the behavior of DHCPv4 clients and 241 servers. We also specify changes to the wording in RFC2131 and 242 RFC2132. DHCPv4 clients, servers and relay agents that conform to 243 this specification must implement RFC2131 and RFC2132 with the 244 wording changes specified in sections 6.3 and 6.4. 246 6.1. DHCPv4 client behavior 248 DHCPv4 clients conforming to this specification MUST use stable 249 DHCPv4 node identifiers in the dhcp-client-identifier option. 250 DHCPv4 clients MUST NOT use client identifiers based solely on 251 layer two addresses that are hard-wired to the layer two device 252 (e.g., the ethernet MAC address) as suggested in RFC2131, except as 253 allowed in section 9.2 of RFC3315. DHCPv4 clients MUST send a 254 'client identifier' option containing an Identity Association 255 Unique Identifier, as defined in section 10 of RFC3315, and a DHCP 256 Unique Identifier, as defined in section 9 of RFC3315. These 257 together constitute an RFC3315-style binding identifier. 259 The general format of the DHCPv4 'client identifier' option is 260 defined in section 9.14 of RFC2132. 262 To send an RFC3315-style binding identifiier in a DHCPv4 'client 263 identifier' option, the type of the 'client identifier' option is 264 set to 255. The type field is immediately followed by the IAID, 265 which is an opaque 32-bit quantity. The IAID is immediately 266 followed by the DUID, which consumes the remaining contents of the 267 'client identifier' option. The format of the 'client identifier' 268 option is as follows: 270 Code Len Type IAID DUID 271 +----+----+-----+----+----+----+----+----+----+--- 272 | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |... 273 +----+----+-----+----+----+----+----+----+----+--- 275 Any DHCPv4 client that conforms to this specification SHOULD 276 provide a means by which an operator can learn what DUID the client 277 has chosen. Such clients SHOULD also provide a means by which the 278 operator can configure the DUID. A device that is normally 279 configured by both a DHCPv4 and DHCPv6 client SHOULD automatically 280 use the same DUID for DHCPv4 and DHCPv6 without any operator 281 intervention. 283 DHCPv4 clients that support more than one network interface SHOULD 284 use the same DUID on every interface. DHCPv4 clients that support 285 more than one network interface SHOULD use a different IAID on 286 each interface. 288 A DHCPv4 client that generates a DUID and that has stable storage 289 MUST retain this DUID for use in subsequent DHCPv4 messages, even 290 after an operating system reboot. 292 6.2 DHCPv6 client behavior 294 Any DHCPv6 client that conforms to this specification SHOULD 295 provide a means by which an operator can learn what DUID the client 296 has chosen. Such clients SHOULD also provide a means by which the 297 operator can configure the DUID. A device that is normally 298 configured by both a DHCPv4 and DHCPv6 client SHOULD automatically 299 use the same DUID for DHCPv4 and DHCPv6 without any operator 300 intervention. 302 6.3. DHCPv4 server behavior 304 This document does not require any change to DHCPv4 or DHCPv6 305 servers that follow RFC2131 and RFC2132. However, some DHCPv4 306 servers can be configured not to conform to RFC2131 and RFC2132, in 307 the sense that they ignore the 'client identifier' option and use 308 the client's hardware address instead. 310 DHCPv4 servers that conform to this specification MUST use the 311 'client identifier' option to identify the client if the client 312 sends it. 314 DHCPv4 servers MAY use administrator-supplied values for chaddr and 315 htype to identify the client in the case where the administrator is 316 assigning a fixed IP address to the client, even if the client 317 sends an client identifier option. This is ONLY permitted in the 318 case where the DHCPv4 server administrator has provided the values 319 for chaddr and htype, because in this case if it causes a problem, 320 the administrator can correct the problem by removing the offending 321 configuration information. 323 6.4. Changes from RFC2131 325 In section 2 of RFC2131, on page 9, the text that reads "; for 326 example, the 'client identifier' may contain a hardware address, 327 identical to the contents of the 'chaddr' field, or it may contain 328 another type of identifier, such as a DNS name" is deleted. 330 In section 4.2 of RFC2131, the text "The client MAY choose to 331 explicitly provide the identifier through the 'client identifier' 332 option. If the client supplies a 'client identifier', the client 333 MUST use the same 'client identifier' in all subsequent messages, 334 and the server MUST use that identifier to identify the client. If 335 the client does not provide a 'client identifier' option, the 336 server MUST use the contents of the 'chaddr' field to identify the 337 client." is replaced by the text "The client MUST explicitly 338 provide a client identifier through the 'client identifier' 339 option. The client MUST use the same 'client identifier' option 340 for all messages." 342 In the same section, the text "Use of 'chaddr' as the client's 343 unique identifier may cause unexpected results, as that identifier 344 may be associated with a hardware interface that could be moved to 345 a new client. Some sites may choose to use a manufacturer's serial 346 number as the 'client identifier', to avoid unexpected changes in a 347 clients network address due to transfer of hardware interfaces 348 among computers. Sites may also choose to use a DNS name as the 349 'client identifier', causing address leases to be associated with 350 the DNS name rather than a specific hardware box." is replaced by 351 the text "The DHCP client MUST NOT rely on the 'chaddr' field to 352 identify it." 354 In section 4.4.1 of RFC2131, the text "The client MAY include a 355 different unique identifier" is replaced with "The client MUST 356 include a unique identifier". 358 In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where 359 RFC2131 says that 'chaddr' may be used instead of the 'client 360 identifier' option, the text that says "or 'chaddr'" and "'chaddr' 361 or" is deleted. 363 Note that these changes do not relieve the DHCPv4 server of the 364 obligation to use 'chaddr' as an identifier if the client does not 365 send a 'client identifier' option. Rather, they oblige clients 366 that conform with this document to send a 'client identifier' 367 option, and not rely on 'chaddr' for identification. DHCPv4 368 servers MUST use 'chaddr' as an identifier in cases where 'client 369 identifier' is not sent, in order to support old clients that do 370 not conform with this document. 372 6.5. Changes from RFC2132 374 The text in section 9.14, beginning with "The client identifier MAY 375 consist of" through "that meet this requirement for uniqueness." is 376 replaced with "the client identifier consists of a type field whose 377 value is normally 255, followed by a four-byte IA_ID field, followed 378 by the DUID for the client as defined in RF3315, section 9." The 379 text "its minimum length is 2" in the following paragraph is deleted. 381 7. Notes on DHCP clients in multi-stage network booting 383 In some cases a single device may actually run more than one DHCP 384 client in sequence, in the process of loading an operating system 385 over the network. In such cases, it may be that the first stage 386 boot uses a different client identifier, or no client identifier, 387 than the subsequent stage or stages. 389 The effect of this, under the DHCPv4 protocol, is that the two (in 390 some cases more than two!) boot stages will present different 391 identities. A DHCPv4 server will therefore allocate two different 392 IP addresses to the two different boot stages. 394 Some DHCP servers work around this problem for the common case 395 where the boot PROM presents no client identifier, and the 396 operating system DHCP client presents a client identifier 397 constructed from the MAC address of the network interface - both 398 are treated as the same identifier. This prevents the consumption 399 of an extra IP address. 401 A compliant DHCPv4 client does not use a client identifier 402 constructed from the MAC address of the network interface, because 403 network interfaces are not stable. So a compliant DHCPv4 client 404 can't be supported by a simple hack like the one described 405 previously; this may have some significant impact at some sites. 407 We can't state the solution to this problem as a set of 408 requirements, because the circumstances in which this occurs vary 409 too widely. However, we can make some suggestions. 411 First, we suggest that DHCP clients in network boot loaders request 412 short lease times, so that their IP addresses are not retained. 413 Such clients should send a DHCPRELEASE message to the DHCP server 414 before moving on to the next stage of the boot process. Such 415 clients should provide a way for the operating system DHCP client 416 to configure a DUID to use in subsequent boots. DHCP clients in 417 the final stage should, where possible, configure the DUID used by 418 the boot PROM to be the same as the DUID used by the operating 419 system. 421 Secondly, implementors of DHCPv4 clients that are expected to only 422 be used in a multi-stage network boot configuration, and that are 423 not expected ever to network boot using DHCPv6, and that have a MAC 424 address that can't be easily changed, may not need to implement the 425 changes described in this specification. There is some danger in 426 making this assumption--the first solution suggested is definitely 427 better. A compromise might be to have the final-stage DHCP client 428 detect whether it is running on legacy hardware; if it is, it uses 429 the old identifier; if it is not, it follows the scheme described 430 in the previous paragraph. 432 8. Security Considerations 434 This document raises no new security issues. Potential exposure to 435 attack in the DHCPv4 protocol are discussed in section 7 of the 436 DHCP protocol specification [RFC2131] and in Authentication for 437 DHCP messages [RFC3118]. Potential exposure to attack in the 438 DHCPv6 protocol is discussed in section 23 of RFC3315. 440 9. IANA Considerations 442 None. 444 10. Normative References 446 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 447 March 1997. 448 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 449 Extensions", RFC2132, March, 1997 450 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 451 Carney, M., "Dynamic Host Configuration Protocol for 452 IPv6 (DHCPV6)", July, 2003 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 11. Informative References 458 [RFC3118] Droms, R., Arbaugh, W., "Authentication for DHCP 459 Messages", RFC3118, June, 2001 461 Author's Addresses 463 Ted Lemon 464 Nominum 465 2385 Bay Road 466 Redwood City, CA 94063 USA 467 +1 650 381 6000 468 mellon@nominum.com 470 Bill Sommerfeld 471 Sun Microsystems 472 1 Network Drive 473 Burlington, MA 01824 474 +1 781 442 3458 475 sommerfeld@sun.com 477 Full Copyright Statement 479 Copyright (C) The Internet Society (2005). This document is 480 subject to the rights, licenses and restrictions contained in BCP 481 78, and except as set forth therein, the authors retain all their 482 rights. 484 This document and the information contained herein are provided on 485 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 486 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 487 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 488 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 489 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 490 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 491 PARTICULAR PURPOSE. 493 Intellectual Property 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed to 497 pertain to the implementation or use of the technology described in 498 this document or the extent to which any license under such rights 499 might or might not be available; nor does it represent that it has 500 made any independent effort to identify any such rights. Information 501 on the procedures with respect to rights in RFC documents can be 502 found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use of 507 such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository at 509 http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at ietf- 515 ipr@ietf.org. 517 Acknowledgement 519 Funding for the RFC Editor function is currently provided by the 520 Internet Society.