idnits 2.17.1 draft-ietf-dhc-mac-assign-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2020) is 1293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dhc-slap-quadrant-10 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: March 7, 2021 ISC 6 CJ. Bernardos 7 UC3M 8 September 3, 2020 10 Link-Layer Addresses Assignment Mechanism for DHCPv6 11 draft-ietf-dhc-mac-assign-09 13 Abstract 15 In certain environments, e.g., large scale virtualization 16 deployments, new devices are created in an automated manner. Such 17 devices may have their link-layer addresses assigned in an automated 18 fashion. With sufficient scale, the likelihood of a collision using 19 random assignment without duplication detection is not acceptable. 20 Therefore an allocation mechanism is required. This draft proposes 21 an extension to DHCPv6 that allows a scalable approach to link-layer 22 address assignments where preassigned link-layer address assignments 23 (such as by a manufacturer) are not possible or unnecessary. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 7, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Deployment scenarios and mechanism overview . . . . . . . . . 4 63 4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4 64 4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5 65 4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 66 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 6 67 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 7 68 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 7 69 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 9 70 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 9 71 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Identity Association for Link-Layer Addresses Option . . 10 73 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12 74 11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 78 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 16.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 There are several deployment types that deal with a large number of 88 devices that need to be initialized. One of them is a scenario where 89 virtual machines (VMs) are created on a massive scale. Typically the 90 new VM instances are assigned a link-layer address, but random 91 assignment does not scale well due to the risk of a collision (see 92 Appendix A.1 of [RFC4429]). Another use case is IoT (Internet of 93 Things) devices (see [RFC7228]). The huge number of such devices 94 could strain the IEEE's available OUI (Organizationally Unique 95 Identifier) global address space. While there is typically no need 96 to provide global link-layer address uniqueness for such devices, a 97 link-layer assignment mechanism allows for conflicts to be avoided 98 inside an administrative domain. For those reasons, it is desired to 99 have some form of mechanism that would be able to assign locally 100 unique MAC (media access control) addresses. 102 This document proposes a new mechanism that extends DHCPv6 operation 103 to handle link-layer address assignments. 105 Since DHCPv6 ([RFC8415]) is a protocol that can allocate various 106 types of resources (non-temporary addresses, temporary addresses, 107 prefixes, as well as many options) and has the necessary 108 infrastructure to maintain such allocations (numerous server and 109 client implementations, large deployed relay infrastructure, and 110 supportive solutions such as leasequery and failover), it is a good 111 candidate to address the desired functionality. 113 While this document presents a design that should be usable for any 114 link-layer address type, some of the details are specific to IEEE 802 115 48-bit MAC addresses [IEEEStd802]. Future documents may provide 116 specifics for other link-layer address types. 118 IEEE 802 originally set aside half of the 48-bit MAC address space 119 for local use (where the U/L bit is set to 1). In 2017, IEEE 120 published an amendment [IEEEStd802c] that divides this space into 121 quadrants with differentied address rules. More details are in 122 Appendix A. 124 IEEE is also developing protocols and procedures for assignment of 125 locally unique addresses (IEEE 802.1CQ). This work may serve as an 126 alternative protocol for assignment. For additional background, see 127 [IEEE-P802.1CQ-Project]. 129 2. Requirements 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Terminology 139 The DHCP terminology relevant to this specification from [RFC8415] 140 applies here. The following definitions either modify those 141 definitions as to how they are used in this document or define new 142 terminology used herein. 144 address Unless specified otherwise, an address means a link- 145 layer (or MAC) address, as specified in [IEEEStd802]. 146 The address is typically six octets long, but some 147 network architectures may use different lengths. 149 address block A number of consecutive link-layer addresses. An 150 address block is expressed as a first address plus a 151 number that designates the number of additional (extra) 152 addresses. A single address can be represented by the 153 address itself and zero extra addresses. 155 client A node that is interested in obtaining link-layer 156 addresses. It implements the basic DHCP mechanisms 157 needed by a DHCP client as described in [RFC8415] and 158 supports the new options (IA_LL and LLADDR, see below) 159 specified in this document. The client may or may not 160 support IPv6 address assignment and prefix delegation 161 as specified in [RFC8415]. 163 IA_LL Identity Association for Link-Layer Address: an 164 identity association (IA) used to request or assign 165 link-layer addresses. See Section 10.1 for details on 166 the IA_LL option. 168 LLADDR Link-layer address option that is used to request or 169 assign a block of link-layer addresses. See 170 Section 10.2 for details on the LLADDR option. 172 server A node that manages link-layer address allocation and 173 is able to respond to client queries. It implements 174 basic DHCP server functionality as described in 175 [RFC8415] and supports the new options (IA_LL and 176 LLADDR) specified in this document. The server may or 177 may not support IPv6 address assignment and prefix 178 delegation as specified in [RFC8415]. 180 4. Deployment scenarios and mechanism overview 182 This mechanism is designed to be generic and usable in many 183 deployments, but there are two scenarios it attempts to address in 184 particular: (i) proxy client mode, and (ii) direct client mode. 186 4.1. Proxy client mode scenario 188 This mode is used when an entity acts as a DHCP client and requests 189 available DHCP servers to assign one or more addresses (an address 190 block), to be then assigned for use by the final end-devices. Large- 191 scale virtualization is one application scenario for proxy client 192 mode. In such environments this entity is often called a hypervisor 193 and is frequently required to spawn new VMs. The hypervisor needs to 194 assign new addresses to those machines. The hypervisor does not use 195 those addresses for itself, but rather uses them to create new VMs 196 with appropriate addresses. It is worth pointing out the cumulative 197 nature of this scenario. Over time, the hypervisor is likely to 198 increase its address usage. Some obsolete VMs will be deleted and 199 their addresses are potentially eligible for reuse for new VMs. 201 4.2. Direct client mode scenario 203 This mode can be used when an entity acts as a DHCP client and 204 requests available DHCP servers to assign one or more addresses (an 205 address block) for its use. This usage scenario is related to IoT, 206 as described earlier (see Section 1). Upon first boot, for each 207 interface the device uses a temporary address, as described in 208 [IEEEStd802.11] or to be described in IEEE 802.1CQ 209 [IEEE-P802.1CQ-Project], to send initial DHCP packets to available 210 DHCP servers wherein the device requests a single address for that 211 network interface. Once the server assigns an address, the device 212 abandons its temporary address and uses the assigned (leased) 213 address. 215 Note that a client that operates as above that does not have a 216 globally unique link-layer address on any of its interfaces MUST NOT 217 use a link-layer based DUID (DHCP Unique Identifier). For more 218 details, refer to Section 11 of [RFC8415]. 220 Also, a client that operates as above may run into issues if the 221 switch it is connected to prohibits or restricts link-layer address 222 changes. This may limit where this capability can be used, or may 223 require the administrator to adjust the configuration of the 224 switch(es) to allow a change in address. 226 4.3. Mechanism Overview 228 In all scenarios the protocol operates in fundamentally the same way. 229 The device requesting an address, acting as a DHCP client, will send 230 a Solicit message with a IA_LL option to all available DHCP servers. 231 That IA_LL option MUST include a LLADDR option specifying the link- 232 layer-type and link-layer-len and may include a specific address or 233 address block as a hint for the server. Each available server 234 responds with either a Reply message with committed address(es) (if 235 Rapid Commit was requested and honored) or an Advertise message with 236 offered address(es). The client selects a server's response as 237 governed by [RFC8415]. If necessary, the client sends a Request 238 message and the target server will then assign the address(es) and 239 send a Reply message. Once a Reply is received, the client can start 240 using those address(es). 242 Normal DHCP mechanisms are in use. The client is expected to 243 periodically renew the addresses as governed by T1 and T2 timers and 244 stop using the address once the valid lifetime expires. Renewals can 245 be administratively disabled by the server sending "infinity" as the 246 T1 and T2 values (see Section 7.7 of [RFC8415]). An administrator 247 may make the address assignment permanent by specifying use of the 248 "infinity" valid lifetime, as defined in Section 7.7 of [RFC8415]. 250 The client can release addresses when they are no longer needed by 251 sending a Release message (see Section 18.2.7 of [RFC8415]). 253 Figure 9 in [RFC8415] shows a timeline diagram of the messages 254 exchanged between a client and two servers for the typical lifecycle 255 of one or more leases. 257 Confirm and Information-Request messages are not used in link-layer 258 address assignment. Decline should technically never be needed, but 259 see Section 11 for one situation where this message is needed. 261 Clients implementing this mechanism SHOULD use the Rapid Commit 262 option as specified in Section 5.1 and 18.2.1 of [RFC8415] to obtain 263 addresses with a 2-message exchange when possible. 265 Devices supporting this proposal MAY support the reconfigure 266 mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported 267 by both server and client, the reconfigure mechanism allows the 268 administrator to immediately notify clients that the configuration 269 has changed and triggers retrieval of relevant changes immediately, 270 rather than after the T1 timer elapses. Since this mechanism 271 requires implementation of Reconfigure Key Authentication Protocol 272 (See Section 20.4 of [RFC8415]), small-footprint devices may choose 273 to not support it. 275 5. Design Assumptions 277 One of the essential aspects of this mechanism is its cumulative 278 nature, especially in the hypervisor scenario. The server-client 279 relationship does not look like other DHCP transactions in the 280 hypervisor scenario. In a typical environment, there would be one 281 server and a rather small number of hypervisors, possibly even only 282 one. However, over time the number of addresses requested by the 283 hypervisor(s) will increase as more VMs are spawned. 285 Another aspect crucial for efficient design is the observation that a 286 single client acting as hypervisor will likely use thousands of 287 addresses. An approach similar to what is used for IPv6 address or 288 prefix assignment (IA container with all assigned addresses listed, 289 one option for each address) would not work well. Therefore the 290 mechanism should operate on address blocks, rather than single 291 values. A single address can be treated as an address block with 292 just one address. 294 The DHCP mechanisms are reused to large degree, including message and 295 option formats, transmission mechanisms, relay infrastructure and 296 others. However, a device wishing to support only link-layer address 297 assignment is not required to support full DHCP. In other words, the 298 device may support only assignment of link-layer addresses, but not 299 IPv6 addresses or prefixes. 301 6. Information Encoding 303 A client MUST send a LLADDR option encapsulated in an IA_LL option to 304 specify the link-layer-type and link-layer-len values. For link- 305 layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the 306 link-layer-address field to: 308 1. All zeroes if the client has no hint as to the starting address 309 of the unicast address block. This address has the IEEE 802 310 individual/group bit set to 0 (individual). 312 2. Any other value to request a specific block of address starting 313 with the specified address 315 Encoding information for other link-layer-types may be added in the 316 future by publishing an RFC that specifies those values. 318 A client sets the extra-addresses field to either 0 for a single 319 address or the size of the requested address block minus 1. 321 A client MUST set the valid-lifetime field to 0 (this field MUST be 322 ignored by the server). 324 7. Requesting Addresses 326 The addresses are assigned in blocks. The smallest block is a single 327 address. To request an assignment, the client sends a Solicit 328 message with an IA_LL option in the message. The IA_LL option MUST 329 contain a LLADDR option as specified in Section 6. 331 The server, upon receiving an IA_LL option, inspects its content and 332 may offer an address or addresses for each LLADDR option according to 333 its policy. The server MAY take into consideration the address block 334 requested by the client in the LLADDR option. However, the server 335 MAY choose to ignore some or all parameters of the requested address 336 block. In particular, the server may send a different starting 337 address than requested, or a smaller number of addresses than 338 requested. The server sends back an Advertise message with an IA_LL 339 option containing an LLADDR option that specifies the addresses being 340 offered. If the server is unable to provide any addresses it MUST 341 return the IA_LL option containing a Status Code option (see 342 Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. 344 Note: Servers that do not support the IA_LL option will ignore the 345 option and not return it in Advertise (and Reply) messages. Clients 346 that send IA_LL options MUST treat this as if the server returned the 347 NoAddrsAvail status for these IA_LL option(s). 349 The client waits for available servers to send Advertise responses 350 and picks one server as defined in Section 18.2.9 of [RFC8415]. The 351 client then sends a Request message that includes the IA_LL container 352 option with the LLADDR option copied from the Advertise message sent 353 by the chosen server. 355 The client MUST process the address block(s) returned in the 356 Advertise, rather than what it included in the Solicit, and may 357 consider the offered address block(s) in selecting the Advertise to 358 accept. The server may offer a smaller number of addresses or 359 different addresses from those requested. A client MUST NOT use 360 resources returned in an Advertise message except to select a server 361 and in sending the Request to that server; resources are only useable 362 by a client when returned in a Reply message. 364 Upon reception of a Request message with IA_LL container option, the 365 server assigns the requested addresses. The server allocates a block 366 of addresses according to its configured policy. The server MAY 367 assign a different block or smaller block size than requested in the 368 Request message. The server then generates and sends a Reply message 369 back to the client. 371 Upon receiving a Reply message, the client parses the IA_LL container 372 option and may start using all provided addresses. It MUST restart 373 its T1 and T2 timers using the values specified in the IA_LL option. 375 The client MUST use the address block(s) returned in the Reply 376 message, which may be smaller block(s) or with different address(es) 377 than requested. 379 A client that has included a Rapid Commit option in the Solicit may 380 receive a Reply in response to the Solicit and skip the Advertise and 381 Request steps above (see Section 18.2.1 of [RFC8415]). 383 A client that changes its link-layer address on an interface SHOULD 384 follow the recommendations in Section 7.2.6 of [RFC4861] to inform 385 its neighbors of the new link-layer address quickly. 387 8. Renewing Addresses 389 Address renewals follow the normal DHCP renewals processing described 390 in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the 391 client starts sending Renew messages with the IA_LL option containing 392 a LLADDR option for the address block being renewed. The server 393 responds with a Reply message that contains the renewed address 394 block. The server MUST NOT shrink or expand the address block. Once 395 a block is assigned and has a non-zero valid lifetime, its size, 396 starting address, and ending address MUST NOT change. 398 If the requesting client needs additional addresses -- e.g., in the 399 hypervisor scenario because addresses need to be assigned to new VMs 400 -- it MUST send an IA_LL option with a different IAID to create 401 another "container" for more addresses. 403 If the client is unable to Renew before the T2 timer elapses, it 404 starts sending Rebind messages as described in Section 18.2.5 of 405 [RFC8415]. 407 9. Releasing Addresses 409 The client may decide to release a leased address block. A client 410 MUST release the whole block in its entirety. A client releases an 411 address block by sending a Release message that includes an IA_LL 412 option containing the LLADDR option for the address block to release. 413 The Release transmission mechanism is described in Section 18.2.7 of 414 [RFC8415]. 416 Note: If the client is releasing the link-layer address it is using, 417 it MUST stop using this address before sending the Release message 418 (as per [RFC8415]). In order to send the Release message, the client 419 MUST use another address (such as the one originally used to initiate 420 DHCPv6 to provide an allocated link-layer address). 422 10. Option Definitions 424 This mechanism uses an approach similar to the existing mechanisms in 425 DHCP. There is one container option (the IA_LL option) that contains 426 the actual address or addresses, represented by an LLADDR option. 427 Each LLADDR option represents an address block, which is expressed as 428 a first address with a number that specifies how many additional 429 addresses are included. 431 10.1. Identity Association for Link-Layer Addresses Option 433 The Identity Association for Link-Layer Addresses option (IA_LL 434 option) is used to carry an IA_LL, the parameters associated with the 435 IA_LL, and the address blocks associated with the IA_LL. 437 The format of the IA_LL option is: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | OPTION_IA_LL | option-len | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | IAID (4 octets) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | T1 (4 octets) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | T2 (4 octets) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 . . 451 . IA_LL-options . 452 . . 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 1: IA_LL Option Format 457 option-code OPTION_IA_LL (tbd1). 459 option-len 12 + length of IA_LL-options field. 461 IAID The unique identifier for this IA_LL; the IAID must 462 be unique among the identifiers for all of this 463 client's IA_LLs. The number space for IA_LL IAIDs is 464 separate from the number space for other IA option 465 types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet 466 field containing an unsigned integer. 468 T1 The time interval after which the client should 469 contact the server from which the addresses in the 470 IA_LL were obtained to extend the valid lifetime of 471 the addresses assigned to the IA_LL; T1 is a time 472 duration relative to the current time expressed in 473 units of seconds. A 4-octet field containing an 474 unsigned integer. 476 T2 The time interval after which the client should 477 contact any available server to extend the valid 478 lifetime of the addresses assigned to the IA_LL; T2 479 is a time duration relative to the current time 480 expressed in units of seconds. A 4-octet field 481 containing an unsigned integer. 483 IA_LL-options Options associated with this IA_LL. A variable 484 length field (12 octets less than the value in the 485 option-len field). 487 An IA_LL option may only appear in the options area of a DHCP 488 message. A DHCP message may contain multiple IA_LL options (though 489 each must have a unique IAID). 491 The status of any operations involving this IA_LL is indicated in a 492 Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- 493 options field. 495 Note that an IA_LL has no explicit "lifetime" or "lease length" of 496 its own. When the valid lifetimes of all of the addresses in an 497 IA_LL have expired, the IA_LL can be considered as having expired. 498 T1 and T2 are included to give servers explicit control over when a 499 client recontacts the server about a specific IA_LL. 501 In a message sent by a client to a server, the T1 and T2 fields MUST 502 be set to 0. The server MUST ignore any values in these fields in 503 messages received from a client. 505 In a message sent by a server to a client, the client MUST use the 506 values in the T1 and T2 fields for the T1 and T2 times, unless those 507 values in those fields are 0. The values in the T1 and T2 fields are 508 the number of seconds until T1 and T2. 510 As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to 511 mean "infinity" and should be used carefully. 513 The server selects the T1 and T2 times to allow the client to extend 514 the lifetimes of any address block in the IA_LL before the lifetimes 515 expire, even if the server is unavailable for some short period of 516 time. Recommended values for T1 and T2 are .5 and .8 times the 517 shortest valid lifetime of the address blocks in the IA that the 518 server is willing to extend, respectively. If the "shortest" valid 519 lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values 520 are also 0xffffffff. If the time at which the addresses in an IA_LL 521 are to be renewed is to be left to the discretion of the client, the 522 server sets T1 and T2 to 0. The client MUST follow the rules defined 523 in Section 14.2 in [RFC8415]. 525 If a client receives an IA_LL with T1 greater than T2, and both T1 526 and T2 are greater than 0, the client discards the IA_LL option and 527 processes the remainder of the message as though the server had not 528 included the invalid IA_LL option. 530 The IA_LL-options field typically contains one or more LLADDR options 531 (see Section 10.2). If a client does not include a LLADDR option in 532 a Solicit or Request message, the server MUST treat this as a request 533 for a single address and that the client has no hint as to the 534 address it would like. 536 10.2. Link-Layer Addresses Option 538 The Link-Layer Addresses option is used to specify an address block 539 associated with an IA_LL. The option must be encapsulated in the 540 IA_LL-options field of an IA_LL option. The LLaddr-options fields 541 encapsulates those options that are specific to this address block. 543 The format of the Link-Layer Addresses option is: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | OPTION_LLADDR | option-len | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | link-layer-type | link-layer-len | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 . . 553 . link-layer-address . 554 . . 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | extra-addresses | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | valid-lifetime | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 . . 561 . LLaddr-options . 562 . . 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 2: LLADDR Option Format 567 option-code OPTION_LLADDR (tbd2). 569 option-len 12 + link-layer-len field value + length of LLaddr- 570 options field. Assuming a link-layer-address length 571 of 6 and no extra options, the option-len would be 572 18. 574 link-layer-type The link-layer type MUST be a valid hardware type 575 assigned by the IANA, as described in [RFC5494] and 576 in the "Hardware Types" table at 577 https://www.iana.org/assignments/arp-parameters. A 578 2-octet field containing an unsigned integer. 580 link-layer-len Specifies the length, in octets, of the link-layer- 581 address field (typically 6, for a link-layer-type of 582 1 (Ethernet) and 6 (IEEE 802 Networks)). This is to 583 accommodate link-layers that may have variable-length 584 addresses. A 2-octet field containing an unsigned 585 integer. 587 link-layer-address Specifies the address of the first link-layer 588 address that is being requested or assigned depending 589 on the message. A client MAY send a special value to 590 request any address. For a link-layer type of 1 and 591 6, see Section 6 for details on this field. A link- 592 layer-len length octet field containing an address. 594 extra-addresses Specifies the number of additional addresses that 595 follow the address specified in link-layer-address. 596 For a single address, 0 is used. For example: link- 597 layer-address: 02:04:06:08:0a and extra-addresses 3 598 designates a block of 4 addresses, starting from 599 02:04:06:08:0a and ending with 02:04:06:08:0d 600 (inclusive). A 4-octet field containing an unsigned 601 integer. 603 valid-lifetime The valid lifetime for the address(es) in the option, 604 expressed in units of seconds. A 4-octet field 605 containing an unsigned integer. 607 LLaddr-options Any encapsulated options that are specific to this 608 particular address block. Currently there are no 609 such options defined, but there may be in the future. 611 In a message sent by a client to a server, the valid lifetime field 612 MUST be set to 0. The server MUST ignore any received value. 614 In a message sent by a server to a client, the client MUST use the 615 value in the valid lifetime field for the valid lifetime for the 616 address block. The value in the valid lifetime field is the number 617 of seconds remaining in the lifetime. 619 As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is 620 taken to mean "infinity" and should be used carefully. 622 More than one LLADDR option can appear in an IA_LL option. 624 11. Selecting Link-Layer Addresses for Assignment to an IA_LL 626 A server selects link-layer addresses to be assigned to an IA_LL 627 according to the assignment policies determined by the server 628 administrator and the requirements of that address space. 630 Link-layer addresses are typically specific to a link and the server 631 SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the 632 client's link. 634 For IEEE 802 MAC addresses (see [IEEEStd802] as amended by 635 [IEEEStd802c]): 637 1. Server administrators SHOULD follow the IEEE 802 Specifications 638 with regards to the unicast address pools made available for 639 assignment (see Appendix A and [IEEEStd802c]) -- only address 640 space reserved for local use or with the authorization of the 641 assignee may be used. 643 2. Servers MUST NOT allow administrators to configure address pools 644 that would cross the 2^42 bit boundary (for 48-bit MAC addresses) 645 to avoid issues with changes in the first octet of the address 646 and the special bits therein (see Appendix A). Clients MUST 647 reject assignments where the assigned block would cross this 648 boundary (they MUST decline the allocation - see Section 18.2.8 649 of [RFC8415]). 651 3. A server MAY use options supplied by a relay agent or client to 652 select the quadrant (see Appendix A) from which addresses are to 653 be assigned. This MAY include options, such as those specified 654 in [I-D.ietf-dhc-slap-quadrant]. 656 12. IANA Considerations 658 IANA is requested to assign the OPTION_IA_LL (tbd1) option code from 659 the DHCPv6 "Option Codes" registry maintained at 660 http://www.iana.org/assignments/dhcpv6-parameters and use the 661 following data when adding the option to the registry: 663 Value: tbd1 664 Description: OPTION_IA_LL 665 Client ORO: No 666 Singleton Option: No 667 Reference: this document 669 IANA is requested to assign the OPTION_LLADDR (tbd2) option code from 670 the DHCPv6 "Option Codes" registry maintained at 671 http://www.iana.org/assignments/dhcpv6-parameters and use the 672 following data when adding the option to the registry: 674 Value: tbd2 675 Description: OPTION_LLADDR 676 Client ORO: No 677 Singleton Option: No 678 Reference: this document 680 13. Security Considerations 682 See Section 22 of [RFC8415] and Section 23 of [RFC7227] for the DHCP 683 security considerations. See [RFC8200] for the IPv6 security 684 considerations. 686 As discussed in Section 22 of [RFC8415], "DHCP lacks end-to-end 687 encryption between clients and servers; thus, hijacking, tampering, 688 and eavesdropping attacks are all possible as a result." In some 689 network environments, it is possible to secure them as discussed 690 later in that Section 22. 692 There is a possibility of the same link-layer address being used by 693 more than one device if not all parties on a link use this mechanism 694 to obtain an address from the space assigned to the DHCP server. 695 Note that this issue would exist on these networks even if DHCP were 696 not used to obtain the address. 698 Server implementations SHOULD consider configuration options to limit 699 the maximum number of addresses to allocate (both in a single request 700 and in total) to a client. However, note that this does not prevent 701 a bad client actor from pretending to be many different clients and 702 consuming all available addresses. 704 14. Privacy Considerations 706 See Section 23 of [RFC8415] for the DHCP privacy considerations. 708 For a client requesting a link-layer address directly from a server, 709 as the address assigned to a client will likely be used by the client 710 to communicate on the link, the address will be exposed to those able 711 to listen in on this communication. For those peers on the link that 712 are able to listen in on the DHCP exchange, they would also be able 713 to correlate the client's identity (based on the DUID used) with the 714 assigned address. Additional mechanisms, such as the ones described 715 in [RFC7844] can also be used to improve anonymity by minimizing what 716 is exposed. 718 As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors 719 may need to consider the implications of assigning addresses 720 sequentially. Though in general, this is only of link-local concern 721 unlike for IPv6 address assignment and prefix delegation as these may 722 be used for communication over the Internet. 724 15. Acknowledgements 726 Thanks to the DHC Working Group participants that reviewed this 727 document, provided comments, and support. With special thanks to Ian 728 Farrer for his thorough reviews and shepherding of this document 729 through the IETF process. Thanks also to area reviewers Samita 730 Chakrabarti, Roni Even and Tianran Zhou, and IESG members Martin 731 Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, 732 Alvaro Retana, Eric Vyncke, and Robert Wilton for their suggestions. 733 And to Roger Marks, Bob Grow, and Antonio de la Oliva for comments 734 related to IEEE work and references. 736 16. References 738 16.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, 742 DOI 10.17487/RFC2119, March 1997, 743 . 745 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 746 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 747 DOI 10.17487/RFC4861, September 2007, 748 . 750 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 751 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 752 May 2017, . 754 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 755 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 756 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 757 RFC 8415, DOI 10.17487/RFC8415, November 2018, 758 . 760 16.2. Informative References 762 [I-D.ietf-dhc-slap-quadrant] 763 Bernardos, C. and A. Mourad, "SLAP quadrant selection 764 option for DHCPv6", draft-ietf-dhc-slap-quadrant-10 (work 765 in progress), August 2020. 767 [IEEE-P802.1CQ-Project] 768 "P802.1CQ - Standard for Local and Metropolitan Area 769 Networks: Multicast and Local Address Assignment", 770 . 772 [IEEEStd802] 773 "IEEE Standard for Local and Metropolitan Area Networks: 774 Overview and Architecture, IEEE Std 802". 776 [IEEEStd802.11] 777 "IEEE Standard for Information technology - 778 Telecommunications and information exchange between 779 systems Local and metropolitan area networks - Specific 780 requirements - Part 11: Wireless LAN Medium Access Control 781 (MAC) and Physical Layer (PHY) Specifications, IEEE Std 782 802.11". 784 [IEEEStd802c] 785 "IEEE Standard for Local and Metropolitan Area Networks: 786 Overview and Architecture, Amendment 2: Local Medium 787 Access Control (MAC) Address Usage, IEEE Std 802c-2017". 789 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 790 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 791 . 793 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 794 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 795 . 797 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 798 for the Address Resolution Protocol (ARP)", RFC 5494, 799 DOI 10.17487/RFC5494, April 2009, 800 . 802 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 803 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 804 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 805 . 807 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 808 Constrained-Node Networks", RFC 7228, 809 DOI 10.17487/RFC7228, May 2014, 810 . 812 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 813 Profiles for DHCP Clients", RFC 7844, 814 DOI 10.17487/RFC7844, May 2016, 815 . 817 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 818 (IPv6) Specification", STD 86, RFC 8200, 819 DOI 10.17487/RFC8200, July 2017, 820 . 822 Appendix A. IEEE 802c Summary 824 This appendix provides a brief summary of IEEE 802c [IEEEStd802c]. 826 The original IEEE 802 specifications assigned half of the 48-bit MAC 827 address space to local use -- these addresses have the U/L bit set to 828 1 and are locally administered with no imposed structure. 830 In 2017, the IEEE issued the IEEE Std 802c specification which 831 defines a new optional "Structured Local Address Plan (SLAP) that 832 specifies different assignment approaches in four specified regions 833 of the local MAC address space." Under this plan, there are 4 SLAP 834 quadrants that use different assignment policies. 836 The first octet of the MAC address Z and Y bits define the quadrant 837 for locally assigned addresses (X-bit is 1). In IEEE representation, 838 these bits are as follows: 840 LSB MSB 841 M X Y Z - - - - 842 | | | | 843 | | | +------------ SLAP Z-bit 844 | | +--------------- SLAP Y-bit 845 | +------------------ X-bit (U/L) = 1 for locally assigned 846 +--------------------- M-bit (I/G) (unicast/group) 848 Figure 3: SLAP Bits 850 The SLAP quadrants are: 852 +----------+-------+-------+-----------------------+----------------+ 853 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 854 | | | | | Identifier | 855 +----------+-------+-------+-----------------------+----------------+ 856 | 01 | 0 | 1 | Extended Local | ELI | 857 | 11 | 1 | 1 | Standard Assigned | SAI | 858 | 00 | 0 | 0 | Administratively | AAI | 859 | | | | Assigned | | 860 | 10 | 1 | 0 | Reserved | Reserved | 861 +----------+-------+-------+-----------------------+----------------+ 863 SLAP Quadrants 865 Extended Local Identifier (ELI) derived MAC addresses are based on an 866 assigned Company ID (CID), which is 24-bits (including the M, X, Y, 867 and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the 868 locally assigned address for each CID for unicast (M-bit = 0) and 869 also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. 871 Standard Assigned Identifier (SAI) derived MAC addresses are assigned 872 by a protocol specified in an IEEE 802 standard. For 48-bit MAC 873 addresses, 44 bits are available. Multiple protocols for assigning 874 SAIs may be specified in IEEE standards. Coexistence of multiple 875 protocols may be supported by limiting the subspace available for 876 assignment by each protocol. 878 Administratively Assigned Identifier (AAI) derived MAC addresses are 879 assigned locally. Administrators manage the space as needed. Note 880 that multicast IPv6 packets ([RFC2464]) use a destination address 881 starting in 33-33, so AAI addresses in that range should not be 882 assigned. For 48-bit MAC addresses, 44 bits are available. 884 The last quadrant is reserved for future use. While this quadrant 885 may also be used similar to AAI space, administrators should be aware 886 that future specifications may define alternate uses that could be 887 incompatible. 889 Authors' Addresses 891 Bernie Volz 892 Cisco Systems, Inc. 893 1414 Massachusetts Ave 894 Boxborough, MA 01719 895 USA 897 Email: volz@cisco.com 898 Tomek Mrugalski 899 Internet Systems Consortium, Inc. 900 950 Charter Street 901 Redwood City, CA 94063 902 USA 904 Email: tomasz.mrugalski@gmail.com 906 Carlos J. Bernardos 907 Universidad Carlos III de Madrid 908 Av. Universidad, 30 909 Leganes, Madrid 28911 910 Spain 912 Phone: +34 91624 6236 913 Email: cjbc@it.uc3m.es 914 URI: http://www.it.uc3m.es/cjbc/