idnits 2.17.1 draft-ietf-dhc-slap-quadrant-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 (May 27, 2020) is 1423 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 (-09) exists of draft-ietf-dhc-mac-assign-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Standards Track A. Mourad 5 Expires: November 28, 2020 InterDigital 6 May 27, 2020 8 SLAP quadrant selection options for DHCPv6 9 draft-ietf-dhc-slap-quadrant-09 11 Abstract 13 The IEEE originally structured the 48-bit MAC address space in such a 14 way that half of it was reserved for local use. Recently, the IEEE 15 has been working on a new specification (IEEE 802c) which defines a 16 new optional "Structured Local Address Plan" (SLAP) that specifies 17 different assignment approaches in four specified regions of the 18 local MAC address space. 20 The IEEE is working on mechanisms to allocate addresses in the one of 21 these quadrants (IEEE 802.1CQ). There is work also in the IETF on 22 specifying a new mechanism that extends DHCPv6 operation to handle 23 the local MAC address assignments. We complement this work by 24 defining a mechanism to allow choosing the SLAP quadrant to use in 25 the allocation of the MAC address to the requesting device/client. 27 This document proposes extensions to DHCPv6 protocols to enable a 28 DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant 29 to the server, so that the server allocates the MAC addresses to the 30 given client out of the quadrant requested by relay or client. A new 31 DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this 32 purpose. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 28, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 69 1.1.1. WiFi devices . . . . . . . . . . . . . . . . . . . . 4 70 1.1.2. Hypervisor: migratable vs non-migratable functions . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Quadrant Selection Mechanisms examples . . . . . . . . . . . 7 73 4. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Address Assignment from the Preferred SLAP Quadrant 75 Indicated by the Client . . . . . . . . . . . . . . . . . 9 76 4.2. Address Assignment from the SLAP Quadrant Indicated by 77 the Relay . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5. DHCPv6 Options Definitions . . . . . . . . . . . . . . . . . 14 79 5.1. Quad (IA_LL) option . . . . . . . . . . . . . . . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 The IEEE originally structured the 48-bit MAC address space in such a 91 way that half of it was reserved for local use (where the Universal/ 92 Local -- U/L -- bit is set to 1). Recently, the IEEE has been 93 working on a new specification (IEEE 802c [IEEEStd802c-2017]) which 94 defines a new "optional Structured Local Address Plan" (SLAP) that 95 specifies different assignment approaches in four specified regions 96 of the local MAC address space. These four regions, called SLAP 97 quadrants, are briefly described below (see Figure 1 and Figure 2 for 98 details): 100 o Quadrant "Extended Local Identifier" (ELI) MAC addresses are 101 assigned based on a Company ID (CID), which takes 24-bits, leaving 102 the remaining 24-bits for the locally assigned address for each 103 CID for unicast (M-bit = 0) and also for multicast (M-bit = 1). 104 The CID is assigned by the IEEE Registration Authority (RA). 106 o Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are 107 assigned based on a protocol specified in an IEEE 802 standard. 108 For 48-bit MAC addresses, 44 bits are available. Multiple 109 protocols for assigning SAIs may be specified in IEEE standards. 110 Coexistence of multiple protocols may be supported by limiting the 111 subspace available for assignment by each protocol. 113 o Quadrant "Administratively Assigned Identifier" (AAI) MAC 114 addresses are assigned locally by an administrator. Multicast 115 IPv6 packets use a destination address starting in 33-33 and this 116 falls within this space and therefore should not be used to avoid 117 conflict with the MAC addresses used for use with IPv6 multicast 118 addresses. For 48-bit MAC addresses, 44 bits are available. 120 o Quadrant "Reserved for future use" where MAC addresses may be 121 assigned using new methods yet to be defined, or by an 122 administrator like in the AAI quadrant. For 48-bit MAC addresses, 123 44 bits would be available. 125 LSB MSB 126 M X Y Z - - - - 127 | | | | 128 | | | +------------ SLAP Z-bit 129 | | +--------------- SLAP Y-bit 130 | +------------------ X-bit (U/L) = 1 for locally assigned 131 +--------------------- M-bit (I/G) (unicast/group) 133 Figure 1: IEEE 48-bit MAC address structure 135 +----------+-------+-------+-----------------------+----------------+ 136 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 137 | | | | | Identifier | 138 +----------+-------+-------+-----------------------+----------------+ 139 | 01 | 0 | 1 | Extended Local | ELI | 140 | 11 | 1 | 1 | Standard Assigned | SAI | 141 | 00 | 0 | 0 | Administratively | AAI | 142 | | | | Assigned | | 143 | 10 | 1 | 0 | Reserved | Reserved | 144 +----------+-------+-------+-----------------------+----------------+ 146 Figure 2: SLAP quadrants 148 1.1. Problem statement 150 The IEEE is working on mechanisms to allocate addresses in the SAI 151 quadrant (IEEE 802.1CQ project). There is also ongoing work in the 152 IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that 153 extends DHCPv6 operation to handle the local MAC address assignments. 154 We complement this work by defining a mechanism to allow choosing the 155 SLAP quadrant to use in the allocation of the MAC address to the 156 requesting device/client. This document proposes extensions to 157 DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to 158 indicate a preferred SLAP quadrant to the server, so that the server 159 allocates the MAC address to the given client out of the quadrant 160 requested by relay or client. 162 In the following, we describe two application scenarios where a need 163 arises to assign local MAC addresses according to preferred SLAP 164 quadrants. 166 1.1.1. WiFi devices 168 Today, most WiFi devices come with interfaces that have a "burned in" 169 MAC address, allocated from the universal address space using a 170 24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802 171 interface vendors). However, recently, the need to assign local 172 (instead of universal) MAC addresses has emerged in particular in the 173 following two scenarios: 175 o IoT (Internet of Things): where there are a lot of cheap, 176 sometimes short lived and disposable devices. Examples of this 177 include: sensors and actuators for health or home automation 178 applications. In this scenario, it is common that upon a first 179 boot, the device uses a temporary MAC address, to send initial 180 DHCP packets to available DHCP servers. IoT devices typically 181 request a single MAC address for each available network interface. 182 Once the server assigns a MAC address, the device abandons its 183 temporary MAC address. This type of device is typically not 184 moving. In general, any type of SLAP quadrant would be good for 185 assigning addresses from, but ELI/SAI quadrants might be more 186 suitable in some scenarios, such as if the addresses need to 187 belong to the CID assigned to the IoT communication device vendor. 189 o Privacy: Today, MAC addresses allow the exposure of users' 190 locations making it relatively easy to track users' movement. One 191 of the mechanisms considered to mitigate this problem is the use 192 of local random MAC addresses, changing them every time the user 193 connects to a different network. In this scenario, devices are 194 typically mobile. Here, AAI is probably the best SLAP quadrant to 195 assign addresses from, as it is the best fit for randomization of 196 addresses, and it is not required for the addresses to survive 197 when changing networks. 199 1.1.2. Hypervisor: migratable vs non-migratable functions 201 In large scale virtualization environments, thousands of virtual 202 machines (VMs) are active. These VMs are typically managed by a 203 hypervisor, in charge of spawning and stopping VMs as needed. The 204 hypervisor is also typically in charge of assigning new MAC addresses 205 to the VMs. If a DHCP solution is in place for that, the hypervisor 206 acts as a DHCP client and requests available DHCP servers to assign 207 one or more MAC addresses (an address block). The hypervisor does 208 not use those addresses for itself, but rather uses them to create 209 new VMs with appropriate MAC addresses. If we assume very large data 210 center environments, such as the ones that are typically used 211 nowadays, it is expected that the data center is divided in different 212 network regions, each one managing its own local address space. In 213 this scenario, there are two possible situations that need to be 214 tackled: 216 o Migratable functions. If a VM (providing a given function) needs 217 to be migrated to another region of the data center (e.g., for 218 maintenance, resilience, end-user mobility, etc.), the VM's 219 networking context needs to migrate with the VM. This includes 220 the VM's MAC address(es). Therefore, for this case, it is better 221 to allocate addresses from the ELI/SAI SLAP quadrant, which can be 222 centrally allocated by the DHCP server. 224 o Non-migratable functions. If a VM will not be migrated to 225 another region of the data center, there are no requirements 226 associated with its MAC address. In this case, it is more 227 efficient to allocate it from the AAI SLAP quadrant, that does not 228 need to be unique across multiple data centers (i.e., each region 229 can manage its own MAC address assignment, without checking for 230 duplicates globally). 232 2. Terminology 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 236 "OPTIONAL" in this document are to be interpreted as described in BCP 237 14 [RFC2119] [RFC8174] when, and only when, they appear in all 238 capitals, as shown here. 240 Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol 241 [RFC8415] also applies here. Additionally, the following definitions 242 are updated for this document. 244 client A device that is interested in obtaining link-layer 245 addresses. It implements the basic DHCPv6 mechanisms 246 needed by a DHCPv6 client as described in [RFC8415] and 247 supports the new options (IA_LL and LLADDR) specified 248 in [I-D.ietf-dhc-mac-assign]. The client may or may 249 not support address assignment and prefix delegation as 250 specified in [RFC8415]. 252 server Software that manages link-layer address allocation and 253 is able to respond to client queries. It implements 254 basic DHCPv6 server functionality as described in 255 [RFC8415] and supports the new options (IA_LL and 256 LLADDR) specified in [I-D.ietf-dhc-mac-assign]. The 257 server may or may not support address assignment and 258 prefix delegation as specified in [RFC8415]. 260 relay A node that acts as an intermediary to deliver DHCP 261 messages between clients and servers. A relay, based 262 on local knowledge and policies, may include the 263 preferred SLAP quadrant in a QUAD option sent to the 264 server. The relay implements basic DHCPv6 relay agent 265 functionality as described in [RFC8415]. 267 address Unless specified otherwise, an address means a link- 268 layer (or MAC) address, as defined in IEEE802. The 269 address is typically 6 bytes long, but some network 270 architectures may use different lengths. 272 address block A number of consecutive link-layer addresses. An 273 address block is expressed as a first address plus a 274 number that designates the number of additional (extra) 275 addresses. A single address can be represented by the 276 address itself and zero extra addresses. 278 3. Quadrant Selection Mechanisms examples 280 The following section describes some examples of how the quadrant 281 preference mechanisms could be used. 283 Let's take first an IoT scenario as an example. An IoT device might 284 decide on its own the SLAP quadrant it wants to use to obtain a local 285 MAC address, using the following information to take the decision: 287 o Type of IoT deployment: e.g., industrial, domestic, rural, etc. 288 For small deployments, such as domestic ones, the IoT itself can 289 decide to use the AAI quadrant (this might not even involve the 290 use of DHCP, by the device just configuring a random address 291 computed by the device itself). For large deployments, such as 292 industrial or rural ones, where thousands of devices might co- 293 exist, the IoT can decide to use the ELI or SAI quadrants. 295 o Mobility: if the IoT device can move, then it might prefer to 296 select the SAI or AAI quadrants to minimize address collisions 297 when moving to another network. If the device is known to remain 298 fixed, then the ELI is probably the most suitable one to use. 300 o Managed/unmanaged: depending on whether the IoT device is managed 301 during its lifetime or cannot be re-configured, the selected 302 quadrant might be different. For example, if it can be managed, 303 this means that network topology changes might occur during its 304 lifetime (e.g., due to changes on the deployment, such as 305 extensions involving additional devices), and this might have an 306 impact on the preferred quadrant (e.g., to avoid potential 307 collisions in the future). 309 o Operation/battery lifetime: depending on the expected lifetime of 310 the device a different quadrant might be preferred (as before, to 311 minimize potential address collisions in the future). 313 The previous parameters are considerations that the device vendor/ 314 administrator may wish to use when defining the IoT device's 315 MAC address request policy (i.e., how to select a given SLAP 316 quadrant). IoT devices are typically very resource constrained, so 317 there may only be simple decision making process based on pre- 318 configured preferences. 320 If we now take the WiFi device scenario, considering for example that 321 a laptop or smartphone connects to a network using its built in MAC 322 address. Due to privacy/security concerns, the device might want to 323 configure a local MAC address. The device might use different 324 parameters and context information to decide, not only which SLAP 325 quadrant to use for the local MAC address configuration, but also 326 when to perform a change of address (e.g., it might be needed to 327 change address several times). This information includes, but it is 328 not limited to: 330 o Type of network the device is connected: public, work, home. 332 o Trusted network? Y/N. 334 o First time visited network? Y/N. 336 o Network geographical location. 338 o Mobility? Y/N. 340 o Operating System (OS) network profile, including security/trust 341 related parameters. Most modern OSs keep metadata associated to 342 the networks they can attach to, as for example the level of trust 343 the user or administrator assigns to the network. This 344 information is used to configure how the device behaves in terms 345 of advertising itself on the network, firewall settings, etc. But 346 this information can also be used to decide whether to configure a 347 local MAC address or not, from which SLAP quadrant and how often. 349 o Triggers coming from applications regarding location privacy. An 350 app might request to the OS to maximize location privacy (due to 351 the nature of the application) and this might require that the OS 352 forces the use of a local MAC address, or that the local MAC 353 address is changed. 355 This information can be used by the device to select the SLAP 356 quadrant. For example, if the device is moving around (e.g., while 357 connected to a public network in an airport), it is likely that it 358 might change access point several times, and therefore it is best to 359 minimize the chances of address collision, using the SAI or AAI 360 quadrants. If the device is not moving and attached to a trusted 361 network (e.g. at work), then it is probably best to select the ELI 362 quadrant. These are just some examples of how to use this 363 information to select the quadrant. 365 Additionally, the information can also be used to trigger subsequent 366 changes of MAC address, to enhance location privacy. Besides, 367 changing the SLAP quadrant used might also be used as an additional 368 enhancement to make it harder to track the user location. 370 Last, if we consider the data center scenario, a hypervisor might 371 request local MAC addresses to be assigned to virtual machines. As 372 in the previous scenarios, the hypervisor might select the preferred 373 SLAP quadrant using information provided by the cloud management 374 system (CMS) or virtualization infrastructure manager (VIM) running 375 on top of the hypervisor. This information might include, but is not 376 limited to: 378 o Migratable VM. If the function implemented by the VM is subject 379 to be moved to another physical server or not. This has an impact 380 on the preference for the SLAP quadrant, as some quadrants are 381 better suited (e.g., ELI/SAI) for supporting migration in a large 382 data center. 384 o VM connectivity characteristics , e.g.,: standalone, part of a 385 pool, part of a service graph/chain. If the connectivity 386 characteristics of the VM are known, this can be used by the 387 hypervisor to select the best SLAP quadrant. 389 4. DHCPv6 Extensions 391 4.1. Address Assignment from the Preferred SLAP Quadrant Indicated by 392 the Client 394 Next, we describe the protocol operations for a client to select a 395 preferred SLAP quadrant using the DHCPv6 signaling procedures 396 described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown 397 in Figure 3. 399 +--------+ +--------+ 400 | DHCPv6 | | DHCPv6 | 401 | client | | server | 402 +--------+ +--------+ 403 | | 404 +-------1. Solicit(IA_LL(QUAD))------->| 405 | | 406 |<--2. Advertise(IA_LL(LLADDR,QUAD))--+| 407 | | 408 +---3. Request(IA_LL(LLADDR,QUAD))---->| 409 | | 410 |<------4. Reply(IA_LL(LLADDR))--------+ 411 | | 412 . . 413 . (timer expiring) . 414 . . 415 | | 416 +---5. Renew(IA_LL(LLADDR,QUAD))------>| 417 | | 418 |<-----6. Reply(IA_LL(LLADDR))---------+ 419 | | 421 Figure 3: DHCPv6 signaling flow (client-server) 423 1. Link-layer addresses (i.e., MAC addresses) are assigned in 424 blocks. The smallest block is a single address. To request an 425 assignment, the client sends a Solicit message with an IA_LL 426 option in the message. The IA_LL option MUST contain a LLADDR 427 option. In order to indicate the preferred SLAP quadrant(s), the 428 IA_LL option includes the new OPTION_SLAP_QUAD option in the 429 IA_LL-option field (with the LLAADR option). 431 2. The server, upon receiving an IA_LL option, inspects its 432 contents. For each of the entries in OPTION_SLAP_QUAD, in order 433 of the preference field (highest to lowest), the server checks if 434 it has a configured MAC address pool matching the requested 435 quadrant identifier, and an available range of addresses of the 436 requested size. If suitable addresses are found, the server 437 sends back an Advertise message with an IA_LL option containing 438 an LLADDR option that specifies the addresses being offered. If 439 the server supports the new QUAD IA_LL-option, and manages a 440 block of addresses belonging to the requested quadrant(s), the 441 addresses being offered MUST belong to the requested quadrant(s). 442 If the server does not have a configured address pool matching 443 the client's request, it MUST return the IA_LL option containing 444 a Status Code option with status set to NoQuadAvail (IANA-2). If 445 the client specified more than one SLAP quadrant, the server MUST 446 only return a NoQuadAvail status code if no address pool(s) 447 configured at the server match any of the specified SLAP 448 quadrants. If the server has a configured address pool of the 449 correct quadrant, but no available addresses, it MUST return the 450 IA_LL option containing a Status Code option with status set to 451 NoAddrsAvail. 453 3. The client waits for available servers to send Advertise 454 responses and picks one server as defined in Section 18.2.9 of 455 [RFC8415]. The client SHOULD NOT pick a server that does not 456 advertise an address in the requested quadrant. The client then 457 sends a Request message that includes the IA_LL container option 458 with the LLADDR option copied from the Advertise message sent by 459 the chosen server. It includes the preferred SLAP quadrant(s) in 460 the new QUAD IA_LL-option. 462 4. Upon reception of a Request message with IA_LL container option, 463 the server assigns requested addresses. The server MAY alter the 464 allocation at this time. It then generates and sends a Reply 465 message back to the client. Upon receiving a Reply message, the 466 client parses the IA_LL container option and may start using all 467 provided addresses. Note that a client that has included a Rapid 468 Commit option in the Solicit, may receive a Reply in response to 469 the Solicit and skip the Advertise and Request steps above 470 (following standard DHCPv6 procedures). 472 5. The client is expected to periodically renew the link-layer 473 addresses as governed by T1 and T2 timers. This mechanism can be 474 administratively disabled by the server sending "infinity" as the 475 T1 and T2 values (see Section 7.7 of [RFC8415]). When the 476 assigned addresses are about to expire, the client sends a Renew 477 message. It includes the preferred SLAP quadrant(s) in the new 478 QUAD IA_LL-option, so in case the server is unable to extend the 479 lifetime on the existing address(es), the preferred quadrants are 480 known for the allocation of any "new" (i.e., different) 481 addresses. 483 6. The server responds with a Reply message, including an LLADDR 484 option with extended lifetime. 486 The client SHOULD check if the received MAC address comes from one of 487 the requested quadrants. Otherwise, the client SHOULD NOT configure 488 the obtained address. It MAY repeat the process selecting a 489 different DHCP server. 491 4.2. Address Assignment from the SLAP Quadrant Indicated by the Relay 493 Next, we describe the protocol operations for a relay to select a 494 preferred SLAP quadrant using the DHCPv6 signaling procedures 495 described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6 496 server is operating over a large infrastructure split in different 497 network regions, where each region might have different requirements. 498 The signaling flow is shown in Figure 4. 500 +--------+ +--------+ +--------+ 501 | DHCPv6 | | DHCPv6 | | DHCPv6 | 502 | client | | relay | | server | 503 +--------+ +--------+ +--------+ 504 | | | 505 +-----1. Solicit(IA_LL)----->| | 506 | +----2. Relay-forward | 507 | | (Solicit(IA_LL),QUAD)------>| 508 | | | 509 | |<---3. Relay-reply | 510 | | (Advertise(IA_LL(LLADDR)))--+ 511 |<4. Advertise(IA_LL(LLADDR))+ | 512 |-5. Request(IA_LL(LLADDR))->| | 513 | +-6. Relay-forward | 514 | | (Request(IA_LL(LLADDR)),QUAD)->| 515 | | | 516 | |<--7. Relay-reply | 517 | | (Reply(IA_LL(LLADDR)))-------+ 518 |<--8. Reply(IA_LL(LLADDR))--+ | 519 | | | 520 . . . 521 . (timer expiring) . 522 . . . 523 | | | 524 +--9. Renew(IA_LL(LLADDR))-->| | 525 | |--10. Relay-forward | 526 | | (Renew(IA_LL(LLADDR)),QUAD)-->| 527 | | | 528 | |<---11. Relay-reply | 529 | | (Reply(IA_LL(LLADDR)))-----+ 530 |<--12. Reply(IA_LL(LLADDR)--+ | 531 | | | 533 Figure 4: DHCPv6 signaling flow (client-relay-server) 535 1. Link-layer addresses (i.e., MAC addresses) are assigned in 536 blocks. The smallest block is a single address. To request an 537 assignment, the client sends a Solicit message with an IA_LL 538 option in the message. The IA_LL option MUST contain a LLADDR 539 option. 541 2. The DHCP relay receives the Solicit message and encapsulates it 542 in a Relay-forward message. The relay, based on local knowledge 543 and policies, includes in the Relay-forward message the QUAD 544 option with the preferred quadrant. The relay might know which 545 quadrant to request based on local configuration (e.g., the 546 served network contains IoT devices only, thus requiring ELI/ 547 SAI) or other means. Note that if a client sends multiple 548 instances of the IA_LL option in the same message, the DHCP 549 relay MUST only add a single instance of the QUAD option. 551 3. Upon receiving a relayed message containing an IA_LL option, the 552 server inspects the contents for instances of OPTION_SLAP_QUAD 553 in both the Relay Forward message and the client's message 554 payload. Depending on the server's policy, the instance(s) of 555 the option to process is selected. For each of the entries in 556 OPTION_SLAP_QUAD, in order of the preference field (highest to 557 lowest), the server checks if it has a configured MAC address 558 pool matching the requested quadrant identifier, and an 559 available range of addresses of the requested size. If suitable 560 addresses are found, the server sends back an Advertise message 561 with an IA_LL option containing an LLADDR option that specifies 562 the addresses being offered. This message is sent to the Relay 563 in a Relay-reply message. If the server supports the semantics 564 of the preferred quadrant included in the QUAD option, and 565 manages a block of addresses belonging to the requested 566 quadrant(s), then the addresses being offered MUST belong to the 567 requested quadrant(s). The server SHOULD apply the contents of 568 the relay's supplied QUAD option for all of the client's IA_LLs, 569 unless configured to do otherwise. 571 4. The relay sends the received Advertise message to the client. 573 5. The client waits for available servers to send Advertise 574 responses and picks one server as defined in Section 18.2.9 of 575 [RFC8415]. The client then sends a Request message that 576 includes the IA_LL container option with the LLADDR option 577 copied from the Advertise message sent by the chosen server. 579 6. The relay forwards the received Request in a Relay-forward 580 message. It adds in the Relay-forward a QUAD IA_LL-option with 581 the preferred quadrant. 583 7. Upon reception of the forwarded Request message with IA_LL 584 container option, the server assigns requested addresses. The 585 server MAY alter the allocation at this time. It then generates 586 and sends a Reply message, in a Relay-reply back to the relay. 588 8. Upon receiving a Reply message, the client parses the IA_LL 589 container option and may start using all provided addresses. 591 9. The client is expected to periodically renew the link-layer 592 addresses as governed by T1 and T2 timers. This mechanism can 593 be administratively disabled by the server sending "infinity" as 594 the T1 and T2 values (see Section 7.7 of [RFC8415]). When the 595 assigned addresses are about to expire, the client sends a Renew 596 message. 598 10. This message is forwarded by the Relay in a Relay-forward 599 message, including a QUAD IA_LL-option with the preferred 600 quadrant. 602 11. The server responds with a Reply message, including an LLADDR 603 option with extended lifetime. This message is sent in a Relay- 604 reply message. 606 12. The relay sends the Reply message back to the client. 608 The server SHOULD implement a configuration parameter to deal 609 with the case where the client's DHCP message contains an instance of 610 OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- 611 forward message. This parameter configures the server to process 612 either the client's, or the relay's instance of option QUAD. It is 613 RECOMMENDED that the default for such a parameter is to process the 614 client's instance of the option. 616 The client MAY check if the received MAC address belongs to a 617 quadrant it is willing to use/configure, and MAY decide based on that 618 whether to use configure the received address. 620 5. DHCPv6 Options Definitions 622 5.1. Quad (IA_LL) option 624 The QUAD option is used to specify the preferences for the selected 625 quadrants within an IA_LL. The option MUST either be encapsulated in 626 the IA_LL-options field of an IA_LL option or in a Relay-forward 627 message. 629 The format of the QUAD option is: 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | OPTION_SLAP_QUAD | option-len | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | quadrant-1 | pref-1 | quadrant-2 | pref-2 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 . . 639 . . 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 5: Quad Option Format 644 option-code OPTION_SLAP_QUAD (IANA-1). 646 option-len 2 * number of included (quadrant, preference). A 647 2-byte field containing the total length of all 648 (quadrant, preference) pairs included in the option. 650 quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: 651 Reserved, 3: SAI). Each quadrant MUST only appear 652 once at most in the option. A 1-byte field. 654 pref-n Preference associated to quadrant-n. A higher value 655 means a more preferred quadrant. A 1-byte field. 657 A quadrant identifier value MUST only appear at most once in the 658 option. If an option includes more than one occurrence of the same 659 quadrant identifier, only the first occurence is processed and the 660 rest MUST be ignored by the server. 662 If the same preference value is used for more than one quadrant, the 663 server MAY select which quadrant should be preferred (if the server 664 can assign addresses from all or some of the quadrants with the same 665 assigned preference). Note that a quadrant - preference tuple is 666 used in this option (instead of using a list of quadrants ordered by 667 preference) to support the case whereby a client really has no 668 preference between two or three quadrants, leaving the decision to 669 the server. 671 If the client or relay agent provide the OPTION_SLAP_QUAD, the server 672 MUST use the quadrant-n/pref-n values to order the selection of the 673 quadrants. If the server can provide an assignment from one of the 674 specified quadrants, it SHOULD proceed with the assignment. If the 675 server cannot provide an assignment from one of the specified 676 quadrant-n fields, it MUST NOT assign any addresses and return a 677 status of NoQuadAvail (IANA-2) in the IA_LL Option. 679 There is no requirement that the client or relay agent order the 680 quadrant/pref values in any specific order; hence servers MUST NOT 681 assume that quadrant-1/pref-1 have the highest preference (except if 682 there is only 1 set of values). 684 6. IANA Considerations 686 IANA is requested to assign the QUAD (IANA-1) option code from the 687 DHCPv6 "Option Codes" registry maintained at 688 http://www.iana.org/assignments/dhcpv6-parameters and use the 689 following data when adding the option to the registry: 691 Value: IANA-1 692 Description: OPTION_SLAP_QUAD 693 Client ORO: No 694 Singleton Option: No 695 Reference: this document 697 IANA is requested to assign the NoQuadAvail (IANA-2) code from the 698 DHCPv6 "Status Codes" registry maintained 699 athttp://www.iana.org/assignments/dhcpv6-parameters and use the 700 following data when adding the option to the registry: 702 Value: IANA-2 703 Description: NoQuadAvail 704 Reference: this document 706 7. Security Considerations 708 See [RFC8415] for the DHCPv6 security considerations. See [RFC8200] 709 for the IPv6 security considerations. 711 See also [I-D.ietf-dhc-mac-assign] for security considerations 712 regarding link-layer address assignments using DHCP. 714 8. Acknowledgments 716 The authors would like to thank Bernie Volz for his very valuable 717 comments on this document. We also want to thank Ian Farrer, Tomek 718 Mrugalski, Eric Vyncke, Tatuya Jinmei and Carl Wallace for their very 719 detailed and helpful reviews. 721 The work in this draft will be further developed and explored under 722 the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE 723 projects (Grant 859881). 725 9. References 727 9.1. Normative References 729 [I-D.ietf-dhc-mac-assign] 730 Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 731 Addresses Assignment Mechanism for DHCPv6", draft-ietf- 732 dhc-mac-assign-06 (work in progress), May 2020. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, 736 DOI 10.17487/RFC2119, March 1997, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 744 (IPv6) Specification", STD 86, RFC 8200, 745 DOI 10.17487/RFC8200, July 2017, 746 . 748 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 749 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 750 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 751 RFC 8415, DOI 10.17487/RFC8415, November 2018, 752 . 754 9.2. Informative References 756 [IEEEStd802c-2017] 757 IEEE Computer Society, "IEEE Standard for Local and 758 Metropolitan Area Networks: Overview and Architecture, 759 Amendment 2: Local Medium Access Control (MAC) Address 760 Usage, IEEE Std 802c-2017". 762 Authors' Addresses 764 Carlos J. Bernardos 765 Universidad Carlos III de Madrid 766 Av. Universidad, 30 767 Leganes, Madrid 28911 768 Spain 770 Phone: +34 91624 6236 771 Email: cjbc@it.uc3m.es 772 URI: http://www.it.uc3m.es/cjbc/ 774 Alain Mourad 775 InterDigital Europe 777 Email: Alain.Mourad@InterDigital.com 778 URI: http://www.InterDigital.com/