idnits 2.17.1 draft-ietf-dhc-mac-assign-00.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 == Line 614 has weird spacing: '...options any e...' -- The document date (April 17, 2019) is 1835 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) No issues found here. 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: October 19, 2019 ISC 6 CJ. Bernardos 7 UC3M 8 April 17, 2019 10 Link-Layer Addresses Assignment Mechanism for DHCPv6 11 draft-ietf-dhc-mac-assign-00 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 October 19, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 16.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. Typically there is no need to 91 provide global uniqueness of MAC addresses for such devices. On the 92 other hand, the huge number of such devices would likely exhaust a 93 vendor's OUI (Organizationally Unique Identifier) global address 94 space. For those reasons, it is desired to have some form of local 95 authority that would be able to assign locally unique MAC addresses. 97 This document proposes a new mechanism that extends DHCPv6 operation 98 to handle link-layer address assignments. 100 Since DHCPv6 ([RFC8415]) is a protocol that can allocate various 101 types of resources (non-temporary addresses, temporary addresses, 102 prefixes, but also many options) and has necessary infrastructure 103 (numerous server and client implementations, large deployed relay 104 infrastructure, supportive solutions, like leasequery and failover) 105 to maintain such assignment, it is a good candidate to address the 106 desired functionality. 108 While this document presents a design that should be usable for any 109 link-layer address type, some of the details are specific to Ethernet 110 / IEEE 802 48-bit MAC addresses. Future documents may provide 111 specifics for other link-layer address types. 113 The IEEE originally set aside half of the 48-bit MAC Address space 114 for local use (where the U/L bit is set to 1). In 2017, the IEEE 115 specified an optional specification (IEEE 802c) that divides this 116 space into quadrants (Standards Assigned Identifier, Extended Local 117 Identifier, Administratively Assigned Identifier, and a Reserved 118 quadrant) - more details are in Appendix A. The IEEE is also working 119 to specify protocols and procedures for assignment of locally unique 120 addresses (IEEE 802.1cq). This work may serve as one such protocol 121 for assignment. For additional background, see [IEEE-802-Tutorial]. 123 2. Requirements 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Terminology 133 The DHCPv6 terminology relevant to this specification from the DHCPv6 134 Protocol [RFC8415] applies here. 136 client A device that is interested in obtaining link-layer 137 addresses. It implements the basic DHCPv6 mechanisms 138 needed by a DHCPv6 client as described in [RFC8415] and 139 supports the new options (IA_LL and LLADDR) specified 140 in this document. The client may or may not support 141 address assignment and prefix delegation as specified 142 in [RFC8415]. 144 server Software that manages link-layer address allocation and 145 is able to respond to client queries. It implements 146 basic DHCPv6 server functionality as described in 147 [RFC8415] and supports the new options (IA_LL and 148 LLADDR) specified in this document. The server may or 149 may not support address assignment and prefix 150 delegation as specified in [RFC8415]. 152 address Unless specified otherwise, an address means a link- 153 layer (or MAC) address, as defined in IEEE802. The 154 address is typically 6 bytes long, but some network 155 architectures may use different lengths. 157 address block A number of consecutive link-layer addresses. An 158 address block is expressed as a first address plus a 159 number that designates the number of additional (extra) 160 addresses. A single address can be represented by the 161 address itself and zero extra addresses. 163 4. Deployment scenarios and mechanism overview 165 This mechanism is designed to be generic and usable in many 166 deployments, but there are two scenarios it attempts to address in 167 particular: (i) proxy client mode, and (ii) direct client mode. 169 4.1. Proxy client mode scenario 171 This mode is used when an entity acts as a DHCP client and requests 172 available DHCP servers to assign one or more MAC addresses (an 173 address block), to be then assigned for use to the final end-devices. 174 One relevant example of scenario of application of this mode is large 175 scale virtualization. In such environments the governing entity is 176 often called a hypervisor and is frequently required to spawn new 177 VMs. The hypervisor needs to assign new MAC addresses to those 178 machines. The hypervisor does not use those addresses for itself, 179 but rather uses them to create new VMs with appropriate MAC 180 addresses. It is worth pointing out the cumulative nature of this 181 scenario. Over time, the hypervisor is likely to increase its MAC 182 addresses usage. While some obsolete VMs will be deleted and their 183 MAC addresses will become eligible for release or reuse, it is 184 unexpected for all MAC addresses to be released. 186 4.2. Direct client mode scenario 188 This mode is used when an entity acts as a DHCP client and requests 189 available DHCP servers to assign one or more MAC addresses (an 190 address block) for its own use. This usage scenario is related to 191 IoT (Internet of Things). With the emergence of IoT, a new class of 192 cheap, sometimes short lived and disposable devices, has emerged. 193 Examples may include various sensors (e.g. medical) and actuators or 194 controllable LED lights. Upon first boot, the device uses a 195 temporary MAC address, as described in [IEEE-802.11-02-109r0], to 196 send initial DHCP packets to available DHCP servers. Such devices 197 will typically request a single MAC address for each available 198 network interface, which typically means one MAC address per device. 199 Once the server assigns a MAC address, the device abandons its 200 temporary MAC address. 202 4.3. Mechanism Overview 204 In all scenarios the protocol operates in fundamentally the same way. 205 The device requesting an address, acting as a DHCP client, will send 206 a Solicit message with a IA_LL option to all available DHCP servers. 207 That IA_LL option MUST include a LLADDR option specifying the link- 208 layer-type and link-layer-len and may specify a specific address or 209 address block as a hint for the server. Each available server 210 responds with an Advertise message with offered link-layer address or 211 addresses. The client then picks the best server, as governed by 212 [RFC8415], and will send a Request message. The target server will 213 then assign the link-layer addresses and send a Reply message. Upon 214 reception, the client can start using those link-layer addresses. 216 Normal DHCP mechanisms are in use. The client is expected to 217 periodically renew the link-layer addresses as governed by T1 and T2 218 timers. This mechanism can be administratively disabled by the 219 server sending "infinity" as the T1 and T2 values (see Section 7.7 of 220 [RFC8415]). 222 The client can release link-layer addresses when they are no longer 223 needed by sending a Release message (see Section 18.2.7 of 224 [RFC8415]). 226 Figure 1, taken from [RFC8415], shows a timeline diagram of the 227 messages exchanged between a client and two servers for the typical 228 lifecycle of one or more leases 230 Server Server 231 (not selected) Client (selected) 233 v v v 234 | | | 235 | Begins initialization | 236 | | | 237 start of | _____________/|\_____________ | 238 4-message |/ Solicit | Solicit \| 239 exchange | | | 240 Determines | Determines 241 configuration | configuration 242 | | | 243 |\ | ____________/| 244 | \________ | /Advertise | 245 | Advertise\ |/ | 246 | \ | | 247 | Collects Advertises | 248 | \ | | 249 | Selects configuration | 250 | | | 251 | _____________/|\_____________ | 252 |/ Request | Request \| 253 | | | 254 | | Commits configuration 255 | | | 256 end of | | _____________/| 257 4-message | |/ Reply | 258 exchange | | | 259 | Initialization complete | 260 | | | 261 . . . 262 . . . 263 | T1 (Renewal) Timer Expires | 264 | | | 265 2-message | _____________/|\_____________ | 266 exchange |/ Renew | Renew \| 267 | | | 268 | | Commits extended lease(s) 269 | | | 270 | | _____________/| 271 | |/ Reply | 272 . . . 273 . . . 274 | | | 275 | Graceful shutdown | 276 | | | 277 2-message | _____________/|\_____________ | 278 exchange |/ Release | Release \| 279 | | | 280 | | Discards lease(s) 281 | | | 282 | | _____________/| 283 | |/ Reply | 284 | | | 285 v v v 287 Figure 1: Timeline diagram of the messages exchanged between a client 288 and two servers for the typical lifecycle of one or more leases 290 Confirm, Decline, and Information-Request messages are not used in 291 link-layer address assignment. 293 Clients implementing this mechanism SHOULD use the Rapid Commit 294 option as specified in Section 5.1 and 18.2.1 of [RFC8415]. 296 An administrator may make the address assignment permanent by 297 specifying use of infinite lifetimes, as defined in Section 7.7 of 298 [RFC8415]. An administrator may also the disable the need for the 299 renewal mechanism by setting the T1 and T2 values to infinity. 301 Devices supporting this proposal MAY support reconfigure mechanism, 302 as defined in Section 18.2.11 of [RFC8415]. If supported by both 303 server and client, this mechanism allows the administrator to 304 immediately notify clients that the configuration has changed and 305 triggers retrieval of relevant changes immediately, rather than after 306 T1 timer elapses. Since this mechanism requires implementation of 307 Reconfigure Key Authentication Protocol (See Section 20.4 of 308 [RFC8415]), small footprint devices may chose to not support it. 310 DISCUSSION: A device may send its link-layer address in a LLADDR 311 option to ask the server to register that address to the client (if 312 available), making the assignment permanent for the lease duration. 313 The client MUST be prepared to use a different address if the server 314 choses not to honor its hint. 316 5. Design Assumptions 318 One of the essential aspects of this mechanism is its cumulative 319 nature, especially in the hypervisor scenario. The server-client 320 relationship does not look like other DHCP transactions. This is 321 especially true in the hypervisor scenario. In a typical 322 environment, there would be one server and a rather small number of 323 hypervisors, possibly even only one. However, over time the number 324 of MAC addresses requested by the hypervisor(s) will likely increase 325 as new VMs are spawned. 327 Another aspect crucial for efficient design is the observation that a 328 single client acting as hypervisor will likely use thousands of 329 addresses. Therefore an approach similar to what is used for address 330 or prefix assignment (IA container with all assigned addresses 331 listed, one option for each address) would not work well. Therefore 332 the mechanism should operate on address blocks, rather than single 333 values. A single address can be treated as an address block with 334 just one address. 336 The DHCPv6 mechanisms are reused to large degree, including message 337 and option formats, transmission mechanisms, relay infrastructure and 338 others. However, a device wishing to support only link-layer address 339 assignment is not required to support full DHCPv6. In other words, 340 the device may support only assignment of link-layer addresses, but 341 not IPv6 addresses or prefixes. 343 6. Information Encoding 345 A client MUST send a LLADDR option encapsulated in a IA_LL option to 346 specify the link-layer-type and link-layer-len values. For link- 347 layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client 348 sets the link-layer-address field to: 350 1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 351 the starting address of the unicast address block. This address 352 has the IEEE 802 individual/group bit set to 0 (individual). 354 3. Any other value to request a specific block of address starting 355 with the specified address 357 A client sets the extra-addresses field to either 0 for a single 358 address or to the size of the requested address block minus 1. 360 A client SHOULD set the valid-lifetime field to 0 (as it is ignored 361 by the server). 363 7. Requesting Addresses 365 The link-layer addresses are assigned in blocks. The smallest block 366 is a single address. To request an assignment, the client sends a 367 Solicit message with a IA_LL option in the message. The IA_LL option 368 MUST contain a LLADDR option as specified in Section 6. 370 The server, upon receiving a IA_LL option, inspects its content and 371 may offer an address or addresses for each LLADDR option according to 372 its policy. The server MAY take into consideration the address block 373 requested by the client in the LLADDR option. However, the server 374 MAY chose to ignore some or all parameters of the requested address 375 block. In particular, the server may send a different starting 376 address than requested, or grant a smaller number of addresses than 377 requested. The server sends back an Advertise message an IA_LL 378 option containing an LLADDR option that specifies the addresses being 379 offered. If the server is unable to provide any addresses it MUST 380 return the IA_LL option containing a Status Code option (see 381 Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. 383 The client MUST be able to handle a response that contains an address 384 or addresses different than those requested. 386 The client waits for available servers to send Advertise responses 387 and picks one server as defined in Section 18.2.9 of [RFC8415]. The 388 client then sends a Request message that includes the IA_LL container 389 option with the LLADDR option copied from the Advertise message sent 390 by the chosen server. 392 Upon reception of a Request message with IA_LL container option, the 393 server assigns requested addresses. The server MAY alter the 394 allocation at this time. It then generates and sends a Reply message 395 back to the client. 397 Upon receiving a Reply message, the client parses the IA_LL container 398 option and may start using all provided addresses. It MUST restart 399 its T1 and T2 timers using the values specified in the IA_LL option. 401 The client MUST be able to handle a Reply message that contains an 402 address or addresses different than those requested. 404 A client that has included a Rapid Commit option in the Solicit, may 405 receive a Reply in response to the Solicit and skip the Advertise and 406 Request steps above (see Section 18.2.1 of [RFC8415]). 408 8. Renewing Addresses 410 Address renewals follow the normal DHCPv6 renewals processing 411 described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, 412 the client starts sending Renew messages with the IA_LL option 413 containing a LLADDR option for the address block being renewed. The 414 server responds with a Reply message that contains the renewed 415 address block. The server SHOULD NOT alter the address block being 416 renewed, unless its policy has changed. The server MUST NOT shrink 417 or expand the address block - once a block is assigned and has a non- 418 zero valid lifetime, its size, starting address, and ending address 419 MUST NOT change. 421 If the requesting client needs additional MAC addresses -- e.g., in 422 the hypervisor scenario because addresses need to be assigned to new 423 VMs -- the simpler approach is for the requesting device to keep the 424 address blocks as atomic once "leased". Therefore, if a client wants 425 more addresses at a later stage, it SHOULD send an IA_LL option with 426 a different IAID to create another "container" for more addresses. 428 If the client is unable to Renew before the T2 timer elapses, it 429 starts sending Rebind messages as described in 18.2.5 of [RFC8415]. 431 9. Releasing Addresses 433 The client may decide to release a leased address block. A client 434 MUST release the whole block in its entirety. A client releases an 435 address block by sending a Release message that includes the IA_LL 436 option containing the LLADDR option for the address block to release. 437 The Release transmission mechanism is described in Section 18.2.7 of 438 [RFC8415]. 440 10. Option Definitions 442 This mechanism uses an approach similar to the existing mechanisms in 443 DHCP. There is one container option (the IA_LL option) that contains 444 the actual link-layer address or addresses, represented by an LLADDR 445 option. Each such option represents an address block, which is 446 expressed as a first address with a number that specifies how many 447 additional addresses are included. 449 10.1. Identity Association for Link-Layer Addresses Option 451 The Identity Association for Link-Layer Addresses option (IA_LL 452 option) is used to carry one or more IA_LL options, the parameters 453 associated with the IA_LL, and the address blocks associated with the 454 IA_LL. 456 The format of the IA_LL option is: 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | OPTION_IA_LL | option-len | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | IAID (4 octets) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | T1 (4 octets) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | T2 (4 octets) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 . . 468 . IA_LL-options . 469 . . 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Figure 2: IA_LL Option Format 474 option-code OPTION_IA_LL (tbd1). 476 option-len 12 + length of IA_LL-options field. 478 IAID The unique identifier for this IA_LL; the IAID must 479 be unique among the identifiers for all of this 480 client's IA_LLs. The number space for IA_LL IAIDs is 481 separate from the number space for other IA option 482 types (i.e., IA_NA, IA_TA, and IA_PD). A four octets 483 long field. 485 T1 The time at which the client should contact the 486 server from which the addresses in the IA_LL were 487 obtained to extend the valid lifetime of the 488 addresses assigned to the IA_LL; T1 is a time 489 duration relative to the current time expressed in 490 units of seconds. A four octets long field. 492 T2 The time at which the client should contact any 493 available server to extend the valid lifetime of the 494 addresses assigned to the IA_LL; T2 is a time 495 duration relative to the current time expressed in 496 units of seconds. A four octets long field. 498 IA_LL-options Options associated with this IA_LL. A variable 499 length field (12 octets less than the value in the 500 option-len field). 502 An IA_LL option may only appear in the options area of a DHCP 503 message. A DHCP message may contain multiple IA_LL options (though 504 each must have a unique IAID). 506 The status of any operations involving this IA_LL is indicated in a 507 Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- 508 options field. 510 Note that an IA_LL has no explicit "lifetime" or "lease length" of 511 its own. When the valid lifetimes of all of the addresses in an 512 IA_LL have expired, the IA_LL can be considered as having expired. 513 T1 and T2 are included to give servers explicit control over when a 514 client recontacts the server about a specific IA_LL. 516 In a message sent by a client to a server, the T1 and T2 fields 517 SHOULD be set to 0. The server MUST ignore any values in these 518 fields in messages received from a client. 520 In a message sent by a server to a client, the client MUST use the 521 values in the T1 and T2 fields for the T1 and T2 times, unless those 522 values in those fields are 0. The values in the T1 and T2 fields are 523 the number of seconds until T1 and T2. 525 As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to 526 mean "infinity" and should be used carefully. 528 The server selects the T1 and T2 times to allow the client to extend 529 the lifetimes of any address block in the IA_LL before the lifetimes 530 expire, even if the server is unavailable for some short period of 531 time. Recommended values for T1 and T2 are .5 and .8 times the 532 shortest valid lifetime of the address blocks in the IA that the 533 server is willing to extend, respectively. If the "shortest" valid 534 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 535 are also 0xffffffff. If the time at which the addresses in an IA_LL 536 are to be renewed is to be left to the discretion of the client, the 537 server sets T1 and T2 to 0. The client MUST follow the rules defined 538 in Section 14.2 in [RFC8415]. 540 If a client receives an IA_LL with T1 greater than T2, and both T1 541 and T2 are greater than 0, the client discards the IA_LL option and 542 processes the remainder of the message as though the server had not 543 included the invalid IA_LL option. 545 10.2. Link-Layer Addresses Option 547 The Link-Layer Addresses option is used to specify an address block 548 associated with a IA_LL. The option must be encapsulated in the 549 IA_LL-options field of an IA_LL option. The LLaddr-options fields 550 encapsulates those options that are specific to this address block. 552 The format of the Link-Layer Addresses option is: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | OPTION_LLADDR | option-len | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | link-layer-type | link-layer-len | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 | link-layer-address | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | extra-addresses | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | valid-lifetime | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 . . 570 . LLaddr-options . 571 . . 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 3: LLADDR Option Format 576 option-code OPTION_LLADDR (tbd2). 578 option-len 12 + link-layer-len field (typically 6) + length of 579 LLaddr-options field. Assuming a typical link-layer 580 address of 6 is used and there are no extra options, 581 length should be equal to 18. 583 link-layer-type The link-layer type MUST be a valid hardware type 584 assigned by the IANA, as described in [RFC5494]. The 585 type is stored in network byte order. 587 link-layer-len Specifies the length of the link-layer-address field 588 (typically 6, for a link-layer-type of 1 (Ethernet)). 589 A two octets long field. 591 link-layer-address Specifies the link-layer address that is being 592 requested or a special value to request any address. 593 For a link-layer type of 1 (Ethernet / IEEE 802 594 48-bit MAC addresses), see Section 6 for details on 595 these values. This value can be only sent by a 596 client that requests a new block. In responses from 597 a server, this value specifies the first address 598 allocated. 600 extra-addresses Number of additional addresses that follow address 601 specified in link-layer-address. For requesting a 602 single address, use 0. For example: link-layer- 603 address: 02:04:06:08:0a and extra-addresses 3 604 designates a block of 4 addresses, starting from 605 02:04:06:08:0a (inclusive) and ending with 606 02:04:06:08:0d (inclusive). In responses from a 607 server, this value specifies the number of additional 608 addresses allocated. A four octets long field. 610 valid-lifetime The valid lifetime for the address(es) in the option, 611 expressed in units of seconds. A four octets long 612 field. 614 LLaddr-options any encapsulated options that are specific to this 615 particular address block. Currently there are no 616 such options defined, but they may appear in the 617 future. 619 In a message sent by a client to a server, the valid lifetime field 620 SHOULD be set to 0. The server MUST ignore any received value. 622 In a message sent by a server to a client, the client MUST use the 623 value in the valid lifetime field for the valid lifetime for the 624 address block. The value in the valid lifetime field is the number 625 of seconds remaining in the lifetime. 627 As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is 628 taken to mean "infinity" and should be used carefully. 630 More than one LLADDR option can appear in an IA_LL option. 632 11. Client Behavior 634 TODO: We need start this section by clearly defining what 'client' 635 means in this context (either hypervisor acting on behalf of the 636 client to be spawned or the IOT device acting on its own behalf). 638 12. Server Behavior 640 TODO: Need to describe server operation. Likely also recommend 641 assigning MAC addresses from an appropriate quadrant (see Appendix). 643 13. IANA Considerations 645 IANA is kindly requested to assign new value for options OPTION_LL 646 (tbd1) and OPTION_LLADDR (tbd2) and add those values to the DHCPv6 647 Option Codes registry maintained at http://www.iana.org/assignments/ 648 dhcpv6-parameters. 650 14. Security Considerations 652 See [RFC8415] for the DHCPv6 security considerations. 654 TODO: Do we need more? 656 15. Privacy Considerations 658 See [RFC8415] for the DHCPv6 privacy considerations. 660 For a client requesting a link-layer address directly from a server, 661 as the link-layer address assigned to a client will likely be used by 662 the client to communicate on the link, the address will be exposed to 663 those able to listen in on this communication. For those peers on 664 the link that are able to listen in on the DHCPv6 exchange, they 665 would also be able to correlate the client's identity (based on the 666 DUID used) with the assigned address. Additional mechanisms, such as 667 the ones described in [RFC7844] can also be used. 669 TODO: Do we need more? 671 16. References 673 16.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 681 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 682 May 2017, . 684 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 685 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 686 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 687 RFC 8415, DOI 10.17487/RFC8415, November 2018, 688 . 690 16.2. Informative References 692 [IEEE-802-Tutorial] 693 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", 694 . 697 [IEEE-802.11-02-109r0] 698 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 699 "Temporary MAC address for anonymity", 700 . 703 [IEEEStd802c-2017] 704 IEEE Computer Society, "IEEE Standard for Local and 705 Metropolitan Area Networks: Overview and Architecture, 706 Amendment 2: Local Medium Access Control (MAC) Address 707 Usage, IEEE Std 802c-2017". 709 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 710 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 711 . 713 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 714 for the Address Resolution Protocol (ARP)", RFC 5494, 715 DOI 10.17487/RFC5494, April 2009, 716 . 718 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 719 Profiles for DHCP Clients", RFC 7844, 720 DOI 10.17487/RFC7844, May 2016, 721 . 723 Appendix A. IEEE 802c Summary 725 This appendix provides a brief summary of IEEE802c from 726 [IEEEStd802c-2017]. 728 The original IEEE 802 specifications assigned half of the 48-bit MAC 729 address space to local use -- these addresses have the U/L bit set to 730 1 and are locally administered with no imposed structure. 732 In 2017, the IEEE issued the 802c specification which defines a new 733 "optional Structured Local Address Plan (SLAP) that specifies 734 different assignment approaches in four specified regions of the 735 local MAC address space." Under this plan, there are 4 SLAP 736 quadrants that use different assignment policies. 738 The first octet of the MAC address Z and Y bits define the quadrant 739 for locally assigned addresses (X-bit is 1). In IEEE representation, 740 these bits are as follows: 742 LSB MSB 743 M X Y Z - - - - 744 | | | | 745 | | | +------------ SLAP Z-bit 746 | | +--------------- SLAP Y-bit 747 | +------------------ X-bit (U/L) = 1 for locally assigned 748 +--------------------- M-bit (I/G) (unicast/group) 750 Figure 4: SLAP Bits 752 The SLAP quadrants are: 754 +----------+-------+-------+-----------------------+----------------+ 755 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 756 | | | | | Identifier | 757 +----------+-------+-------+-----------------------+----------------+ 758 | 01 | 0 | 1 | Extended Local | ELI | 759 | 11 | 1 | 1 | Standard Assigned | SAI | 760 | 00 | 0 | 0 | Administratively | AAI | 761 | | | | Assigned | | 762 | 10 | 1 | 0 | Reserved | Reserved | 763 +----------+-------+-------+-----------------------+----------------+ 765 SLAP Quadrants 767 Extended Local Identifier (ELI) derived MAC addresses are based on an 768 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 769 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 770 locally assigned address for each CID for unicast (M-bit = 0) and 771 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 773 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 774 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 775 addresses, 44 bits are available. Multiple protocols for assigning 776 SAIs may be specified in IEEE standards. Coexistence of multiple 777 protocols may be supported by limiting the subspace available for 778 assignment by each protocol. 780 Administratively Assigned Identifier (AAI) derived MAC addresses are 781 assigned locally. Administrators manage the space as needed. Note 782 that multicast IPv6 packets ([RFC2464]) use a destination address 783 starting in 33-33 and this falls within this space and therefore 784 should not be used to avoid conflict with IPv6 multicast addresses. 785 For 48-bit MAC addresses, 44 bits are available. 787 The last quadrant is reserved for future use. While this quadrant 788 may also be used for AAI space, administrators should be aware that 789 future specifications may define alternate uses that could be 790 incompatible. 792 Authors' Addresses 794 Bernie Volz 795 Cisco Systems, Inc. 796 1414 Massachusetts Ave 797 Boxborough, MA 01719 798 USA 800 Email: volz@cisco.com 802 Tomek Mrugalski 803 Internet Systems Consortium, Inc. 804 950 Charter Street 805 Redwood City, CA 94063 806 USA 808 Email: tomasz.mrugalski@gmail.com 810 Carlos J. Bernardos 811 Universidad Carlos III de Madrid 812 Av. Universidad, 30 813 Leganes, Madrid 28911 814 Spain 816 Phone: +34 91624 6236 817 Email: cjbc@it.uc3m.es 818 URI: http://www.it.uc3m.es/cjbc/