idnits 2.17.1 draft-ietf-dhc-mac-assign-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 16, 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dhc-slap-quadrant-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) B. Volz 3 Internet-Draft Cisco 4 Intended status: Standards Track T. Mrugalski 5 Expires: September 17, 2020 ISC 6 CJ. Bernardos 7 UC3M 8 March 16, 2020 10 Link-Layer Addresses Assignment Mechanism for DHCPv6 11 draft-ietf-dhc-mac-assign-05 13 Abstract 15 In certain environments, e.g. large scale virtualization deployments, 16 new devices are created in an automated manner. Such devices 17 typically have their link-layer (MAC) addresses randomized. With 18 sufficient scale, the likelihood of collision is not acceptable. 19 Therefore an allocation mechanism is required. This draft proposes 20 an extension to DHCPv6 that allows a scalable approach to link-layer 21 address assignments. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 17, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Deployment scenarios and mechanism overview . . . . . . . . . 4 61 4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4 62 4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5 63 4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 64 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 7 65 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 8 66 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 8 67 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 10 68 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 10 69 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. Identity Association for Link-Layer Addresses Option . . 10 71 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12 72 11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 76 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 16.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 There are several new deployment types that deal with a large number 86 of devices that need to be initialized. One of them is a scenario 87 where virtual machines (VMs) are created on a massive scale. 88 Typically the new VM instances are assigned a random link-layer (MAC) 89 address, but that does not scale well due to the birthday paradox. 90 Another use case is IoT devices. The huge number of such devices 91 would likely exhaust a vendor's OUI (Organizationally Unique 92 Identifier) global address space, and while there is typically no 93 need to provide global uniqueness for such devices, a link-layer 94 assignment mechanisms allows for conflicts to be avoided inside an 95 administrative domain. For those reasons, it is desired to have some 96 form of local authority that would be able to assign locally unique 97 MAC addresses. 99 This document proposes a new mechanism that extends DHCPv6 operation 100 to handle link-layer address assignments. 102 Since DHCPv6 ([RFC8415]) is a protocol that can allocate various 103 types of resources (non-temporary addresses, temporary addresses, 104 prefixes, but also many options) and has necessary infrastructure 105 (numerous server and client implementations, large deployed relay 106 infrastructure, supportive solutions, like leasequery and failover) 107 to maintain such assignment, it is a good candidate to address the 108 desired functionality. 110 While this document presents a design that should be usable for any 111 link-layer address type, some of the details are specific to Ethernet 112 / IEEE 802 48-bit MAC addresses. Future documents may provide 113 specifics for other link-layer address types. 115 The IEEE originally set aside half of the 48-bit MAC Address space 116 for local use (where the U/L bit is set to 1). In 2017, the IEEE 117 specified an optional specification (IEEE 802c) that divides this 118 space into quadrants (Standards Assigned Identifier, Extended Local 119 Identifier, Administratively Assigned Identifier, and a Reserved 120 quadrant) - more details are in Appendix A. 122 The IEEE is also working to specify protocols and procedures for 123 assignment of locally unique addresses (IEEE 802.1cq). This work may 124 serve as one such protocol for assignment. For additional 125 background, see [IEEE-802-Tutorial]. 127 2. Requirements 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. Terminology 137 The DHCPv6 terminology relevant to this specification from the DHCPv6 138 Protocol [RFC8415] applies here. 140 client A device that is interested in obtaining link-layer 141 addresses. It implements the basic DHCPv6 mechanisms 142 needed by a DHCPv6 client as described in [RFC8415] and 143 supports the new options (IA_LL and LLADDR) specified 144 in this document. The client may or may not support 145 address assignment and prefix delegation as specified 146 in [RFC8415]. 148 server Software that manages link-layer address allocation and 149 is able to respond to client queries. It implements 150 basic DHCPv6 server functionality as described in 151 [RFC8415] and supports the new options (IA_LL and 152 LLADDR) specified in this document. The server may or 153 may not support address assignment and prefix 154 delegation as specified in [RFC8415]. 156 address Unless specified otherwise, an address means a link- 157 layer (or MAC) address, as defined in IEEE802. The 158 address is typically 6 octets long, but some network 159 architectures may use different lengths. 161 address block A number of consecutive link-layer addresses. An 162 address block is expressed as a first address plus a 163 number that designates the number of additional (extra) 164 addresses. A single address can be represented by the 165 address itself and zero extra addresses. 167 4. Deployment scenarios and mechanism overview 169 This mechanism is designed to be generic and usable in many 170 deployments, but there are two scenarios it attempts to address in 171 particular: (i) proxy client mode, and (ii) direct client mode. 173 4.1. Proxy client mode scenario 175 This mode is used when an entity acts as a DHCP client and requests 176 available DHCP servers to assign one or more MAC addresses (an 177 address block), to be then assigned for use to the final end-devices. 178 One relevant example of scenario of application of this mode is large 179 scale virtualization. In such environments the governing entity is 180 often called a hypervisor and is frequently required to spawn new 181 VMs. The hypervisor needs to assign new MAC addresses to those 182 machines. The hypervisor does not use those addresses for itself, 183 but rather uses them to create new VMs with appropriate MAC 184 addresses. It is worth pointing out the cumulative nature of this 185 scenario. Over time, the hypervisor is likely to increase its MAC 186 addresses usage. While some obsolete VMs will be deleted and their 187 MAC addresses will become eligible for release or reuse, it is 188 unexpected for all MAC addresses to be released. 190 4.2. Direct client mode scenario 192 This mode is used when an entity acts as a DHCP client and requests 193 available DHCP servers to assign one or more MAC addresses (an 194 address block) for its own use. This usage scenario is related to 195 IoT (Internet of Things). With the emergence of IoT, a new class of 196 cheap, sometimes short lived and disposable devices, has emerged. 197 Examples may include various sensors (e.g. medical) and actuators or 198 controllable LED lights. Upon first boot, the device uses a 199 temporary MAC address, as described in [IEEE-802.11-02-109r0], to 200 send initial DHCP packets to available DHCP servers. Then, such 201 devices would typically request a single MAC address for each 202 available network interface, which typically means one MAC address 203 per device. Once the server assigns a MAC address, the device 204 abandons its temporary MAC address and uses the assigned (leased) MAC 205 address. 207 Note that a client that operates as above that does not have a 208 globally unique link-layer address on any of its interfaces MUST NOT 209 use a DUID-LLT or DUID-LL (link-layer based DUID). For more details, 210 refer to Section 11 of [RFC8415]. 212 4.3. Mechanism Overview 214 In all scenarios the protocol operates in fundamentally the same way. 215 The device requesting an address, acting as a DHCP client, will send 216 a Solicit message with a IA_LL option to all available DHCP servers. 217 That IA_LL option MUST include a LLADDR option specifying the link- 218 layer-type and link-layer-len and may specify a specific address or 219 address block as a hint for the server. Each available server 220 responds with an Advertise message with offered link-layer address or 221 addresses. The client then picks the best server, as governed by 222 [RFC8415], and will send a Request message. The target server will 223 then assign the link-layer addresses and send a Reply message. Upon 224 reception, the client can start using those link-layer addresses. 226 Normal DHCP mechanisms are in use. The client is expected to 227 periodically renew the link-layer addresses as governed by T1 and T2 228 timers. This mechanism can be administratively disabled by the 229 server sending "infinity" as the T1 and T2 values (see Section 7.7 of 230 [RFC8415]). 232 The client can release link-layer addresses when they are no longer 233 needed by sending a Release message (see Section 18.2.7 of 234 [RFC8415]). 236 Figure 1, taken from [RFC8415], shows a timeline diagram of the 237 messages exchanged between a client and two servers for the typical 238 lifecycle of one or more leases 240 Server Server 241 (not selected) Client (selected) 243 v v v 244 | | | 245 | Begins initialization | 246 | | | 247 start of | _____________/|\_____________ | 248 4-message |/ Solicit | Solicit \| 249 exchange | | | 250 Determines | Determines 251 configuration | configuration 252 | | | 253 |\ | ____________/| 254 | \________ | /Advertise | 255 | Advertise\ |/ | 256 | \ | | 257 | Collects Advertises | 258 | \ | | 259 | Selects configuration | 260 | | | 261 | _____________/|\_____________ | 262 |/ Request | Request \| 263 | | | 264 | | Commits configuration 265 | | | 266 end of | | _____________/| 267 4-message | |/ Reply | 268 exchange | | | 269 | Initialization complete | 270 | | | 271 . . . 272 . . . 273 | T1 (Renewal) Timer Expires | 274 | | | 275 2-message | _____________/|\_____________ | 276 exchange |/ Renew | Renew \| 277 | | | 278 | | Commits extended lease(s) 279 | | | 280 | | _____________/| 281 | |/ Reply | 282 . . . 283 . . . 285 | | | 286 | Graceful shutdown | 287 | | | 288 2-message | _____________/|\_____________ | 289 exchange |/ Release | Release \| 290 | | | 291 | | Discards lease(s) 292 | | | 293 | | _____________/| 294 | |/ Reply | 295 | | | 296 v v v 298 Figure 1: Timeline diagram of the messages exchanged between a client 299 and two servers for the typical lifecycle of one or more leases 301 Confirm, Decline, and Information-Request messages are not used in 302 link-layer address assignment. 304 Clients implementing this mechanism SHOULD use the Rapid Commit 305 option as specified in Section 5.1 and 18.2.1 of [RFC8415]. 307 An administrator may make the address assignment permanent by 308 specifying use of infinite lifetimes, as defined in Section 7.7 of 309 [RFC8415]. An administrator may also disable the need for the 310 renewal mechanism by setting the T1 and T2 values to infinity. 312 Devices supporting this proposal MAY support the reconfigure 313 mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported 314 by both server and client, this mechanism allows the administrator to 315 immediately notify clients that the configuration has changed and 316 triggers retrieval of relevant changes immediately, rather than after 317 the T1 timer elapses. Since this mechanism requires implementation 318 of Reconfigure Key Authentication Protocol (See Section 20.4 of 319 [RFC8415]), small footprint devices may choose to not support it. 321 DISCUSSION: A device may send its link-layer address in a LLADDR 322 option to ask the server to register that address to the client (if 323 available), making the assignment permanent for the lease duration. 324 The client MUST be prepared to use a different address if the server 325 chooses not to honor its hint. 327 5. Design Assumptions 329 One of the essential aspects of this mechanism is its cumulative 330 nature, especially in the hypervisor scenario. The server-client 331 relationship does not look like other DHCP transactions. This is 332 especially true in the hypervisor scenario. In a typical 333 environment, there would be one server and a rather small number of 334 hypervisors, possibly even only one. However, over time the number 335 of MAC addresses requested by the hypervisor(s) will likely increase 336 as new VMs are spawned. 338 Another aspect crucial for efficient design is the observation that a 339 single client acting as hypervisor will likely use thousands of 340 addresses. Therefore an approach similar to what is used for address 341 or prefix assignment (IA container with all assigned addresses 342 listed, one option for each address) would not work well. Therefore 343 the mechanism should operate on address blocks, rather than single 344 values. A single address can be treated as an address block with 345 just one address. 347 The DHCPv6 mechanisms are reused to large degree, including message 348 and option formats, transmission mechanisms, relay infrastructure and 349 others. However, a device wishing to support only link-layer address 350 assignment is not required to support full DHCPv6. In other words, 351 the device may support only assignment of link-layer addresses, but 352 not IPv6 addresses or prefixes. 354 6. Information Encoding 356 A client MUST send a LLADDR option encapsulated in an IA_LL option to 357 specify the link-layer-type and link-layer-len values. For link- 358 layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client 359 sets the link-layer-address field to: 361 1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 362 the starting address of the unicast address block. This address 363 has the IEEE 802 individual/group bit set to 0 (individual). 365 2. Any other value to request a specific block of address starting 366 with the specified address 368 A client sets the extra-addresses field to either 0 for a single 369 address or to the size of the requested address block minus 1. 371 A client SHOULD set the valid-lifetime field to 0 (this field MUST be 372 ignored by the server). 374 7. Requesting Addresses 376 The link-layer addresses are assigned in blocks. The smallest block 377 is a single address. To request an assignment, the client sends a 378 Solicit message with an IA_LL option in the message. The IA_LL 379 option MUST contain a LLADDR option as specified in Section 6. 381 The server, upon receiving an IA_LL option, inspects its content and 382 may offer an address or addresses for each LLADDR option according to 383 its policy. The server MAY take into consideration the address block 384 requested by the client in the LLADDR option. However, the server 385 MAY chose to ignore some or all parameters of the requested address 386 block. In particular, the server may send a different starting 387 address than requested, or grant a smaller number of addresses than 388 requested. The server sends back an Advertise message an IA_LL 389 option containing an LLADDR option that specifies the addresses being 390 offered. If the server is unable to provide any addresses it MUST 391 return the IA_LL option containing a Status Code option (see 392 Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. 394 The client MUST be able to handle an Advertise message containing a 395 smaller number of addresses, or an address or addresses different 396 than those requested. 398 The client waits for available servers to send Advertise responses 399 and picks one server as defined in Section 18.2.9 of [RFC8415]. The 400 client then sends a Request message that includes the IA_LL container 401 option with the LLADDR option copied from the Advertise message sent 402 by the chosen server. 404 Upon reception of a Request message with IA_LL container option, the 405 server assigns requested addresses. The server allocates block of 406 addresses according to its configured policy. The server MAY assign 407 a different block than requested in the Request message. It then 408 generates and sends a Reply message back to the client. 410 Upon receiving a Reply message, the client parses the IA_LL container 411 option and may start using all provided addresses. It MUST restart 412 its T1 and T2 timers using the values specified in the IA_LL option. 414 The client MUST be able to handle a Reply message containing a 415 smaller number of addresses, or an address or addresses different 416 than those requested. 418 A client that has included a Rapid Commit option in the Solicit, may 419 receive a Reply in response to the Solicit and skip the Advertise and 420 Request steps above (see Section 18.2.1 of [RFC8415]). 422 A client that changes its link-layer address on an interface SHOULD 423 follow the recommendations in Section 7.2.6 of [RFC4861] to inform 424 its neighbors of the new link-layer address quickly. 426 8. Renewing Addresses 428 Address renewals follow the normal DHCPv6 renewals processing 429 described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, 430 the client starts sending Renew messages with the IA_LL option 431 containing a LLADDR option for the address block being renewed. The 432 server responds with a Reply message that contains the renewed 433 address block. The server SHOULD NOT alter the address block being 434 renewed, unless its policy has changed. The server MUST NOT shrink 435 or expand the address block - once a block is assigned and has a non- 436 zero valid lifetime, its size, starting address, and ending address 437 MUST NOT change. 439 If the requesting client needs additional MAC addresses -- e.g., in 440 the hypervisor scenario because addresses need to be assigned to new 441 VMs -- the simpler approach is for the requesting device to keep the 442 address blocks as atomic once "leased". Therefore, if a client wants 443 more addresses at a later stage, it SHOULD send an IA_LL option with 444 a different IAID to create another "container" for more addresses. 446 If the client is unable to Renew before the T2 timer elapses, it 447 starts sending Rebind messages as described in 18.2.5 of [RFC8415]. 449 9. Releasing Addresses 451 The client may decide to release a leased address block. A client 452 MUST release the whole block in its entirety. A client releases an 453 address block by sending a Release message that includes the IA_LL 454 option containing the LLADDR option for the address block to release. 455 The Release transmission mechanism is described in Section 18.2.7 of 456 [RFC8415]. 458 10. Option Definitions 460 This mechanism uses an approach similar to the existing mechanisms in 461 DHCP. There is one container option (the IA_LL option) that contains 462 the actual link-layer address or addresses, represented by an LLADDR 463 option. Each such option represents an address block, which is 464 expressed as a first address with a number that specifies how many 465 additional addresses are included. 467 10.1. Identity Association for Link-Layer Addresses Option 469 The Identity Association for Link-Layer Addresses option (IA_LL 470 option) is used to carry one or more IA_LL options, the parameters 471 associated with the IA_LL, and the address blocks associated with the 472 IA_LL. 474 The format of the IA_LL option is: 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | OPTION_IA_LL | option-len | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IAID (4 octets) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | T1 (4 octets) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | T2 (4 octets) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 . . 486 . IA_LL-options . 487 . . 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 2: IA_LL Option Format 492 option-code OPTION_IA_LL (tbd1). 494 option-len 12 + length of IA_LL-options field. 496 IAID The unique identifier for this IA_LL; the IAID must 497 be unique among the identifiers for all of this 498 client's IA_LLs. The number space for IA_LL IAIDs is 499 separate from the number space for other IA option 500 types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet 501 field containing an unsigned integer. 503 T1 The time at which the client should contact the 504 server from which the addresses in the IA_LL were 505 obtained to extend the valid lifetime of the 506 addresses assigned to the IA_LL; T1 is a time 507 duration relative to the current time expressed in 508 units of seconds. A 4-octet field containing an 509 unsigned integer. 511 T2 The time at which the client should contact any 512 available server to extend the valid lifetime of the 513 addresses assigned to the IA_LL; T2 is a time 514 duration relative to the current time expressed in 515 units of seconds. A 4-octet field containing an 516 unsigned integer. 518 IA_LL-options Options associated with this IA_LL. A variable 519 length field (12 octets less than the value in the 520 option-len field). 522 An IA_LL option may only appear in the options area of a DHCP 523 message. A DHCP message may contain multiple IA_LL options (though 524 each must have a unique IAID). 526 The status of any operations involving this IA_LL is indicated in a 527 Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- 528 options field. 530 Note that an IA_LL has no explicit "lifetime" or "lease length" of 531 its own. When the valid lifetimes of all of the addresses in an 532 IA_LL have expired, the IA_LL can be considered as having expired. 533 T1 and T2 are included to give servers explicit control over when a 534 client recontacts the server about a specific IA_LL. 536 In a message sent by a client to a server, the T1 and T2 fields 537 SHOULD be set to 0. The server MUST ignore any values in these 538 fields in messages received from a client. 540 In a message sent by a server to a client, the client MUST use the 541 values in the T1 and T2 fields for the T1 and T2 times, unless those 542 values in those fields are 0. The values in the T1 and T2 fields are 543 the number of seconds until T1 and T2. 545 As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to 546 mean "infinity" and should be used carefully. 548 The server selects the T1 and T2 times to allow the client to extend 549 the lifetimes of any address block in the IA_LL before the lifetimes 550 expire, even if the server is unavailable for some short period of 551 time. Recommended values for T1 and T2 are .5 and .8 times the 552 shortest valid lifetime of the address blocks in the IA that the 553 server is willing to extend, respectively. If the "shortest" valid 554 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 555 are also 0xffffffff. If the time at which the addresses in an IA_LL 556 are to be renewed is to be left to the discretion of the client, the 557 server sets T1 and T2 to 0. The client MUST follow the rules defined 558 in Section 14.2 in [RFC8415]. 560 If a client receives an IA_LL with T1 greater than T2, and both T1 561 and T2 are greater than 0, the client discards the IA_LL option and 562 processes the remainder of the message as though the server had not 563 included the invalid IA_LL option. 565 10.2. Link-Layer Addresses Option 567 The Link-Layer Addresses option is used to specify an address block 568 associated with a IA_LL. The option must be encapsulated in the 569 IA_LL-options field of an IA_LL option. The LLaddr-options fields 570 encapsulates those options that are specific to this address block. 572 The format of the Link-Layer Addresses option is: 574 0 1 2 3 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | OPTION_LLADDR | option-len | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | link-layer-type | link-layer-len | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 . . 582 . link-layer-address . 583 . . 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | extra-addresses | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | valid-lifetime | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 . . 590 . LLaddr-options . 591 . . 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Figure 3: LLADDR Option Format 596 option-code OPTION_LLADDR (tbd2). 598 option-len 12 + link-layer-len field (typically 6) + length of 599 LLaddr-options field. Assuming a typical link-layer 600 address of 6 is used and there are no extra options, 601 length should be equal to 18. 603 link-layer-type The link-layer type MUST be a valid hardware type 604 assigned by the IANA, as described in [RFC5494] and 605 in the "Hardware Types" table at 606 https://www.iana.org/assignments/arp-parameters. A 607 2-octet field containing an unsigned integer. 609 link-layer-len Specifies the length of the link-layer-address field 610 (typically 6, for a link-layer-type of 1 (Ethernet)). 611 A 2-octet field containing an unsigned integer. 613 link-layer-address Specifies the link-layer address that is being 614 requested or renewed, or a special value to request 615 any address. For a link-layer type of 1 (Ethernet / 616 IEEE 802 48-bit MAC addresses), see Section 6 for 617 details on these values. In responses from a server, 618 this value specifies the first address allocated. 620 extra-addresses Number of additional addresses that follow the 621 address specified in link-layer-address. For a 622 single address, 0 is used. For example: link-layer- 623 address: 02:04:06:08:0a and extra-addresses 3 624 designates a block of 4 addresses, starting from 625 02:04:06:08:0a (inclusive) and ending with 626 02:04:06:08:0d (inclusive). In responses from a 627 server, this value specifies the number of additional 628 addresses allocated. A 4-octet field containing an 629 unsigned integer. 631 valid-lifetime The valid lifetime for the address(es) in the option, 632 expressed in units of seconds. A 4-octet field 633 containing an unsigned integer. 635 LLaddr-options Any encapsulated options that are specific to this 636 particular address block. Currently there are no 637 such options defined, but there may be in the future. 639 In a message sent by a client to a server, the valid lifetime field 640 SHOULD be set to 0. The server MUST ignore any received value. 642 In a message sent by a server to a client, the client MUST use the 643 value in the valid lifetime field for the valid lifetime for the 644 address block. The value in the valid lifetime field is the number 645 of seconds remaining in the lifetime. 647 As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is 648 taken to mean "infinity" and should be used carefully. 650 More than one LLADDR option can appear in an IA_LL option. 652 11. Selecting Link-Layer Addresses for Assignment to an IA_LL 654 A server selects link-layer addresses to be assigned to an IA_LL 655 according to the assignment policies determined by the server 656 administrator. 658 Link-layer addresses are typically specific to a link and the server 659 SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the 660 client's link. 662 For Ethernet / IEEE 802 MAC addresses, a server MAY use additional 663 options supplied by a relay agent or client to select the quadrant 664 (see Appendix A) from which addresses are to be assigned. This MAY 665 include new options, such as those specified in 666 [I-D.ietf-dhc-slap-quadrant]. 668 12. IANA Considerations 670 IANA is requested to assign the OPTION_IA_LL (tbd1) option code from 671 the DHCPv6 "Option Codes" registry maintained at 672 http://www.iana.org/assignments/dhcpv6-parameters and use the 673 following data when adding the option to the registry: 675 Value: tbd1 676 Description: OPTION_IA_LL 677 Client ORO: No 678 Singleton Option: No 679 Reference: this document 681 IANA is requested to assign the OPTION_LLADDR (tbd2) option code from 682 the DHCPv6 "Option Codes" registry maintained at 683 http://www.iana.org/assignments/dhcpv6-parameters and use the 684 following data when adding the option to the registry: 686 Value: tbd2 687 Description: OPTION_LLADDR 688 Client ORO: No 689 Singleton Option: No 690 Reference: this document 692 13. Security Considerations 694 See [RFC8415] for the DHCPv6 security considerations. See [RFC8200] 695 for the IPv6 security considerations. 697 There is a possibility of the same link-layer address being used by 698 more than one device if not all parties on a link use this mechanism 699 to obtain a link-layer address from the space assigned to the DHCP 700 server. It is also possible that a bad actor purposely uses a 701 device's link-layer address. 703 14. Privacy Considerations 705 See [RFC8415] for the DHCPv6 privacy considerations. 707 For a client requesting a link-layer address directly from a server, 708 as the link-layer address assigned to a client will likely be used by 709 the client to communicate on the link, the address will be exposed to 710 those able to listen in on this communication. For those peers on 711 the link that are able to listen in on the DHCPv6 exchange, they 712 would also be able to correlate the client's identity (based on the 713 DUID used) with the assigned address. Additional mechanisms, such as 714 the ones described in [RFC7844] can also be used. 716 15. Acknowledgements 718 Thanks to the DHC Working Group participants that reviewed this 719 document, provided comments, and support. With special thanks to Ian 720 Farrer for his thorough reviews and shepherding of this document 721 through the IETF process. 723 16. References 725 16.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 733 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 734 DOI 10.17487/RFC4861, September 2007, 735 . 737 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 738 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 739 May 2017, . 741 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 742 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 743 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 744 RFC 8415, DOI 10.17487/RFC8415, November 2018, 745 . 747 16.2. Informative References 749 [I-D.ietf-dhc-slap-quadrant] 750 Bernardos, C. and A. Mourad, "SLAP quadrant selection 751 options for DHCPv6", draft-ietf-dhc-slap-quadrant-06 (work 752 in progress), March 2020. 754 [IEEE-802-Tutorial] 755 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", 756 . 759 [IEEE-802.11-02-109r0] 760 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 761 "Temporary MAC address for anonymity", 762 . 765 [IEEEStd802c-2017] 766 IEEE Computer Society, "IEEE Standard for Local and 767 Metropolitan Area Networks: Overview and Architecture, 768 Amendment 2: Local Medium Access Control (MAC) Address 769 Usage, IEEE Std 802c-2017". 771 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 772 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 773 . 775 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 776 for the Address Resolution Protocol (ARP)", RFC 5494, 777 DOI 10.17487/RFC5494, April 2009, 778 . 780 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 781 Profiles for DHCP Clients", RFC 7844, 782 DOI 10.17487/RFC7844, May 2016, 783 . 785 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 786 (IPv6) Specification", STD 86, RFC 8200, 787 DOI 10.17487/RFC8200, July 2017, 788 . 790 Appendix A. IEEE 802c Summary 792 This appendix provides a brief summary of IEEE802c from 793 [IEEEStd802c-2017]. 795 The original IEEE 802 specifications assigned half of the 48-bit MAC 796 address space to local use -- these addresses have the U/L bit set to 797 1 and are locally administered with no imposed structure. 799 In 2017, the IEEE issued the 802c specification which defines a new 800 "optional Structured Local Address Plan (SLAP) that specifies 801 different assignment approaches in four specified regions of the 802 local MAC address space." Under this plan, there are 4 SLAP 803 quadrants that use different assignment policies. 805 The first octet of the MAC address Z and Y bits define the quadrant 806 for locally assigned addresses (X-bit is 1). In IEEE representation, 807 these bits are as follows: 809 LSB MSB 810 M X Y Z - - - - 811 | | | | 812 | | | +------------ SLAP Z-bit 813 | | +--------------- SLAP Y-bit 814 | +------------------ X-bit (U/L) = 1 for locally assigned 815 +--------------------- M-bit (I/G) (unicast/group) 817 Figure 4: SLAP Bits 819 The SLAP quadrants are: 821 +----------+-------+-------+-----------------------+----------------+ 822 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 823 | | | | | Identifier | 824 +----------+-------+-------+-----------------------+----------------+ 825 | 01 | 0 | 1 | Extended Local | ELI | 826 | 11 | 1 | 1 | Standard Assigned | SAI | 827 | 00 | 0 | 0 | Administratively | AAI | 828 | | | | Assigned | | 829 | 10 | 1 | 0 | Reserved | Reserved | 830 +----------+-------+-------+-----------------------+----------------+ 832 SLAP Quadrants 834 Extended Local Identifier (ELI) derived MAC addresses are based on an 835 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 836 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 837 locally assigned address for each CID for unicast (M-bit = 0) and 838 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 840 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 841 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 842 addresses, 44 bits are available. Multiple protocols for assigning 843 SAIs may be specified in IEEE standards. Coexistence of multiple 844 protocols may be supported by limiting the subspace available for 845 assignment by each protocol. 847 Administratively Assigned Identifier (AAI) derived MAC addresses are 848 assigned locally. Administrators manage the space as needed. Note 849 that multicast IPv6 packets ([RFC2464]) use a destination address 850 starting in 33-33 and this falls within this space and therefore 851 should not be used to avoid conflict with IPv6 multicast addresses. 852 For 48-bit MAC addresses, 44 bits are available. 854 The last quadrant is reserved for future use. While this quadrant 855 may also be used for AAI space, administrators should be aware that 856 future specifications may define alternate uses that could be 857 incompatible. 859 Authors' Addresses 861 Bernie Volz 862 Cisco Systems, Inc. 863 1414 Massachusetts Ave 864 Boxborough, MA 01719 865 USA 867 Email: volz@cisco.com 869 Tomek Mrugalski 870 Internet Systems Consortium, Inc. 871 950 Charter Street 872 Redwood City, CA 94063 873 USA 875 Email: tomasz.mrugalski@gmail.com 877 Carlos J. Bernardos 878 Universidad Carlos III de Madrid 879 Av. Universidad, 30 880 Leganes, Madrid 28911 881 Spain 883 Phone: +34 91624 6236 884 Email: cjbc@it.uc3m.es 885 URI: http://www.it.uc3m.es/cjbc/