idnits 2.17.1 draft-bvtm-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 521 has weird spacing: '...options any e...' -- The document date (March 5, 2018) is 2237 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 (-13) exists of draft-ietf-dhc-rfc3315bis-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) B. Volz 3 Internet-Draft Cisco 4 Intended status: Standards Track T. Mrugalski 5 Expires: September 6, 2018 ISC 6 March 5, 2018 8 Link-Layer Addresses Assignment Mechanism for DHCPv6 9 draft-bvtm-dhc-mac-assign-00 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 September 6, 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 . . . . . . . . . . . . . . . . . . . . . 5 60 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 6 61 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 6 62 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 15 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 The IEEE originally set aside half of the 48-bit MAC Address space 93 for local use (where the U/L bit is set to 1). In 2017, the IEEE 94 specified an optional specification (IEEE 802c) that divides this 95 space into quadrants (Standards Assigned Identifier, Extended Local 96 Identifier, Administratively Assigned Identifier, and a Reserved 97 quadrant) - more details are in Appendix A. The IEEE is also working 98 to specify protocols and procedures for assignment of locally unique 99 addresses (IEEE 802.1cq). This work may serve as one such protocol 100 for assignment. For additional background, see [IEEE-802-Tutorial]. 102 This document proposes a new mechanism that extends DHCPv6 operation 103 to handle MAC address assignments. 105 Since DHCPv6 ([I-D.ietf-dhc-rfc3315bis]) is a protocol that can 106 allocate various types of resources (non-temporary addresses, 107 temporary addresses, prefixes, but also many options) and has 108 necessary infrastructure (numerous server and client implementations, 109 large deployed relay infrastructure, supportive solutions, like 110 leasequery and failover) to maintain such assignment, it is a good 111 candidate to address the desired functionality. 113 2. Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Terminology 123 The DHCPv6 terminology relevant to this specification from the DHCPv6 124 Protocol [I-D.ietf-dhc-rfc3315bis] applies here. 126 client A device that is interested in obtaining 127 link-layer addresses. It implements the 128 basic DHCPv6 mechanisms needed by a DHCPv6 129 client as described in 130 [I-D.ietf-dhc-rfc3315bis] and supports the 131 new options (IA_LL and LLADDR) specified in 132 this document. The client may or may not 133 support address assignment and prefix 134 delegation as specified in 135 [I-D.ietf-dhc-rfc3315bis]. 137 server Software that manages link-layer address 138 allocation and is able to respond to client 139 queries. It implements basic DHCPv6 server 140 functionality as described in 141 [I-D.ietf-dhc-rfc3315bis] and supports the 142 new options (IA_LL and LLADDR) specified in 143 this document. The server may or may not 144 support address assignment and prefix 145 delegation as specified in 146 [I-D.ietf-dhc-rfc3315bis]. 148 address Unless specified otherwise, an address 149 means a link-layer (or MAC) address, as 150 defined in IEEE802. The address is 151 typically 6 bytes long, but some network 152 architectures may use different lengths. 154 address block A number of consecutive link-layer 155 addresses. An address block is expressed 156 as a first address plus a number that 157 designates the number of additional (extra) 158 addresses. A single address can be 159 represented by the address itself and zero 160 extra addresses. 162 4. Mechanism Overview 164 This mechanism is designed to be generic and usable in many 165 deployments, but there are two scenarios it attempts to address in 166 particular. The first one pertains to large scale virtualization. 167 In such environments the governing entity is often called a 168 hypervisor and is frequently required to spawn new VMs. The 169 hypervisor needs to assign new MAC addresses to those machines. It 170 acts as a DHCP client and requests available DHCP servers to assign 171 one or more MAC addresses (an address block). The hypervisor does 172 not use those addresses for itself, but rather uses them to create 173 new VMs with appropriate MAC addresses. It is worth pointing out the 174 cumulative nature of a scenario. Over time, the hypervisor is likely 175 to increase its MAC addresses usage. While some obsolete VMs will be 176 deleted and their MAC addresses will become eligible for release or 177 reuse, it is unexpected for all MAC addresses to be released. 179 Another usage scenario is related to IoT (Internet of Things). With 180 the emergence of IoT, a new class of cheap, sometimes short lived and 181 disposable devices, has emerged. Examples may include various 182 sensors (e.g. medical) and actuators or controllable LED lights. 183 Upon first boot, the device uses a temporary MAC address, as 184 described in [IEEE-802.11-02/109r0], to send initial DHCP packets to 185 available DHCP servers. Such devices will typically request a single 186 MAC address for each available network interface, which typically 187 means one MAC address per device. Once the server assigns a MAC 188 address, the device abandons its temporary MAC address. 190 In all scenarios the protocol operates in fundamentally the same way. 191 The device requesting an address, acting as a DHCP client, will send 192 a Solicit message with a IA_LL option to all available DHCP servers. 194 That IA_LL option MUST include a LLADDR option specifying the link- 195 layer-type and link-layer-len and may specify a specific address or 196 address block as a hint for the server. Each available server 197 responds with an Advertise message with offered link-layer address or 198 addresses. The client then picks the best server, as governed by 199 [I-D.ietf-dhc-rfc3315bis], and will send a Request message. The 200 target server will then assign the link-layer addresses and send a 201 Reply message. Upon reception, the client can start using those 202 link-layer addresses. 204 Normal DHCP mechanisms are in use. The client is expected to 205 periodically renew the link-layer addresses as governed by T1 and T2 206 timers. This mechanism can be administratively disabled by the 207 server sending "infinity" as the T1 and T2 values (see Section 7.7 of 208 [I-D.ietf-dhc-rfc3315bis]). 210 The client can release link-layer addresses when they are no longer 211 needed by sending a Release message (see Section 18.2.7 of 212 [I-D.ietf-dhc-rfc3315bis]). 214 Confirm, Decline, Reconfigure and Information-Request messages are 215 not used in link-layer address assignment. 217 Clients implementing this mechanism SHOULD use the Rapid Commit 218 option as specified in Section 5.1 and 18.2.1 of 219 [I-D.ietf-dhc-rfc3315bis]. 221 An administrator may make the address assignment permanent by 222 specifying use of infinite lifetimes, as defined in Section 7.7 of 223 [I-D.ietf-dhc-rfc3315bis]. An administrator may also the disable the 224 need for the renewal mechanism by setting the T1 and T2 values to 225 infinity. 227 DISCUSSION: A device may send its link-layer address in a LLADDR 228 option to ask the server to register that address to the client (if 229 available), making the assignment permanent for the lease duration. 230 The client MUST be prepared to use a different address if the server 231 choses not to honor its hint. 233 5. Design Assumptions 235 One of the essential aspects of this mechanism is its cumulative 236 nature, especially in the hypervisor scenario. The server-client 237 relationship does not look like other DHCP transactions. This is 238 especially true in the hypervisor scenario. In a typical 239 environment, there would be one server and a rather small number of 240 hypervisors, possibly even only one. However, over time the number 241 of MAC addresses requested by the hypervisor(s) will likely increase 242 as new VMs are spawned. 244 Another aspect crucial for efficient design is the observation that a 245 single client acting as hypervisor will likely use thousands of 246 addresses. Therefore an approach similar to what is used for address 247 or prefix assignment (IA container with all assigned addresses 248 listed, one option for each address) would not work well. Therefore 249 the mechanism should operate on address blocks, rather than single 250 values. A single address can be treated as an address block with 251 just one address. 253 The DHCPv6 mechanisms are reused to large degree, including message 254 and option formats, transmission mechanisms, relay infrastructure and 255 others. However, a device wishing to support only link-layer address 256 assignment is not required to support full DHCPv6. In other words, 257 the device may support only assignment of link-layer addresses, but 258 not IPv6 addresses or prefixes. 260 6. Information Encoding 262 A client MUST send a LLADDR option encapsulated in a IA_LL option to 263 specify the link-layer-type and link-layer-len values. A client sets 264 the link-layer-address field to all zeros if it has no hint as to the 265 starting address of the address block; otherwise it sets this field 266 to the starting address. A client sets the extra-addresses field to 267 either 0 for a single address or to the size of the requested address 268 block minus 1. A client SHOULD set the valid-lifetime field to 0 (as 269 it is ignored by the server). 271 7. Requesting Addresses 273 The link-layer addresses are assigned in blocks. The smallest block 274 is a single address. To request an assignment, the client sends a 275 Solicit message with a IA_LL option in the message. The IA_LL option 276 MUST contain a LLADDR option as specified in Section 6. 278 The server, upon receiving a IA_LL option, inspects its content and 279 may offer an address or addresses for each LLADDR option according to 280 its policy. The server MAY take into consideration the address block 281 requested by the client in the LLADDR option. However, the server 282 MAY chose to ignore some or all of the requested address block. In 283 particular, the server may send a different starting address than 284 requested, or grant a smaller number of addresses than requested. 285 The server sends back an Advertise message an IA_LL option containing 286 an LLADDR option that specifies the addresses being offered. If the 287 server is unable to provide any addresses it MUST return the IA_LL 288 option containing a Status Code option (see Section 21.13 of 289 [I-D.ietf-dhc-rfc3315bis]) with status set to NoAddrsAvail. 291 The client MUST be able to handle a response that contains an address 292 or addresses different than those requested. 294 The client waits for available servers to send Advertise responses 295 and picks one server as defined in Section 18.2.9 of 296 [I-D.ietf-dhc-rfc3315bis]. The client then sends a Request message 297 that includes the IA_LL container option with the LLADDR option 298 copied from the Advertise message sent by the chosen server. 300 Upon reception of a Request message with IA_LL container option, the 301 server assigns requested addresses. The server MAY alter the 302 allocation at this time. It then generates and sends a Reply message 303 back to the client. 305 Upon receiving a Reply message, the client parses the IA_LL container 306 option and may start using all provided addresses. It MUST restart 307 its T1 and T2 timers using the values specified in the IA_LL option. 309 A client that has included a Rapid Commit option in the Solicit, may 310 receive a Reply in response to the Solicit and skip the Advertise and 311 Request steps above (see Section 18.2.1 of 312 [I-D.ietf-dhc-rfc3315bis]). 314 8. Renewing Addresses 316 Address renewals follow the normal DHCPv6 renewals processing 317 described in Section 18.2.4 of [I-D.ietf-dhc-rfc3315bis]. Once the 318 T1 timer elapses, the client starts sending Renew messages with the 319 IA_LL option containing a LLADDR option for the address block being 320 renewed. The server responds with a Reply message that contains the 321 renewed address block. The server SHOULD NOT alter the address block 322 being renewed, unless its policy has changed. The server MUST NOT 323 shrink the address block. The server MAY expand the address block by 324 adding additional addresses. 326 TODO: The growth in hypervisor case. The hypervisor client will 327 start with certain number of MAC addresses and then will keep asking 328 for more over time. 330 TODO: May have to review this renewing behavior? Server should renew 331 or not the entire address block. Not sure about expanding the block? 332 Earlier (Advertise), we required server to use at most the requested 333 block size; so not sure why to allow expanding for Renew. 335 If the client is unable to Renew before the T2 timer elapses, it 336 starts sending Rebind messages as described in 18.2.5 of 337 [I-D.ietf-dhc-rfc3315bis]. 339 9. Releasing Addresses 341 The client may decide to release a leased address block. A client 342 MUST release the whole block in its entirety. A client releases an 343 address block by sending a Release message that includes the IA_LL 344 option containing the LLADDR option for the address block to release. 345 The Release transmission mechanism is described in Section 18.2.7 of 346 [I-D.ietf-dhc-rfc3315bis]. 348 10. Option Definitions 350 This mechanism uses an approach similar to the existing mechanisms in 351 DHCP. There is one container option (the IA_LL option) that contains 352 the actual link-layer address or addresses, represented by an LLADDR 353 option. Each such option represents an address block, which is 354 expressed as a first address with a number that specifies how many 355 additional addresses are included. 357 10.1. Identity Association for Link-Layer Addresses Option 359 The Identity Association for Link-Layer Addresses option (IA_LL 360 option) is used to carry an IA_LL, the parameters associated with the 361 IA_LL, and the address blocks associated with the IA_LL. 363 The format of the IA_LL option is: 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | OPTION_IA_LL | option-len | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | IAID (4 octets) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | T1 (4 octets) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | T2 (4 octets) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 . . 375 . IA_LL-options . 376 . . 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 1: IA_LL Option Format 381 option-code OPTION_IA_LL (tbd1). 383 option-len 12 + length of IA_LL-options field. 385 IAID The unique identifier for this IA_LL; the IAID must 386 be unique among the identifiers for all of this 387 client's IA_LLs. The number space for IA_LL IAIDs is 388 separate from the number space for other IA option 389 types (i.e., IA_NA, IA_TA, and IA_PD). A four octets 390 long field. 392 T1 The time at which the client should contact the 393 server from which the addresses in the IA_LL were 394 obtained to extend the valid lifetime of the 395 addresses assigned to the IA_LL; T1 is a time 396 duration relative to the current time expressed in 397 units of seconds. A four octets long field. 399 T2 The time at which the client should contact any 400 available server to extend the valid lifetime of the 401 addresses assigned to the IA_LL; T2 is a time 402 duration relative to the current time expressed in 403 units of seconds. A four octets long field. 405 IA_LL-options Options associated with this IA_LL. A variable 406 length field (12 octets less than the value in the 407 option-len field). 409 An IA_LL option may only appear in the options area of a DHCP 410 message. A DHCP message may contain multiple IA_LL options (though 411 each must have a unique IAID). 413 Each IA_LL carries one block of link-layer addresses. 415 The status of any operations involving this IA_LL is indicated in a 416 Status Code option (see Section 21.13 of [I-D.ietf-dhc-rfc3315bis]) 417 in the IA_LL-options field. 419 Note that an IA_LL has no explicit "lifetime" or "lease length" of 420 its own. When the valid lifetimes of all of the addresses in an 421 IA_LL have expired, the IA_LL can be considered as having expired. 422 T1 and T2 are included to give servers explicit control over when a 423 client recontacts the server about a specific IA_LL. 425 In a message sent by a client to a server, the T1 and T2 fields 426 SHOULD be set to 0. The server MUST ignore any values in these 427 fields in messages received from a client. 429 In a message sent by a server to a client, the client MUST use the 430 values in the T1 and T2 fields for the T1 and T2 times, unless those 431 values in those fields are 0. The values in the T1 and T2 fields are 432 the number of seconds until T1 and T2. 434 As per Section 7.7 of [I-D.ietf-dhc-rfc3315bis]), the value 435 0xffffffff is taken to mean "infinity" and should be used carefully. 437 The server selects the T1 and T2 times to allow the client to extend 438 the lifetimes of any address block in the IA_LL before the lifetimes 439 expire, even if the server is unavailable for some short period of 440 time. Recommended values for T1 and T2 are .5 and .8 times the 441 shortest valid lifetime of the address blocks in the IA that the 442 server is willing to extend, respectively. If the "shortest" valid 443 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 444 are also 0xffffffff. If the time at which the addresses in an IA_LL 445 are to be renewed is to be left to the discretion of the client, the 446 server sets T1 and T2 to 0. The client MUST follow the rules defined 447 in Section 14.2 in [I-D.ietf-dhc-rfc3315bis]. 449 If a client receives an IA_LL with T1 greater than T2, and both T1 450 and T2 are greater than 0, the client discards the IA_LL option and 451 processes the remainder of the message as though the server had not 452 included the invalid IA_LL option. 454 10.2. Link-Layer Addresses Option 456 The Link-Layer Addresses option is used to specify an address block 457 associated with a IA_LL. The option must be encapsulated in the 458 IA_LL-options field of an IA_LL option. The LLaddr-options fields 459 encapsulates those options that are specific to this address block. 461 The format of the Link-Layer Addresses option is: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | OPTION_LLADDR | option-len | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | link-layer-type | link-layer-len | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 | link-layer-address | 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | extra-addresses | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | valid-lifetime | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 . . 479 . LLaddr-options . 480 . . 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 2: LLADDR Option Format 485 option-code OPTION_LLADDR (tbd2). 487 option-len 12 + link-layer-len field (typically 6) + length of 488 LLaddr-options field. Assuming a typical link-layer 489 address of 6 is used and there are no extra options, 490 length should be equal to 18. 492 link-layer-type The link-layer type MUST be a valid hardware type 493 assigned by the IANA, as described in [RFC5494]. The 494 type is stored in network byte order. 496 link-layer-len Specifies the length of the link-layer-address field 497 (typically 6, for a link-layer-type of 1 (Ethernet)). 498 A two octets long field. 500 link-layer-address Specific value of link-layer address that is 501 being requested. A special case of address 502 consisting of only zeroes means any address. This 503 value can be only sent by a client that requests a 504 new block. In responses from a server, this value 505 specifies the first address allocated. 507 extra-addresses Number of additional addresses that follow address 508 specified in link-layer-address. For requesting a 509 single address, use 0. For example: link-layer- 510 address: 02:04:06:08:0a and extra-addresses 3 511 designates a block of 4 addresses, starting from 512 02:04:06:08:0a (inclusive) and ending with 513 02:04:06:08:0d (inclusive). In responses from a 514 server, this value specifies the number of additional 515 addresses allocated. A four octets long field. 517 valid-lifetime The valid lifetime for the address(es) in the option, 518 expressed in units of seconds. A four octets long 519 field. 521 LLaddr-options any encapsulated options that are specific to this 522 particular address block. Currently there are no 523 such options defined, but they may appear in the 524 future. 526 In a message sent by a client to a server, the valid lifetime field 527 SHOULD be set to 0. The server MUST ignore any received value. 529 In a message sent by a server to a client, the client MUST use the 530 value in the valid lifetime field for the valid lifetime for the 531 address block. The value in the valid lifetime field is the number 532 of seconds remaining in the lifetime. 534 As per Section 7.7 of [I-D.ietf-dhc-rfc3315bis], the valid lifetime 535 of 0xffffffff is taken to mean "infinity" and should be used 536 carefully. 538 More than one LLADDR option can appear in an IA_LL option. 540 11. Client Behavior 542 TODO: We need start this section by clearly defining what 'client' 543 means in this context (either hypervisor acting on behalf of the 544 client to be spawned or the IOT device acting on its own behalf). 546 12. Server Behavior 548 TODO: Need to describe server operation. Likely also recommend 549 assigning MAC addresses from an appropriate quadrant (see Appendix). 551 13. IANA Considerations 553 IANA is kindly requested to assign new value for options OPTION_LL 554 (tbd1) and OPTION_LLADDR (tbd2) and add those values to the DHCPv6 555 Option Codes registry maintained at http://www.iana.org/assignments/ 556 dhcpv6-parameters. 558 14. Security Considerations 560 TODO: 562 15. Privacy Considerations 564 TODO: 566 16. References 568 16.1. Normative References 570 [I-D.ietf-dhc-rfc3315bis] 571 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 572 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 573 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 574 bis", draft-ietf-dhc-rfc3315bis-12 (work in progress), 575 March 2018. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, 579 DOI 10.17487/RFC2119, March 1997, 580 . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 16.2. Informative References 588 [IEEE-802-Tutorial] 589 Thaler, P., "Emerging IEEE 802 Work on MAC Addressing, 590 https://datatracker.ietf.org/meeting/96/materials/ 591 slides-96-edu-ieee802work-0/". 593 [IEEE-802.11-02/109r0] 594 Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, 595 "Temporary MAC address for anonymity, 596 https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i- 597 temporary-mac-address-for-anonymity.ppt". 599 [IEEEStd802c-2017] 600 IEEE Computer Society, "IEEE Standard for Local and 601 Metropolitan Area Networks: Overview and Architecture, 602 Amendment 2: Local Medium Access Control (MAC) Address 603 Usage, IEEE Std 802c-2017". 605 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 606 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 607 . 609 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 610 for the Address Resolution Protocol (ARP)", RFC 5494, 611 DOI 10.17487/RFC5494, April 2009, 612 . 614 Appendix A. IEEE 802c Summary 616 This appendix provides a brief summary of IEEE802c from 617 [IEEEStd802c-2017]. 619 The original IEEE 802 specifications assigned half of the 48-bit MAC 620 address space to local use -- these addresses have the U/L bit set to 621 1 and are locally administered with no imposed structure. 623 In 2017, the IEEE issued the 802c specification which defines a new 624 "optional Structured Local Address Plan (SLAP) that specifies 625 different assignment approaches in four specified regions of the 626 local MAC address space." Under this plan, there are 4 SLAP 627 quadrants that use different assignment policies. 629 The first octet of the MAC address Z and Y bits define the quadrant 630 for locally assigned addresses (X-bit is 1). In IEEE representation, 631 these bits are as follows: 633 LSB MSB 634 M X Y Z - - - - 635 | | | | 636 | | | +------------ SLAP Z-bit 637 | | +--------------- SLAP Y-bit 638 | +------------------ X-bit (U/L) = 1 for locally assigned 639 +--------------------- M-bit (I/G) (unicast/group) 641 Figure 3: SLAP Bits 643 The SLAP quadrants are: 645 +----------+-------+-------+-----------------------+----------------+ 646 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 647 | | | | | Identifier | 648 +----------+-------+-------+-----------------------+----------------+ 649 | 01 | 0 | 1 | Extended Local | ELI | 650 | 11 | 1 | 1 | Standard Assigned | SAI | 651 | 00 | 0 | 0 | Administratively | AAI | 652 | | | | Assigned | | 653 | 10 | 1 | 0 | Reserved | Reserved | 654 +----------+-------+-------+-----------------------+----------------+ 656 SLAP Quadrants 658 Extended Local Identifier (ELI) derived MAC addresses are based on an 659 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 660 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 661 locally assigned address for each CID for unicast (M-bit = 0) and 662 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 664 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 665 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 666 addresses, 44 bits are available. Multiple protocols for assigning 667 SAIs may be specified in IEEE standards. Coexistence of multiple 668 protocols may be supported by limiting the subspace available for 669 assignment by each protocol. 671 Administratively Assigned Identifier (AAI) derived MAC addresses are 672 assigned locally. Administrators manage the space as needed. Note 673 that multicast IPv6 packets ([RFC2464]) use a destination address 674 starting in 33-33 and this falls within this space and therefore 675 should not be used to avoid conflict with IPv6 multicast addresses. 676 For 48-bit MAC addresses, 44 bits are available. 678 The last quadrant is reserved for future use. While this quadrant 679 may also be used for AAI space, administrators should be aware that 680 future specifications may define alternate uses that could be 681 incompatible. 683 Authors' Addresses 685 Bernie Volz 686 Cisco Systems, Inc. 687 1414 Massachusetts Ave 688 Boxborough, MA 01719 689 USA 691 Email: volz@cisco.com 692 Tomek Mrugalski 693 Internet Systems Consortium, Inc. 694 950 Charter Street 695 Redwood City, CA 94063 696 USA 698 Email: tomasz.mrugalski@gmail.com