idnits 2.17.1 draft-ietf-dhc-slap-quadrant-10.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 (August 3, 2020) is 1359 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-08 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: February 4, 2021 InterDigital 6 August 3, 2020 8 SLAP quadrant selection option for DHCPv6 9 draft-ietf-dhc-slap-quadrant-10 11 Abstract 13 IEEE originally structured the 48-bit MAC address space in such a way 14 that half of it was reserved for local use. In 2017, IEEE published 15 a new standard (IEEE Std 802c) with a new optional "Structured Local 16 Address Plan" (SLAP). It specifies different assignment approaches 17 in four specified regions of the local MAC address space. 19 IEEE is developing protocols to assign addresses (IEEE P802.1CQ). 20 There is work also in the IETF on specifying a new mechanism that 21 extends DHCPv6 operation to handle the local MAC address assignments. 23 This document proposes extensions to DHCPv6 protocols to enable a 24 DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant 25 to the server, so that the server may allocate MAC addresses in the 26 quadrant requested by the relay or client. A new DHCPv6 option 27 (QUAD) is defined for this purpose. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 4, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 65 1.1.1. WiFi (IEEE 802.11) devices . . . . . . . . . . . . . 4 66 1.1.2. Hypervisor: migratable vs non-migratable functions . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Address Assignment from the Preferred SLAP Quadrant 70 Indicated by the Client . . . . . . . . . . . . . . . . . 7 71 3.2. Address Assignment from the SLAP Quadrant Indicated by 72 the Relay . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4. DHCPv6 Option Definition . . . . . . . . . . . . . . . . . . 11 74 4.1. Quad option . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Appendix A. Quadrant Selection Mechanisms examples . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 IEEE structures the 48-bit MAC address space in such a way that half 87 of it was reserved for local use (where the Universal/Local -- U/L -- 88 bit is set to 1). In 2017, IEEE published a new standard (IEEE Std 89 802c [IEEEStd802c]) which defines a new optional "Structured Local 90 Address Plan" (SLAP) that specifies different assignment approaches 91 in four specified regions of the local MAC address space. These four 92 regions, called SLAP quadrants, are briefly described below (see 93 Figure 1 and Figure 2 for details): 95 o In SLAP Quadrant 01, "Extended Local Identifier" (ELI) MAC 96 addresses are assigned based on a 24-bit Company ID (CID), 97 assigned by the IEEE Registration Authority (RA). The remaining 98 bits are specified as an extension by the CID assignee or by a 99 protocol designated by the CID assignee. 101 o In SLAP Quadrant 11, "Standard Assigned Identifier" (SAI) MAC 102 addresses are assigned based on a protocol specified in an IEEE 103 802 standard. For 48-bit MAC addresses, 44 bits are available. 104 Multiple protocols for assigning SAIs may be specified in IEEE 105 standards. Coexistence of multiple protocols may be supported by 106 limiting the subspace available for assignment by each protocol. 108 o In SLAP Quadrant 00, "Administratively Assigned Identifier" (AAI) 109 MAC addresses are assigned locally by an administrator. Multicast 110 IPv6 packets use a destination address starting in 33-33, so AAI 111 addresses in that range should not be assigned. For 48-bit MAC 112 addresses, 44 bits are available. 114 o SLAP Quadrant 10 is "Reserved for future use" where MAC addresses 115 may be assigned using new methods yet to be defined, or until then 116 by an administrator as in the AAI quadrant. For 48-bit MAC 117 addresses, 44 bits would be available. 119 LSB MSB 120 M X Y Z - - - - 121 | | | | 122 | | | +------------ SLAP Z-bit 123 | | +--------------- SLAP Y-bit 124 | +------------------ X-bit (U/L) = 1 for locally assigned 125 +--------------------- M-bit (I/G) (unicast/group) 127 Figure 1: IEEE 48-bit MAC address structure (in IEEE representation) 129 +----------+-------+-------+-----------------------+----------------+ 130 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 131 | | | | | Identifier | 132 +----------+-------+-------+-----------------------+----------------+ 133 | 01 | 0 | 1 | Extended Local | ELI | 134 | 11 | 1 | 1 | Standard Assigned | SAI | 135 | 00 | 0 | 0 | Administratively | AAI | 136 | | | | Assigned | | 137 | 10 | 1 | 0 | Reserved | Reserved | 138 +----------+-------+-------+-----------------------+----------------+ 140 Figure 2: SLAP quadrants 142 1.1. Problem statement 144 IEEE is developing mechanisms to assign addresses (IEEE P802.1CQ 145 project) [IEEE-P802.1CQ-Project]. There is also ongoing work in the 146 IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that 147 extends DHCPv6 operation to handle the local MAC address assignments. 148 This document proposes extensions to DHCPv6 protocols to enable a 149 DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant 150 to the server, so that the server may allocate the MAC addresses in 151 the quadrant requested by the relay or client. 153 In the following, we describe two application scenarios in which a 154 need arises to assign local MAC addresses according to preferred SLAP 155 quadrants. 157 1.1.1. WiFi (IEEE 802.11) devices 159 Today, most WiFi devices come with interfaces that have a "burned in" 160 MAC address, allocated from the universal address space using a 161 24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802 162 interface vendors). However, recently, the need to assign local 163 (instead of universal) MAC addresses has emerged in particular in the 164 following two scenarios: 166 o IoT (Internet of Things): In general, composed of constrained 167 devices [RFC7228] with constraints such as available power and 168 energy, memory, and processing resources. Examples of this 169 include sensors and actuators for health or home automation 170 applications. In this scenario, a reasonable behavior would be 171 that, upon a first boot, the device uses a temporary MAC address 172 to send initial DHCP packets to available DHCP servers. IoT 173 devices typically need a single MAC address for each available 174 network interface. Once the server assigns a MAC address, the 175 device abandons its temporary MAC address. Home automation IoT 176 devices typically do not move (however, not that there is an 177 increase of smart health monitoring devices, which are mobile). 178 For this type of device, in general, any type of SLAP quadrant 179 would be good for assigning addresses, but ELI/SAI quadrants might 180 be more suitable in some scenarios. For example, the device might 181 need to use an address from the CID assigned to the IoT 182 communication device vendor, thus preferring the ELI quadrant. 184 o Privacy: Today, MAC addresses allow the exposure of users' 185 locations making it relatively easy to track users' movements. 186 One of the mechanisms considered to mitigate this problem is the 187 use of local random MAC addresses, changing them every time the 188 user connects to a different network. In this scenario, devices 189 are typically mobile. Here, AAI is probably the best SLAP 190 quadrant from which to assign addresses, as it is the best fit for 191 randomization of addresses, and it is not required for the 192 addresses to survive when changing networks. 194 1.1.2. Hypervisor: migratable vs non-migratable functions 196 In large scale virtualization environments, thousands of virtual 197 machines (VMs) are active. These VMs are typically managed by a 198 hypervisor, in charge of spawning and stopping VMs as needed. The 199 hypervisor is also typically in charge of assigning new MAC addresses 200 to the VMs. If a DHCP solution is in place for that, the hypervisor 201 acts as a DHCP client and requests available DHCP servers to assign 202 one or more MAC addresses (an address block). The hypervisor does 203 not use those addresses for itself, but rather uses them to create 204 new VMs with appropriate MAC addresses. If we assume very large data 205 center environments, such as the ones that are typically used 206 nowadays, it is expected that the data center is divided in different 207 network regions, each one managing its own local address space. In 208 this scenario, there are two possible situations that need to be 209 tackled: 211 o Migratable functions. If a VM (providing a given function) needs 212 to be migrated to another region of the data center (e.g., for 213 maintenance, resilience, end-user mobility, etc.), the VM's 214 networking context needs to migrate with the VM. This includes 215 the VM's MAC address(es). Therefore, for this case, it is better 216 to allocate addresses from the ELI/SAI SLAP quadrant, which can be 217 centrally allocated by the DHCP server. 219 o Non-migratable functions. If a VM will not be migrated to 220 another region of the data center, there are no requirements 221 associated with its MAC address. In this case, it is more 222 efficient to allocate it from the AAI SLAP quadrant, that does not 223 need to be unique across multiple data centers (i.e., each region 224 can manage its own MAC address assignment, without checking for 225 duplicates globally). 227 2. Terminology 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 231 "OPTIONAL" in this document are to be interpreted as described in BCP 232 14 [RFC2119] [RFC8174] when, and only when, they appear in all 233 capitals, as shown here. 235 Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol 236 [RFC8415] also applies here. Additionally, the following definitions 237 are updated for this document. 239 IA_LL Identity Association for Link-Layer Address: an 240 identity association (IA) used to request or assign 241 link-layer addresses. Section 10.1 of 242 [I-D.ietf-dhc-mac-assign] provides details on the IA_LL 243 option. 245 LLADDR Link-layer address option that is used to request or 246 assign a block of link-layer addresses. Section 10.2 247 of [I-D.ietf-dhc-mac-assign] provides details on the 248 LLADDR option. 250 client A node that is interested in obtaining link-layer 251 addresses. It implements the basic DHCP mechanisms 252 needed by a DHCP client as described in [RFC8415] and 253 supports the options (IA_LL and LLADDR) specified in 254 [I-D.ietf-dhc-mac-assign], as well as the new option 255 (QUAD) specified in this document. The client may or 256 may not support IPv6 address assignment and prefix 257 delegation as specified in [RFC8415]. 259 server A node that manages link-layer address allocation and 260 is able to respond to client queries. It implements 261 basic DHCP server functionality as described in 262 [RFC8415] and supports the options (IA_LL and LLADDR) 263 specified in [I-D.ietf-dhc-mac-assign], as well as the 264 new option (QUAD) specified in this document. The 265 server may or may not support IPv6 address assignment 266 and prefix delegation as specified in [RFC8415]. 268 relay A node that acts as an intermediary to deliver DHCP 269 messages between clients and servers. A relay, based 270 on local knowledge and policies, may include the 271 preferred SLAP quadrant in a QUAD option sent to the 272 server. The relay implements basic DHCPv6 relay agent 273 functionality as described in [RFC8415]. 275 address Unless specified otherwise, an address means a link- 276 layer (or MAC) address, as specified in IEEE Std 802 277 [IEEEStd802]. The address is six or eight bytes long. 279 address block A number of consecutive link-layer addresses. An 280 address block is expressed as a first address plus a 281 number that designates the number of additional (extra) 282 addresses. A single address can be represented by the 283 address itself and zero extra addresses. 285 3. DHCPv6 Extensions 287 3.1. Address Assignment from the Preferred SLAP Quadrant Indicated by 288 the Client 290 Next, we describe the protocol operations for a client to select a 291 preferred SLAP quadrant using the DHCPv6 signaling procedures 292 described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown 293 in Figure 3. 295 +--------+ +--------+ 296 | DHCPv6 | | DHCPv6 | 297 | client | | server | 298 +--------+ +--------+ 299 | | 300 +----1. Solicit(IA_LL(LLADDR,QUAD))--->| 301 | | 302 |<--2. Advertise(IA_LL(LLADDR,QUAD))---+ 303 | | 304 +---3. Request(IA_LL(LLADDR,QUAD))---->| 305 | | 306 |<------4. Reply(IA_LL(LLADDR))--------+ 307 | | 308 . . 309 . (timer expiring) . 310 . . 311 | | 312 +---5. Renew(IA_LL(LLADDR,QUAD))------>| 313 | | 314 |<-----6. Reply(IA_LL(LLADDR))---------+ 315 | | 317 Figure 3: DHCPv6 signaling flow (client-server) 319 1. Link-layer addresses (i.e., MAC addresses) are assigned in 320 blocks. The smallest block is a single address. To request an 321 assignment, the client sends a Solicit message with an IA_LL 322 option in the message. The IA_LL option MUST contain a LLADDR 323 option. In order to indicate the preferred SLAP quadrant(s), the 324 IA_LL option includes the new OPTION_SLAP_QUAD option in the 325 IA_LL-option field (alongside the LLADDR option). 327 2. The server, upon receiving an IA_LL option in Solicit, inspects 328 its contents. For each of the entries in OPTION_SLAP_QUAD, in 329 order of the preference field (highest to lowest), the server 330 checks if it has a configured MAC address pool matching the 331 requested quadrant identifier, and an available range of 332 addresses of the requested size. If suitable addresses are 333 found, the server sends back an Advertise message with an IA_LL 334 option containing an LLADDR option that specifies the addresses 335 being offered. If the server supports the new QUAD IA_LL-option, 336 and manages a block of addresses belonging to a requested 337 quadrant, the addresses being offered MUST belong to a requested 338 quadrant. If the server does not have a configured address pool 339 matching the client's request, it MUST return the IA_LL option 340 containing a Status Code option with status set to NoQuadAvail 341 (IANA-2). If the client specified more than one SLAP quadrant, 342 the server MUST only return a NoQuadAvail status code if no 343 address pool(s) configured at the server match any of the 344 specified SLAP quadrants. If the server has a configured address 345 pool of the correct quadrant, but no available addresses, it MUST 346 return the IA_LL option containing a Status Code option with 347 status set to NoAddrsAvail. 349 3. The client waits for available servers to send Advertise 350 responses and picks one server as defined in Section 18.2.9 of 351 [RFC8415]. The client SHOULD NOT pick a server that does not 352 advertise an address in the requested quadrant(s). The client 353 then sends a Request message that includes the IA_LL container 354 option with the LLADDR option copied from the Advertise message 355 sent by the chosen server. It includes the preferred SLAP 356 quadrant(s) in a new QUAD IA_LL-option. 358 4. Upon reception of a Request message with IA_LL container option, 359 the server assigns requested addresses. The server MAY alter the 360 allocation at this time (e.g., by reducing the address block). 361 It then generates and sends a Reply message back to the client. 362 Upon receiving a Reply message, the client parses the IA_LL 363 container option and may start using all provided addresses. 364 Note that a client that has included a Rapid Commit option in the 365 Solicit, may receive a Reply in response to the Solicit and skip 366 the Advertise and Request steps above (following standard DHCPv6 367 procedures). 369 5. The client is expected to periodically renew the link-layer 370 addresses as governed by T1 and T2 timers. This mechanism can be 371 administratively disabled by the server sending "infinity" as the 372 T1 and T2 values (see Section 7.7 of [RFC8415]). The client 373 sends a Renew option after T1. It includes the preferred SLAP 374 quadrant(s) in the new QUAD IA_LL-option, so in case the server 375 is unable to extend the lifetime on the existing address(es), the 376 preferred quadrants are known for the allocation of any "new" 377 (i.e., different) addresses. 379 6. The server responds with a Reply message, with an IA_LL option 380 that includes an LLADDR option with extended lifetime. 382 The client SHOULD check if the received MAC address comes from one of 383 the requested quadrants. It MAY repeat the process selecting a 384 different DHCP server. 386 3.2. Address Assignment from the SLAP Quadrant Indicated by the Relay 388 Next, we describe the protocol operations for a relay to select a 389 preferred SLAP quadrant using the DHCPv6 signaling procedures 390 described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6 391 server is operating over a large infrastructure split in different 392 network regions, where each region might have different requirements. 393 The signaling flow is shown in Figure 4. 395 +--------+ +--------+ +--------+ 396 | DHCPv6 | | DHCPv6 | | DHCPv6 | 397 | client | | relay | | server | 398 +--------+ +--------+ +--------+ 399 | | | 400 +-----1. Solicit(IA_LL)----->| | 401 | +----2. Relay-forward | 402 | | (Solicit(IA_LL),QUAD)------>| 403 | | | 404 | |<---3. Relay-reply | 405 | | (Advertise(IA_LL(LLADDR)))--+ 406 |<4. Advertise(IA_LL(LLADDR))+ | 407 |-5. Request(IA_LL(LLADDR))->| | 408 | +-6. Relay-forward | 409 | | (Request(IA_LL(LLADDR)),QUAD)->| 410 | | | 411 | |<--7. Relay-reply | 412 | | (Reply(IA_LL(LLADDR)))-------+ 413 |<--8. Reply(IA_LL(LLADDR))--+ | 414 | | | 415 . . . 416 . (timer expiring) . 417 . . . 418 | | | 419 +--9. Renew(IA_LL(LLADDR))-->| | 420 | |--10. Relay-forward | 421 | | (Renew(IA_LL(LLADDR)),QUAD)-->| 422 | | | 423 | |<---11. Relay-reply | 424 | | (Reply(IA_LL(LLADDR)))-----+ 425 |<--12. Reply(IA_LL(LLADDR)--+ | 426 | | | 428 Figure 4: DHCPv6 signaling flow (client-relay-server) 430 1. Link-layer addresses (i.e., MAC addresses) are assigned in 431 blocks. The smallest block is a single address. To request an 432 assignment, the client sends a Solicit message with an IA_LL 433 option in the message. The IA_LL option MUST contain a LLADDR 434 option. 436 2. The DHCP relay receives the Solicit message and encapsulates it 437 in a Relay-forward message. The relay, based on local knowledge 438 and policies, includes in the Relay-forward message the QUAD 439 option with the preferred quadrant. The relay might know which 440 quadrant to request based on local configuration (e.g., the 441 served network contains IoT devices only, thus requiring ELI/ 442 SAI) or other means. Note that if a client sends multiple 443 instances of the IA_LL option in the same message, the DHCP 444 relay MAY only add a single instance of the QUAD option. 446 3. Upon receiving a relayed message containing an IA_LL option, the 447 server inspects the contents for instances of OPTION_SLAP_QUAD 448 in both the Relay Forward message and the client's message 449 payload. Depending on the server's policy, the instance of the 450 option to process is selected (see also at the end of this 451 section). For each of the entries in OPTION_SLAP_QUAD, in order 452 of the preference field (highest to lowest), the server checks 453 if it has a configured MAC address pool matching the requested 454 quadrant identifier, and an available range of addresses of the 455 requested size. If suitable addresses are found, the server 456 sends back an Advertise message with an IA_LL option containing 457 an LLADDR option that specifies the addresses being offered. 458 This message is sent to the Relay in a Relay-reply message. If 459 the server supports the semantics of the preferred quadrant 460 included in the QUAD option, and manages a block of addresses 461 belonging to a requested quadrant, then the addresses being 462 offered MUST belong to a requested quadrant. The server SHOULD 463 apply the contents of the relay's supplied QUAD option for all 464 of the client's IA_LLs, unless configured to do otherwise. 466 4. The relay sends the received Advertise message to the client. 468 5. The client waits for available servers to send Advertise 469 responses and picks one server as defined in Section 18.2.9 of 470 [RFC8415]. The client then sends a Request message that 471 includes the IA_LL container option with the LLADDR option 472 copied from the Advertise message sent by the chosen server. 474 6. The relay forwards the received Request in a Relay-forward 475 message. It adds in the Relay-forward a QUAD IA_LL-option with 476 the preferred quadrant. 478 7. Upon reception of the forwarded Request message with IA_LL 479 container option, the server assigns requested addresses. The 480 server MAY alter the allocation at this time. It then generates 481 and sends a Reply message, in a Relay-reply back to the relay. 483 8. Upon receiving a Reply message, the client parses the IA_LL 484 container option and may start using all provided addresses. 486 9. The client is expected to periodically renew the link-layer 487 addresses as governed by T1 and T2 timers. This mechanism can 488 be administratively disabled by the server sending "infinity" as 489 the T1 and T2 values (see Section 7.7 of [RFC8415]). The client 490 sends a Renew option after T1. 492 10. This message is forwarded by the relay in a Relay-forward 493 message, including a QUAD IA_LL-option with the preferred 494 quadrant. 496 11. The server responds with a Reply message, including an LLADDR 497 option with extended lifetime. This message is sent in a Relay- 498 reply message. 500 12. The relay sends the Reply message back to the client. 502 The server SHOULD implement a configuration parameter to deal 503 with the case where the client's DHCP message contains an instance of 504 OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- 505 forward message. This parameter configures the server to process 506 either the client's, or the relay's instance of option QUAD. It is 507 RECOMMENDED that the default for such a parameter is to process the 508 client's instance of the option. 510 The client MAY check if the received MAC address belongs to a 511 quadrant it is willing to use/configure, and MAY decide based on that 512 whether to use configure the received address. 514 4. DHCPv6 Option Definition 516 4.1. Quad option 518 The QUAD option is used to specify the preferences for the selected 519 quadrants within an IA_LL. The option MUST either be encapsulated in 520 the IA_LL-options field of an IA_LL option or in a Relay-forward 521 message. 523 The format of the QUAD option is: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | OPTION_SLAP_QUAD | option-len | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | quadrant-1 | pref-1 | quadrant-2 | pref-2 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 . . 533 . . 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | quadrant-n-1 | pref-n-1 | quadrant-n | pref-n | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 5: Quad Option Format 540 option-code OPTION_SLAP_QUAD (IANA-1). 542 option-len 2 * number of included (quadrant, preference). A 543 2-byte field containing the total length of all 544 (quadrant, preference) pairs included in the option. 546 quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: 547 Reserved by IEEE [IEEEStd802c], 3: SAI). Each 548 quadrant MUST only appear once at most in the option. 549 A 1-byte field. 551 pref-n Preference associated to quadrant-n. A higher value 552 means a more preferred quadrant. A 1-byte field. 554 A quadrant identifier value MUST only appear at most once in the 555 option. If an option includes more than one occurrence of the same 556 quadrant identifier, only the first occurence is processed and the 557 rest MUST be ignored by the server. 559 If the same preference value is used for more than one quadrant, the 560 server MAY select which quadrant should be preferred (if the server 561 can assign addresses from all or some of the quadrants with the same 562 assigned preference). Note that this is not a simple list of 563 quadrants ordered by preference without no preference value but a 564 list of quadrants with explicit preference values. This way it can 565 support the case whereby a client really has no preference between 566 two or three quadrants, leaving the decision to the server. 568 If the client or relay agent provide the OPTION_SLAP_QUAD, the server 569 MUST use the quadrant-n/pref-n values to order the selection of the 570 quadrants. If the server can provide an assignment from one of the 571 specified quadrants, it SHOULD proceed with the assignment. If the 572 server does not have a configured address pool matching any of the 573 specified quadrant-n fields, it MUST NOT assign any addresses and 574 return a status of NoQuadAvail (IANA-2) in the IA_LL Option. If the 575 server has a configured address pool of the correct quadrant, but no 576 available addresses, it MUST return the IA_LL option containing a 577 statis of NoAddrsAvail. 579 There is no requirement that the client or relay agent order the 580 quadrant/pref values in any specific order; hence servers MUST NOT 581 assume that quadrant-1/pref-1 have the highest preference (except if 582 there is only 1 set of values). 584 5. IANA Considerations 586 IANA is requested to assign the QUAD (IANA-1) option code from the 587 DHCPv6 "Option Codes" registry maintained at 588 http://www.iana.org/assignments/dhcpv6-parameters and use the 589 following data when adding the option to the registry: 591 Value: IANA-1 592 Description: OPTION_SLAP_QUAD 593 Client ORO: No 594 Singleton Option: No 595 Reference: this document 597 IANA is requested to assign the NoQuadAvail (IANA-2) code from the 598 DHCPv6 "Status Codes" registry maintained 599 athttp://www.iana.org/assignments/dhcpv6-parameters and use the 600 following data when adding the option to the registry: 602 Value: IANA-2 603 Description: NoQuadAvail 604 Reference: this document 606 6. Security Considerations 608 See [RFC8415] and [RFC7227] for the DHCPv6 security and privacy 609 considerations. See [RFC8200] for the IPv6 security considerations. 611 See also [I-D.ietf-dhc-mac-assign] for security considerations 612 regarding link-layer address assignments using DHCP. 614 7. Acknowledgments 616 The authors would like to thank Bernie Volz for his very valuable 617 comments on this document. We also want to thank Ian Farrer, Tomek 618 Mrugalski, Eric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted 619 Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, 620 Alvaro Retana and Murray Kucherawy for their very detailed and 621 helpful reviews. And to Roger Marks and Antonio de la Oliva for 622 comments related to IEEE work and references. 624 The work in document draft has been supported by the H2020 5Growth 625 (Grant 856709) and 5G-DIVE projects (Grant 859881). 627 8. References 629 8.1. Normative References 631 [I-D.ietf-dhc-mac-assign] 632 Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 633 Addresses Assignment Mechanism for DHCPv6", draft-ietf- 634 dhc-mac-assign-08 (work in progress), July 2020. 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 642 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 643 May 2017, . 645 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 646 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 647 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 648 RFC 8415, DOI 10.17487/RFC8415, November 2018, 649 . 651 8.2. Informative References 653 [IEEE-P802.1CQ-Project] 654 IEEE, "IEEE P802.1CQ: Multicast and Local Address 655 Assignment". 657 [IEEEStd802] 658 IEEE, "IEEE Standard for Local and Metropolitan Area 659 Networks: Overview and Architecture, IEEE Std 802-2014", 660 June 2014. 662 [IEEEStd802c] 663 IEEE, "IEEE Standard for Local and Metropolitan Area 664 Networks: Overview and Architecture, Amendment 2: Local 665 Medium Access Control (MAC) Address Usage, IEEE Std 802c- 666 2017", June 2017. 668 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 669 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 670 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 671 . 673 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 674 Constrained-Node Networks", RFC 7228, 675 DOI 10.17487/RFC7228, May 2014, 676 . 678 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 679 Sehgal, "Management of Networks with Constrained Devices: 680 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 681 . 683 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 684 (IPv6) Specification", STD 86, RFC 8200, 685 DOI 10.17487/RFC8200, July 2017, 686 . 688 Appendix A. Quadrant Selection Mechanisms examples 690 This appendix describes some examples of how the quadrant preference 691 mechanisms could be used. 693 Let's take first an IoT scenario as an example. An IoT device might 694 decide on its own the SLAP quadrant it wants to use to obtain a local 695 MAC address, using the following information to take the decision: 697 o Type of IoT deployment: e.g., industrial, domestic, rural, etc. 698 For small deployments, such as domestic ones, the IoT device 699 itself can decide to use the AAI quadrant (this might not even 700 involve the use of DHCP, by the device just configuring a random 701 address computed by the device itself). For large deployments, 702 such as industrial or rural ones, where thousands of devices might 703 co-exist, the IoT can decide to use the ELI or SAI quadrants. 705 o Mobility: if the IoT device can move, then it might prefer to 706 select the SAI or AAI quadrants to minimize address collisions 707 when moving to another network. If the device is known to remain 708 fixed, then the ELI is probably the most suitable one to use. 710 o Managed/unmanaged: depending on whether the IoT device is managed 711 during its lifetime or cannot be re-configured [RFC7548], the 712 decision of what quadrant is more appropriate might be different. 713 For example, if the IoT device can be managed (e.g., configured), 714 and network topology changes might occur during its lifetime 715 (e.g., due to changes on the deployment, such as extensions 716 involving additional devices), this has an impact on the preferred 717 quadrant (e.g., to avoid potential collisions in the future). 719 o Operation/battery lifetime: depending on the expected lifetime of 720 the device a different quadrant might be preferred (as before, to 721 minimize potential address collisions in the future). 723 The previous parameters are considerations that the device vendor/ 724 administrator may wish to use when defining the IoT device's 725 MAC address request policy (i.e., how to select a given SLAP 726 quadrant). IoT devices are typically very resource constrained, so 727 there may only be a simple decision-making process based on pre- 728 configured preferences. 730 We now take the WiFi device scenario, considering for example that a 731 laptop or smartphone connects to a network using its built in MAC 732 address. Due to privacy/security concerns, the device might want to 733 configure a local MAC address. The device might use different 734 parameters and context information to decide, not only which SLAP 735 quadrant to use for the local MAC address configuration, but also 736 when to perform a change of address (e.g., it might be needed to 737 change address several times). This information includes, but it is 738 not limited to: 740 o Type of network the device is connected: public, work, home. 742 o Trusted network: Yes/No. 744 o First time visited network: Yes/No. 746 o Network geographical location. 748 o Mobility: Yes (the device might change its network attachment 749 point)/No (the device is not going to change its network 750 attachment point). 752 o Operating System (OS) network profile, including security/trust 753 related parameters: most modern OSs keep metadata associated to 754 the networks they can attach to, as for example the level of trust 755 the user or administrator assigns to the network. This 756 information is used to configure how the device behaves in terms 757 of advertising itself on the network, firewall settings, etc. But 758 this information can also be used to decide whether to configure a 759 local MAC address or not, from which SLAP quadrant and how often. 761 o Triggers coming from applications regarding location privacy. An 762 app might request to the OS to maximize location privacy (due to 763 the nature of the application) and this might require that the OS 764 forces the use of a local MAC address, or that the local MAC 765 address is changed. 767 This information can be used by the device to select the SLAP 768 quadrant. For example, if the device is moving around (e.g., while 769 connected to a public network in an airport), it is likely that it 770 might change access point several times, and therefore it is best to 771 minimize the chances of address collision, using the SAI or AAI 772 quadrants. If the device is not expected to move and attached to a 773 trusted network (e.g. in some scenarios at work), then it is probably 774 best to select the ELI quadrant. These are just some examples of how 775 to use this information to select the quadrant. 777 Additionally, the information can also be used to trigger subsequent 778 changes of MAC address, to enhance location privacy. Besides, 779 changing the SLAP quadrant might also be used as an additional 780 enhancement to make it harder to track the user location. 782 Last, if we consider the data center scenario, a hypervisor might 783 request local MAC addresses to be assigned to virtual machines. As 784 in the previous scenarios, the hypervisor might select the preferred 785 SLAP quadrant using information provided by the cloud management 786 system or virtualization infrastructure manager running on top of the 787 hypervisor. This information might include, but is not limited to: 789 o Migratable VM. If the function implemented by the VM is subject 790 to be moved to another physical server or not. This has an impact 791 on the preference for the SLAP quadrant, as the ELI and SAI 792 quadrants are better suited for supporting migration in a large 793 data center. 795 o VM connectivity characteristics , e.g., standalone, part of a 796 pool, part of a service graph/chain. If the connectivity 797 characteristics of the VM are known, this can be used by the 798 hypervisor to select the best SLAP quadrant. 800 Authors' Addresses 801 Carlos J. Bernardos 802 Universidad Carlos III de Madrid 803 Av. Universidad, 30 804 Leganes, Madrid 28911 805 Spain 807 Phone: +34 91624 6236 808 Email: cjbc@it.uc3m.es 809 URI: http://www.it.uc3m.es/cjbc/ 811 Alain Mourad 812 InterDigital Europe 814 Email: Alain.Mourad@InterDigital.com 815 URI: http://www.InterDigital.com/