idnits 2.17.1 draft-ietf-dhc-mac-assign-03.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 (January 13, 2020) is 1558 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-02 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: July 16, 2020 ISC 6 CJ. Bernardos 7 UC3M 8 January 13, 2020 10 Link-Layer Addresses Assignment Mechanism for DHCPv6 11 draft-ietf-dhc-mac-assign-03 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 July 16, 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 . . . . . . . . . . . . . . . 4 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 15.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 There are several new deployment types that deal with a large number 85 of devices that need to be initialized. One of them is a scenario 86 where virtual machines (VMs) are created on a massive scale. 87 Typically the new VM instances are assigned a random link-layer (MAC) 88 address, but that does not scale well due to the birthday paradox. 89 Another use case is IoT devices. Typically there is no need to 90 provide global uniqueness of MAC addresses for such devices. On the 91 other hand, the huge number of such devices would likely exhaust a 92 vendor's OUI (Organizationally Unique Identifier) global address 93 space. For those reasons, it is desired to have some form of local 94 authority that would be able to assign locally unique MAC addresses. 96 This document proposes a new mechanism that extends DHCPv6 operation 97 to handle link-layer address assignments. 99 Since DHCPv6 ([RFC8415]) is a protocol that can allocate various 100 types of resources (non-temporary addresses, temporary addresses, 101 prefixes, but also many options) and has necessary infrastructure 102 (numerous server and client implementations, large deployed relay 103 infrastructure, supportive solutions, like leasequery and failover) 104 to maintain such assignment, it is a good candidate to address the 105 desired functionality. 107 While this document presents a design that should be usable for any 108 link-layer address type, some of the details are specific to Ethernet 109 / IEEE 802 48-bit MAC addresses. Future documents may provide 110 specifics for other link-layer address types. 112 The IEEE originally set aside half of the 48-bit MAC Address space 113 for local use (where the U/L bit is set to 1). In 2017, the IEEE 114 specified an optional specification (IEEE 802c) that divides this 115 space into quadrants (Standards Assigned Identifier, Extended Local 116 Identifier, Administratively Assigned Identifier, and a Reserved 117 quadrant) - more details are in Appendix A. 119 The IEEE is also working to specify protocols and procedures for 120 assignment of locally unique addresses (IEEE 802.1cq). This work may 121 serve as one such protocol for assignment. For additional 122 background, see [IEEE-802-Tutorial]. 124 2. Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Terminology 134 The DHCPv6 terminology relevant to this specification from the DHCPv6 135 Protocol [RFC8415] applies here. 137 client A device that is interested in obtaining link-layer 138 addresses. It implements the basic DHCPv6 mechanisms 139 needed by a DHCPv6 client as described in [RFC8415] and 140 supports the new options (IA_LL and LLADDR) specified 141 in this document. The client may or may not support 142 address assignment and prefix delegation as specified 143 in [RFC8415]. 145 server Software that manages link-layer address allocation and 146 is able to respond to client queries. It implements 147 basic DHCPv6 server functionality as described in 148 [RFC8415] and supports the new options (IA_LL and 149 LLADDR) specified in this document. The server may or 150 may not support address assignment and prefix 151 delegation as specified in [RFC8415]. 153 address Unless specified otherwise, an address means a link- 154 layer (or MAC) address, as defined in IEEE802. The 155 address is typically 6 octets long, but some network 156 architectures may use different lengths. 158 address block A number of consecutive link-layer addresses. An 159 address block is expressed as a first address plus a 160 number that designates the number of additional (extra) 161 addresses. A single address can be represented by the 162 address itself and zero extra addresses. 164 4. Deployment scenarios and mechanism overview 166 This mechanism is designed to be generic and usable in many 167 deployments, but there are two scenarios it attempts to address in 168 particular: (i) proxy client mode, and (ii) direct client mode. 170 4.1. Proxy client mode scenario 172 This mode is used when an entity acts as a DHCP client and requests 173 available DHCP servers to assign one or more MAC addresses (an 174 address block), to be then assigned for use to the final end-devices. 175 One relevant example of scenario of application of this mode is large 176 scale virtualization. In such environments the governing entity is 177 often called a hypervisor and is frequently required to spawn new 178 VMs. The hypervisor needs to assign new MAC addresses to those 179 machines. The hypervisor does not use those addresses for itself, 180 but rather uses them to create new VMs with appropriate MAC 181 addresses. It is worth pointing out the cumulative nature of this 182 scenario. Over time, the hypervisor is likely to increase its MAC 183 addresses usage. While some obsolete VMs will be deleted and their 184 MAC addresses will become eligible for release or reuse, it is 185 unexpected for all MAC addresses to be released. 187 4.2. Direct client mode scenario 189 This mode is used when an entity acts as a DHCP client and requests 190 available DHCP servers to assign one or more MAC addresses (an 191 address block) for its own use. This usage scenario is related to 192 IoT (Internet of Things). With the emergence of IoT, a new class of 193 cheap, sometimes short lived and disposable devices, has emerged. 194 Examples may include various sensors (e.g. medical) and actuators or 195 controllable LED lights. Upon first boot, the device uses a 196 temporary MAC address, as described in [IEEE-802.11-02-109r0], to 197 send initial DHCP packets to available DHCP servers. Then, such 198 devices would typically request a single MAC address for each 199 available network interface, which typically means one MAC address 200 per device. Once the server assigns a MAC address, the device 201 abandons its temporary MAC address and uses the assigned (leased) MAC 202 address. 204 4.3. Mechanism Overview 206 In all scenarios the protocol operates in fundamentally the same way. 207 The device requesting an address, acting as a DHCP client, will send 208 a Solicit message with a IA_LL option to all available DHCP servers. 209 That IA_LL option MUST include a LLADDR option specifying the link- 210 layer-type and link-layer-len and may specify a specific address or 211 address block as a hint for the server. Each available server 212 responds with an Advertise message with offered link-layer address or 213 addresses. The client then picks the best server, as governed by 214 [RFC8415], and will send a Request message. The target server will 215 then assign the link-layer addresses and send a Reply message. Upon 216 reception, the client can start using those link-layer addresses. 218 Normal DHCP mechanisms are in use. The client is expected to 219 periodically renew the link-layer addresses as governed by T1 and T2 220 timers. This mechanism can be administratively disabled by the 221 server sending "infinity" as the T1 and T2 values (see Section 7.7 of 222 [RFC8415]). 224 The client can release link-layer addresses when they are no longer 225 needed by sending a Release message (see Section 18.2.7 of 226 [RFC8415]). 228 Figure 1, taken from [RFC8415], shows a timeline diagram of the 229 messages exchanged between a client and two servers for the typical 230 lifecycle of one or more leases 232 Server Server 233 (not selected) Client (selected) 235 v v v 236 | | | 237 | Begins initialization | 238 | | | 239 start of | _____________/|\_____________ | 240 4-message |/ Solicit | Solicit \| 241 exchange | | | 242 Determines | Determines 243 configuration | configuration 244 | | | 245 |\ | ____________/| 246 | \________ | /Advertise | 247 | Advertise\ |/ | 248 | \ | | 249 | Collects Advertises | 250 | \ | | 251 | Selects configuration | 252 | | | 253 | _____________/|\_____________ | 254 |/ Request | Request \| 255 | | | 256 | | Commits configuration 257 | | | 258 end of | | _____________/| 259 4-message | |/ Reply | 260 exchange | | | 261 | Initialization complete | 262 | | | 263 . . . 264 . . . 265 | T1 (Renewal) Timer Expires | 266 | | | 267 2-message | _____________/|\_____________ | 268 exchange |/ Renew | Renew \| 269 | | | 270 | | Commits extended lease(s) 271 | | | 272 | | _____________/| 273 | |/ Reply | 274 . . . 275 . . . 276 | | | 277 | Graceful shutdown | 278 | | | 279 2-message | _____________/|\_____________ | 280 exchange |/ Release | Release \| 281 | | | 282 | | Discards lease(s) 283 | | | 284 | | _____________/| 285 | |/ Reply | 286 | | | 287 v v v 289 Figure 1: Timeline diagram of the messages exchanged between a client 290 and two servers for the typical lifecycle of one or more leases 292 Confirm, Decline, and Information-Request messages are not used in 293 link-layer address assignment. 295 Clients implementing this mechanism SHOULD use the Rapid Commit 296 option as specified in Section 5.1 and 18.2.1 of [RFC8415]. 298 An administrator may make the address assignment permanent by 299 specifying use of infinite lifetimes, as defined in Section 7.7 of 300 [RFC8415]. An administrator may also disable the need for the 301 renewal mechanism by setting the T1 and T2 values to infinity. 303 Devices supporting this proposal MAY support the reconfigure 304 mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported 305 by both server and client, this mechanism allows the administrator to 306 immediately notify clients that the configuration has changed and 307 triggers retrieval of relevant changes immediately, rather than after 308 the T1 timer elapses. Since this mechanism requires implementation 309 of Reconfigure Key Authentication Protocol (See Section 20.4 of 310 [RFC8415]), small footprint devices may chose to not support it. 312 DISCUSSION: A device may send its link-layer address in a LLADDR 313 option to ask the server to register that address to the client (if 314 available), making the assignment permanent for the lease duration. 315 The client MUST be prepared to use a different address if the server 316 choses not to honor its hint. 318 5. Design Assumptions 320 One of the essential aspects of this mechanism is its cumulative 321 nature, especially in the hypervisor scenario. The server-client 322 relationship does not look like other DHCP transactions. This is 323 especially true in the hypervisor scenario. In a typical 324 environment, there would be one server and a rather small number of 325 hypervisors, possibly even only one. However, over time the number 326 of MAC addresses requested by the hypervisor(s) will likely increase 327 as new VMs are spawned. 329 Another aspect crucial for efficient design is the observation that a 330 single client acting as hypervisor will likely use thousands of 331 addresses. Therefore an approach similar to what is used for address 332 or prefix assignment (IA container with all assigned addresses 333 listed, one option for each address) would not work well. Therefore 334 the mechanism should operate on address blocks, rather than single 335 values. A single address can be treated as an address block with 336 just one address. 338 The DHCPv6 mechanisms are reused to large degree, including message 339 and option formats, transmission mechanisms, relay infrastructure and 340 others. However, a device wishing to support only link-layer address 341 assignment is not required to support full DHCPv6. In other words, 342 the device may support only assignment of link-layer addresses, but 343 not IPv6 addresses or prefixes. 345 6. Information Encoding 347 A client MUST send a LLADDR option encapsulated in an IA_LL option to 348 specify the link-layer-type and link-layer-len values. For link- 349 layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client 350 sets the link-layer-address field to: 352 1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 353 the starting address of the unicast address block. This address 354 has the IEEE 802 individual/group bit set to 0 (individual). 356 2. Any other value to request a specific block of address starting 357 with the specified address 359 A client sets the extra-addresses field to either 0 for a single 360 address or to the size of the requested address block minus 1. 362 A client SHOULD set the valid-lifetime field to 0 (this field MUST be 363 ignored by the server). 365 7. Requesting Addresses 367 The link-layer addresses are assigned in blocks. The smallest block 368 is a single address. To request an assignment, the client sends a 369 Solicit message with an IA_LL option in the message. The IA_LL 370 option MUST contain a LLADDR option as specified in Section 6. 372 The server, upon receiving an IA_LL option, inspects its content and 373 may offer an address or addresses for each LLADDR option according to 374 its policy. The server MAY take into consideration the address block 375 requested by the client in the LLADDR option. However, the server 376 MAY chose to ignore some or all parameters of the requested address 377 block. In particular, the server may send a different starting 378 address than requested, or grant a smaller number of addresses than 379 requested. The server sends back an Advertise message an IA_LL 380 option containing an LLADDR option that specifies the addresses being 381 offered. If the server is unable to provide any addresses it MUST 382 return the IA_LL option containing a Status Code option (see 383 Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. 385 The client MUST be able to handle a response that contains an address 386 or addresses different 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 that contains an 405 address or addresses different than those requested. 407 A client that has included a Rapid Commit option in the Solicit, may 408 receive a Reply in response to the Solicit and skip the Advertise and 409 Request steps above (see Section 18.2.1 of [RFC8415]). 411 8. Renewing Addresses 413 Address renewals follow the normal DHCPv6 renewals processing 414 described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, 415 the client starts sending Renew messages with the IA_LL option 416 containing a LLADDR option for the address block being renewed. The 417 server responds with a Reply message that contains the renewed 418 address block. The server SHOULD NOT alter the address block being 419 renewed, unless its policy has changed. The server MUST NOT shrink 420 or expand the address block - once a block is assigned and has a non- 421 zero valid lifetime, its size, starting address, and ending address 422 MUST NOT change. 424 If the requesting client needs additional MAC addresses -- e.g., in 425 the hypervisor scenario because addresses need to be assigned to new 426 VMs -- the simpler approach is for the requesting device to keep the 427 address blocks as atomic once "leased". Therefore, if a client wants 428 more addresses at a later stage, it SHOULD send an IA_LL option with 429 a different IAID to create another "container" for more addresses. 431 If the client is unable to Renew before the T2 timer elapses, it 432 starts sending Rebind messages as described in 18.2.5 of [RFC8415]. 434 9. Releasing Addresses 436 The client may decide to release a leased address block. A client 437 MUST release the whole block in its entirety. A client releases an 438 address block by sending a Release message that includes the IA_LL 439 option containing the LLADDR option for the address block to release. 440 The Release transmission mechanism is described in Section 18.2.7 of 441 [RFC8415]. 443 10. Option Definitions 445 This mechanism uses an approach similar to the existing mechanisms in 446 DHCP. There is one container option (the IA_LL option) that contains 447 the actual link-layer address or addresses, represented by an LLADDR 448 option. Each such option represents an address block, which is 449 expressed as a first address with a number that specifies how many 450 additional addresses are included. 452 10.1. Identity Association for Link-Layer Addresses Option 454 The Identity Association for Link-Layer Addresses option (IA_LL 455 option) is used to carry one or more IA_LL options, the parameters 456 associated with the IA_LL, and the address blocks associated with the 457 IA_LL. 459 The format of the IA_LL option is: 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | OPTION_IA_LL | option-len | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | IAID (4 octets) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | T1 (4 octets) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | T2 (4 octets) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 . . 471 . IA_LL-options . 472 . . 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 2: IA_LL Option Format 477 option-code OPTION_IA_LL (tbd1). 479 option-len 12 + length of IA_LL-options field. 481 IAID The unique identifier for this IA_LL; the IAID must 482 be unique among the identifiers for all of this 483 client's IA_LLs. The number space for IA_LL IAIDs is 484 separate from the number space for other IA option 485 types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet 486 field containing an unsigned integer. 488 T1 The time at which the client should contact the 489 server from which the addresses in the IA_LL were 490 obtained to extend the valid lifetime of the 491 addresses assigned to the IA_LL; T1 is a time 492 duration relative to the current time expressed in 493 units of seconds. A 4-octet field containing an 494 unsigned integer. 496 T2 The time at which the client should contact any 497 available server to extend the valid lifetime of the 498 addresses assigned to the IA_LL; T2 is a time 499 duration relative to the current time expressed in 500 units of seconds. A 4-octet field containing an 501 unsigned integer. 503 IA_LL-options Options associated with this IA_LL. A variable 504 length field (12 octets less than the value in the 505 option-len field). 507 An IA_LL option may only appear in the options area of a DHCP 508 message. A DHCP message may contain multiple IA_LL options (though 509 each must have a unique IAID). 511 The status of any operations involving this IA_LL is indicated in a 512 Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- 513 options field. 515 Note that an IA_LL has no explicit "lifetime" or "lease length" of 516 its own. When the valid lifetimes of all of the addresses in an 517 IA_LL have expired, the IA_LL can be considered as having expired. 518 T1 and T2 are included to give servers explicit control over when a 519 client recontacts the server about a specific IA_LL. 521 In a message sent by a client to a server, the T1 and T2 fields 522 SHOULD be set to 0. The server MUST ignore any values in these 523 fields in messages received from a client. 525 In a message sent by a server to a client, the client MUST use the 526 values in the T1 and T2 fields for the T1 and T2 times, unless those 527 values in those fields are 0. The values in the T1 and T2 fields are 528 the number of seconds until T1 and T2. 530 As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to 531 mean "infinity" and should be used carefully. 533 The server selects the T1 and T2 times to allow the client to extend 534 the lifetimes of any address block in the IA_LL before the lifetimes 535 expire, even if the server is unavailable for some short period of 536 time. Recommended values for T1 and T2 are .5 and .8 times the 537 shortest valid lifetime of the address blocks in the IA that the 538 server is willing to extend, respectively. If the "shortest" valid 539 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 540 are also 0xffffffff. If the time at which the addresses in an IA_LL 541 are to be renewed is to be left to the discretion of the client, the 542 server sets T1 and T2 to 0. The client MUST follow the rules defined 543 in Section 14.2 in [RFC8415]. 545 If a client receives an IA_LL with T1 greater than T2, and both T1 546 and T2 are greater than 0, the client discards the IA_LL option and 547 processes the remainder of the message as though the server had not 548 included the invalid IA_LL option. 550 10.2. Link-Layer Addresses Option 552 The Link-Layer Addresses option is used to specify an address block 553 associated with a IA_LL. The option must be encapsulated in the 554 IA_LL-options field of an IA_LL option. The LLaddr-options fields 555 encapsulates those options that are specific to this address block. 557 The format of the Link-Layer Addresses option is: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | OPTION_LLADDR | option-len | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | link-layer-type | link-layer-len | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 . . 567 . link-layer-address . 568 . . 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | extra-addresses | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | valid-lifetime | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 . . 575 . LLaddr-options . 576 . . 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 3: LLADDR Option Format 581 option-code OPTION_LLADDR (tbd2). 583 option-len 12 + link-layer-len field (typically 6) + length of 584 LLaddr-options field. Assuming a typical link-layer 585 address of 6 is used and there are no extra options, 586 length should be equal to 18. 588 link-layer-type The link-layer type MUST be a valid hardware type 589 assigned by the IANA, as described in [RFC5494]. The 590 type is stored in network byte order. 592 link-layer-len Specifies the length of the link-layer-address field 593 (typically 6, for a link-layer-type of 1 (Ethernet)). 594 A 2-octet field containing an unsigned integer. 596 link-layer-address Specifies the link-layer address that is being 597 requested or renewed, or a special value to request 598 any address. For a link-layer type of 1 (Ethernet / 599 IEEE 802 48-bit MAC addresses), see Section 6 for 600 details on these values. In responses from a server, 601 this value specifies the first address allocated. 603 extra-addresses Number of additional addresses that follow the 604 address specified in link-layer-address. For a 605 single address, 0 is used. For example: link-layer- 606 address: 02:04:06:08:0a and extra-addresses 3 607 designates a block of 4 addresses, starting from 608 02:04:06:08:0a (inclusive) and ending with 609 02:04:06:08:0d (inclusive). In responses from a 610 server, this value specifies the number of additional 611 addresses allocated. A 4-octet field containing an 612 unsigned integer. 614 valid-lifetime The valid lifetime for the address(es) in the option, 615 expressed in units of seconds. A 4-octet field 616 containing an unsigned integer. 618 LLaddr-options Any encapsulated options that are specific to this 619 particular address block. Currently there are no 620 such options defined, but there may be in the future. 622 In a message sent by a client to a server, the valid lifetime field 623 SHOULD be set to 0. The server MUST ignore any received value. 625 In a message sent by a server to a client, the client MUST use the 626 value in the valid lifetime field for the valid lifetime for the 627 address block. The value in the valid lifetime field is the number 628 of seconds remaining in the lifetime. 630 As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is 631 taken to mean "infinity" and should be used carefully. 633 More than one LLADDR option can appear in an IA_LL option. 635 11. Selecting Link Layer Addresses for Assignment to an IA_LL 637 A server selects link layer addresses to be assigned to an IA_LL 638 according to the assignment policies determined by the server 639 administrator. 641 Link layer addresses are typically specific to a link and the server 642 SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the 643 client's link. 645 For Ethernet / IEEE 802 MAC addresses, a server MAY use additional 646 options supplied by a relay agent or client to select the quadrant 647 (see Appendix A) from which addresses are to be assigned. This MAY 648 include new options, such as those specified in 649 [I-D.ietf-dhc-slap-quadrant]. 651 12. IANA Considerations 653 IANA is requested to assign the OPTION_IA_LL (tbd1) option code from 654 the DHCPv6 "Option Codes" registry maintained at 655 http://www.iana.org/assignments/dhcpv6-parameters and use the 656 following data when adding the option to the registry: 658 Value: tbd1 659 Description: OPTION_IA_LL 660 Client ORO: No 661 Singleton Option: No 662 Reference: this document 664 IANA is requested to assign the OPTION_LLADDR (tbd2) option code from 665 the DHCPv6 "Option Codes" registry maintained at 666 http://www.iana.org/assignments/dhcpv6-parameters and use the 667 following data when adding the option to the registry: 669 Value: tbd2 670 Description: OPTION_LLADDR 671 Client ORO: No 672 Singleton Option: No 673 Reference: this document 675 13. Security Considerations 677 See [RFC8415] for the DHCPv6 security considerations. See [RFC8200] 678 for the IPv6 security considerations. 680 There is a possibility of the same link-layer address being used by 681 more than one device if not all parties on a link use this mechanism 682 to obtain a link-layer address from the space assigned to the DHCP 683 server. It is also possible that a bad actor purposely uses a 684 device's link-layer address. 686 14. Privacy Considerations 688 See [RFC8415] for the DHCPv6 privacy considerations. 690 For a client requesting a link-layer address directly from a server, 691 as the link-layer address assigned to a client will likely be used by 692 the client to communicate on the link, the address will be exposed to 693 those able to listen in on this communication. For those peers on 694 the link that are able to listen in on the DHCPv6 exchange, they 695 would also be able to correlate the client's identity (based on the 696 DUID used) with the assigned address. Additional mechanisms, such as 697 the ones described in [RFC7844] can also be used. 699 15. References 701 15.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 709 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 710 May 2017, . 712 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 713 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 714 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 715 RFC 8415, DOI 10.17487/RFC8415, November 2018, 716 . 718 15.2. Informative References 720 [I-D.ietf-dhc-slap-quadrant] 721 Bernardos, C. and A. Mourad, "SLAP quadrant selection 722 options for DHCPv6", draft-ietf-dhc-slap-quadrant-02 (work 723 in progress), January 2020. 725 [IEEE-802-Tutorial] 726 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", 727 . 730 [IEEE-802.11-02-109r0] 731 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 732 "Temporary MAC address for anonymity", 733 . 736 [IEEEStd802c-2017] 737 IEEE Computer Society, "IEEE Standard for Local and 738 Metropolitan Area Networks: Overview and Architecture, 739 Amendment 2: Local Medium Access Control (MAC) Address 740 Usage, IEEE Std 802c-2017". 742 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 743 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 744 . 746 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 747 for the Address Resolution Protocol (ARP)", RFC 5494, 748 DOI 10.17487/RFC5494, April 2009, 749 . 751 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 752 Profiles for DHCP Clients", RFC 7844, 753 DOI 10.17487/RFC7844, May 2016, 754 . 756 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 757 (IPv6) Specification", STD 86, RFC 8200, 758 DOI 10.17487/RFC8200, July 2017, 759 . 761 Appendix A. IEEE 802c Summary 763 This appendix provides a brief summary of IEEE802c from 764 [IEEEStd802c-2017]. 766 The original IEEE 802 specifications assigned half of the 48-bit MAC 767 address space to local use -- these addresses have the U/L bit set to 768 1 and are locally administered with no imposed structure. 770 In 2017, the IEEE issued the 802c specification which defines a new 771 "optional Structured Local Address Plan (SLAP) that specifies 772 different assignment approaches in four specified regions of the 773 local MAC address space." Under this plan, there are 4 SLAP 774 quadrants that use different assignment policies. 776 The first octet of the MAC address Z and Y bits define the quadrant 777 for locally assigned addresses (X-bit is 1). In IEEE representation, 778 these bits are as follows: 780 LSB MSB 781 M X Y Z - - - - 782 | | | | 783 | | | +------------ SLAP Z-bit 784 | | +--------------- SLAP Y-bit 785 | +------------------ X-bit (U/L) = 1 for locally assigned 786 +--------------------- M-bit (I/G) (unicast/group) 788 Figure 4: SLAP Bits 790 The SLAP quadrants are: 792 +----------+-------+-------+-----------------------+----------------+ 793 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 794 | | | | | Identifier | 795 +----------+-------+-------+-----------------------+----------------+ 796 | 01 | 0 | 1 | Extended Local | ELI | 797 | 11 | 1 | 1 | Standard Assigned | SAI | 798 | 00 | 0 | 0 | Administratively | AAI | 799 | | | | Assigned | | 800 | 10 | 1 | 0 | Reserved | Reserved | 801 +----------+-------+-------+-----------------------+----------------+ 803 SLAP Quadrants 805 Extended Local Identifier (ELI) derived MAC addresses are based on an 806 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 807 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 808 locally assigned address for each CID for unicast (M-bit = 0) and 809 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 811 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 812 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 813 addresses, 44 bits are available. Multiple protocols for assigning 814 SAIs may be specified in IEEE standards. Coexistence of multiple 815 protocols may be supported by limiting the subspace available for 816 assignment by each protocol. 818 Administratively Assigned Identifier (AAI) derived MAC addresses are 819 assigned locally. Administrators manage the space as needed. Note 820 that multicast IPv6 packets ([RFC2464]) use a destination address 821 starting in 33-33 and this falls within this space and therefore 822 should not be used to avoid conflict with IPv6 multicast addresses. 823 For 48-bit MAC addresses, 44 bits are available. 825 The last quadrant is reserved for future use. While this quadrant 826 may also be used for AAI space, administrators should be aware that 827 future specifications may define alternate uses that could be 828 incompatible. 830 Authors' Addresses 831 Bernie Volz 832 Cisco Systems, Inc. 833 1414 Massachusetts Ave 834 Boxborough, MA 01719 835 USA 837 Email: volz@cisco.com 839 Tomek Mrugalski 840 Internet Systems Consortium, Inc. 841 950 Charter Street 842 Redwood City, CA 94063 843 USA 845 Email: tomasz.mrugalski@gmail.com 847 Carlos J. Bernardos 848 Universidad Carlos III de Madrid 849 Av. Universidad, 30 850 Leganes, Madrid 28911 851 Spain 853 Phone: +34 91624 6236 854 Email: cjbc@it.uc3m.es 855 URI: http://www.it.uc3m.es/cjbc/