idnits 2.17.1 draft-ietf-intarea-provisioning-domains-02.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 (June 4, 2018) is 2147 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) == Missing Reference: 'BCP36' is mentioned on line 748, but not defined == Unused Reference: 'RFC6731' is defined on line 875, but no explicit reference was found in the text ** 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) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea P. Pfister 3 Internet-Draft E. Vyncke, Ed. 4 Intended status: Standards Track Cisco 5 Expires: December 6, 2018 T. Pauly 6 D. Schinazi 7 Apple 8 W. Shao 9 Telecom-ParisTech 10 June 4, 2018 12 Discovering Provisioning Domain Names and Data 13 draft-ietf-intarea-provisioning-domains-02 15 Abstract 17 An increasing number of hosts access the Internet via multiple 18 interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix 19 configurations context. 21 This document describes a way for hosts to identify such contexts, 22 called Provisioning Domains (PvDs), where Fully Qualified Domain 23 Names (FQDNs) act as PvD identifiers. Those identifiers are 24 advertised in a new Router Advertisement (RA) option and, when 25 present, are associated with the set of information included within 26 the RA. 28 Based on this FQDN, hosts can retrieve additional information about 29 their network access characteristics via an HTTP over TLS query. 30 This allows applications to select which Provisioning Domains to use 31 as well as to provide configuration parameters to the transport layer 32 and above. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Provisioning Domain Identification using Router 70 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4 72 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 73 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8 74 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8 75 3.4.1. DHCPv6 configuration association . . . . . . . . . . 9 76 3.4.2. DHCPv4 configuration association . . . . . . . . . . 9 77 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9 78 4. Provisioning Domain Additional Information . . . . . . . . . 10 79 4.1. Retrieving the PvD Additional Information . . . . . . . . 10 80 4.2. Operational Consideration to Providing the PvD Additional 81 Information . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.3. PvD Additional Information Format . . . . . . . . . . . . 12 83 4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 13 84 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14 86 5. Operational Considerations . . . . . . . . . . . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 10.1. Normative references . . . . . . . . . . . . . . . . . . 18 93 10.2. Informative references . . . . . . . . . . . . . . . . . 19 94 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 20 95 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 20 96 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 20 97 A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 21 98 A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22 99 A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 22 100 A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 It has become very common in modern networks for hosts to access the 106 internet through different network interfaces, tunnels, or next-hop 107 routers. To describe the set of network configurations associated 108 with each access method, the concept of Provisioning Domain (PvD) was 109 defined in [RFC7556]. 111 This document specifies a way to identify PvDs with Fully Qualified 112 Domain Names (FQDN), called PvD IDs. Those identifiers are 113 advertised in a new Router Advertisement (RA) [RFC4861] option called 114 the PvD ID Router Advertisement option which, when present, 115 associates the PvD ID with all the information present in the Router 116 Advertisement as well as any configuration object, such as addresses, 117 deriving from it. The PVD ID Router Advertisement option may also 118 contain a set of other RA options. Since such options are only 119 considered by hosts implementing this specification, network 120 operators may configure hosts that are 'PvD-aware' with PvDs that are 121 ignored by other hosts. 123 Since PvD IDs are used to identify different ways to access the 124 internet, multiple PvDs (with different PvD IDs) could be provisioned 125 on a single host interface. Similarly, the same PvD ID could be used 126 on different interfaces of a host in order to inform that those PvDs 127 ultimately provide identical services. 129 This document also introduces a way for hosts to retrieve additional 130 information related to a specific PvD by means of an HTTP over TLS 131 query using an URI derived from the PvD ID. The retrieved JSON 132 object contains additional information that would typically be 133 considered unfit, or too large, to be directly included in the Router 134 Advertisement, but might be considered useful to the applications, or 135 even sometimes users, when choosing which PvD should be used. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 [RFC2119]. 144 In addition, this document uses the following terminology: 146 Provisioning Domain (PvD): A set of network configuration 147 information; for more information, see [RFC7556]. 149 PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a 150 PvD. 152 Explicit PvD: A PvD uniquely identified with a PvD ID. For more 153 information, see [RFC7556]. 155 Implicit PvD: A PvD that, in the absence of a PvD ID, is identified 156 by the host interface to which it is attached and the address of 157 the advertising router. See also [RFC7556]. 159 PvD-aware host A host that supports the association of network 160 configuration information into PvDs and the use of these PvDs. 161 Also named PvD-aware node in [RFC7556]. 163 3. Provisioning Domain Identification using Router Advertisements 165 Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully 166 Qualified Domain Name (FQDN) which MUST belong to the network 167 operator in order to avoid naming collisions. The same PvD ID MAY be 168 used in several access networks when they ultimately provide 169 identical services (e.g., in all home networks subscribed to the same 170 service); else, the PvD ID MUST be different to follow section 2.4 of 171 [RFC7556]. 173 3.1. PvD ID Option for Router Advertisements 175 This document introduces a Router Advertisement (RA) option called 176 PvD option. It is used to convey the FQDN identifying a given PvD 177 (see Figure 1), bind the PvD ID with configuration information 178 received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over 179 TLS to retrieve the PvD Additional Information JSON object (see 180 Section 4), as well as contain any other RA options which would 181 otherwise be valid in the RA. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length |H|L|R| Reserved | Delay | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Sequence Number | ... 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 190 ... PvD ID FQDN ... 191 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 ... | Padding | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | ... 195 ... Router Advertisement message header ... 196 ... (Only present when R-flag is set) ... 197 ... | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Options ... 200 +-+-+-+-+-+-+-+-+-+-+-+- 202 Figure 1: PvD ID Router Advertisements Option format 204 Type : (8 bits) Set to 21. 206 Length : (8 bits) The length of the option in units of 8 207 octets, including the Type and Length fields, the Router 208 Advertisement message header, if any, as well as the RA options 209 that are included within the PvD Option. 211 H-flag : (1 bit) 'HTTP' flag stating whether some PvD 212 Additional Information is made available through HTTP over TLS, as 213 described in Section 4. 215 L-flag : (1 bit) 'Legacy' flag stating whether the router is 216 also providing IPv4 information using DHCPv4 (see Section 3.4.2). 218 R-flag : (1 bit) 'Router Advertisement' flag stating whether 219 the PvD Option is followed (right after padding to the next 64 220 bits boundary) by a Router Advertisement message header (See 221 section 4.2 of [RFC4861]). 223 Delay : (4 bits) Unsigned integer used to delay HTTP GET 224 queries from hosts by a randomized backoff (see Section 4.1). 226 Reserved : (13 bits) Reserved for later use. It MUST be set to 227 zero by the sender and ignored by the receiver. 229 Sequence Number: (16 bits) Sequence number for the PvD Additional 230 Information, as described in Section 4. 232 PvD ID FQDN : The FQDN used as PvD ID encoded in DNS format, as 233 described in Section 3.1 of [RFC1035]. Domain names compression 234 described in Section 4.1.4 of [RFC1035] MUST NOT be used. 236 Padding : Zero or more padding octets to the next 8 octets 237 boundary. It MUST be set to zero by the sender, and ignored by 238 the receiver. 240 RA message header : (16 octets) When the R-flag is set, a full 241 Router Advertisement message header as specified in [RFC4861]. 242 The 'Type', 'Code' and 'Checksum' fields (i.e. the first 32 bits), 243 MUST be set to zero by the sender and ignored by the receiver. 244 The other fields are to be set and parsed as specified in 245 [RFC4861] or any updating documents. 247 Options : Zero or more RA options that would otherwise be valid as 248 part of the Router Advertisement main body, but are instead 249 included in the PvD Option such as to be ignored by hosts that are 250 not 'PvD-aware'. 252 Here is an example of a PvD option with example.org as the PvD ID 253 FQDN and including a RDNSS and prefix information options (it also 254 have the sequence number 123, presence of additional information to 255 be fetched with a delay indicated as 5): 257 0 1 2 3 258 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 259 +---------------+-----------------------------------------------+ 260 | Type: 21 | Length: 12 |1|0|0| Reserved |Delay:5| 261 +---------------+-------------------------------+---------------+ 262 | Seq number: 123 | 7 | e | 263 +---------------+-----------------------------------------------+ 264 | x | a | m | p | 265 +---------------------------------------------------------------+ 266 | l | e | 3 | o | 267 +---------------------------------------------------------------+ 268 | r | g | 0 | 0 (padding) | 269 +---------------------------------------------------------------+ 270 | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | 271 +---------------+---------------+---------------+---------------+ 272 | RDNSS option (RFC 6106) length: 5 ... 273 ... ... 274 ... | 275 +---------------------------------------------------------------+ 276 | Prefix Information Option (RFC 4861) length: 4 ... 277 ... | 278 ... | 279 +---------------------------------------------------------------+ 281 Figure 2 283 3.2. Router Behavior 285 A router MAY send RAs containing one PvD option, but MUST NOT include 286 more than one PvD option in each RA. In particular, the PvD option 287 MUST NOT contain further PvD options. 289 The PvD Option MAY contain zero, one, or more RA options which would 290 otherwise be valid as part of the same RA. Such options are 291 processed by PvD-aware hosts, while ignored by others. 293 In order to provide multiple different PvDs, a router MUST send 294 multiple RAs. Different explicit PvDs MAY be advertised with RAs 295 using the same IPv6 source address; but different implicit PvDs, 296 advertised by different RAs, MUST use different link-local addresses 297 because these implicit PvDs are identified by the source addresses of 298 the RAs. 300 Whenever an RA, for a single PvD, would need to be sent via multiple 301 packets, the PvD option header (i.e., all fields except the 'Options' 302 field) MUST be repeated in all the transmitted RAs. But the options 303 within the 'Options' field, MAY be transmitted only once, included in 304 one of the transmitted PvD options. 306 3.3. Non-PvD-aware Host Behavior 308 As the PvD Option has a new option code, non-PvD-aware hosts will 309 simply ignore the PvD Option and all the options it contains. This 310 ensure the backward compatibility required in section 3.3 of 311 [RFC7556]. This behavior allows for a mixed-mode network with a mix 312 of PvD-aware and non-PvD-aware hosts coexist. 314 3.4. PvD-aware Host Behavior 316 Hosts MUST associate received RAs and included configuration 317 information (e.g., Router Valid Lifetime, Prefix Information 318 [RFC4861], Recursive DNS Server [RFC8106], Routing Information 319 [RFC4191] options) with the explicit PvD identified by the first PvD 320 Option present in the received RA, if any, or with the implicit PvD 321 identified by the host interface and the source address of the 322 received RA otherwise. 324 In case multiple PvD options are found in a given RA, hosts MUST 325 ignore all but the first PvD option. 327 Similarly, hosts MUST associate all network configuration objects 328 (e.g., default routers, addresses, more specific routes, DNS 329 Recursive Resolvers) with the PvD associated with the RA which last 330 updated the object. For example, addresses that are generated using 331 a received Prefix Information option (PIO) are associated with the 332 PvD of the last received RA which included the given PIO. 334 PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a), 335 assuming ASCII with zero parity while non-alphabetic codes must match 336 exactly (see also Section 3.1 of [RFC1035]). For example, 337 "pvd.example.com." or "PvD.Example.coM." would refer to the same PvD. 339 While resolving names, executing the default address selection 340 algorithm [RFC6724] or executing the default router selection 341 algorithm when forwarding packets ([RFC2461], [RFC4191] and 342 [RFC8028]), hosts MAY consider only the configuration associated with 343 an arbitrary set of PvDs. 345 For example, a host MAY associate a given process with a specific 346 PvD, or a specific set of PvDs, while associating another process 347 with another PvD. A PvD-aware application might also be able to 348 select, on a per-connection basis, which PvDs should be used. In 349 particular, constrained devices such as small battery operated 350 devices (e.g. IoT), or devices with limited CPU or memory resources 351 may purposefully use a single PvD while ignoring some received RAs 352 containing different PvD IDs. 354 The way an application expresses its desire to use a given PvD, or a 355 set of PvDs, or the way this selection is enforced, is out of the 356 scope of this document. Useful insights about these considerations 357 can be found in [I-D.kline-mif-mpvd-api-reqs]. 359 3.4.1. DHCPv6 configuration association 361 When a host retrieves configuration elements using DHCPv6 (e.g., 362 addresses or DNS recursive resolvers), they MUST be associated with 363 the explicit or implicit PvD of the RA received on the same 364 interface, sent from the same LLA, and with the O-flag or M-flag set 365 [RFC4861]. If no such PvD is found, or whenever multiple different 366 PvDs are found, the host behavior is unspecified. 368 This process requires hosts to keep track of received RAs, associated 369 PvD IDs, and routers LLA; it also assumes that the router either acts 370 as a DHCPv6 server or relay and uses the same LLA for DHCPv6 and RA 371 traffic (which may not be the case when the router uses VRRP to send 372 its RA). 374 3.4.2. DHCPv4 configuration association 376 When a host retrieves configuration elements from DHCPv4, they MUST 377 be associated with the explicit PvD received on the same interface, 378 whose PVD Options L-flag is set and, in the case of a non point-to- 379 point link, using the same datalink address. If no such PvD is 380 found, or whenever multiple different PvDs are found, the 381 configuration elements coming from DHCPv4 MUST be associated with the 382 implicit PvD identified by the interface on which the DHCPv4 383 transaction happened. The case of multiple explicit PvD for an IPv4 384 interface is undefined. 386 3.4.3. Connection Sharing by the Host 388 The situation when a node receives an RA on one interface (e.g. 389 cellular) and shares this connectivity by also acting as a router by 390 transmitting RA on another interface (e.g. WiFi) is known as 391 'tethering'. It can be done as ND proxy. The exact behavior is out 392 of scope of this document but it is expected that the one or several 393 PvD associated to the shared interface (e.g. cellular) will also be 394 advertised to the clients on the other interface (e.g. WiFi). 396 4. Provisioning Domain Additional Information 398 Additional information about the network characteristics can be 399 retrieved based on the PvD ID. This set of information is called PvD 400 Additional Information, and is encoded as a JSON object [RFC7159]. 402 The purpose of this additional set of information is to securely 403 provide additional information to applications about the connectivity 404 that is provided using a given interface and source address pair. It 405 typically includes data that would be considered too large, or not 406 critical enough, to be provided within an RA option. The information 407 contained in this object MAY be used by the operating system, network 408 libraries, applications, or users, in order to decide which set of 409 PvDs should be used for which connection, as described in 410 Section 3.4. 412 4.1. Retrieving the PvD Additional Information 414 When the H-flag of the PvD Option is set, hosts MAY attempt to 415 retrieve the PvD Additional Information associated with a given PvD 416 by performing an HTTP over TLS [RFC2818] GET query to https:///.well-known/pvd [RFC5785]. Inversely, hosts MUST NOT do so 418 whenever the H-flag is not set. 420 Note that the DNS name resolution of the PvD ID, the PKI checks as 421 well as the actual query MUST be performed using the considered PvD. 422 In other words, the name resolution, PKI checks, source address 423 selection, as well as the next-hop router selection MUST be performed 424 while using exclusively the set of configuration information attached 425 with the PvD, as defined in Section 3.4. In some cases, it may 426 therefore be necessary to wait for an address to be available for use 427 (e.g., once the Duplicate Address Detection or DHCPv6 processes are 428 complete) before initiating the HTTP over TLS query. If the host has 429 a temporary address per [RFC4941] in this PvD, then hosts SHOULD use 430 a temporary address to fetch the PvD Additional Information and 431 SHOULD deprecate the used temporary address and generate a new 432 temporary address afterward. 434 If the HTTP status of the answer is greater than or equal to 400 the 435 host MUST abandon and consider that there is no additional PvD 436 information. If the HTTP status of the answer is between 300 and 437 399, inclusive, it MUST follow the redirection(s). If the HTTP 438 status of the answer is between 200 and 299, inclusive, the host MAY 439 get a file containing a single JSON object. When a JSON object could 440 not be retrieved, an error message SHOULD be logged and/or displayed 441 in a rate-limited fashion. 443 After retrieval of the PvD Additional Information, hosts MUST keep 444 track of the Sequence Number value received in subsequent RAs 445 including the same PvD ID. In case the new value is greater than the 446 value that was observed when the PvD Additional Information object 447 was retrieved (using serial number arithmetic comparisons [RFC1982]), 448 or whenever the validity time included in the PVD Additional 449 Information JSON object is expired, hosts MUST either perform a new 450 query and retrieve a new version of the object, or, failing that, 451 deprecate the object and stop using the additional information 452 provided in the JSON object. 454 Hosts retrieving a new PvD Additional Information object MUST check 455 for the presence and validity of the mandatory fields specified in 456 Section 4.3. A retrieved object including an expiration time that is 457 already past or missing a mandatory element MUST be ignored. 459 In order to avoid synchronized queries toward the server hosting the 460 PvD Additional Information when an object expires, object updates are 461 delayed by a randomized backoff time. 463 When a host performs an object update after it detected a change 464 in the PvD Option Sequence number, it MUST delay the query by a 465 random time between zero and 2**(Delay * 2) milliseconds, where 466 'Delay' corresponds to the 4 bits long unsigned integer in the 467 last received PvD Option. 469 When a host last retrieved an object at time A including a 470 validity time B, and is configured to keep the object up to date, 471 it MUST perform the update at a uniformly random time in the 472 interval [(B-A)/2,B]. 474 In the example Figure 2, the delay field value is 5, this means that 475 host MUST delay the query by a random number between 0 and 2**(5 * 2) 476 milliseconds, i.e., between 0 and 1024 milliseconds. 478 Since the 'Delay' value is directly within the PvD Option rather than 479 the object itself, an operator may perform a push-based update by 480 incrementing the Sequence value while changing the Delay value 481 depending on the criticality of the update and its PvD Additional 482 Information servers capacity. 484 The PvD Additional Information object includes a set of IPv6 prefixes 485 (under the key "prefixes") which MUST be checked against all the 486 Prefix Information Options advertised in the RA. If any of the 487 prefixes included in the PIO is not covered by at least one of the 488 listed prefixes, the PvD associated with the tested prefix MUST be 489 considered unsafe and MUST NOT be used. While this does not prevent 490 a malicious network provider, it does complicate some attack 491 scenarios, and may help detecting misconfiguration. 493 4.2. Operational Consideration to Providing the PvD Additional 494 Information 496 Whenever the H-flag is set in the PvD Option, a valid PvD Additional 497 Information object MUST be made available to all hosts receiving the 498 RA by the network operator. In particular, when a captive portal is 499 present, hosts MUST still be allowed to perform DNS, PKI and HTTP 500 over TLS operations related to the retrieval of the object, even 501 before logging into the captive portal. 503 Routers MAY increment the PVD Option Sequence number in order to 504 inform host that a new PvD Additional Information object is available 505 and should be retrieved. 507 The server providing the JSON files SHOULD also check whether the 508 client address is part of the prefixes listed into the additional 509 information and SHOULD return a 403 response code if there is no 510 match. 512 4.3. PvD Additional Information Format 514 The PvD Additional Information is a JSON object. 516 The following table presents the mandatory keys which MUST be 517 included in the object: 519 +----------+-----------------+-------------+------------------------+ 520 | JSON key | Description | Type | Example | 521 +----------+-----------------+-------------+------------------------+ 522 | name | Human-readable | UTF-8 | "Awesome Wifi" | 523 | | service name | string | | 524 | | | [RFC3629] | | 525 | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | 526 | | which this | | | 527 | | object is not | | | 528 | | valid | | | 529 | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | 530 | | prefixes valid | strings | "2001:db8:4::/48"] | 531 | | for this PVD | | | 532 +----------+-----------------+-------------+------------------------+ 534 A retrieved object which does not include a valid string associated 535 with the "name" key at the root of the object, or a valid date 536 associated with the "expires" key, also at the root of the object, 537 MUST be ignored. In such cases, an error message SHOULD be logged 538 and/or displayed in a rate-limited fashion. If the PIO of the 539 received RA is not covered by at least one of the "prefixes" key, the 540 retrieved object SHOULD be ignored. 542 The following table presents some optional keys which MAY be included 543 in the object. 545 +---------------+-----------------+---------+-----------------------+ 546 | JSON key | Description | Type | Example | 547 +---------------+-----------------+---------+-----------------------+ 548 | localizedName | Localized user- | UTF-8 | "Wifi Genial" | 549 | | visible service | string | | 550 | | name, language | | | 551 | | can be selected | | | 552 | | based on the | | | 553 | | HTTP Accept- | | | 554 | | Language header | | | 555 | | in the request. | | | 556 | dnsZones | DNS zones | array | ["example.com","sub.e | 557 | | searchable and | of DNS | xample.org"] | 558 | | accessible | zones | | 559 | noInternet | No Internet, | boolean | true | 560 | | set when the | | | 561 | | PvD only | | | 562 | | provides | | | 563 | | restricted | | | 564 | | access to a set | | | 565 | | of services | | | 566 +---------------+-----------------+---------+-----------------------+ 568 It is worth noting that the JSON format allows for extensions. 569 Whenever an unknown key is encountered, it MUST be ignored along with 570 its associated elements. 572 4.3.1. Private Extensions 574 JSON keys starting with "x-" are reserved for private use and can be 575 utilized to provide information that is specific to vendor, user or 576 enterprise. It is RECOMMENDED to use one of the patterns "x-FQDN- 577 KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or 578 PEN is a private enterprise number [PEN] under control of the author 579 of the extension to avoid collisions. 581 4.3.2. Example 583 Here are two examples based on the keys defined in this section. 585 { 586 "name": "Foo Wireless", 587 "localizedName": "Foo-France Wifi", 588 "expires": "2017-07-23T06:00:00Z", 589 "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"], 590 } 592 { 593 "name": "Bar 4G", 594 "localizedName": "Bar US 4G", 595 "expires": "2017-07-23T06:00:00Z", 596 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 597 } 599 4.4. Detecting misconfiguration and misuse 601 When a host retrieves the PvD Additional Information, it MUST verify 602 that the TLS server certificate is valid for the performed request 603 (e.g., that the Subject Name is equal to the PvD ID expressed as an 604 FQDN). This authentication creates a secure binding between the 605 information provided by the trusted Router Advertisement, and the 606 HTTPS server. But this does not mean the Advertising Router and the 607 PvD server belong to the same entity. 609 Hosts MUST verify that all prefixes in the RA PIO are covered by a 610 prefix from the PvD Additional Information. An adversarial router 611 willing to fake the use of a given explicit PvD, without any access 612 to the actual PvD Additional Information, would need to perform NAT66 613 in order to circumvent this check. 615 It is also RECOMMENDED that the HTTPS server checks the source 616 addresses of incoming connections (see Section 4.1). This check give 617 reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used 618 and restricts the information to the valid network users. 620 5. Operational Considerations 622 This section describes some use cases of PvD. For the sake of 623 simplicity, the RA messages will not be described in the usual ASCII 624 art but rather in an indented list. For example, a RA message 625 containing some options and a PvD option that also contains other 626 options will be described as: 628 o RA Header: router lifetime = 6000 630 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 631 o PvD Option header: length = 3+ 5 +4 , PvD ID FQDN = example.org., 632 R-flag = 0 (actual length of the header with padding 24 bytes = 3 633 * 8 bytes) 635 * Recursive DNS Server: length = 5, addresses= 636 [2001:db8:cafe::53, 2001:db8:f00d::53] 638 * Prefix Information Option: length = 4, prefix = 639 2001:db8:f00d::/64 641 It is expected that for some years, networks will have a mixed 642 environment of PvD-aware hosts and non-PvD-aware hosts. If there is 643 a need to give specific information to PvD-aware hosts only, then it 644 is recommended to send TWO RA messages: one for each class of hosts. 645 For example, here is the RA for non-PvD-aware hosts: 647 o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use 648 this router as a default router) 650 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 652 o Recursive DNS Server Option: length = 3, addresses= 653 [2001:db8:cafe::53] 655 o PvD Option header: length = 3+ 2, PvD ID FQDN = foo.example.org., 656 R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) 658 * RA Header: router lifetime = 0 (PvD-aware hosts will not use 659 this router as a default router), implicit length = 2 661 And here is a RA example for PvD-aware hosts: 663 o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use 664 this router as a default router) 666 o PvD Option header: length = 3+ 2 + 4 + 3, PvD ID FQDN = 667 example.org., R-flag = 1 (actual length of the header 24 bytes = 3 668 * 8 bytes) 670 * RA Header: router lifetime = 1600 (PvD-aware hosts will use 671 this router as a default router), implicit length = 2 673 * Prefix Information Option: length = 4, prefix = 674 2001:db8:f00d::/64 676 * Recursive DNS Server Option: length = 3, addresses= 677 [2001:db8:f00d::53] 679 In the above example, non-PvD-aware hosts will only use the first RA 680 sent from their default router and using the 2001:db8:cafe::/64 681 prefix. PvD-aware hosts will autonomously configure addresses from 682 both PIOs, but will only use the source address in 2001:db8:f00d::/64 683 to communicate past the first hop router since only the router 684 sending the second RA will be used as default router; similarly, they 685 will use the DNS server 2001:db8:f00d::53 when communicating with 686 this adress. 688 6. Security Considerations 690 Although some solutions such as IPsec or SeND [RFC3971] can be used 691 in order to secure the IPv6 Neighbor Discovery Protocol, in practice 692 actual deployments largely rely on link layer or physical layer 693 security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA 694 Guard [RFC6105]. 696 This specification does not improve the Neighbor Discovery Protocol 697 security model, but extends the purely link-local trust relationship 698 between the host and the default routers with HTTP over TLS 699 communications which servers are authenticated as rightful owners of 700 the FQDN received within the trusted PvD ID RA option. 702 It must be noted that Section 4.4 of this document only provides 703 reasonable assurance against misconfiguration but does not prevent an 704 hostile network access provider to advertize wrong information that 705 could lead applications or hosts to select an hostile PvD. Users 706 should always apply caution when connecting to an unknown network. 708 7. Privacy Considerations 710 Retrieval of the PvD Additional Information over HTTPS requires early 711 communications between the connecting host and a server which may be 712 located further than the first hop router. Although this server is 713 likely to be located within the same administrative domain as the 714 default router, this property can't be ensured. Therefore, hosts 715 willing to retrieve the PvD Additional Information before using it 716 without leaking identity information, SHOULD make use of an IPv6 717 Privacy Address and SHOULD NOT include any privacy sensitive data, 718 such as User Agent header or HTTP cookie, while performing the HTTP 719 over TLS query. 721 From a privacy perspective, retrieving the PvD Additional Information 722 is not different from establishing a first connection to a remote 723 server, or even performing a single DNS lookup. For example, most 724 operating systems already perform early queries to well known web 725 sites, such as http://captive.example.com/hotspot-detect.html, in 726 order to detect the presence of a captive portal. 728 There may be some cases where hosts, for privacy reasons, should 729 refrain from accessing servers that are located outside a certain 730 network boundary. In practice, this could be implemented as a 731 whitelist of 'trusted' FQDNs and/or IP prefixes that the host is 732 allowed to communicate with. In such scenarios, the host SHOULD 733 check that the provided PvD ID, as well as the IP address that it 734 resolves into, are part of the allowed whitelist. 736 8. IANA Considerations 738 Upon publication of this document, IANA is asked to remove the 739 'reclaimable' tag off the value 21 for the PvD option (from the IPv6 740 Neighbor Discovery Option Formats registry). 742 IANA is asked to assign the value "pvd" from the Well-Known URIs 743 registry. 745 IANA is asked to create and maintain a new registry entitled 746 "Additional Information PvD Keys" containing ASCII strings. The 747 initial content of this registry are given in Section 4.3; future 748 assignments are to be made through Expert Review [BCP36]. 750 Finally, IANA is asked to create and maintain a new registry entitled 751 "PvD option Flags" reserving bit positions from 0 to 15 to be used in 752 the PvD option bitmask. Bit position 0, 1 and 2 are reserved by this 753 document (as specified in Figure 1). Future assignments require a 754 Standard Track RFC document. 756 9. Acknowledgements 758 Many thanks to M. Stenberg and S. Barth for their earlier work: 759 [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was 760 author of an early version of this document. 762 Thanks also to Marcus Keane, Mikael Abrahamson, Ray Bellis, Zhen Cao, 763 Tim Chow, Lorenzo Colitti, Ian Farrer, Bob Hinden, Tatuya Jinmei, 764 Erik Kline, Ted Lemon, Jen Lenkova, Veronika McKillop, Mark Townsley 765 and James Woodyatt for useful and interesting discussions. 767 Finally, special thanks to Thierry Danis and Wenqin Shao for their 768 valuable inputs and implementation efforts ([github]), Tom Jones for 769 his integration effort into the NEAT project and Rigil Salim for his 770 implementation work. 772 10. References 774 10.1. Normative references 776 [RFC1035] Mockapetris, P., "Domain names - implementation and 777 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 778 November 1987, . 780 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 781 DOI 10.17487/RFC1982, August 1996, 782 . 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 790 Discovery for IP Version 6 (IPv6)", RFC 2461, 791 DOI 10.17487/RFC2461, December 1998, 792 . 794 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 795 DOI 10.17487/RFC2818, May 2000, 796 . 798 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 799 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 800 2003, . 802 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 803 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 804 DOI 10.17487/RFC4861, September 2007, 805 . 807 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 808 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 809 2014, . 811 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 812 Writing an IANA Considerations Section in RFCs", BCP 26, 813 RFC 8126, DOI 10.17487/RFC8126, June 2017, 814 . 816 10.2. Informative references 818 [github] Cisco, "IPv6-mPvD github repository", 819 . 821 [I-D.kline-mif-mpvd-api-reqs] 822 Kline, E., "Multiple Provisioning Domains API 823 Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in 824 progress), November 2015. 826 [I-D.stenberg-mif-mpvd-dns] 827 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 828 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 829 (work in progress), October 2015. 831 [IEEE8021X] 832 IEEE, "IEEE Standards for Local and Metropolitan Area 833 Networks: Port based Network Access Control, IEEE Std". 835 [PEN] IANA, "Private Enterprise Numbers", 836 . 838 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 839 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 840 . 842 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 843 "SEcure Neighbor Discovery (SEND)", RFC 3971, 844 DOI 10.17487/RFC3971, March 2005, 845 . 847 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 848 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 849 November 2005, . 851 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 852 Extensions for Stateless Address Autoconfiguration in 853 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 854 . 856 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 857 Uniform Resource Identifiers (URIs)", RFC 5785, 858 DOI 10.17487/RFC5785, April 2010, 859 . 861 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 862 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 863 DOI 10.17487/RFC6105, February 2011, 864 . 866 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 867 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 868 . 870 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 871 "Default Address Selection for Internet Protocol Version 6 872 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 873 . 875 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 876 Recursive DNS Server Selection for Multi-Interfaced 877 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 878 . 880 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 881 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 882 . 884 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 885 Hosts in a Multi-Prefix Network", RFC 8028, 886 DOI 10.17487/RFC8028, November 2016, 887 . 889 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 890 "IPv6 Router Advertisement Options for DNS Configuration", 891 RFC 8106, DOI 10.17487/RFC8106, March 2017, 892 . 894 Appendix A. Changelog 896 Note to RFC Editors: Remove this section before publication. 898 A.1. Version 00 900 Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke 901 and based on Basile's work. 903 A.2. Version 01 905 Major rewrite intended to focus on the the retained solution based on 906 corridors, online, and WG discussions. Edited by Pierre Pfister. 907 The following list only includes major changes. 909 PvD ID is an FQDN retrieved using a single RA option. This option 910 contains a sequence number for push-based updates, a new H-flag, 911 and a L-flag in order to link the PvD with the IPv4 DHCP server. 913 A lifetime is included in the PvD ID option. 915 Detailed Hosts and Routers specifications. 917 Additional Information is retrieved using HTTP-over-TLS when the 918 PvD ID Option H-flag is set. Retrieving the object is optional. 920 The PvD Additional Information object includes a validity date. 922 DNS-based approach is removed as well as the DNS-based encoding of 923 the PvD Additional Information. 925 Major cut in the list of proposed JSON keys. This document may be 926 extended later if need be. 928 Monetary discussion is moved to the appendix. 930 Clarification about the 'prefixes' contained in the additional 931 information. 933 Clarification about the processing of DHCPv6. 935 A.3. Version 02 937 The FQDN is now encoded with ASCII format (instead of DNS binary) 938 in the RA option. 940 The PvD ID option lifetime is removed from the object. 942 Use well known URI "https:///.well-known/pvd" 944 Reference RFC3339 for JSON timestamp format. 946 The PvD ID Sequence field has been extended to 16 bits. 948 Modified host behavior for DHCPv4 and DHCPv6. 950 Removed IKEv2 section. 952 Removed mention of RFC7710 Captive Portal option. A new I.D. 953 will be proposed to address the captive portal use case. 955 A.4. WG Document version 00 957 Document has been accepted as INTAREA working group document 959 IANA considerations follow RFC8126 [RFC8126] 961 PvD ID FQDN is encoded as per RFC 1035 [RFC1035] 963 PvD ID FQDN is prepended by a one-byte length field 965 Marcus Keane added as co-author 967 dnsZones key is added back 969 draft of a privacy consideration section and added that a 970 temporary address should be used to retrieve the PvD additional 971 information 973 per Bob Hinden's request: the document is now aiming at standard 974 track and security considerations have been moved to the main 975 section 977 A.5. WG Document version 01 979 Removing references to 'metered' and 'characteristics' keys. 980 Those may be in scope of the PvD work, but this document will 981 focus on essential parts only. 983 Removing appendix section regarding link quality and billing 984 information. 986 The PvD RA Option may now contain other RA options such that PvD- 987 aware hosts may receive configuration information otherwise 988 invisible to non-PvD-aware hosts. 990 Clarify that the additional PvD Additional Information is not 991 intended to modify host's networking stack behavior, but rather 992 provide information to the Application, used to select which PvDs 993 must be used and provide configuration parameters to the transport 994 layer. 996 The RA option padding is used to increase the option size to the 997 next 64 (was 32) bits boundary. 999 Better detail the Security model and Privacy considerations. 1001 A.6. WG Document version 02 1003 Use the IANA value of 21 in the text and update the IANA 1004 considerations section accordingly 1006 add the Delay field to avoid the thundering herd effect 1008 add Wenqin Shao as author 1010 keep the 1 PvD per RA model 1012 changed the intro (per Zhen Cao) "when choosing which PvD and 1013 transport should be used" => "when choosing which PvD should be 1014 used" 1016 rename A-flag in R-flag to avoid A-flag of PIO 1018 use the wording "PvD Option", removing the ID token as it is now a 1019 container with more then just an ID, removing 'RA' in the option 1020 name to be consistent with other IANA NDP option 1022 use "non-PvD-aware" rather than "PvD-ignorant" 1024 added more reference to RFC 7556 (notably for PvD being globally 1025 unique, introducing PvD-aware host vs. PvD-aware node) 1027 Section 3.4.3 renamed from "interconnection shared by node" to 1028 'connection shared by node" 1030 Section 3.4 renamed into "PvD-aware Host Behavior" 1032 Added a section "Non-PvD-aware Host Behavior" 1034 Authors' Addresses 1036 Pierre Pfister 1037 Cisco 1038 11 Rue Camille Desmoulins 1039 Issy-les-Moulineaux 92130 1040 France 1042 Email: ppfister@cisco.com 1043 Eric Vyncke (editor) 1044 Cisco 1045 De Kleetlaan, 6 1046 Diegem 1831 1047 Belgium 1049 Email: evyncke@cisco.com 1051 Tommy Pauly 1052 Apple 1054 Email: tpauly@apple.com 1056 David Schinazi 1057 Apple 1059 Email: dschinazi@apple.com 1061 Wenqin Shao 1062 Telecom-ParisTech 1063 France 1065 Email: wenqin.shao@telecom-paristech.fr