idnits 2.17.1 draft-ietf-dhc-mac-assign-06.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 (May 4, 2020) is 1452 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-07 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: November 5, 2020 ISC 6 CJ. Bernardos 7 UC3M 8 May 4, 2020 10 Link-Layer Addresses Assignment Mechanism for DHCPv6 11 draft-ietf-dhc-mac-assign-06 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 November 5, 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 . . . . . . . . . . . . . . . . . . . . . 9 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 authority that would be able to assign locally unique MAC 97 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 DHCP terminology relevant to this specification from [RFC8415] 138 applies here. 140 client A device that is interested in obtaining link-layer 141 addresses. It implements the basic DHCP mechanisms 142 needed by a DHCP 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 IPv6 address assignment and prefix delegation as 146 specified in [RFC8415]. 148 server Software that manages link-layer address allocation and 149 is able to respond to client queries. It implements 150 basic DHCP 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 IPv6 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 IEEE 802. 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 addresses (an address 177 block), to be then assigned for use to the final end-devices. One 178 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 addresses to those machines. 182 The hypervisor does not use those addresses for itself, but rather 183 uses them to create new VMs with appropriate addresses. It is worth 184 pointing out the cumulative nature of this scenario. Over time, the 185 hypervisor is likely to increase its addresses usage. Some obsolete 186 VMs will be deleted and their addresses will be eligible for reuse 187 for new VMs. 189 4.2. Direct client mode scenario 191 This mode is used when an entity acts as a DHCP client and requests 192 available DHCP servers to assign one or more addresses (an address 193 block) for its own use. This usage scenario is related to IoT 194 (Internet of Things). With the emergence of IoT, a new class of 195 cheap, sometimes short lived and disposable devices, has emerged. 196 Examples may include various sensors (e.g. medical) and actuators or 197 controllable LED lights. Upon first boot, the device uses a 198 temporary address, as described in [IEEE-802.11-02-109r0], to send 199 initial DHCP packets to available DHCP servers. Then, such devices 200 would typically request a single address for each available network 201 interface, which typically means one address per device. Once the 202 server assigns a address, the device abandons its temporary address 203 and uses the assigned (leased) address. 205 Note that a client that operates as above that does not have a 206 globally unique link-layer address on any of its interfaces MUST NOT 207 use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT 208 or DUID-LL. For more details, refer to Section 11 of [RFC8415]. 210 4.3. Mechanism Overview 212 In all scenarios the protocol operates in fundamentally the same way. 213 The device requesting an address, acting as a DHCP client, will send 214 a Solicit message with a IA_LL option to all available DHCP servers. 215 That IA_LL option MUST include a LLADDR option specifying the link- 216 layer-type and link-layer-len and may specify a specific address or 217 address block as a hint for the server. Each available server 218 responds with an Advertise message with offered address or addresses. 219 The client then picks the best server, as governed by [RFC8415], and 220 will send a Request message. The target server will then assign the 221 addresses and send a Reply message. Upon reception, the client can 222 start using those addresses. 224 Normal DHCP mechanisms are in use. The client is expected to 225 periodically renew the addresses as governed by T1 and T2 timers. 226 This mechanism can be administratively disabled by the server sending 227 "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). 229 The client can release addresses when they are no longer needed by 230 sending a Release message (see Section 18.2.7 of [RFC8415]). 232 Figure 1, taken from [RFC8415], shows a timeline diagram of the 233 messages exchanged between a client and two servers for the typical 234 lifecycle of one or more leases 236 Server Server 238 (not selected) Client (selected) 240 v v v 241 | | | 242 | Begins initialization | 243 | | | 244 start of | _____________/|\_____________ | 245 4-message |/ Solicit | Solicit \| 246 exchange | | | 247 Determines | Determines 248 configuration | configuration 249 | | | 250 |\ | ____________/| 251 | \________ | /Advertise | 252 | Advertise\ |/ | 253 | \ | | 254 | Collects Advertises | 255 | \ | | 256 | Selects configuration | 257 | | | 258 | _____________/|\_____________ | 259 |/ Request | Request \| 260 | | | 261 | | Commits configuration 262 | | | 263 end of | | _____________/| 264 4-message | |/ Reply | 265 exchange | | | 266 | Initialization complete | 267 | | | 268 . . . 269 . . . 270 | T1 (Renewal) Timer Expires | 271 | | | 272 2-message | _____________/|\_____________ | 273 exchange |/ Renew | Renew \| 274 | | | 275 | | Commits extended lease(s) 276 | | | 277 | | _____________/| 278 | |/ Reply | 279 . . . 280 . . . 281 | | | 282 | Graceful shutdown | 283 | | | 284 2-message | _____________/|\_____________ | 285 exchange |/ Release | Release \| 286 | | | 287 | | Discards lease(s) 288 | | | 289 | | _____________/| 290 | |/ Reply | 291 | | | 292 v v v 294 Figure 1: Timeline diagram of the messages exchanged between a client 295 and two servers for the typical lifecycle of one or more leases 297 Confirm, Decline, and Information-Request messages are not used in 298 link-layer address assignment. 300 Clients implementing this mechanism SHOULD use the Rapid Commit 301 option as specified in Section 5.1 and 18.2.1 of [RFC8415]. 303 An administrator may make the address assignment permanent by 304 specifying use of infinite lifetimes, as defined in Section 7.7 of 305 [RFC8415]. An administrator may also disable the need for the 306 renewal mechanism by setting the T1 and T2 values to infinity. 308 Devices supporting this proposal MAY support the reconfigure 309 mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported 310 by both server and client, this mechanism allows the administrator to 311 immediately notify clients that the configuration has changed and 312 triggers retrieval of relevant changes immediately, rather than after 313 the T1 timer elapses. Since this mechanism requires implementation 314 of Reconfigure Key Authentication Protocol (See Section 20.4 of 315 [RFC8415]), small footprint devices may choose to not support it. 317 5. Design Assumptions 319 One of the essential aspects of this mechanism is its cumulative 320 nature, especially in the hypervisor scenario. The server-client 321 relationship does not look like other DHCP transactions. This is 322 especially true in the hypervisor scenario. In a typical 323 environment, there would be one server and a rather small number of 324 hypervisors, possibly even only one. However, over time the number 325 of addresses requested by the hypervisor(s) will likely increase as 326 new VMs are spawned. 328 Another aspect crucial for efficient design is the observation that a 329 single client acting as hypervisor will likely use thousands of 330 addresses. Therefore an approach similar to what is used for IPv6 331 address or prefix assignment (IA container with all assigned 332 addresses listed, one option for each address) would not work well. 333 Therefore the mechanism should operate on address blocks, rather than 334 single values. A single address can be treated as an address block 335 with just one address. 337 The DHCP mechanisms are reused to large degree, including message and 338 option formats, transmission mechanisms, relay infrastructure and 339 others. However, a device wishing to support only link-layer address 340 assignment is not required to support full DHCP. In other words, the 341 device may support only assignment of link-layer addresses, but not 342 IPv6 addresses or prefixes. 344 6. Information Encoding 346 A client MUST send a LLADDR option encapsulated in an IA_LL option to 347 specify the link-layer-type and link-layer-len values. For link- 348 layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client 349 sets the link-layer-address field to: 351 1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 352 the starting address of the unicast address block. This address 353 has the IEEE 802 individual/group bit set to 0 (individual). 355 2. Any other value to request a specific block of address starting 356 with the specified address 358 A client sets the extra-addresses field to either 0 for a single 359 address or to the size of the requested address block minus 1. 361 A client SHOULD set the valid-lifetime field to 0 (this field MUST be 362 ignored by the server). 364 7. Requesting Addresses 366 The addresses are assigned in blocks. The smallest block is a single 367 address. To request an assignment, the client sends a Solicit 368 message with an IA_LL option in the message. The IA_LL option MUST 369 contain a LLADDR option as specified in Section 6. 371 The server, upon receiving an IA_LL option, inspects its content and 372 may offer an address or addresses for each LLADDR option according to 373 its policy. The server MAY take into consideration the address block 374 requested by the client in the LLADDR option. However, the server 375 MAY chose to ignore some or all parameters of the requested address 376 block. In particular, the server may send a different starting 377 address than requested, or grant a smaller number of addresses than 378 requested. The server sends back an Advertise message an IA_LL 379 option containing an LLADDR option that specifies the addresses being 380 offered. If the server is unable to provide any addresses it MUST 381 return the IA_LL option containing a Status Code option (see 382 Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. 384 The client MUST be able to handle an Advertise message containing a 385 smaller number of addresses, or an address or addresses different 386 than those requested. 388 The client waits for available servers to send Advertise responses 389 and picks one server as defined in Section 18.2.9 of [RFC8415]. The 390 client then sends a Request message that includes the IA_LL container 391 option with the LLADDR option copied from the Advertise message sent 392 by the chosen server. 394 Upon reception of a Request message with IA_LL container option, the 395 server assigns requested addresses. The server allocates block of 396 addresses according to its configured policy. The server MAY assign 397 a different block than requested in the Request message. It then 398 generates and sends a Reply message back to the client. 400 Upon receiving a Reply message, the client parses the IA_LL container 401 option and may start using all provided addresses. It MUST restart 402 its T1 and T2 timers using the values specified in the IA_LL option. 404 The client MUST be able to handle a Reply message containing a 405 smaller number of addresses, or an address or addresses different 406 than those requested. 408 A client that has included a Rapid Commit option in the Solicit, may 409 receive a Reply in response to the Solicit and skip the Advertise and 410 Request steps above (see Section 18.2.1 of [RFC8415]). 412 A client that changes its link-layer address on an interface SHOULD 413 follow the recommendations in Section 7.2.6 of [RFC4861] to inform 414 its neighbors of the new link-layer address quickly. 416 8. Renewing Addresses 418 Address renewals follow the normal DHCP renewals processing described 419 in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the 420 client starts sending Renew messages with the IA_LL option containing 421 a LLADDR option for the address block being renewed. The server 422 responds with a Reply message that contains the renewed address 423 block. The server MUST NOT shrink or expand the address block - once 424 a block is assigned and has a non-zero valid lifetime, its size, 425 starting address, and ending address MUST NOT change. 427 If the requesting client needs additional addresses -- e.g., in the 428 hypervisor scenario because addresses need to be assigned to new VMs 429 -- the simpler approach is for the requesting device to keep the 430 address blocks as atomic once "leased". Therefore, if a client wants 431 more addresses at a later stage, it SHOULD send an IA_LL option with 432 a different IAID to create another "container" for more addresses. 434 If the client is unable to Renew before the T2 timer elapses, it 435 starts sending Rebind messages as described in 18.2.5 of [RFC8415]. 437 9. Releasing Addresses 439 The client may decide to release a leased address block. A client 440 MUST release the whole block in its entirety. A client releases an 441 address block by sending a Release message that includes the IA_LL 442 option containing the LLADDR option for the address block to release. 443 The Release transmission mechanism is described in Section 18.2.7 of 444 [RFC8415]. 446 10. Option Definitions 448 This mechanism uses an approach similar to the existing mechanisms in 449 DHCP. There is one container option (the IA_LL option) that contains 450 the actual address or addresses, represented by an LLADDR option. 451 Each such option represents an address block, which is expressed as a 452 first address with a number that specifies how many additional 453 addresses are included. 455 10.1. Identity Association for Link-Layer Addresses Option 457 The Identity Association for Link-Layer Addresses option (IA_LL 458 option) is used to carry one or more IA_LL options, the parameters 459 associated with the IA_LL, and the address blocks associated with the 460 IA_LL. 462 The format of the IA_LL option is: 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | OPTION_IA_LL | option-len | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | IAID (4 octets) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | T1 (4 octets) | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | T2 (4 octets) | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 . . 474 . IA_LL-options . 475 . . 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 2: IA_LL Option Format 480 option-code OPTION_IA_LL (tbd1). 482 option-len 12 + length of IA_LL-options field. 484 IAID The unique identifier for this IA_LL; the IAID must 485 be unique among the identifiers for all of this 486 client's IA_LLs. The number space for IA_LL IAIDs is 487 separate from the number space for other IA option 488 types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet 489 field containing an unsigned integer. 491 T1 The time at which the client should contact the 492 server from which the addresses in the IA_LL were 493 obtained to extend the valid lifetime of the 494 addresses assigned to the IA_LL; T1 is a time 495 duration relative to the current time expressed in 496 units of seconds. A 4-octet field containing an 497 unsigned integer. 499 T2 The time at which the client should contact any 500 available server to extend the valid lifetime of the 501 addresses assigned to the IA_LL; T2 is a time 502 duration relative to the current time expressed in 503 units of seconds. A 4-octet field containing an 504 unsigned integer. 506 IA_LL-options Options associated with this IA_LL. A variable 507 length field (12 octets less than the value in the 508 option-len field). 510 An IA_LL option may only appear in the options area of a DHCP 511 message. A DHCP message may contain multiple IA_LL options (though 512 each must have a unique IAID). 514 The status of any operations involving this IA_LL is indicated in a 515 Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- 516 options field. 518 Note that an IA_LL has no explicit "lifetime" or "lease length" of 519 its own. When the valid lifetimes of all of the addresses in an 520 IA_LL have expired, the IA_LL can be considered as having expired. 521 T1 and T2 are included to give servers explicit control over when a 522 client recontacts the server about a specific IA_LL. 524 In a message sent by a client to a server, the T1 and T2 fields 525 SHOULD be set to 0. The server MUST ignore any values in these 526 fields in messages received from a client. 528 In a message sent by a server to a client, the client MUST use the 529 values in the T1 and T2 fields for the T1 and T2 times, unless those 530 values in those fields are 0. The values in the T1 and T2 fields are 531 the number of seconds until T1 and T2. 533 As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to 534 mean "infinity" and should be used carefully. 536 The server selects the T1 and T2 times to allow the client to extend 537 the lifetimes of any address block in the IA_LL before the lifetimes 538 expire, even if the server is unavailable for some short period of 539 time. Recommended values for T1 and T2 are .5 and .8 times the 540 shortest valid lifetime of the address blocks in the IA that the 541 server is willing to extend, respectively. If the "shortest" valid 542 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 543 are also 0xffffffff. If the time at which the addresses in an IA_LL 544 are to be renewed is to be left to the discretion of the client, the 545 server sets T1 and T2 to 0. The client MUST follow the rules defined 546 in Section 14.2 in [RFC8415]. 548 If a client receives an IA_LL with T1 greater than T2, and both T1 549 and T2 are greater than 0, the client discards the IA_LL option and 550 processes the remainder of the message as though the server had not 551 included the invalid IA_LL option. 553 10.2. Link-Layer Addresses Option 555 The Link-Layer Addresses option is used to specify an address block 556 associated with a IA_LL. The option must be encapsulated in the 557 IA_LL-options field of an IA_LL option. The LLaddr-options fields 558 encapsulates those options that are specific to this address block. 560 The format of the Link-Layer Addresses option is: 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | OPTION_LLADDR | option-len | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | link-layer-type | link-layer-len | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 . . 570 . link-layer-address . 571 . . 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | extra-addresses | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | valid-lifetime | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 . . 578 . LLaddr-options . 579 . . 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 3: LLADDR Option Format 584 option-code OPTION_LLADDR (tbd2). 586 option-len 12 + link-layer-len field (typically 6) + length of 587 LLaddr-options field. Assuming a typical link-layer 588 address of 6 is used and there are no extra options, 589 length should be equal to 18. 591 link-layer-type The link-layer type MUST be a valid hardware type 592 assigned by the IANA, as described in [RFC5494] and 593 in the "Hardware Types" table at 594 https://www.iana.org/assignments/arp-parameters. A 595 2-octet field containing an unsigned integer. 597 link-layer-len Specifies the length, in octets, of the link-layer- 598 address field (typically 6, for a link-layer-type of 599 1 (Ethernet)). A 2-octet field containing an 600 unsigned integer. 602 link-layer-address Specifies the link-layer address that is being 603 requested or renewed, or a special value to request 604 any address. For a link-layer type of 1 (Ethernet / 605 IEEE 802 48-bit MAC addresses), see Section 6 for 606 details on these values. In responses from a server, 607 this value specifies the first address allocated. 609 extra-addresses Number of additional addresses that follow the 610 address specified in link-layer-address. For a 611 single address, 0 is used. For example: link-layer- 612 address: 02:04:06:08:0a and extra-addresses 3 613 designates a block of 4 addresses, starting from 614 02:04:06:08:0a and ending with 02:04:06:08:0d 615 (inclusive). In responses from a server, this value 616 specifies the number of additional addresses 617 allocated. A 4-octet field containing an unsigned 618 integer. 620 valid-lifetime The valid lifetime for the address(es) in the option, 621 expressed in units of seconds. A 4-octet field 622 containing an unsigned integer. 624 LLaddr-options Any encapsulated options that are specific to this 625 particular address block. Currently there are no 626 such options defined, but there may be in the future. 628 In a message sent by a client to a server, the valid lifetime field 629 SHOULD be set to 0. The server MUST ignore any received value. 631 In a message sent by a server to a client, the client MUST use the 632 value in the valid lifetime field for the valid lifetime for the 633 address block. The value in the valid lifetime field is the number 634 of seconds remaining in the lifetime. 636 As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is 637 taken to mean "infinity" and should be used carefully. 639 More than one LLADDR option can appear in an IA_LL option. 641 11. Selecting Link-Layer Addresses for Assignment to an IA_LL 643 A server selects link-layer addresses to be assigned to an IA_LL 644 according to the assignment policies determined by the server 645 administrator. 647 Link-layer addresses are typically specific to a link and the server 648 SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the 649 client's link. 651 For Ethernet / IEEE 802 MAC addresses, a server MAY use additional 652 options supplied by a relay agent or client to select the quadrant 653 (see Appendix A) from which addresses are to be assigned. This MAY 654 include new options, such as those specified in 655 [I-D.ietf-dhc-slap-quadrant]. 657 12. IANA Considerations 659 IANA is requested to assign the OPTION_IA_LL (tbd1) option code from 660 the DHCPv6 "Option Codes" registry maintained at 661 http://www.iana.org/assignments/dhcpv6-parameters and use the 662 following data when adding the option to the registry: 664 Value: tbd1 665 Description: OPTION_IA_LL 666 Client ORO: No 667 Singleton Option: No 668 Reference: this document 670 IANA is requested to assign the OPTION_LLADDR (tbd2) 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: tbd2 676 Description: OPTION_LLADDR 677 Client ORO: No 678 Singleton Option: No 679 Reference: this document 681 13. Security Considerations 683 See [RFC8415] for the DHCP security considerations. See [RFC8200] 684 for the IPv6 security considerations. 686 There is a possibility of the same link-layer address being used by 687 more than one device if not all parties on a link use this mechanism 688 to obtain a link-layer address from the space assigned to the DHCP 689 server. It is also possible that a bad actor purposely uses a 690 device's link-layer address. 692 14. Privacy Considerations 694 See [RFC8415] for the DHCP privacy considerations. 696 For a client requesting a link-layer address directly from a server, 697 as the address assigned to a client will likely be used by the client 698 to communicate on the link, the address will be exposed to those able 699 to listen in on this communication. For those peers on the link that 700 are able to listen in on the DHCP exchange, they would also be able 701 to correlate the client's identity (based on the DUID used) with the 702 assigned address. Additional mechanisms, such as the ones described 703 in [RFC7844] can also be used. 705 15. Acknowledgements 707 Thanks to the DHC Working Group participants that reviewed this 708 document, provided comments, and support. With special thanks to Ian 709 Farrer for his thorough reviews and shepherding of this document 710 through the IETF process. 712 16. References 714 16.1. Normative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 722 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 723 DOI 10.17487/RFC4861, September 2007, 724 . 726 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 727 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 728 May 2017, . 730 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 731 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 732 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 733 RFC 8415, DOI 10.17487/RFC8415, November 2018, 734 . 736 16.2. Informative References 738 [I-D.ietf-dhc-slap-quadrant] 739 Bernardos, C. and A. Mourad, "SLAP quadrant selection 740 options for DHCPv6", draft-ietf-dhc-slap-quadrant-07 (work 741 in progress), April 2020. 743 [IEEE-802-Tutorial] 744 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", 745 . 748 [IEEE-802.11-02-109r0] 749 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 750 "Temporary MAC address for anonymity", 751 . 754 [IEEEStd802c-2017] 755 IEEE Computer Society, "IEEE Standard for Local and 756 Metropolitan Area Networks: Overview and Architecture, 757 Amendment 2: Local Medium Access Control (MAC) Address 758 Usage, IEEE Std 802c-2017". 760 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 761 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 762 . 764 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 765 for the Address Resolution Protocol (ARP)", RFC 5494, 766 DOI 10.17487/RFC5494, April 2009, 767 . 769 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 770 Profiles for DHCP Clients", RFC 7844, 771 DOI 10.17487/RFC7844, May 2016, 772 . 774 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 775 (IPv6) Specification", STD 86, RFC 8200, 776 DOI 10.17487/RFC8200, July 2017, 777 . 779 Appendix A. IEEE 802c Summary 781 This appendix provides a brief summary of IEEE 802c from 782 [IEEEStd802c-2017]. 784 The original IEEE 802 specifications assigned half of the 48-bit MAC 785 address space to local use -- these addresses have the U/L bit set to 786 1 and are locally administered with no imposed structure. 788 In 2017, the IEEE issued the 802c specification which defines a new 789 "optional Structured Local Address Plan (SLAP) that specifies 790 different assignment approaches in four specified regions of the 791 local MAC address space." Under this plan, there are 4 SLAP 792 quadrants that use different assignment policies. 794 The first octet of the MAC address Z and Y bits define the quadrant 795 for locally assigned addresses (X-bit is 1). In IEEE representation, 796 these bits are as follows: 798 LSB MSB 799 M X Y Z - - - - 800 | | | | 801 | | | +------------ SLAP Z-bit 802 | | +--------------- SLAP Y-bit 803 | +------------------ X-bit (U/L) = 1 for locally assigned 804 +--------------------- M-bit (I/G) (unicast/group) 806 Figure 4: SLAP Bits 808 The SLAP quadrants are: 810 +----------+-------+-------+-----------------------+----------------+ 811 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 812 | | | | | Identifier | 813 +----------+-------+-------+-----------------------+----------------+ 814 | 01 | 0 | 1 | Extended Local | ELI | 815 | 11 | 1 | 1 | Standard Assigned | SAI | 816 | 00 | 0 | 0 | Administratively | AAI | 817 | | | | Assigned | | 818 | 10 | 1 | 0 | Reserved | Reserved | 819 +----------+-------+-------+-----------------------+----------------+ 821 SLAP Quadrants 823 Extended Local Identifier (ELI) derived MAC addresses are based on an 824 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 825 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 826 locally assigned address for each CID for unicast (M-bit = 0) and 827 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 829 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 830 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 831 addresses, 44 bits are available. Multiple protocols for assigning 832 SAIs may be specified in IEEE standards. Coexistence of multiple 833 protocols may be supported by limiting the subspace available for 834 assignment by each protocol. 836 Administratively Assigned Identifier (AAI) derived MAC addresses are 837 assigned locally. Administrators manage the space as needed. Note 838 that multicast IPv6 packets ([RFC2464]) use a destination address 839 starting in 33-33 and this falls within this space and therefore 840 should not be used to avoid conflict with IPv6 multicast addresses. 841 For 48-bit MAC addresses, 44 bits are available. 843 The last quadrant is reserved for future use. While this quadrant 844 may also be used for AAI space, administrators should be aware that 845 future specifications may define alternate uses that could be 846 incompatible. 848 Authors' Addresses 850 Bernie Volz 851 Cisco Systems, Inc. 852 1414 Massachusetts Ave 853 Boxborough, MA 01719 854 USA 856 Email: volz@cisco.com 858 Tomek Mrugalski 859 Internet Systems Consortium, Inc. 860 950 Charter Street 861 Redwood City, CA 94063 862 USA 864 Email: tomasz.mrugalski@gmail.com 866 Carlos J. Bernardos 867 Universidad Carlos III de Madrid 868 Av. Universidad, 30 869 Leganes, Madrid 28911 870 Spain 872 Phone: +34 91624 6236 873 Email: cjbc@it.uc3m.es 874 URI: http://www.it.uc3m.es/cjbc/