idnits 2.17.1 draft-bvtm-dhc-mac-assign-01.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 541 has weird spacing: '...options any e...' -- The document date (May 14, 2018) is 2171 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: November 15, 2018 ISC 6 May 14, 2018 8 Link-Layer Addresses Assignment Mechanism for DHCPv6 9 draft-bvtm-dhc-mac-assign-01 11 Abstract 13 In certain environments, e.g. large scale virtualization deployments, 14 new devices are created in an automated manner. Such devices 15 typically have their link-layer (MAC) addresses randomized. With 16 sufficient scale, the likelihood of collision is not acceptable. 17 Therefore an allocation mechanism is required. This draft proposes 18 an extension to DHCPv6 that allows a scalable approach to link-layer 19 address assignments. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 15, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . 4 59 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 6 60 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 6 61 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 7 62 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 8 63 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 8 64 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 8 65 10.1. Identity Association for Link-Layer Addresses Option . . 8 66 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 10 67 11. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 68 12. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 69 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 72 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 16.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 There are several new deployment types that deal with a large number 81 of devices that need to be initialized. One of them is a scenario 82 where virtual machines (VMs) are created on a massive scale. 83 Typically the new VM instances are assigned a random link-layer (MAC) 84 address, but that does not scale well due to the birthday paradox. 85 Another use case is IoT devices. Typically there is no need to 86 provide global uniqueness of MAC addresses for such devices. On the 87 other hand, the huge number of such devices would likely exhaust a 88 vendor's OUI (Organizationally Unique Identifier) global address 89 space. For those reasons, it is desired to have some form of local 90 authority that would be able to assign MAC addresses. 92 This document proposes a new mechanism that extends DHCPv6 operation 93 to handle link-layer address assignments. 95 Since DHCPv6 ([I-D.ietf-dhc-rfc3315bis]) is a protocol that can 96 allocate various types of resources (non-temporary addresses, 97 temporary addresses, prefixes, but also many options) and has 98 necessary infrastructure (numerous server and client implementations, 99 large deployed relay infrastructure, supportive solutions, like 100 leasequery and failover) to maintain such assignment, it is a good 101 candidate to address the desired functionality. 103 While this document presents a design that should be usable for any 104 link-layer address type, some of the details are specific to Ethernet 105 / IEEE 802 48-bit MAC addresses. Future documents may provide 106 specifics for other link-layer address types. 108 The IEEE originally set aside half of the 48-bit MAC Address space 109 for local use (where the U/L bit is set to 1). In 2017, the IEEE 110 specified an optional specification (IEEE 802c) that divides this 111 space into quadrants (Standards Assigned Identifier, Extended Local 112 Identifier, Administratively Assigned Identifier, and a Reserved 113 quadrant) - more details are in Appendix A. The IEEE is also working 114 to specify protocols and procedures for assignment of locally unique 115 addresses (IEEE 802.1cq). This work may serve as one such protocol 116 for assignment. For additional background, see [IEEE-802-Tutorial]. 118 2. Requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Terminology 128 The DHCPv6 terminology relevant to this specification from the DHCPv6 129 Protocol [I-D.ietf-dhc-rfc3315bis] applies here. 131 client A device that is interested in obtaining link-layer 132 addresses. It implements the basic DHCPv6 mechanisms 133 needed by a DHCPv6 client as described in 134 [I-D.ietf-dhc-rfc3315bis] and supports the new options 135 (IA_LL and LLADDR) specified in this document. The 136 client may or may not support address assignment and 137 prefix delegation as specified in 138 [I-D.ietf-dhc-rfc3315bis]. 140 server Software that manages link-layer address allocation and 141 is able to respond to client queries. It implements 142 basic DHCPv6 server functionality as described in 143 [I-D.ietf-dhc-rfc3315bis] and supports the new options 144 (IA_LL and LLADDR) specified in this document. The 145 server may or may not support address assignment and 146 prefix delegation as specified in 147 [I-D.ietf-dhc-rfc3315bis]. 149 address Unless specified otherwise, an address means a link- 150 layer (or MAC) address, as defined in IEEE802. The 151 address is typically 6 bytes long, but some network 152 architectures may use different lengths. 154 address block A number of consecutive link-layer addresses. An 155 address block is expressed as a first address plus a 156 number that designates the number of additional (extra) 157 addresses. A single address can be represented by the 158 address itself and zero extra addresses. 160 4. Mechanism Overview 162 This mechanism is designed to be generic and usable in many 163 deployments, but there are two scenarios it attempts to address in 164 particular. The first one pertains to large scale virtualization. 165 In such environments the governing entity is often called a 166 hypervisor and is frequently required to spawn new VMs. The 167 hypervisor needs to assign new MAC addresses to those machines. It 168 acts as a DHCP client and requests available DHCP servers to assign 169 one or more MAC addresses (an address block). The hypervisor does 170 not use those addresses for itself, but rather uses them to create 171 new VMs with appropriate MAC addresses. It is worth pointing out the 172 cumulative nature of this scenario. Over time, the hypervisor is 173 likely to increase its MAC addresses usage. While some obsolete VMs 174 will be deleted and their MAC addresses will become eligible for 175 release or reuse, it is unexpected for all MAC addresses to be 176 released. 178 Another usage scenario is related to IoT (Internet of Things). With 179 the emergence of IoT, a new class of cheap, sometimes short lived and 180 disposable devices, has emerged. Examples may include various 181 sensors (e.g. medical) and actuators or controllable LED lights. 182 Upon first boot, the device uses a temporary MAC address, as 183 described in [IEEE-802.11-02/109r0], to send initial DHCP packets to 184 available DHCP servers. Such devices will typically request a single 185 MAC address for each available network interface, which typically 186 means one MAC address per device. Once the server assigns a MAC 187 address, the device abandons its temporary MAC address. 189 In all scenarios the protocol operates in fundamentally the same way. 190 The device requesting an address, acting as a DHCP client, will send 191 a Solicit message with a IA_LL option to all available DHCP servers. 192 That IA_LL option MUST include a LLADDR option specifying the link- 193 layer-type and link-layer-len and may specify a specific address or 194 address block as a hint for the server. Each available server 195 responds with an Advertise message with offered link-layer address or 196 addresses. The client then picks the best server, as governed by 197 [I-D.ietf-dhc-rfc3315bis], and will send a Request message. The 198 target server will then assign the link-layer addresses and send a 199 Reply message. Upon reception, the client can start using those 200 link-layer addresses. 202 Normal DHCP mechanisms are in use. The client is expected to 203 periodically renew the link-layer addresses as governed by T1 and T2 204 timers. This mechanism can be administratively disabled by the 205 server sending "infinity" as the T1 and T2 values (see Section 7.7 of 206 [I-D.ietf-dhc-rfc3315bis]). 208 The client can release link-layer addresses when they are no longer 209 needed by sending a Release message (see Section 18.2.7 of 210 [I-D.ietf-dhc-rfc3315bis]). 212 Confirm, Decline, and Information-Request messages are not used in 213 link-layer address assignment. 215 Clients implementing this mechanism SHOULD use the Rapid Commit 216 option as specified in Section 5.1 and 18.2.1 of 217 [I-D.ietf-dhc-rfc3315bis]. 219 An administrator may make the address assignment permanent by 220 specifying use of infinite lifetimes, as defined in Section 7.7 of 221 [I-D.ietf-dhc-rfc3315bis]. An administrator may also the disable the 222 need for the renewal mechanism by setting the T1 and T2 values to 223 infinity. 225 Devices supporting this proposal MAY support reconfigure mechanism, 226 as defined in Section 18.2.11 of [I-D.ietf-dhc-rfc3315bis]. If 227 supported by both server and client, this mechanism allows the 228 administrator to immediately notify clients that the configuration 229 has changed and triggers retrieval of relevant changes immediately, 230 rather than after T1 timer elapses. Since this mechanism requires 231 implementation of Reconfigure Key Authentication Protocol (See 232 Section 20.4 of [I-D.ietf-dhc-rfc3315bis]), small footprint devices 233 may chose to not support it. 235 DISCUSSION: A device may send its link-layer address in a LLADDR 236 option to ask the server to register that address to the client (if 237 available), making the assignment permanent for the lease duration. 238 The client MUST be prepared to use a different address if the server 239 choses not to honor its hint. 241 5. Design Assumptions 243 One of the essential aspects of this mechanism is its cumulative 244 nature, especially in the hypervisor scenario. The server-client 245 relationship does not look like other DHCP transactions. This is 246 especially true in the hypervisor scenario. In a typical 247 environment, there would be one server and a rather small number of 248 hypervisors, possibly even only one. However, over time the number 249 of MAC addresses requested by the hypervisor(s) will likely increase 250 as new VMs are spawned. 252 Another aspect crucial for efficient design is the observation that a 253 single client acting as hypervisor will likely use thousands of 254 addresses. Therefore an approach similar to what is used for address 255 or prefix assignment (IA container with all assigned addresses 256 listed, one option for each address) would not work well. Therefore 257 the mechanism should operate on address blocks, rather than single 258 values. A single address can be treated as an address block with 259 just one address. 261 The DHCPv6 mechanisms are reused to large degree, including message 262 and option formats, transmission mechanisms, relay infrastructure and 263 others. However, a device wishing to support only link-layer address 264 assignment is not required to support full DHCPv6. In other words, 265 the device may support only assignment of link-layer addresses, but 266 not IPv6 addresses or prefixes. 268 6. Information Encoding 270 A client MUST send a LLADDR option encapsulated in a IA_LL option to 271 specify the link-layer-type and link-layer-len values. For link- 272 layer-type 1 (Ethernet / IEEE 802 48-bit MAC addresses), a client 273 sets the link-layer-address field to: 275 1. 00:00:00:00:00:00 (all zeroes) if the client has no hint as to 276 the starting address of the unicast address block. This address 277 has the IEEE 802 individual/group bit set to 0 (individual). 279 2. 01:00:00:00:00:00 if the client has no hint as to the starting 280 address of the multicast address block. This address has the 281 IEEE 802 individual/group bit set to 1 (group). 283 3. Any other value to request a specific block of address starting 284 with the specified address (this may be a unicast or multicast 285 address). 287 A client sets the extra-addresses field to either 0 for a single 288 address or to the size of the requested address block minus 1. 290 A client SHOULD set the valid-lifetime field to 0 (as it is ignored 291 by the server). 293 7. Requesting Addresses 295 The link-layer addresses are assigned in blocks. The smallest block 296 is a single address. To request an assignment, the client sends a 297 Solicit message with a IA_LL option in the message. The IA_LL option 298 MUST contain a LLADDR option as specified in Section 6. 300 The server, upon receiving a IA_LL option, inspects its content and 301 may offer an address or addresses for each LLADDR option according to 302 its policy. The server MAY take into consideration the address block 303 requested by the client in the LLADDR option. However, the server 304 MAY chose to ignore some or all parameters of the requested address 305 block. In particular, the server may send a different starting 306 address than requested, or grant a smaller number of addresses than 307 requested. The server sends back an Advertise message an IA_LL 308 option containing an LLADDR option that specifies the addresses being 309 offered. If the server is unable to provide any addresses it MUST 310 return the IA_LL option containing a Status Code option (see 311 Section 21.13 of [I-D.ietf-dhc-rfc3315bis]) with status set to 312 NoAddrsAvail. 314 The client MUST be able to handle a response that contains an address 315 or addresses different than those requested. 317 The client waits for available servers to send Advertise responses 318 and picks one server as defined in Section 18.2.9 of 319 [I-D.ietf-dhc-rfc3315bis]. The client then sends a Request message 320 that includes the IA_LL container option with the LLADDR option 321 copied from the Advertise message sent by the chosen server. 323 Upon reception of a Request message with IA_LL container option, the 324 server assigns requested addresses. The server MAY alter the 325 allocation at this time. It then generates and sends a Reply message 326 back to the client. 328 Upon receiving a Reply message, the client parses the IA_LL container 329 option and may start using all provided addresses. It MUST restart 330 its T1 and T2 timers using the values specified in the IA_LL option. 332 A client that has included a Rapid Commit option in the Solicit, may 333 receive a Reply in response to the Solicit and skip the Advertise and 334 Request steps above (see Section 18.2.1 of 335 [I-D.ietf-dhc-rfc3315bis]). 337 8. Renewing Addresses 339 Address renewals follow the normal DHCPv6 renewals processing 340 described in Section 18.2.4 of [I-D.ietf-dhc-rfc3315bis]. Once the 341 T1 timer elapses, the client starts sending Renew messages with the 342 IA_LL option containing a LLADDR option for the address block being 343 renewed. The server responds with a Reply message that contains the 344 renewed address block. The server SHOULD NOT alter the address block 345 being renewed, unless its policy has changed. The server MUST NOT 346 shrink or expand the address block - once a block is assigned and has 347 a non-zero valid lifetime, its size, starting address, and ending 348 address MUST NOT change. 350 TODO: The growth in hypervisor case. The hypervisor client will 351 start with certain number of MAC addresses and then will keep asking 352 for more over time. 354 If the client is unable to Renew before the T2 timer elapses, it 355 starts sending Rebind messages as described in 18.2.5 of 356 [I-D.ietf-dhc-rfc3315bis]. 358 9. Releasing Addresses 360 The client may decide to release a leased address block. A client 361 MUST release the whole block in its entirety. A client releases an 362 address block by sending a Release message that includes the IA_LL 363 option containing the LLADDR option for the address block to release. 364 The Release transmission mechanism is described in Section 18.2.7 of 365 [I-D.ietf-dhc-rfc3315bis]. 367 10. Option Definitions 369 This mechanism uses an approach similar to the existing mechanisms in 370 DHCP. There is one container option (the IA_LL option) that contains 371 the actual link-layer address or addresses, represented by an LLADDR 372 option. Each such option represents an address block, which is 373 expressed as a first address with a number that specifies how many 374 additional addresses are included. 376 10.1. Identity Association for Link-Layer Addresses Option 378 The Identity Association for Link-Layer Addresses option (IA_LL 379 option) is used to carry one or more IA_LL options, the parameters 380 associated with the IA_LL, and the address blocks associated with the 381 IA_LL. 383 The format of the IA_LL option is: 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | OPTION_IA_LL | option-len | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | IAID (4 octets) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | T1 (4 octets) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | T2 (4 octets) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 . . 395 . IA_LL-options . 396 . . 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 1: IA_LL Option Format 401 option-code OPTION_IA_LL (tbd1). 403 option-len 12 + length of IA_LL-options field. 405 IAID The unique identifier for this IA_LL; the IAID must 406 be unique among the identifiers for all of this 407 client's IA_LLs. The number space for IA_LL IAIDs is 408 separate from the number space for other IA option 409 types (i.e., IA_NA, IA_TA, and IA_PD). A four octets 410 long field. 412 T1 The time at which the client should contact the 413 server from which the addresses in the IA_LL were 414 obtained to extend the valid lifetime of the 415 addresses assigned to the IA_LL; T1 is a time 416 duration relative to the current time expressed in 417 units of seconds. A four octets long field. 419 T2 The time at which the client should contact any 420 available server to extend the valid lifetime of the 421 addresses assigned to the IA_LL; T2 is a time 422 duration relative to the current time expressed in 423 units of seconds. A four octets long field. 425 IA_LL-options Options associated with this IA_LL. A variable 426 length field (12 octets less than the value in the 427 option-len field). 429 An IA_LL option may only appear in the options area of a DHCP 430 message. A DHCP message may contain multiple IA_LL options (though 431 each must have a unique IAID). 433 The status of any operations involving this IA_LL is indicated in a 434 Status Code option (see Section 21.13 of [I-D.ietf-dhc-rfc3315bis]) 435 in the IA_LL-options field. 437 Note that an IA_LL has no explicit "lifetime" or "lease length" of 438 its own. When the valid lifetimes of all of the addresses in an 439 IA_LL have expired, the IA_LL can be considered as having expired. 440 T1 and T2 are included to give servers explicit control over when a 441 client recontacts the server about a specific IA_LL. 443 In a message sent by a client to a server, the T1 and T2 fields 444 SHOULD be set to 0. The server MUST ignore any values in these 445 fields in messages received from a client. 447 In a message sent by a server to a client, the client MUST use the 448 values in the T1 and T2 fields for the T1 and T2 times, unless those 449 values in those fields are 0. The values in the T1 and T2 fields are 450 the number of seconds until T1 and T2. 452 As per Section 7.7 of [I-D.ietf-dhc-rfc3315bis]), the value 453 0xffffffff is taken to mean "infinity" and should be used carefully. 455 The server selects the T1 and T2 times to allow the client to extend 456 the lifetimes of any address block in the IA_LL before the lifetimes 457 expire, even if the server is unavailable for some short period of 458 time. Recommended values for T1 and T2 are .5 and .8 times the 459 shortest valid lifetime of the address blocks in the IA that the 460 server is willing to extend, respectively. If the "shortest" valid 461 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 462 are also 0xffffffff. If the time at which the addresses in an IA_LL 463 are to be renewed is to be left to the discretion of the client, the 464 server sets T1 and T2 to 0. The client MUST follow the rules defined 465 in Section 14.2 in [I-D.ietf-dhc-rfc3315bis]. 467 If a client receives an IA_LL with T1 greater than T2, and both T1 468 and T2 are greater than 0, the client discards the IA_LL option and 469 processes the remainder of the message as though the server had not 470 included the invalid IA_LL option. 472 10.2. Link-Layer Addresses Option 474 The Link-Layer Addresses option is used to specify an address block 475 associated with a IA_LL. The option must be encapsulated in the 476 IA_LL-options field of an IA_LL option. The LLaddr-options fields 477 encapsulates those options that are specific to this address block. 479 The format of the Link-Layer Addresses option is: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | OPTION_LLADDR | option-len | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | link-layer-type | link-layer-len | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | | 489 | link-layer-address | 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | extra-addresses | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | valid-lifetime | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 . . 497 . LLaddr-options . 498 . . 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 2: LLADDR Option Format 503 option-code OPTION_LLADDR (tbd2). 505 option-len 12 + link-layer-len field (typically 6) + length of 506 LLaddr-options field. Assuming a typical link-layer 507 address of 6 is used and there are no extra options, 508 length should be equal to 18. 510 link-layer-type The link-layer type MUST be a valid hardware type 511 assigned by the IANA, as described in [RFC5494]. The 512 type is stored in network byte order. 514 link-layer-len Specifies the length of the link-layer-address field 515 (typically 6, for a link-layer-type of 1 (Ethernet)). 516 A two octets long field. 518 link-layer-address Specifies the link-layer address that is being 519 requested or a special value to request any address. 520 For a link-layer type of 1 (Ethernet / IEEE 802 521 48-bit MAC addresses), see Section 6 for details on 522 these values. This value can be only sent by a 523 client that requests a new block. In responses from 524 a server, this value specifies the first address 525 allocated. 527 extra-addresses Number of additional addresses that follow address 528 specified in link-layer-address. For requesting a 529 single address, use 0. For example: link-layer- 530 address: 02:04:06:08:0a and extra-addresses 3 531 designates a block of 4 addresses, starting from 532 02:04:06:08:0a (inclusive) and ending with 533 02:04:06:08:0d (inclusive). In responses from a 534 server, this value specifies the number of additional 535 addresses allocated. A four octets long field. 537 valid-lifetime The valid lifetime for the address(es) in the option, 538 expressed in units of seconds. A four octets long 539 field. 541 LLaddr-options any encapsulated options that are specific to this 542 particular address block. Currently there are no 543 such options defined, but they may appear in the 544 future. 546 In a message sent by a client to a server, the valid lifetime field 547 SHOULD be set to 0. The server MUST ignore any received value. 549 In a message sent by a server to a client, the client MUST use the 550 value in the valid lifetime field for the valid lifetime for the 551 address block. The value in the valid lifetime field is the number 552 of seconds remaining in the lifetime. 554 As per Section 7.7 of [I-D.ietf-dhc-rfc3315bis], the valid lifetime 555 of 0xffffffff is taken to mean "infinity" and should be used 556 carefully. 558 More than one LLADDR option can appear in an IA_LL option. 560 11. Client Behavior 562 TODO: We need start this section by clearly defining what 'client' 563 means in this context (either hypervisor acting on behalf of the 564 client to be spawned or the IOT device acting on its own behalf). 566 12. Server Behavior 568 TODO: Need to describe server operation. Likely also recommend 569 assigning MAC addresses from an appropriate quadrant (see Appendix). 571 13. IANA Considerations 573 IANA is kindly requested to assign new value for options OPTION_LL 574 (tbd1) and OPTION_LLADDR (tbd2) and add those values to the DHCPv6 575 Option Codes registry maintained at http://www.iana.org/assignments/ 576 dhcpv6-parameters. 578 14. Security Considerations 580 See [I-D.ietf-dhc-rfc3315bis] for the DHCPv6 security considerations. 582 TODO: Do we need more? 584 15. Privacy Considerations 586 See [I-D.ietf-dhc-rfc3315bis] for the DHCPv6 privacy considerations. 588 For a client requesting a link-layer address directly from a server, 589 as the link-layer address assigned to a client will likely be used by 590 the client to communicate on the link, the address will be exposed to 591 those able to listen in on this communication. For those peers on 592 the link that are able to listen in on the DHCPv6 exchange, they 593 would also be able to correlate the client's identity (based on the 594 DUID used) with the assigned address. 596 TODO: Do we need more? 598 16. References 600 16.1. Normative References 602 [I-D.ietf-dhc-rfc3315bis] 603 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 604 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 605 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 606 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 607 April 2018. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 615 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 616 May 2017, . 618 16.2. Informative References 620 [IEEE-802-Tutorial] 621 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing, 622 https://datatracker.ietf.org/meeting/96/materials/ 623 slides-96-edu-ieee802work-0/". 625 [IEEE-802.11-02/109r0] 626 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 627 "Temporary MAC address for anonymity, 628 https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i- 629 temporary-mac-address-for-anonymity.ppt". 631 [IEEEStd802c-2017] 632 IEEE Computer Society, "IEEE Standard for Local and 633 Metropolitan Area Networks: Overview and Architecture, 634 Amendment 2: Local Medium Access Control (MAC) Address 635 Usage, IEEE Std 802c-2017". 637 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 638 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 639 . 641 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 642 for the Address Resolution Protocol (ARP)", RFC 5494, 643 DOI 10.17487/RFC5494, April 2009, 644 . 646 Appendix A. IEEE 802c Summary 648 This appendix provides a brief summary of IEEE802c from 649 [IEEEStd802c-2017]. 651 The original IEEE 802 specifications assigned half of the 48-bit MAC 652 address space to local use -- these addresses have the U/L bit set to 653 1 and are locally administered with no imposed structure. 655 In 2017, the IEEE issued the 802c specification which defines a new 656 "optional Structured Local Address Plan (SLAP) that specifies 657 different assignment approaches in four specified regions of the 658 local MAC address space." Under this plan, there are 4 SLAP 659 quadrants that use different assignment policies. 661 The first octet of the MAC address Z and Y bits define the quadrant 662 for locally assigned addresses (X-bit is 1). In IEEE representation, 663 these bits are as follows: 665 LSB MSB 666 M X Y Z - - - - 667 | | | | 668 | | | +------------ SLAP Z-bit 669 | | +--------------- SLAP Y-bit 670 | +------------------ X-bit (U/L) = 1 for locally assigned 671 +--------------------- M-bit (I/G) (unicast/group) 673 Figure 3: SLAP Bits 675 The SLAP quadrants are: 677 +----------+-------+-------+-----------------------+----------------+ 678 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 679 | | | | | Identifier | 680 +----------+-------+-------+-----------------------+----------------+ 681 | 01 | 0 | 1 | Extended Local | ELI | 682 | 11 | 1 | 1 | Standard Assigned | SAI | 683 | 00 | 0 | 0 | Administratively | AAI | 684 | | | | Assigned | | 685 | 10 | 1 | 0 | Reserved | Reserved | 686 +----------+-------+-------+-----------------------+----------------+ 688 SLAP Quadrants 690 Extended Local Identifier (ELI) derived MAC addresses are based on an 691 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 692 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 693 locally assigned address for each CID for unicast (M-bit = 0) and 694 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 696 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 697 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 698 addresses, 44 bits are available. Multiple protocols for assigning 699 SAIs may be specified in IEEE standards. Coexistence of multiple 700 protocols may be supported by limiting the subspace available for 701 assignment by each protocol. 703 Administratively Assigned Identifier (AAI) derived MAC addresses are 704 assigned locally. Administrators manage the space as needed. Note 705 that multicast IPv6 packets ([RFC2464]) use a destination address 706 starting in 33-33 and this falls within this space and therefore 707 should not be used to avoid conflict with IPv6 multicast addresses. 708 For 48-bit MAC addresses, 44 bits are available. 710 The last quadrant is reserved for future use. While this quadrant 711 may also be used for AAI space, administrators should be aware that 712 future specifications may define alternate uses that could be 713 incompatible. 715 Authors' Addresses 717 Bernie Volz 718 Cisco Systems, Inc. 719 1414 Massachusetts Ave 720 Boxborough, MA 01719 721 USA 723 Email: volz@cisco.com 725 Tomek Mrugalski 726 Internet Systems Consortium, Inc. 727 950 Charter Street 728 Redwood City, CA 94063 729 USA 731 Email: tomasz.mrugalski@gmail.com