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