idnits 2.17.1 draft-ietf-intarea-provisioning-domains-06.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 12, 2019) is 1719 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pfister 3 Internet-Draft E. Vyncke 4 Intended status: Standards Track Cisco 5 Expires: February 13, 2020 T. Pauly 6 Apple Inc. 7 D. Schinazi 8 Google LLC 9 W. Shao 10 Cisco 11 August 12, 2019 13 Discovering Provisioning Domain Names and Data 14 draft-ietf-intarea-provisioning-domains-06 16 Abstract 18 Provisioning Domains (PvDs) are defined as consistent sets of network 19 configuration information. This allows hosts to manage connections 20 to multiple networks and interfaces simultaneously, such as when a 21 home router provides connectivity through both a broadband and 22 cellular network provider. 24 This document defines a mechanism for explicitly identifying PvDs 25 through a Router Advertisement (RA) option. This RA option announces 26 a PvD identifier, which hosts can compare to differentiate between 27 PvDs. The option can directly carry some information about a PvD and 28 can optionally point to additional PvD information that can be 29 retrieved using HTTP over TLS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 13, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Provisioning Domain Identification using Router 69 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 5 71 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 9 73 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 9 74 3.4.1. DHCPv6 configuration association . . . . . . . . . . 10 75 3.4.2. DHCPv4 configuration association . . . . . . . . . . 10 76 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 11 77 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 12 78 4. Provisioning Domain Additional Information . . . . . . . . . 12 79 4.1. Retrieving the PvD Additional Information . . . . . . . . 13 80 4.2. Operational Consideration to Providing the PvD Additional 81 Information . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.3. PvD Additional Information Format . . . . . . . . . . . . 15 83 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17 85 5. Operational Considerations . . . . . . . . . . . . . . . . . 18 86 5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18 87 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 18 88 5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 19 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 8.1. Additional Information PvD Keys Registry . . . . . . . . 22 93 8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22 94 8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 22 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 98 10.2. Informative References . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 Provisioning Domains (PvDs) are defined in [RFC7556] as consistent 104 sets of network configuration information. This information includes 105 properties that are traditionally associated with a single networking 106 interface, such as source addresses, DNS configuration, proxy 107 configuration, and gateway addresses. 109 Clients that are aware of PvDs can take advantage of multiple network 110 interfaces simultaneously. This enables using two PvDs in parallel 111 for separate connections or for multi-path transports. 113 While most PvDs today are discovered implicitly (such as by receiving 114 information via Router Advertisements from a router on a network that 115 a client host directly connects to), [RFC7556] also defines the 116 notion of Explicit PvDs. IPsec Virtual Private Networks are 117 considered Explicit PvDs, but Explicit PvDs can also be discovered 118 via the local network router. Discovering Explicit PvDs allows two 119 key advancements in managing multiple PvDs: 121 1. The ability to discover and use multiple PvDs on a single 122 interface, such as when a local router can provide connectivity 123 to two different Internet Service Providers. 125 2. The ability to associate additional informations about PvDs to 126 describe the properties of the network. 128 While [RFC7556] defines the concept of Explicit PvDs, it does not 129 define the mechanism for discovering multiple Explicit PvDs on a 130 single network and their additional information. 132 This document specifies a way to identify PvDs with Fully Qualified 133 Domain Names (FQDN), called PvD IDs. Those identifiers are 134 advertised in a new Router Advertisement (RA) [RFC4861] option called 135 the PvD ID Router Advertisement option which, when present, 136 associates the PvD ID with all the information present in the Router 137 Advertisement as well as any configuration object, such as addresses, 138 deriving from it. The PVD ID Router Advertisement option may also 139 contain a set of other RA options. Since such options are only 140 considered by hosts implementing this specification, network 141 operators may configure hosts that are 'PvD-aware' with PvDs that are 142 ignored by other hosts. 144 Since PvD IDs are used to identify different ways to access the 145 internet, multiple PvDs (with different PvD IDs) can be provisioned 146 on a single host interface. Similarly, the same PvD ID could be used 147 on different interfaces of a host in order to inform that those PvDs 148 ultimately provide equivalent services. 150 This document also introduces a mechanism for hosts to retrieve 151 optional additional information related to a specific PvD by means of 152 an HTTP over TLS query using an URI derived from the PvD ID. The 153 retrieved JSON object contains additional information that would 154 typically be considered too large to be directly included in the 155 Router Advertisement, but might be considered useful to the 156 applications, or even sometimes users, when choosing which PvD should 157 be used. 159 For example, if Alice has both a cellular network provider and a 160 broadband provider in her home, her PvD-aware devices and 161 applications would be aware of both available uplinks. These 162 applications could fail-over between these networks, or run 163 connections over both (potentially using multi-path transports). 164 Applications could also select specific uplinks based on the 165 properties of the network; for example, if the cellular network 166 provides free high-quality video streaming, a video-streaming 167 application could select that network while most of the other traffic 168 on Alice's device uses the broadband provider. 170 1.1. Specification of Requirements 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2. Terminology 180 This document uses the following terminology: 182 Provisioning Domain (PvD): A set of network configuration 183 information; for more information, see [RFC7556]. 185 PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a PvD. 187 Explicit PvD: A PvD uniquely identified with a PvD ID. For more 188 information, see [RFC7556]. 190 Implicit PvD: A PvD that, in the absence of a PvD ID, is identified 191 by the host interface to which it is attached and the address of 192 the advertising router. See also [RFC7556]. 194 PvD-aware host: A host that supports the association of network 195 configuration information into PvDs and the use of these PvDs as 196 described in this document. Also named PvD-aware node in 197 [RFC7556]. 199 3. Provisioning Domain Identification using Router Advertisements 201 Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully 202 Qualified Domain Name (FQDN) which MUST belong to the network 203 operator in order to avoid naming collisions. The same PvD ID MAY be 204 used in several access networks when they ultimately provide 205 identical services (e.g., in all home networks subscribed to the same 206 service); else, the PvD ID MUST be different to follow Section 2.4 of 207 [RFC7556]. 209 3.1. PvD ID Option for Router Advertisements 211 This document introduces a Router Advertisement (RA) option called 212 PvD Option. It is used to convey the FQDN identifying a given PvD 213 (see Figure 1, bind the PvD ID with configuration information 214 received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over 215 TLS to retrieve the PvD Additional Information JSON object (see 216 Section 4), as well as contain any other RA options which would 217 otherwise be valid in the RA. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length |H|L|R| Reserved | Delay | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Sequence Number | ... 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 226 ... PvD ID FQDN ... 227 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 ... | Padding | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | ... 231 ... Router Advertisement message header ... 232 ... (Only present when R-flag is set) ... 233 ... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Options ... 236 +-+-+-+-+-+-+-+-+-+-+-+- 238 Figure 1: PvD ID Router Advertisements Option Format 240 Type: (8 bits) Set to 21. 242 Length: (8 bits) The length of the option in units of 8 octets, 243 including the Type and Length fields, the Router Advertisement 244 message header, if any, as well as the RA options that are 245 included within the PvD Option. 247 H-flag: (1 bit) 'HTTP' flag stating whether some PvD Additional 248 Information is made available through HTTP over TLS, as described 249 in Section 4. 251 L-flag: (1 bit) 'Legacy' flag stating whether the router is also 252 providing IPv4 information using DHCPv4 (see Section 3.4.2). 254 R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD 255 Option is followed (right after padding to the next 64 bits 256 boundary) by a Router Advertisement message header (See section 257 4.2 of [RFC4861]). 259 Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from 260 hosts by a randomized backoff (see Section 4.1). 262 Reserved: (13 bits) Reserved for later use. It MUST be set to zero 263 by the sender and ignored by the receiver. 265 Sequence Number: (16 bits) Sequence number for the PvD Additional 266 Information, as described in Section 4. 268 PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as 269 described in Section 3.1 of [RFC1035]. Domain names compression 270 described in Section 4.1.4 of [RFC1035] MUST NOT be used. 272 Padding: Zero or more padding octets to the next 8 octet boundary 273 (see Section 4.6 of [RFC4861]). It MUST be set to zero by the 274 sender, and ignored by the receiver. 276 RA message header: (16 octets) When the R-flag is set, a full Router 277 Advertisement message header as specified in [RFC4861]. The 278 sender MUST set the 'Type' to 134, the value for "Router 279 Advertisement", and set the 'Code' to 0. Receivers MUST ignore 280 both of these fields. The 'Checksum' MUST be set to 0 by the 281 sender; non-zero checksums MUST be ignored by the receiver. All 282 other fields are to be set and parsed as specified in [RFC4861] or 283 any updating documents. 285 Options: Zero or more RA options that would otherwise be valid as 286 part of the Router Advertisement main body, but are instead 287 included in the PvD Option such as to be ignored by hosts that are 288 not PvD-aware. 290 Here is an example of a PvD Option with "example.org" as the PvD ID 291 FQDN and including both an RDNSS option and a prefix information 292 option. It has a Sequence Number of 123, and indicates the presence 293 of additional information that is expected to be fetched with a delay 294 factor of 5. 296 0 1 2 3 297 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 298 +---------------+-----------------------------------------------+ 299 | Type: 21 | Length: 12 |1|0|0| Reserved |Delay:5| 300 +---------------+-------------------------------+---------------+ 301 | Seq number: 123 | 7 | e | 302 +---------------+-----------------------------------------------+ 303 | x | a | m | p | 304 +---------------------------------------------------------------+ 305 | l | e | 3 | o | 306 +---------------------------------------------------------------+ 307 | r | g | 0 | 0 (padding) | 308 +---------------------------------------------------------------+ 309 | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | 310 +---------------+---------------+---------------+---------------+ 311 | RDNSS option (RFC 6106) length: 5 ... 312 ... ... 313 ... | 314 +---------------------------------------------------------------+ 315 | Prefix Information Option (RFC 4861) length: 4 ... 316 ... | 317 ... | 318 +---------------------------------------------------------------+ 320 Figure 2 322 3.2. Router Behavior 324 A router MAY send RAs containing one PvD Option, but MUST NOT include 325 more than one PvD Option in each RA. The PvD Option MUST NOT contain 326 further PvD Options. 328 The PvD Option MAY contain zero, one, or more RA options which would 329 otherwise be valid as part of the same RA. Such options are 330 processed by PvD-aware hosts, while ignored by other hosts per 331 section 4.2 of [RFC4861]. 333 In order to provide multiple different PvDs, a router MUST send 334 multiple RAs. If more than one different Implicit PvDs are 335 advertised, the RAs MUST be sent from different link-local source 336 addresses. Explicit PvDs MAY share link-local source addresses with 337 an Implicit PvD and any number of other Explicit PvDs. 339 In other words, different Explicit PvDs MAY be advertised with RAs 340 using the same link-local source address; but different Implicit 341 PvDs, advertised by different RAs, MUST use different link-local 342 addresses because these Implicit PvDs are identified by the source 343 addresses of the RAs. 345 As specified in [RFC4861], when the set of options causes the size of 346 an advertisement to exceed the link MTU, multiple router 347 advertisements can be sent, each containing a subset of the options. 348 In such cases, the PvD Option header (i.e., all fields except the 349 'Options' field) MUST be repeated in all the transmitted RAs. The 350 options within the 'Options' field, MAY be transmitted only once, 351 included in one of the transmitted PvD Options. 353 3.3. Non-PvD-aware Host Behavior 355 As the PvD Option has a new option code, non-PvD-aware hosts will 356 simply ignore the PvD Option and all the options it contains (see 357 section 4.2 of [RFC4861]. This ensure the backward compatibility 358 required in Section 3.3 of [RFC7556]. This behavior allows for a 359 mixed-mode network with a mix of PvD-aware and non-PvD-aware hosts 360 coexist. 362 3.4. PvD-aware Host Behavior 364 Hosts MUST associate received RAs and included configuration 365 information (e.g., Router Valid Lifetime, Prefix Information 366 [RFC4861], Recursive DNS Server [RFC8106], Routing Information 367 [RFC4191] options) with the Explicit PvD identified by the first PvD 368 Option present in the received RA, if any, or with the Implicit PvD 369 identified by the host interface and the source address of the 370 received RA otherwise. 372 In case multiple PvD Options are found in a given RA, hosts MUST 373 ignore all but the first PvD Option. 375 If a host receives PvD Options flags that it does not recognize 376 (currently in the Reserved field), it MUST ignore these flags. 378 Similarly, hosts MUST associate all network configuration objects 379 (e.g., default routers, addresses, more specific routes, DNS 380 Recursive Resolvers) with the PvD associated with the RA which last 381 updated the object. For example, addresses that are generated using 382 a received Prefix Information option (PIO) are associated with the 383 PvD of the last received RA which included the given PIO. 385 PvD IDs MUST be compared in a case-insensitive manner as defined by 386 [RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM." 387 would refer to the same PvD. 389 While resolving names, executing the default address selection 390 algorithm [RFC6724] or executing the default router selection 391 algorithm when forwarding packets ([RFC2461], [RFC4191] and 393 [RFC8028]), hosts and applications MAY consider only the 394 configuration associated with an arbitrary set of PvDs. 396 For example, a host MAY associate a given process with a specific 397 PvD, or a specific set of PvDs, while associating another process 398 with another PvD. A PvD-aware application might also be able to 399 select, on a per-connection basis, which PvDs should be used. In 400 particular, constrained devices such as small battery operated 401 devices (e.g. IoT), or devices with limited CPU or memory resources 402 may purposefully use a single PvD while ignoring some received RAs 403 containing different PvD IDs. 405 The way an application expresses its desire to use a given PvD, or a 406 set of PvDs, or the way this selection is enforced, is out of the 407 scope of this document. Useful insights about these considerations 408 can be found in [I-D.kline-mif-mpvd-api-reqs]. 410 3.4.1. DHCPv6 configuration association 412 When a host retrieves stateless configuration elements using DHCPv6 413 (e.g., DNS recursive resolvers or DNS domain search lists [RFC3646]), 414 they MUST be associated with all the explicit and implicit PvDs 415 received on the same interface and contained in a RA with the O-flag 416 set [RFC4861]. 418 When a host retrieves stateful assignments using DHCPv6, such 419 assignments MUST be associated with the received PvD which was 420 received with RAs with the M-flag set and including a matching PIO. 421 A PIO is considered to match a DHCPv6 assignment when the IPv6 prefix 422 from the PIO includes the assignment from DHCPv6. For example, if a 423 PvD's associated PIO defines the prefix 2001:db8:cafe::/64, a DHCPv6 424 IA_NA message that assigns the address 2001:db8:cafe::1234:4567 would 425 be considered to match. 427 In cases where an address would be assigned by DHCPv6 and no matching 428 PvD could be found, hosts MAY associate the assigned address with any 429 implicit PvD received on the same interface or to multiple of 430 implicit PvD received on the same interface. This is intended to 431 resolve backward compatibility issues with rare deployments choosing 432 to assign addresses with DHCPv6 while not sending any matching PIO. 434 3.4.2. DHCPv4 configuration association 436 Associating DHCPv4 [RFC2131] configuration elements with Explicit 437 PvDs allows hosts to treat a set of IPv4 and IPv6 configurations as a 438 single PvD with shared properties. For example, consider a router 439 that provides two different uplinks. One could be a broadband 440 network that has data rate and streaming properties described in PvD 441 additional information and that provides both IPv4 and IPv6 network 442 access. The other could be a cellular network that provides only 443 IPv6 network access, and uses NAT64 [RFC6146]. The broadband network 444 can be represented by an Explicit PvD that points to the additional 445 information, and also marks association with DHCPv4 information. The 446 cellular network can be represented by a different Explicit PvD that 447 is not associated with DHCPv4. 449 When a PvD-aware host retrieves configuration elements from DHCPv4, 450 the information is associated either with a single Explicit PvD on 451 that interface, or else with all Implicit PvDs on the same interface. 453 An Explicit PvD indicates its association with DHCPv4 information by 454 setting the L-flag in the PvD RA Option. If there is exactly one 455 Explicit PvD that sets this flag, hosts MUST associate the DHCPv4 456 information with that PvD. Multiple Explicit PvDs on the same 457 interface marking this flag is a misconfiguration, and hosts SHOULD 458 NOT associate the DHCPv4 information with any Explicit PvD in this 459 case. 461 If no single Explicit PvD claims association with DHCPv4, the 462 configuration elements coming from DHCPv4 MUST be associated with the 463 all Implicit PvDs identified by the interface on which the DHCPv4 464 transaction happened. This maintains existing host behavior. 466 3.4.3. Connection Sharing by the Host 468 The situation when a host shares connectivity from an upstream 469 interface (e.g. cellular) to a downstream interface (e.g. Wi-Fi) is 470 known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share 471 [RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC8415]) may 472 be used for that purpose. 474 Whenever the RAs received from the upstream interface contain a PVD 475 RA option, hosts that are sharing connectivity SHOULD include a PVD 476 option within the RAs sent downstream with: 478 o The same PVD-ID FQDN 480 o The same H-bit, Delay and Sequence Number values 482 o The L bit set whenever the host is sharing IPv4 connectivity 483 received from the same upstream interface 485 o The bits from the Reserved field set to 0 487 The values of the R-bit, Router Advertisement message header and 488 Options field depend on whether the connectivity should be shared 489 only with PvD-aware hosts or not (see Section 3.2). In particular, 490 all options received within the upstream PvD Option and included in 491 the downstream RA SHOULD be included in the downstream PvD Option. 493 3.4.4. Usage of DNS Servers 495 PvD-aware hosts can be provisioned with recursive DNS servers via RA 496 options passed within an Explicit PvD, via RA options associated with 497 an Implicit PvD, via DHCPv6 or DHCPv4, or from some other 498 provisioning mechanism that creates an Implicit PvD (such as a VPN). 499 In all of these cases, the DNS server addresses SHOULD be associated 500 with the corresponding PvD. Specifically, queries sent to a 501 configured recursive DNS server SHOULD be sent from a local IP 502 address that was provisioned by the PvD via RA or DHCP. Answers 503 received from the DNS server SHOULD only be used on the same PvD. 505 PvD-aware applications will be able to select which PvD(s) to use for 506 DNS resolution and connections, which allows them to effectively use 507 multiple Explicit PvDs. In order to support non-PvD-aware 508 applications, however, PvD-aware hosts SHOULD ensure that non-PvD- 509 aware name resolution APIs like "getaddrinfo" only use resolvers from 510 a single PvD for each query. More discussion is provided in 511 Section 5.2.1 of [RFC7556]. 513 Maintaining the correct usage of DNS within PvDs avoids various 514 practical errors, such as: 516 o A PvD associated with a VPN or otherwise private network may 517 provide DNS answers that contain addresses inaccessible over 518 another PvD. 520 o A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will 521 synthesize IPv6 addresses in DNS answers that are not globally 522 routable, and would be invalid on other PvDs. Conversely, an IPv4 523 address resolved via DNS on another PvD cannot be directly used on 524 a NAT64 network. 526 4. Provisioning Domain Additional Information 528 Additional information about the network characteristics can be 529 retrieved based on the PvD ID. This set of information is called PvD 530 Additional Information, and is encoded as a JSON object [RFC7159]. 531 This JSON object is restricted to the restricted profile of I-JSON, 532 as defined in [RFC7493]. 534 The purpose of this JSON object is to provide additional information 535 to applications on a client host about the connectivity that is 536 provided using a given interface and source address. It typically 537 includes data that would be considered too large, or not critical 538 enough, to be provided within an RA option. The information 539 contained in this object MAY be used by the operating system, network 540 libraries, applications, or users, in order to decide which set of 541 PvDs should be used for which connection, as described in 542 Section 3.4. 544 The additional information related to a PvD is specifically intended 545 to be optional, and is targeted at optimizing or informing the 546 behavior of user-facing hosts. This information can be extended to 547 provide hints for host system behavior (such as captive portal or 548 walled-garden PvD detection) or application behavior (describing 549 application-specific services offered on a given PvD). This content 550 may not be appropriate for light-weight Internet of Things (IoT) 551 devices. IoT devices might need only a subset of the information, 552 and would in some cases prefer a smaller representation like CBOR 553 ([RFC7049]). Delivering a reduced version of the PvD Additional 554 Information designed for such devices is not defined in this 555 document. 557 4.1. Retrieving the PvD Additional Information 559 When the H-flag of the PvD Option is set, hosts MAY attempt to 560 retrieve the PvD Additional Information associated with a given PvD 561 by performing an HTTP over TLS [RFC2818] GET query to https:///.well-known/pvd [RFC5785]. Inversely, hosts MUST NOT do so 563 whenever the H-flag is not set. 565 HTTP requests and responses for PvD additional information use the 566 "application/pvd+json" media type (see Section 8). Clients SHOULD 567 include this media type as an Accept header in their GET requests, 568 and servers MUST mark this media type as their Content-Type header in 569 responses. 571 Note that the DNS name resolution of the PvD ID, the PKI (Public Key 572 Infrastructure) checks as well as the actual query MUST be performed 573 using the considered PvD. In other words, the name resolution, PKI 574 checks, source address selection, as well as the next-hop router 575 selection MUST be performed while using exclusively the set of 576 configuration information attached with the PvD, as defined in 577 Section 3.4. In some cases, it may therefore be necessary to wait 578 for an address to be available for use (e.g., once the Duplicate 579 Address Detection or DHCPv6 processes are complete) before initiating 580 the HTTP over TLS query. If the host has a temporary address per 581 [RFC4941] in this PvD, then hosts SHOULD use a temporary address to 582 fetch the PvD Additional Information and SHOULD deprecate the used 583 temporary address and generate a new temporary address afterward. 585 If the HTTP status of the answer is greater than or equal to 400 the 586 host MUST abandon and consider that there is no additional PvD 587 information. If the HTTP status of the answer is between 300 and 588 399, inclusive, it MUST follow the redirection(s). If the HTTP 589 status of the answer is between 200 and 299, inclusive, the host MAY 590 get a file containing a single JSON object. 592 After retrieval of the PvD Additional Information, hosts MUST 593 remember the last Sequence Number value received in the RA including 594 the same PvD ID. Whenever a new RA for the same PvD is received with 595 a different Sequence Number value, or whenever the expiry date for 596 the additional information is reached, hosts MUST deprecate the 597 additional information and stop using it until a new JSON object is 598 retrieved. 600 Hosts retrieving a new PvD Additional Information object MUST check 601 for the presence and validity of the mandatory fields specified in 602 Section 4.3. A retrieved object including an expiration time that is 603 already past or missing a mandatory element MUST be ignored. 605 In order to avoid synchronized queries toward the server hosting the 606 PvD Additional Information when an object expires, object updates are 607 delayed by a randomized backoff time. 609 o When a host performs a JSON object update after it detected a 610 change in the PvD Option Sequence Number, it MUST add a delay 611 before sending the query. The target time for the delay is 612 calculated as a random time between zero and 2**(Delay * 2) 613 milliseconds, where 'Delay' corresponds to the 4-bit unsigned 614 integer in the last received PvD Option. 616 o When a host last retrieved a JSON object at time A that includes a 617 expiry time B using the "expires" key, and the host is configured 618 to keep the PvD information up to date, it MUST add some 619 randomness into its calculation of the time to fetch the update. 620 The target time for fetching the updated object is calculated as a 621 uniformly random time in the interval [(B-A)/2,B]. 623 In the example Figure 2, the delay field value is 5, this means that 624 host calculates its delay by choosing a random number between 0 and 625 2**(5 * 2) milliseconds, i.e., between 0 and 1024 milliseconds. 627 Since the 'Delay' value is directly within the PvD Option rather than 628 the object itself, an operator may perform a push-based update by 629 incrementing the Sequence value while changing the Delay value 630 depending on the criticality of the update and its PvD Additional 631 Information servers capacity. 633 The PvD Additional Information object includes a set of IPv6 prefixes 634 (under the key "prefixes") which MUST be checked against all the 635 Prefix Information Options advertised in the RA. If any of the 636 prefixes included in the PIO is not covered by at least one of the 637 listed prefixes, the associated PvD information MUST be considered to 638 be a misconfiguration, and MUST NOT be used by the host. See 639 Section 4.4 for more discussion on handling such misconfigurations. 641 4.2. Operational Consideration to Providing the PvD Additional 642 Information 644 Whenever the H-flag is set in the PvD Option, a valid PvD Additional 645 Information object MUST be made available to all hosts receiving the 646 RA by the network operator. In particular, when a captive portal is 647 present, hosts MUST still be allowed to perform DNS, PKI and HTTP 648 over TLS operations related to the retrieval of the object, even 649 before logging into the captive portal. 651 Routers SHOULD increment the PVD Option Sequence Number by one 652 whenever a new PvD Additional Information object is available and 653 should be retrieved by hosts. If the value exceeds what can be 654 stored in the Sequence Number field, it SHOULD wrap back to zero. 656 The server providing the JSON files SHOULD also check whether the 657 client address is part of the prefixes listed into the additional 658 information and SHOULD return a 403 response code if there is no 659 match. 661 4.3. PvD Additional Information Format 663 The PvD Additional Information is a JSON object. 665 The following table presents the mandatory keys which MUST be 666 included in the object: 668 +------------+-----------------+-----------+------------------------+ 669 | JSON key | Description | Type | Example | 670 +------------+-----------------+-----------+------------------------+ 671 | identifier | PvD ID FQDN | String | "pvd.example.com." | 672 | | | | | 673 | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | 674 | | which this | Date | | 675 | | object is no | | | 676 | | longer valid | | | 677 | | | | | 678 | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | 679 | | prefixes valid | strings | "2001:db8:4::/48"] | 680 | | for this PvD | | | 681 +------------+-----------------+-----------+------------------------+ 683 A retrieved object which does not include all three of these keys at 684 the root of the JSON object MUST be ignored. All three keys need to 685 be validated, otherwise the object MUST be ignored. The value stored 686 for "identifier" MUST be matched against the PvD ID FQDN presented in 687 the PvD RA option using the comparison mechanism described in 688 Section 3.4. The value stored for "expires" MUST be a valid date in 689 the future. If the PIO of the received RA is not covered by at least 690 one of the "prefixes" key, the retrieved object SHOULD be ignored. 692 The following table presents some optional keys which MAY be included 693 in the object. 695 +------------+----------------------+----------+--------------------+ 696 | JSON key | Description | Type | Example | 697 +------------+----------------------+----------+--------------------+ 698 | dnsZones | DNS zones searchable | Array of | ["example.com", | 699 | | and accessible | strings | "sub.example.com"] | 700 | | | | | 701 | noInternet | No Internet, set | Boolean | true | 702 | | when the PvD is | | | 703 | | restricted. | | | 704 +------------+----------------------+----------+--------------------+ 706 It is worth noting that the JSON format allows for extensions. 707 Whenever an unknown key is encountered, it MUST be ignored along with 708 its associated elements. 710 Private-use or experimental keys MAY be used in the JSON dictionary. 711 In order to avoid such keys colliding with IANA registry keys, 712 implementers or vendors defining private-use or experimental keys 713 MUST create sub-dictionaries, where the sub-dictionary is added into 714 the top-level JSON dictionary with a key of the format "vendor-*" 715 where the "*" is replaced by the implementer's or vendor's 716 identifier. For example, keys specific to the FooBar organization 717 could use "vendor-foobar". Upon receiving such a sub-dictionary, 718 host MUST ignore this sub-dictionary if it is unknown. When the 719 vendor or implementer is part of an IANA URN namespace [URN], the URN 720 namespace SHOULD be used rather than the "vendor-*" format. 722 4.3.1. Example 724 The following two examples show how the JSON keys defined in this 725 document can be used: 727 { 728 "identifier": "cafe.example.com", 729 "expires": "2017-07-23T06:00:00Z", 730 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 731 } 733 { 734 "identifier": "company.foo.example.com", 735 "expires": "2017-07-23T06:00:00Z", 736 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 737 "vendor-foo": { "private-key": "private-value" }, 738 } 740 4.4. Detecting misconfiguration and misuse 742 When a host retrieves the PvD Additional Information, it MUST verify 743 that the TLS server certificate is valid for the performed request 744 (e.g., that the Subject Name is equal to the PvD ID expressed as an 745 FQDN). This authentication creates a secure binding between the 746 information provided by the trusted Router Advertisement, and the 747 HTTPS server. However, this does not mean the Advertising Router and 748 the PvD server belong to the same entity. 750 Hosts MUST verify that all prefixes in the RA PIO are covered by a 751 prefix from the PvD Additional Information. An adversarial router 752 attempting to spoof the definition of an Explicit PvD, without the 753 ability to modify the PvD Additional Information, would need to 754 perform NAT66 in order to circumvent this check. Thus, this check 755 cannot prevent all spoofing, but it can detect misconfiguration or 756 mismatched routers that are not adding a NAT. 758 If NAT66 is being added in order to spoof PvD ownership, the HTTPS 759 server for additional information can detect this misconfiguration. 760 The HTTPS server SHOULD validate the source addresses of incoming 761 connections (see Section 4.1). This check gives reasonable assurance 762 that neither NPTv6 [RFC6296] nor NAT66 were used and restricts the 763 information to the valid network users. If the PvD does not 764 provision IPv4 (it does not include the 'L' bit in the RA), the 765 server cannot validate the source addresses of connections using 766 IPv4. Thus, the PvD ID FQDN for such PvDs SHOULD NOT have a DNS A 767 record. 769 5. Operational Considerations 771 This section describes some example use cases of PvD. For the sake 772 of simplicity, the RA messages will not be described in the usual 773 ASCII art but rather in an indented list. 775 5.1. Exposing Extra RA Options to PvD-Aware Hosts 777 In this example, there is one RA message sent by the router. This 778 message contains some options applicable to all hosts on the network, 779 and also a PvD Option that also contains other options only visible 780 to PvD-aware hosts. 782 o RA Header: router lifetime = 6000 784 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 786 o PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN = 787 example.org., R-flag = 0 (actual length of the header with padding 788 24 bytes = 3 * 8 bytes) 790 * Recursive DNS Server: length = 5, addresses = 791 [2001:db8:cafe::53, 2001:db8:f00d::53] 793 * Prefix Information Option: length = 4, prefix = 794 2001:db8:f00d::/64 796 Note that a PvD-aware host will receive two different prefixes, 797 2001:db8:cafe::/64 and 2001:db8:f00d::/64, both associated with the 798 same PvD (identified by "example.org."). A non-PvD-aware host will 799 only receive one prefix, 2001:db8:cafe::/64. 801 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts 803 It is expected that for some years, networks will have a mixed 804 environment of PvD-aware hosts and non-PvD-aware hosts. If there is 805 a need to give specific information to PvD-aware hosts only, then it 806 is recommended to send two RA messages (one for each class of hosts). 807 For example, here is the RA sent for non-PvD-aware hosts: 809 o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use 810 this router as a default router) 812 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 814 o Recursive DNS Server Option: length = 3, addresses= 815 [2001:db8:cafe::53] 817 o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., 818 R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) 820 * RA Header: router lifetime = 0 (PvD-aware hosts will not use 821 this router as a default router), implicit length = 2 823 And here is the RA sent for PvD-aware hosts: 825 o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use 826 this router as a default router) 828 o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = 829 bar.example.org., R-flag = 1 (actual length of the header 24 bytes 830 = 3 * 8 bytes) 832 * RA Header: router lifetime = 1600 (PvD-aware hosts will use 833 this router as a default router), implicit length = 2 835 * Prefix Information Option: length = 4, prefix = 836 2001:db8:f00d::/64 838 * Recursive DNS Server Option: length = 3, addresses = 839 [2001:db8:f00d::53] 841 In the above example, non-PvD-aware hosts will only use the first RA 842 sent from their default router and using the 2001:db8:cafe::/64 843 prefix. PvD-aware hosts will autonomously configure addresses from 844 both PIOs, but will only use the source address in 2001:db8:f00d::/64 845 to communicate past the first hop router since only the router 846 sending the second RA will be used as default router; similarly, they 847 will use the DNS server 2001:db8:f00d::53 when communicating with 848 this address. 850 5.3. Enabling Multi-homing for PvD-Aware Hosts 852 In this example, the goal is to have one prefix from one RA be usable 853 by both non-PvD-aware and PvD-aware hosts; and to have another prefix 854 usable only by PvD-aware hosts. This allows PvD-aware hosts to be 855 able to effectively multi-home on the network. 857 The first RA is usable by all hosts. The only difference for PvD- 858 aware hosts is that they can explicitly identify the PvD ID 859 associated with the RA. PvD-aware hosts will also use this prefix to 860 communicate with non-PvD-aware hosts on the same network. 862 o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use 863 this router as a default router) 865 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 867 o Recursive DNS Server Option: length = 3, addresses= 868 [2001:db8:cafe::53] 870 o PvD Option header: length = 3, PvD ID FQDN = foo.example.org., 871 R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes) 873 The second RA contains a prefix usable only by PvD-aware hosts. Non- 874 PvD-aware hosts will ignore this RA. 876 o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use 877 this router as a default router) 879 o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = 880 bar.example.org., R-flag = 1 (actual length of the header 24 bytes 881 = 3 * 8 bytes) 883 * RA Header: router lifetime = 1600 (PvD-aware hosts will use 884 this router as a default router), implicit length = 2 886 * Prefix Information Option: length = 4, prefix = 887 2001:db8:f00d::/64 889 * Recursive DNS Server Option: length = 3, addresses = 890 [2001:db8:f00d::53] 892 6. Security Considerations 894 Although some solutions such as IPsec or SeND [RFC3971] can be used 895 in order to secure the IPv6 Neighbor Discovery Protocol, in practice 896 actual deployments largely rely on link layer or physical layer 897 security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA 898 Guard [RFC6105]. 900 This specification does not improve the Neighbor Discovery Protocol 901 security model, but extends the purely link-local trust relationship 902 between the host and the default routers with HTTP over TLS 903 communications which servers are authenticated as rightful owners of 904 the FQDN received within the trusted PvD ID RA option. 906 It must be noted that Section 4.4 of this document only provides 907 reasonable assurance against misconfiguration but does not prevent an 908 hostile network access provider to advertise wrong information that 909 could lead applications or hosts to select a hostile PvD. 911 Users cannot be assumed to be able to meaningfully differentiate 912 between "safe" and "unsafe" networks. This is a known attack surface 913 that is present whether or not PvDs are in use, and hence cannot be 914 addressed by this document. However, a host that correctly 915 implements the MPvD architecture ([RFC7556]) using the mechanism 916 described in this document will be less susceptible to such attacks 917 than a host that does not by being able to check for the various 918 misconfigurations described in this document. 920 7. Privacy Considerations 922 Retrieval of the PvD Additional Information over HTTPS requires early 923 communications between the connecting host and a server which may be 924 located further than the first hop router. Although this server is 925 likely to be located within the same administrative domain as the 926 default router, this property can't be ensured. Therefore, hosts 927 willing to retrieve the PvD Additional Information before using it 928 without leaking identity information, SHOULD make use of an IPv6 929 Privacy Address and SHOULD NOT include any privacy sensitive data, 930 such as User Agent header or HTTP cookie, while performing the HTTP 931 over TLS query. 933 From a privacy perspective, retrieving the PvD Additional Information 934 is not different from establishing a first connection to a remote 935 server, or even performing a single DNS lookup. For example, most 936 operating systems already perform early queries to well known web 937 sites, such as http://captive.example.com/hotspot-detect.html, in 938 order to detect the presence of a captive portal. 940 There may be some cases where hosts, for privacy reasons, should 941 refrain from accessing servers that are located outside a certain 942 network boundary. In practice, this could be implemented as a 943 whitelist of 'trusted' FQDNs and/or IP prefixes that the host is 944 allowed to communicate with. In such scenarios, the host SHOULD 945 check that the provided PvD ID, as well as the IP address that it 946 resolves into, are part of the allowed whitelist. 948 8. IANA Considerations 950 Upon publication of this document, IANA is asked to remove the 951 'reclaimable' tag off the value 21 for the PvD Option (from the IPv6 952 Neighbor Discovery Option Formats registry). 954 IANA is asked to assign the value "pvd" from the Well-Known URIs 955 registry. 957 8.1. Additional Information PvD Keys Registry 959 IANA is asked to create and maintain a new registry called 960 "Additional Information PvD Keys", which will reserve JSON keys for 961 use in PvD additional information. The initial contents of this 962 registry are given in Section 4.3. 964 New assignments for Additional Information PvD Keys Registry will be 965 administered by IANA through Expert Review [RFC8126]. 967 8.2. PvD Option Flags Registry 969 IANA is also asked to create and maintain a new registry entitled 970 "PvD Option Flags" reserving bit positions from 0 to 15 to be used in 971 the PvD Option bitmask. Bit position 0, 1 and 2 are reserved by this 972 document (as specified in Figure 1). Future assignments require 973 Standards Action [RFC8126], via a Standards Track RFC document. 975 8.3. PvD JSON Media Type Registration 977 This document registers the media type for PvD JSON text, 978 "application/pvd+json". 980 Type Name: application 982 Subtype Name: pvd+json 984 Required parameters: None 986 Optional parameters: None 988 Encoding considerations: Encoding considerations are identical to 989 those specified for the "application/json" media type. 991 Security considerations: See Section 6. 993 Interoperability considerations: This document specifies format of 994 conforming messages and the interpretation thereof. 996 Published specification: This document 998 Applications that use this media type: This media type is intended to 999 be used by network advertising additional Provisioning Domain 1000 information, and clients looking up such information. 1002 Additional information: None 1004 Person and email address to contact for further information: See 1005 Authors' Addresses section 1007 Intended usage: COMMON 1009 Restrictions on usage: None 1011 Author: IETF 1013 Change controller: IETF 1015 9. Acknowledgments 1017 Many thanks to M. Stenberg and S. Barth for their earlier work: 1018 [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was 1019 author of an early version of this document. 1021 Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen 1022 Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, 1023 Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted 1024 Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst, 1025 Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for 1026 useful and interesting discussions and reviews. 1028 Finally, special thanks to Thierry Danis and Wenqin Shao for their 1029 valuable inputs and implementation efforts, Tom Jones for his 1030 integration effort into the NEAT project and Rigil Salim for his 1031 implementation work. 1033 10. References 1035 10.1. Normative References 1037 [RFC1035] Mockapetris, P., "Domain names - implementation and 1038 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1039 November 1987, . 1041 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1042 Discovery for IP Version 6 (IPv6)", RFC 2461, 1043 DOI 10.17487/RFC2461, December 1998, 1044 . 1046 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1047 DOI 10.17487/RFC2818, May 2000, 1048 . 1050 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1051 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1052 DOI 10.17487/RFC3646, December 2003, 1053 . 1055 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 1056 Insensitivity Clarification", RFC 4343, 1057 DOI 10.17487/RFC4343, January 2006, 1058 . 1060 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1061 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1062 DOI 10.17487/RFC4861, September 2007, 1063 . 1065 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1066 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1067 2014, . 1069 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 1070 DOI 10.17487/RFC7493, March 2015, 1071 . 1073 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1074 Writing an IANA Considerations Section in RFCs", BCP 26, 1075 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1076 . 1078 10.2. Informative References 1080 [I-D.kline-mif-mpvd-api-reqs] 1081 Kline, E., "Multiple Provisioning Domains API 1082 Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in 1083 progress), November 2015. 1085 [I-D.stenberg-mif-mpvd-dns] 1086 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 1087 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 1088 (work in progress), October 2015. 1090 [IEEE8021X] 1091 "IEEE Standards for Local and Metropolitan Area Networks, 1092 Port-based Network Access Control, IEEE Std", n.d.. 1094 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1095 Requirement Levels", BCP 14, RFC 2119, 1096 DOI 10.17487/RFC2119, March 1997, 1097 . 1099 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1100 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1101 . 1103 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1104 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1105 . 1107 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1108 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1109 DOI 10.17487/RFC3971, March 2005, 1110 . 1112 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1113 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1114 November 2005, . 1116 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1117 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 1118 2006, . 1120 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1121 Extensions for Stateless Address Autoconfiguration in 1122 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1123 . 1125 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1126 Uniform Resource Identifiers (URIs)", RFC 5785, 1127 DOI 10.17487/RFC5785, April 2010, 1128 . 1130 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1131 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1132 DOI 10.17487/RFC6105, February 2011, 1133 . 1135 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1136 NAT64: Network Address and Protocol Translation from IPv6 1137 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1138 April 2011, . 1140 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1141 Beijnum, "DNS64: DNS Extensions for Network Address 1142 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1143 DOI 10.17487/RFC6147, April 2011, 1144 . 1146 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1147 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1148 . 1150 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1151 "Default Address Selection for Internet Protocol Version 6 1152 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1153 . 1155 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1156 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1157 October 2013, . 1159 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1160 /64 Prefix from a Third Generation Partnership Project 1161 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 1162 DOI 10.17487/RFC7278, June 2014, 1163 . 1165 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 1166 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 1167 . 1169 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1170 Hosts in a Multi-Prefix Network", RFC 8028, 1171 DOI 10.17487/RFC8028, November 2016, 1172 . 1174 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1175 "IPv6 Router Advertisement Options for DNS Configuration", 1176 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1177 . 1179 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1180 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1181 May 2017, . 1183 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1184 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1185 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1186 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1187 . 1189 [URN] "URN Namespaces", n.d.. 1191 Authors' Addresses 1193 Pierre Pfister 1194 Cisco 1195 11 Rue Camille Desmoulins 1196 Issy-les-Moulineaux 92130 1197 France 1199 Email: ppfister@cisco.com 1201 Eric Vyncke 1202 Cisco 1203 De Kleetlaan, 6 1204 Diegem 1831 1205 Belgium 1207 Email: evyncke@cisco.com 1209 Tommy Pauly 1210 Apple Inc. 1211 One Apple Park Way 1212 Cupertino, California 95014 1213 United States of America 1215 Email: tpauly@apple.com 1217 David Schinazi 1218 Google LLC 1219 1600 Amphitheatre Parkway 1220 Mountain View, California 94043 1221 United States of America 1223 Email: dschinazi.ietf@gmail.com 1225 Wenqin Shao 1226 Cisco 1227 11 Rue Camille Desmoulins 1228 Issy-les-Moulineaux 92130 1229 France 1231 Email: wenshao@apple.com