idnits 2.17.1 draft-bernardos-dhc-slap-quadrant-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 8, 2019) is 1869 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: September 9, 2019 InterDigital 6 March 8, 2019 8 SLAP quadrant selection options for DHCPv6 9 draft-bernardos-dhc-slap-quadrant-01 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. In this document, we complement 24 this ongoing IETF work by defining a mechanism to allow choosing the 25 SLAP quadrant to use in the allocation of the MAC address to the 26 requesting device/client. 28 This document proposes extensions to DHCPv6 protocols to enable a 29 DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant 30 to the server, so that the server allocates the MAC address to the 31 given client out of the quadrant requested by relay or client. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 9, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Quadrant selection mechanisms . . . . . . . . . . . . . . . . 6 73 4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. DHCPv6 options definitions . . . . . . . . . . . . . . . . . 13 79 5.1. Quad (IA-LL) option . . . . . . . . . . . . . . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 9.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 U/L bit is 92 set to 1). Recently, the IEEE has been working on a new 93 specification (IEEE 802c [IEEEStd802c-2017]) which defines a new 94 "optional Structured Local Address Plan" (SLAP) that specifies 95 different assignment approaches in four specified regions of the 96 local MAC address space. These four regions, called SLAP quadrants, 97 are briefly described below (see Figure 1 and Figure 2 for details): 99 o Quadrant "Extended Local Identifier" (ELI) MAC addresses are 100 assigned based on a Company ID (CID), which takes 24-bits, leaving 101 the remaining 24-bits for the locally assigned address for each 102 CID for unicast (M-bit = 0) and also for multicast (M-bit = 1). 103 The CID is assigned by the IEEE Registration Authority (RA). 105 o Quadrant "Standard Assigned Identifier" (SAI) MAC addresses are 106 assigned based on a protocol specified in an IEEE 802 standard. 107 For 48-bit MAC addresses, 44 bits are available. Multiple 108 protocols for assigning SAIs may be specified in IEEE standards. 109 Coexistence of multiple protocols may be supported by limiting the 110 subspace available for assignment by each protocol. 112 o Quadrant "Administratively Assigned Identifier" (AAI) MAC 113 addresses are assigned locally by an administrator. Multicast 114 IPv6 packets use a destination address starting in 33-33 and this 115 falls within this space and therefore should not be used to avoid 116 conflict with IPv6 multicast addresses. For 48-bit MAC addresses, 117 44 bits are available. 119 o Quadrant "Reserved for future use" where MAC addresses may be 120 assigned using new methods yet to be defined, or by an 121 administrator like in the AAI quadrant. 123 LSB MSB 124 M X Y Z - - - - 125 | | | | 126 | | | +------------ SLAP Z-bit 127 | | +--------------- SLAP Y-bit 128 | +------------------ X-bit (U/L) = 1 for locally assigned 129 +--------------------- M-bit (I/G) (unicast/group) 131 Figure 1: IEEE 48-bit MAC address structure 133 +----------+-------+-------+-----------------------+----------------+ 134 | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | 135 | | | | | Identifier | 136 +----------+-------+-------+-----------------------+----------------+ 137 | 01 | 0 | 1 | Extended Local | ELI | 138 | 11 | 1 | 1 | Standard Assigned | SAI | 139 | 00 | 0 | 0 | Administratively | AAI | 140 | | | | Assigned | | 141 | 10 | 1 | 0 | Reserved | Reserved | 142 +----------+-------+-------+-----------------------+----------------+ 144 Figure 2: SLAP quadrants 146 1.1. Problem statement 148 The IEEE is working on mechanisms to allocate addresses in the SAI 149 quadrant (IEEE 802.1CQ project). There is also ongoing work in the 150 IETF [I-D.bvtm-dhc-mac-assign] specifying a new mechanism that 151 extends DHCPv6 operation to handle the local MAC address assignments. 152 In this document, we complement ongoing IETF work with mechanisms to 153 allow choosing the SLAP quadrant to use in the allocation of the MAC 154 address to the requesting device/client. This document proposes 155 extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 156 relay to indicate a preferred SLAP quadrant to the server, so that 157 the server allocates the MAC address to the given client out of the 158 quadrant requested by relay or client. 160 In the following, we describe two application scenarios where a need 161 arises to assign local MAC addresses according to preferred SLAP 162 quadrants. 164 1.1.1. WiFi devices 166 Today, most WiFi devices come with interfaces that have a "burned in" 167 MAC address, allocated from the universal address space using a 168 24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802 169 interface vendors). However, recently, the need to assign local 170 (instead of universal) MAC addresses has emerged in particular in the 171 following two scenarios: 173 o IoT (Internet of Things): where there are a lot of cheap, 174 sometimes short lived and disposable devices. Examples of this 175 include: sensors and actuators for health or home automation 176 applications. In this scenario, it is common that upon a first 177 boot, the device uses a temporary MAC address, to send initial 178 DHCP packets to available DHCP servers. IoT devices typically 179 request a single MAC address for each available network interface. 180 Once the server assigns a MAC address, the device abandons its 181 temporary MAC address. This type of device is typically not 182 moving. In general, any type of SLAP quadrant would be good for 183 assigning addresses from, but ELI/SAI quadrants might be more 184 suitable in some scenarios, such as if it is needed that the 185 addresses belong to the CID assigned to the IoT communication 186 device vendor. 188 o Privacy: Today, MAC addresses allow the exposure of users' 189 locations making it relatively easy to track users' movement. One 190 of the mechanisms considered to mitigate this problem is the use 191 of local random MAC addresses, changing them every time the user 192 connects to a different network. In this scenario, devices are 193 typically mobile. Here, AAI is probably the best SLAP quadrant to 194 assign addresses from, as it is the best fit for randomization of 195 addresses, and it is not required for the addresses to survive 196 when changing networks. 198 1.1.2. Hypervisor: migratable vs non-migratable functions 200 In large scale virtualization environments, thousands of virtual 201 machines (VMs) are active. These VMs are typically managed by a 202 hypervisor, in charge of spawning and stopping VMs as needed. The 203 hypervisor is also typically in charge of assigning new MAC addresses 204 to the VMs. If a DHCP solution is in place for that, the hypervisor 205 acts as a DHCP client and requests available DHCP servers to assign 206 one or more MAC addresses (an address block). The hypervisor does 207 not use those addresses for itself, but rather uses them to create 208 new VMs with appropriate MAC addresses. If we assume very large data 209 center environments, such as the ones that are typically used 210 nowadays, it is expected that the data center is divided in different 211 network regions, each one managing its own local address space. In 212 this scenario, there are two possible situations that need to be 213 tackled: 215 o Migratable functions. If a VM (providing a given function) might 216 need to be potentially migrated to another region of the data 217 center (due to maintenance, resilience, end-user mobility, etc.) 218 it is needed that this VM can keep its networking context in the 219 new region, and this includes keeping its MAC addresses. 220 Therefore, for this case, it is better to allocate addresses from 221 the ELI/SAI SLAP quadrant, which can be centrally allocated by the 222 DHCP server. 224 o Non-migratable functions. If a VM will not be migrated to another 225 region of the data center, there are no requirements associated to 226 its MAC address, and then it is more efficient to allocate it from 227 the AAI SLAP quadrant, which does not need to be same for all the 228 data centers (i.e., each region can manage its own, without 229 checking for duplicates globally). 231 2. Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 235 and"OPTIONAL" in this document are to be interpreted as described in 236 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 The DHCPv6 terminology relevant to this specification from the DHCPv6 240 Protocol [RFC8415] applies here. 242 client A device that is interested in obtaining link-layer 243 addresses. It implements the basic DHCPv6 mechanisms 244 needed by a DHCPv6 client as described in [RFC8415] and 245 supports the new options (IA_LL and LLADDR) specified 246 in [I-D.bvtm-dhc-mac-assign]. The client may or may 247 not support address assignment and prefix delegation as 248 specified in [RFC8415]. 250 server Software that manages link-layer address allocation and 251 is able to respond to client queries. It implements 252 basic DHCPv6 server functionality as described in 253 [RFC8415] and supports the new options (IA_LL and 254 LLADDR) specified in [I-D.bvtm-dhc-mac-assign]. The 255 server may or may not support address assignment and 256 prefix delegation as specified in [RFC8415]. 258 address Unless specified otherwise, an address means a link- 259 layer (or MAC) address, as defined in IEEE802. The 260 address is typically 6 bytes long, but some network 261 architectures may use different lengths. 263 address block A number of consecutive link-layer addresses. An 264 address block is expressed as a first address plus a 265 number that designates the number of additional (extra) 266 addresses. A single address can be represented by the 267 address itself and zero extra addresses. 269 3. Quadrant selection mechanisms 271 We next describe some exemplary ways to perform SLAP quadrant 272 selection. These are provided just as informational text to 273 exemplify how the quadrant preference mechanisms could be used. 275 Let's take first an IoT scenario as an example. An IoT device might 276 decide on its own the SLAP quadrant it wants to use to obtain a local 277 MAC address, using the following information to take the decision: 279 o Type of IoT deployment: e.g., industrial, domestic, rural, etc. 280 For small deployments, such as domestic ones, the IoT itself can 281 decide to use the AAI quadrant (this might not even involve the 282 use of DHCP, by the device just configuring a random address 283 computed by the device itself). For large deployments, such as 284 industrial or rural ones, where thousands of devices might co- 285 exist, the IoT can decide to use the ELI or SAI quadrants. 287 o Mobility: if the IoT device can move, then it might prefer to 288 select the SAI or AAI quadrants to minimize address collisions 289 when moving to another network. If the device is known to remain 290 fixed, then the ELI is probably the most suitable one to use. 292 o Managed/unmanaged: depending on whether the IoT device is managed 293 during its lifetime or cannot be re-configured, the selected 294 quadrant might be different. For example, it can be managed, this 295 means that network topology changes might occur during its 296 lifetime (e.g., due to changes on the deployment, such as 297 extensions involving additional devices), and this might have an 298 impact on the preferred quadrant (e.g., to avoid potential 299 collisions in the future). 301 o Operation/battery lifetime: depending on the expected lifetime of 302 the device a different quadrant might be preferred (as before, to 303 minimize potential address collisions in the future). 305 The previous are examples of parameters that an IoT device might use 306 to select a given SLAP quadrant. IoT devices are typically very 307 resource constrained, so it might be as well that simple decisions 308 are just taken, for example based on pre-configured preferences. 310 If we now take the WiFi device scenario, considering for example that 311 a laptop or smartphone connects to a network using its built in MAC 312 address. Due to privacy/security concerns, the device might want to 313 configure a local MAC address. The device might use different 314 parameters and context information to decide, not only which SLAP 315 quadrant to use for the local MAC address configuration, but also 316 when to perform a change of address (e.g., it might be needed to 317 change address several times). This information includes, but it is 318 not limited to: 320 o Type of network the device is connected: public, work, home. 322 o Trusted network? Y/N. 324 o First time visited network? Y/N. 326 o Network geographical location. 328 o Mobility? Y/N. 330 o OS network profile, including security/trust related parameters. 331 Most modern OS keep metadata associated to the networks they can 332 attach to, as for example the level of trust the user or 333 administrator assigns to the network. This information is used to 334 configure how the device behaves in terms of advertising itself on 335 the network, firewall settings, etc. But this information can 336 also be used to decide whether to configure a local MAC address or 337 not, from which SLAP quadrant and how often. 339 o Triggers coming from applications regarding location privacy. An 340 app might request to the OS to maximize location privacy (due to 341 the nature of the application) and this might mean the OS to force 342 the use or change of a local MAC address. 344 This information can be used by the device to select the SLAP 345 quadrant. For example, if the device is moving around (e.g., while 346 connected to a public network in an airport), it is likely that it 347 might change access point several times, and therefore it is best to 348 minimize the chances of address collision, using the SAI or AAI 349 quadrants. If the device is not moving and attached to a trusted 350 network (e.g. at work), then it is probably best to select the ELI 351 quadrant. These are just some examples of how to use this 352 information to select the quadrant. 354 Additionally, the information can also be used to trigger subsequent 355 changes of MAC address, to enhance location privacy. Besides, 356 changing the SLAP quadrant used might also be used as an additional 357 enhancement to make it harder to track the user location. 359 Last, if we consider the data center scenario, a hypervisor might 360 request local MAC addresses to be assigned to virtual machines. As 361 in the previous scenarios, the hypervisor might select the preferred 362 SLAP quadrant using information provided by the cloud management 363 system (CMS) or virtualization infrastructure manager (VIM) running 364 on top of the hypervisor. This information might include, but is not 365 limited to: 367 o Migratable/non-migratable VM. If the function implemented by the 368 VM is subject to be moved to another physical server or not. This 369 has an impact on the preference for the SLAP quadrant, as some 370 quadrants are better suited (e.g., ELI/SAI) for supporting 371 migration in a large data center. 373 o VM connectivity characteristics , e.g.,: standalone, part of a 374 pool, part of a service graph/chain. If the connectivity 375 characteristics of the VM are known, this can be used by the 376 hypervisor to select the best SLAP quadrant. 378 4. DHCPv6 extensions 379 4.1. Address assignment from the preferred SLAP quadrant indicated by 380 the client 382 We describe next the protocol operations for a client to select a 383 preferred SLAP quadrant using the DHCPv6 signaling procedures 384 described in [I-D.bvtm-dhc-mac-assign]. The signaling flow is shown 385 in Figure 3. 387 +--------+ +--------+ 388 | DHCPv6 | | DHCPv6 | 389 | client | | server | 390 +--------+ +--------+ 391 | | 392 +-------1. Solicit(IA_LL(QUAD))------->| 393 | | 394 |<--2. Advertise(IA_LL(LLADDR,QUAD))--+| 395 | | 396 +---3. Request(IA_LL(LLADDR,QUAD))---->| 397 | | 398 |<------4. Reply(IA_LL(LLADDR))--------+ 399 | | 400 . . 401 . (timer expiring) . 402 . . 403 | | 404 +---5. Renew(IA_LL(LLADDR,QUAD))------>| 405 | | 406 |<-----6. Reply(IA_LL(LLADDR))---------+ 407 | | 409 Figure 3: DHCPv6 signaling flow (client-server) 411 1. Link-layer addresses (i.e., MAC addresses) are assigned in 412 blocks. The smallest block is a single address. To request an 413 assignment, the client sends a Solicit message with a IA_LL 414 option in the message. The IA_LL option MUST contain a LLADDR 415 option. In order to indicate the preferred SLAP quadrant, the 416 IA_LL option includes the new OPTION_QUAD option in the IA-LL- 417 option field (with the LLAADR option). 419 2. The server, upon receiving a IA_LL option, inspects its content 420 and may offer an address or addresses for each LLADDR option 421 according to its policy. The server sends back an Advertise 422 message with an IA_LL option containing an LLADDR option that 423 specifies the addresses being offered. If the server supports 424 the new QUAD IA-LL-option, and manages a block of addresses 425 belonging to the requested quadrant, the addresses being offered 426 SHOULD belong to the requested quadrant. If the server does not 427 have addresses from the requested quadrant, it MUST return the 428 IA_LL option containing a Status Code option with status set to 429 NoQuadAvail. 431 3. The client waits for available servers to send Advertise 432 responses and picks one server as defined in Section 18.2.9 of 433 [RFC8415]. The client then sends a Request message that includes 434 the IA_LL container option with the LLADDR option copied from the 435 Advertise message sent by the chosen server. It includes the 436 preferred SLAP quadrant in the new QUAD IA-LL-option. 438 4. Upon reception of a Request message with IA_LL container option, 439 the server assigns requested addresses. The server MAY alter the 440 allocation at this time. It then generates and sends a Reply 441 message back to the client. Upon receiving a Reply message, the 442 client parses the IA_LL container option and may start using all 443 provided addresses. Note that a client that has included a Rapid 444 Commit option in the Solicit, may receive a Reply in response to 445 the Solicit and skip the Advertise and Request steps above 446 (following standard DHCPv6 procedures). 448 5. When the assigned addresses are about to expire, the client sends 449 a Renew message. It includes the preferred SLAP quadrant in the 450 new QUAD IA-LL-option, so in case the server is unable to extend 451 the lifetime on the existing address(es), the preferred quadrant 452 is known for the allocation of any "new" addresses. 454 6. The server responds with a Reply message, including an LLADDR 455 option with extended lifetime. 457 4.2. Address assignment from the SLAP quadrant indicated by the relay 459 We describe next the protocol operations for a relay to select a 460 preferred SLAP quadrant using the DHCPv6 signaling procedures 461 described in [I-D.bvtm-dhc-mac-assign]. This is useful when a DHCPv6 462 server is operating over a large infrastructure split in different 463 network regions, where each region might have different requirements. 464 The signaling flow is shown in Figure 4. 466 +--------+ +--------+ +--------+ 467 | DHCPv6 | | DHCPv6 | | DHCPv6 | 468 | client | | relay | | server | 469 +--------+ +--------+ +--------+ 470 | | | 471 +-----1. Solicit(IA_LL)----->| | 472 | +----2. Relay-forw | 473 | | (Solicit(IA_LL),QUAD)------>| 474 | | | 475 | |<---3. Relay-reply | 476 | | (Advertise(IA_LL(LLADDR)))--+ 477 |<4. Advertise(IA_LL(LLADDR))+ | 478 |-5. Request(IA_LL(LLADDR))->| | 479 | +-6. Relay-forw | 480 | | (Request(IA_LL(LLADDR)),QUAD)->| 481 | | | 482 | |<--7. Relay-reply | 483 | | (Reply(IA_LL(LLADDR)))-------+ 484 |<--8. Reply(IA_LL(LLADDR))--+ | 485 | | | 486 . . . 487 . (timer expiring) . 488 . . . 489 | | | 490 +--9. Renew(IA_LL(LLADDR))-->| | 491 | |--10. Relay-forw | 492 | | (Renew(IA_LL(LLADDR)),QUAD)-->| 493 | | | 494 | |<---11. Relay-reply | 495 | | (Reply(IA_LL(LLADDR)))-----+ 496 |<--12. Reply(IA_LL(LLADDR)--+ | 497 | | | 499 Figure 4: DHCPv6 signaling flow (client-relay-server) 501 1. Link-layer addresses (i.e., MAC addresses) are assigned in 502 blocks. The smallest block is a single address. To request an 503 assignment, the client sends a Solicit message with a IA_LL 504 option in the message. The IA_LL option MUST contain a LLADDR 505 option. 507 2. The DHCP relay receives the Solicit message and encapsulates it 508 in a Relay-forw message. The relay, based on local knowledge 509 and policies, includes in the Relay-Forw message the QUAD option 510 with the preferred quadrant. The relay might know which 511 quadrant to request based on local configuration (e.g., the 512 served network contains IoT devices only, thus requiring ELI/ 513 SAI) or other means such as based on analyzing the Solicit 514 message from the client. 516 3. The server, upon receiving the forwarded Solicit message 517 including a IA_LL option, inspects its content and decide may 518 offer an address or addresses for each LLADDR option according 519 to its policy. The server sends back an Advertise message with 520 an IA_LL option containing an LLADDR option that specifies the 521 addresses being offered. This message is sent to the Relay in a 522 Relay-reply message. If the server supports the semantics of 523 the preferred quadrant included in the QUAD option, and manages 524 a block of addresses belonging to the requested quadrant, then 525 the addresses being offered SHOULD belong to the requested 526 quadrant. 528 4. The relay sends the received Advertise message to the client. 530 5. The client waits for available servers to send Advertise 531 responses and picks one server as defined in Section 18.2.9 of 532 [RFC8415]. The client then sends a Request message that 533 includes the IA_LL container option with the LLADDR option 534 copied from the Advertise message sent by the chosen server. 536 6. The relay forwards the received Request in a Relay-forw message. 537 It adds in the Relay-forw a QUAD IA-LL-option with the preferred 538 quadrant. 540 7. Upon reception of the forwarded Request message with IA_LL 541 container option, the server assigns requested addresses. The 542 server MAY alter the allocation at this time. It then generates 543 and sends a Reply message, in a Relay-reply back to the relay. 545 8. Upon receiving a Reply message, the client parses the IA_LL 546 container option and may start using all provided addresses. 548 9. When the assigned addresses are about to expire, the client 549 sends a Renew message. 551 10. This message is forwarded by the Relay in a Relay-forw message, 552 including a QUAD IA-LL-option with the preferred quadrant. 554 11. The server responds with a Reply message, including an LLADDR 555 option with extended lifetime. This message is sent in a Relay- 556 Reply message. 558 12. The relay sends the Reply message back to the client. 560 5. DHCPv6 options definitions 562 5.1. Quad (IA-LL) option 564 The QUAD option is used to specify the preferences for the selected 565 quadrants within an IA_LL. The option must either be encapsulated in 566 the IA-LL-options field of an IA_LL option or in a Relay-Forw message 567 in the options field. It MAY also be in a Relay-Reply if the QUAD 568 option code was specified in a ERO option [RFC4994]. 570 The format of the QUAD option is: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | OPTION_QUAD | option-len | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | quadrant-1 | pref-1 | quadrant-2 | pref-2 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 . . 580 . . 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 5: Quad Option Format 585 option-code OPTION_QUAD (value to be assigned by IANA). 587 option-len 2 * number of included (quadrant, preference). 589 quadrant-n Identifier of the quadrant (0: AAI, 1: ELI: 2, SAI: 590 3, 4: reserved). 592 pref-n Preference associated to quadrant-n. 594 6. IANA Considerations 596 TBD. 598 7. Security Considerations 600 TBD. 602 8. Acknowledgments 604 The authors would like to thank Bernie Volz for his very valuable 605 comments on this document. 607 The work in this draft will be further developed and explored under 608 the framework of the H2020 5G-CORAL project (Grant 761586). 610 9. References 612 9.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, 616 DOI 10.17487/RFC2119, March 1997, 617 . 619 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 620 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 621 DOI 10.17487/RFC4994, September 2007, 622 . 624 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 625 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 626 May 2017, . 628 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 629 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 630 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 631 RFC 8415, DOI 10.17487/RFC8415, November 2018, 632 . 634 9.2. Informative References 636 [I-D.bvtm-dhc-mac-assign] 637 Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 638 Addresses Assignment Mechanism for DHCPv6", draft-bvtm- 639 dhc-mac-assign-02 (work in progress), October 2018. 641 [IEEEStd802c-2017] 642 IEEE Computer Society, "IEEE Standard for Local and 643 Metropolitan Area Networks: Overview and Architecture, 644 Amendment 2: Local Medium Access Control (MAC) Address 645 Usage, IEEE Std 802c-2017". 647 Authors' Addresses 648 Carlos J. Bernardos 649 Universidad Carlos III de Madrid 650 Av. Universidad, 30 651 Leganes, Madrid 28911 652 Spain 654 Phone: +34 91624 6236 655 Email: cjbc@it.uc3m.es 656 URI: http://www.it.uc3m.es/cjbc/ 658 Alain Mourad 659 InterDigital Europe 661 Email: Alain.Mourad@InterDigital.com 662 URI: http://www.InterDigital.com/