idnits 2.17.1 draft-ietf-intarea-provisioning-domains-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2018) is 2267 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 704, but not defined ** 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 (~~), 2 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: August 13, 2018 T. Pauly 6 D. Schinazi 7 Apple 8 February 9, 2018 10 Discovering Provisioning Domain Names and Data 11 draft-ietf-intarea-provisioning-domains-01 13 Abstract 15 An increasing number of hosts access the Internet via multiple 16 interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix 17 configurations. 19 This document describes a way for hosts to identify such means, 20 called Provisioning Domains (PvDs), with Fully Qualified Domain Names 21 (FQDN). Those identifiers are advertised in a new Router 22 Advertisement (RA) option and, when present, are associated with the 23 set of information included within the RA. 25 Based on this FQDN, hosts can retrieve additional information about 26 their network access characteristics via an HTTP over TLS query. 27 This allows applications to select which Provisioning Domains to use 28 as well as to provide configuration parameters to the transport layer 29 and above. 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 August 13, 2018. 48 Copyright Notice 50 Copyright (c) 2018 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Provisioning Domain Identification using Router 68 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4 70 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 71 3.3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.1. DHCPv6 configuration association . . . . . . . . . . 8 73 3.3.2. DHCPv4 configuration association . . . . . . . . . . 8 74 3.3.3. Interconnection Sharing by the Host . . . . . . . . . 9 75 4. Provisioning Domain Additional Information . . . . . . . . . 9 76 4.1. Retrieving the PvD Additional Information . . . . . . . . 9 77 4.2. Operational Consideration to Providing the PvD Additional 78 Information . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. PvD Additional Information Format . . . . . . . . . . . . 11 80 4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 12 81 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 13 83 5. Operation Considerations . . . . . . . . . . . . . . . . . . 13 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 10.1. Normative references . . . . . . . . . . . . . . . . . . 16 90 10.2. Informative references . . . . . . . . . . . . . . . . . 17 91 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 19 92 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 19 93 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 19 94 A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 20 95 A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 20 96 A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 It has become very common in modern networks for hosts to access the 102 internet through different network interfaces, tunnels, or next-hop 103 routers. To describe the set of network configurations associated 104 with each access method, the concept of Provisioning Domain (PvD) was 105 defined in [RFC7556]. 107 This document specifies a way to identify PvDs with Fully Qualified 108 Domain Names (FQDN), called PvD IDs. Those identifiers are 109 advertised in a new Router Advertisement (RA) [RFC4861] option called 110 the PvD ID Router Advertisement option which, when present, 111 associates the PvD ID with all the information present in the Router 112 Advertisement as well as any configuration object, such as addresses, 113 deriving from it. The PVD ID Router Advertisement option may also 114 contain a set of other RA options. Since such options are only 115 considered by hosts implementing this specification, network 116 operators may configure hosts that are 'PvD-aware' with PvDs that are 117 ignored by other hosts. 119 Since PvD IDs are used to identify different ways to access the 120 internet, multiple PvDs (with different PvD IDs) could be provisioned 121 on a single host interface. Similarly, the same PvD ID could be used 122 on different interfaces of a host in order to inform that those PvDs 123 ultimately provide identical services. 125 This document also introduces a way for hosts to retrieve additional 126 information related to a specific PvD by means of an HTTP over TLS 127 query using an URI derived from the PvD ID. The retrieved JSON 128 object contains additional information that would typically be 129 considered unfit, or too large, to be directly included in the Router 130 Advertisement, but might be considered useful to the applications, or 131 even sometimes users, when choosing which PvD and transport should be 132 used. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 [RFC2119]. 141 In addition, this document uses the following terminology: 143 Provisioning Domain (PvD): A set of network configuration 144 information; for more information, see [RFC7556]. 146 PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a 147 PvD. 149 Explicit PvD: A PvD uniquely identified with a PvD ID. For more 150 information, see [RFC7556]. 152 Implicit PvD: A PvD that, in the absence of a PvD ID, is identified 153 by the host interface to which it is attached and the address of 154 the advertising router. 156 3. Provisioning Domain Identification using Router Advertisements 158 Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully 159 Qualified Domain Name (FQDN) which MUST belong to the network 160 operator in order to avoid naming collisions. The same PvD ID MAY be 161 used in several access networks when they ultimately provide 162 identical services (e.g., in all home networks subscribed to the same 163 service). 165 3.1. PvD ID Option for Router Advertisements 167 This document introduces a Router Advertisement (RA) option called 168 PvD ID Router Advertisement option. It is used to convey the FQDN 169 identifying a given PvD (see Figure 1), bind the PvD ID with 170 configuration information received over DHCPv4 (see Section 3.3.2), 171 enable the use of HTTP over TLS to retrieve the PvD Additional 172 Information JSON object (see Section 4), as well as contain any other 173 RA options which would otherwise be valid in the RA. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Length |H|L|A| Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Sequence Number | ... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 182 ... PvD ID FQDN ... 183 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ... | Padding | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | ... 187 ... Router Advertisement message header ... 188 ... (Only present when A-flag is set) ... 189 ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Options ... 192 +-+-+-+-+-+-+-+-+-+-+-+- 194 Figure 1: PvD ID Router Advertisements Option format 196 Type : (8 bits) To be defined by IANA. Current 197 experimentation uses the value of 254. 199 Length : (8 bits) The length of the option in units of 8 200 octets, including the Type and Length fields, the Router 201 Advertisement message header, if any, as well as the RA options 202 that are included within the PvD ID Option. 204 H-flag : (1 bit) 'HTTP' flag stating whether some PvD 205 Additional Information is made available through HTTP over TLS, as 206 described in Section 4. 208 L-flag : (1 bit) 'Legacy' flag stating whether the router is 209 also providing IPv4 information using DHCPv4 (see Section 3.3.2). 211 A-flag : (1 bit) 'Advertisement' flag stating whether the PvD 212 ID Option is followed (right after padding to the next 64 bits 213 boundary) by a Router Advertisement message header (See section 214 4.2 of target="RFC4861"/>). 216 Reserved : (13 bits) Reserved for later use. It MUST be set to 217 zero by the sender and ignored by the receiver. 219 Sequence Number: (16 bits) Sequence number for the PvD Additional 220 Information, as described in Section 4. 222 PvD ID FQDN : The FQDN used as PvD ID encoded in DNS format, as 223 described in Section 3.1 of [RFC1035]. Domain names compression 224 described in Section 4.1.4 of [RFC1035] MUST NOT be used. 226 Padding : Zero or more padding octets to the next 8 octets 227 boundary. It MUST be set to zero by the sender, and ignored by 228 the receiver. 230 RA message header : (16 octets) When the A-flag is set, a full 231 Router Advertisement message header as specified in [RFC4861]. 232 The 'Type', 'Code' and 'Checksum' fields (i.e. the first 32 bits), 233 MUST be set to zero by the sender and ignored by the receiver. 234 The other fields are to be set and parsed as specified in 235 [RFC4861] or any updating documents. 237 Options : Zero or more RA options that would otherwise be valid as 238 part of the Router Advertisement main body, but are instead 239 included in the PvD ID Option such as to be ignored by hosts that 240 are not 'PvD-aware'. 242 Here is an example of a PvD ID option with example.org as the PvD ID 243 FQDN and including a RDNSS and prefix information options: 245 0 1 2 3 246 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 247 +---------------+-----------------------------------------------+ 248 | Type: 254 | Length: 12 |0|0|0| Reserved | 249 +---------------+-------------------------------+---------------+ 250 | Sequence Number | 7 | e | 251 +---------------+-----------------------------------------------+ 252 | m | a | m | p | 253 +---------------------------------------------------------------+ 254 | l | e | 3 | o | 255 +---------------------------------------------------------------+ 256 | r | g | 0 | 0 (padding) | 257 +---------------------------------------------------------------+ 258 | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | 259 +---------------+---------------+---------------+---------------+ 260 | RDNSS option (RFC 6106) length: 5 ... 261 ... ... 262 ... | 263 +---------------------------------------------------------------+ 264 | Prefix Information Option (RFC 4861) length: 4 ... 265 ... | 266 ... | 267 +---------------------------------------------------------------+ 269 3.2. Router Behavior 271 A router MAY send RAs containing at most one PvD ID RA option, but 272 MUST NOT include more than one PvD ID RA option in each RA. In 273 particular, the PvD ID RA option MUST NOT contain further PvD ID RA 274 options. 276 The PvD ID Option MAY contain zero, one, or more RA options which 277 would otherwise be valid as part of the same RA. Such options are 278 processed by PvD-aware hosts, while ignored by others. 280 In order to provide multiple different PvDs, a router MUST send 281 multiple RAs. Different explicit PvDs MAY be advertised with RAs 282 using the same IPv6 source address; but different implicit PvDs, 283 advertised with different RAs, MUST use different link local 284 addresses. 286 Whenever an RA, for a single PvD, would need to be sent via multiple 287 packets, the PvD ID RA option header (i.e., all fields except the 288 'Options' field) MUST be repeated in all the transmitted RAs. But 289 the options within the 'Options' field, MAY be transmitted only once, 290 included in one of the transmitted PvD ID RA options. 292 3.3. Host Behavior 294 Hosts MUST associate received RAs and included configuration 295 information (e.g., Router Valid Lifetime, Prefix Information 296 [RFC4861], Recursive DNS Server [RFC8106], Routing Information 297 [RFC4191] options) with the explicit PvD identified by the first PvD 298 ID Option present in the received RA, if any, or with the implicit 299 PvD identified by the host interface and the source address of the 300 received RA otherwise. 302 In case multiple PvD ID options are found in a given RA, hosts MUST 303 ignore all but the first PvD ID option. 305 Similarly, hosts MUST associate all network configuration objects 306 (e.g., default routers, addresses, more specific routes, DNS 307 Recursive Resolvers) with the PvD associated with the RA which last 308 updated the object. For example, addresses that are generated using 309 a received Prefix Information option (PIO) are associated with the 310 PvD of the last received RA which included the given PIO. 312 PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a), 313 assuming ASCII with zero parity while non-alphabetic codes must match 314 exactly (see also Section 3.1 of [RFC1035]). For example, 315 pvd.example.com or PvD.Example.coM would refer to the same PvD. 317 While resolving names, executing the default address selection 318 algorithm [RFC6724] or executing the default router selection 319 algorithm ([RFC2461], [RFC4191] and [RFC8028]), hosts MAY consider 320 only the configuration associated with an arbitrary set of PvDs. 322 For example, a host MAY associate a given process with a specific 323 PvD, or a specific set of PvDs, while associating another process 324 with another PvD. A PvD-aware application might also be able to 325 select, on a per-connection basis, which PvDs should be used. In 326 particular, constrained devices such as small battery operated 327 devices (e.g. IoT), or devices with limited CPU or memory resources 328 may purposefully use a single PvD while ignoring some received RAs 329 containing different PvD IDs. 331 The way an application expresses its desire to use a given PvD, or a 332 set of PvDs, or the way this selection is enforced, is out of the 333 scope of this document. Useful insights about these considerations 334 can be found in [I-D.kline-mif-mpvd-api-reqs]. 336 3.3.1. DHCPv6 configuration association 338 When a host retrieves configuration elements using DHCPv6 (e.g., 339 addresses or DNS recursive resolvers), they MUST be associated with 340 the explicit or implicit PvD of the RA received on the same 341 interface, sent from the same LLA, and with the O-flag or M-flag set 342 [RFC4861]. If no such PvD is found, or whenever multiple different 343 PvDs are found, the host behavior is unspecified. 345 This process requires hosts to keep track of received RAs, associated 346 PvD IDs, and routers LLA; it also assumes that the router either acts 347 as a DHCPv6 server or relay and uses the same LLA for DHCPv6 and RA 348 traffic (which may not be the case when the router uses VRRP to send 349 its RA). 351 3.3.2. DHCPv4 configuration association 353 When a host retrieves configuration elements from DHCPv4, they MUST 354 be associated with the explicit PvD received on the same interface, 355 whose PVD ID Options L-flag is set and, in the case of a non point- 356 to-point link, using the same datalink address. If no such PvD is 357 found, or whenever multiple different PvDs are found, the 358 configuration elements coming from DHCPv4 MUST be associated with the 359 implicit PvD identified by the interface on which the DHCPv4 360 transaction happened. The case of multiple explicit PvD for an IPv4 361 interface is undefined. 363 3.3.3. Interconnection Sharing by the Host 365 The situation when a node receives an RA on one interface (e.g. 366 cellular) and shares this connectivity by also acting as a router by 367 transmitting RA on another interface (e.g. WiFi) is known as 368 'tethering'. It can be done as ND proxy. The exact behavior is TBD 369 but it is expected that the one or several PvD associated to the 370 shared interface (e.g. cellular) will also be advertised to the 371 clients on the other interface (e.g. WiFi). 373 4. Provisioning Domain Additional Information 375 Additional information about the network characteristics can be 376 retrieved based on the PvD ID. This set of information is called PvD 377 Additional Information, and is encoded as a JSON object [RFC7159]. 379 The purpose of this additional set of information is to securely 380 provide additional information to applications about the connectivity 381 that is provided using a given interface and source address pair. It 382 typically includes data that would be considered too large, or not 383 critical enough, to be provided within an RA option. The information 384 contained in this object MAY be used by the operating system, network 385 libraries, applications, or users, in order to decide which set of 386 PvDs should be used for which connection, as described in 387 Section 3.3. 389 4.1. Retrieving the PvD Additional Information 391 When the H-flag of the PvD ID Option is set, hosts MAY attempt to 392 retrieve the PvD Additional Information associated with a given PvD 393 by performing an HTTP over TLS [RFC2818] GET query to https:///.well-known/pvd [RFC5785]. Inversely, hosts MUST NOT do so 395 whenever the H-flag is not set. 397 Note that the DNS name resolution of the PvD ID, the PKI checks as 398 well as the actual query MUST be performed using the considered PvD. 399 In other words, the name resolution, PKI checks, source address 400 selection, as well as the next-hop router selection MUST be performed 401 while using exclusively the set of configuration information attached 402 with the PvD, as defined in Section 3.3. In some cases, it may 403 therefore be necessary to wait for an address to be available for use 404 (e.g., once the Duplicate Address Detection or DHCPv6 processes are 405 complete) before initiating the HTTP over TLS query. If the PvD 406 allows for temporary address per [RFC4941], then hosts SHOULD use a 407 temporary address to fetch the PvD Additional Information and SHOULD 408 deprecate the used temporary address and generate a new temporary 409 address afterward. 411 If the HTTP status of the answer is greater than or equal to 400 the 412 host MUST abandon and consider that there is no additional PvD 413 information. If the HTTP status of the answer is between 300 and 414 399, inclusive, it MUST follow the redirection(s). If the HTTP 415 status of the answer is between 200 and 299, inclusive, the host MAY 416 get a file containing a single JSON object. When a JSON object could 417 not be retrieved, an error message SHOULD be logged and/or displayed 418 in a rate-limited fashion. 420 After retrieval of the PvD Additional Information, hosts MUST keep 421 track of the Sequence Number value received in subsequent RAs 422 including the same PvD ID. In case the new value is greater than the 423 value that was observed when the PvD Additional Information object 424 was retrieved (using serial number arithmetic comparisons [RFC1982]), 425 or whenever the validity time included in the PVD Additional 426 Information JSON object is expired, hosts MUST either perform a new 427 query and retrieve a new version of the object, or, failing that, 428 deprecate the object and stop using the additional information 429 provided in the JSON object. 431 Hosts retrieving a new PvD Additional Information object MUST check 432 for the presence and validity of the mandatory fields specified in 433 Section 4.3. A retrieved object including an expiration time that is 434 already past or missing a mandatory element MUST be ignored. In 435 order to avoid synchronized queries toward the server hosting the PvD 436 Additional Information when an object expires, a host which last 437 retrieved an object at a time A, including a validity time B, SHOULD 438 renew the object at a uniformly random time in the interval 439 [(B-A)/2,A]. 441 The PvD Additional Information object includes a set of IPv6 prefixes 442 (under the key "prefixes") which MUST be checked against all the 443 Prefix Information Options advertised in the RA. If any of the 444 prefixes included in the PIO is not covered by at least one of the 445 listed prefixes, the PvD associated with the tested prefix MUST be 446 considered unsafe and MUST NOT be used. While this does not prevent 447 a malicious network provider, it does complicate some attack 448 scenarios, and may help detecting misconfiguration. 450 4.2. Operational Consideration to Providing the PvD Additional 451 Information 453 Whenever the H-flag is set in the PvD RA Option, a valid PvD 454 Additional Information object MUST be made available to all hosts 455 receiving the RA by the network operator. In particular, when a 456 captive portal is present, hosts MUST still be allowed to perform 457 DNS, PKI and HTTP over TLS operations related to the retrieval of the 458 object, even before logging into the captive portal. 460 Routers MAY increment the PVD ID Sequence number in order to inform 461 host that a new PvD Additional Information object is available and 462 should be retrieved. 464 The server providing the JSON files SHOULD also check whether the 465 client address is part of the prefixes listed into the additional 466 information and SHOULD return a 403 response code if there is no 467 match. 469 4.3. PvD Additional Information Format 471 The PvD Additional Information is a JSON object. 473 The following table presents the mandatory keys which MUST be 474 included in the object: 476 +----------+-----------------+-------------+------------------------+ 477 | JSON key | Description | Type | Example | 478 +----------+-----------------+-------------+------------------------+ 479 | name | Human-readable | UTF-8 | "Awesome Wifi" | 480 | | service name | string | | 481 | | | [RFC3629] | | 482 | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | 483 | | which this | | | 484 | | object is not | | | 485 | | valid | | | 486 | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | 487 | | prefixes valid | strings | "2001:db8:4::/48"] | 488 | | for this PVD | | | 489 +----------+-----------------+-------------+------------------------+ 491 A retrieved object which does not include a valid string associated 492 with the "name" key at the root of the object, or a valid date 493 associated with the "expires" key, also at the root of the object, 494 MUST be ignored. In such cases, an error message SHOULD be logged 495 and/or displayed in a rate-limited fashion. If the PIO of the 496 received RA is not covered by at least one of the "prefixes" key, the 497 retrieved object SHOULD be ignored. 499 The following table presents some optional keys which MAY be included 500 in the object. 502 +---------------+-----------------+---------+-----------------------+ 503 | JSON key | Description | Type | Example | 504 +---------------+-----------------+---------+-----------------------+ 505 | localizedName | Localized user- | UTF-8 | "Wifi Genial" | 506 | | visible service | string | | 507 | | name, language | | | 508 | | can be selected | | | 509 | | based on the | | | 510 | | HTTP Accept- | | | 511 | | Language header | | | 512 | | in the request. | | | 513 | dnsZones | DNS zones | array | ["example.com","sub.e | 514 | | searchable and | of DNS | xample.org"] | 515 | | accessible | zones | | 516 | noInternet | No Internet, | boolean | true | 517 | | set when the | | | 518 | | PvD only | | | 519 | | provides | | | 520 | | restricted | | | 521 | | access to a set | | | 522 | | of services | | | 523 +---------------+-----------------+---------+-----------------------+ 525 It is worth noting that the JSON format allows for extensions. 526 Whenever an unknown key is encountered, it MUST be ignored along with 527 its associated elements. 529 4.3.1. Private Extensions 531 JSON keys starting with "x-" are reserved for private use and can be 532 utilized to provide information that is specific to vendor, user or 533 enterprise. It is RECOMMENDED to use one of the patterns "x-FQDN- 534 KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or 535 PEN is a private enterprise number [PEN] under control of the author 536 of the extension to avoid collisions. 538 4.3.2. Example 540 Here are two examples based on the keys defined in this section. 542 { 543 "name": "Foo Wireless", 544 "localizedName": "Foo-France Wifi", 545 "expires": "2017-07-23T06:00:00Z", 546 "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"], 547 } 548 { 549 "name": "Bar 4G", 550 "localizedName": "Bar US 4G", 551 "expires": "2017-07-23T06:00:00Z", 552 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 553 } 555 4.4. Detecting misconfiguration and misuse 557 When a host retrieves the PvD Additional Information, it MUST verify 558 that the TLS server certificate is valid for the performed request 559 (e.g., that the Subject Name is equal to the PvD ID expressed as an 560 FQDN). This authentication creates a secure binding between the 561 information provided by the trusted Router Advertisement, and the 562 HTTPS server. But this does not mean the Advertising Router and the 563 PvD server belong to the same entity. 565 Hosts MUST verify that all prefixes in the RA PIO are covered by a 566 prefix from the PvD Additional Information. An adversarial router 567 willing to fake the use of a given explicit PvD, without any access 568 to the actual PvD Additional Information, would need to perform NAT66 569 in order to circumvent this check. 571 It is also RECOMMENDED that the HTTPS server checks the source 572 addresses of incoming connections (see Section 4.1). This check give 573 reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used 574 and restricts the information to the valid network users. 576 5. Operation Considerations 578 This section describes some use cases of PvD. For sake of 579 simplicity, the RA messages will not be described in the usual ASCII 580 art but rather in an indented list. For example, a RA message 581 containing some options and a PvD ID option that also contains other 582 options will be described as: 584 o RA Header: router lifetime = 6000 586 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 588 o PvD ID header: length = 3+ 5 +4 , PvD ID FQDN = example.org, 589 A-flag = 0 (actual length of the header with padding 24 bytes = 3 590 * 8 bytes) 592 * Recursive DNS Server: length = 5, addresses= 593 [2001:db8:cafe::53, 2001:db8:f00d::53] 595 * Prefix Information Option: length = 4, prefix = 596 2001:db8:f00d::/64 598 It is expected that for some years, networks will have a mix of PvD- 599 aware hosts and PvD-ignorant hosts. If there is a need to give 600 specific information to PvD-aware hosts only, then it is recommended 601 to send TWO RA messages: one for each class of hosts. For example, 602 here is the RA for PvD-ignorant hosts: 604 o RA Header: router lifetime = 6000 (PvD-ignorant hosts will use 605 this router as a default router) 607 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 609 o Recursive DNS Server Option: length = 3, addresses= 610 [2001:db8:cafe::53] 612 o PvD ID header: length = 3+ 2, PvD ID FQDN = foo.example.org, 613 A-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) 615 * RA Header: router lifetime = 0 (PvD-aware hosts will not use 616 this router as a default router), implicit length = 2 618 And here is a RA example for PvD-aware hosts: 620 o RA Header: router lifetime = 0 (PvD-ignorant hosts will not use 621 this router as a default router) 623 o PvD ID header: length = 3+ 2 + 4 + 3, PvD ID FQDN = example.org, 624 A-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) 626 * RA Header: router lifetime = 1600 (PvD-aware hosts will use 627 this router as a default router), implicit length = 2 629 * Prefix Information Option: length = 4, prefix = 630 2001:db8:f00d::/64 632 * Recursive DNS Server Option: length = 3, addresses= 633 [2001:db8:f00d::53] 635 In the above example, PvD-ignorant hosts will only use the first RA 636 sent from their default router and using the 2001:db8:cafe::/64 637 prefix. PvD-aware hosts will autonomously configure addresses from 638 both PIOs, but will only use the source address in 2001:db8:f00d::/64 639 to communicate past the first hop router since only the router 640 sending the second RA will be used as default router; similarly, they 641 will use the DNS server 2001:db8:f00d::53 when communicating with 642 this adress. 644 6. Security Considerations 646 Although some solutions such as IPsec or SeND [RFC3971] can be used 647 in order to secure the IPv6 Neighbor Discovery Protocol, actual 648 deployments largely rely on link layer or physical layer security 649 mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA Guard 650 [RFC6105]. 652 This specification does not improve the Neighbor Discovery Protocol 653 security model, but extends the purely link-local trust relationship 654 between the host and the default routers with HTTP over TLS 655 communications which servers are authenticated as rightful owners of 656 the FQDN received within the trusted PvD ID RA option. 658 It must be noted that Section 4.4 of this document only provides 659 reasonable assurance against misconfiguration but does not prevent an 660 hostile network access provider to wrong information that could lead 661 applications or hosts to select an hostile PvD. Users should always 662 apply caution when connecting to an unknown network. 664 7. Privacy Considerations 666 Retrieval of the PvD Additional Information over HTTPS requires early 667 communications between the connecting host and a server which may be 668 located further than the first hop router. Although this server is 669 likely to be located within the same administrative domain as the 670 default router, this property can't be ensured. Therefore, hosts 671 willing to retrieve the PvD Additional Information before using it 672 without leaking identity information, SHOULD make use of an IPv6 673 Privacy Address and SHOULD NOT include any privacy sensitive data, 674 such as User Agent header or HTTP cookie, while performing the HTTP 675 over TLS query. 677 From a privacy perspective, retrieving the PvD Additional Information 678 is not different from establishing a first connexion to a remote 679 server, or even performing a single DNS lookup. For example, most 680 operating systems already perform early queries to well known web 681 sites, such as http://captive.example.com/hotspot-detect.html, in 682 order to detect the presence of a captive portal. 684 There may be some cases where hosts, for privacy reasons, should 685 refrain from accessing servers that are located outside a certain 686 network boundary. In practice, this could be implemented as a 687 whitelist of 'trusted' FQDNs and/or IP prefixes that the host is 688 allowed to communicate with. In such scenarios, the host SHOULD 689 check that the provided PvD ID, as well as the IP address that it 690 resolves into, are part of the allowed whitelist. 692 8. IANA Considerations 694 IANA is asked to assign the value TBD from the IPv6 Neighbor 695 Discovery Option Formats registry for the PvD ID Router Advertisement 696 option. 698 IANA is asked to assign the value "pvd" from the Well-Known URIs 699 registry. 701 IANA is asked to create and maintain a new registry entitled 702 "Additional Information PvD Keys" containing ASCII strings. The 703 initial content of this registry are given in Section 4.3; future 704 assignments are to be made through Expert Review [BCP36]. 706 Finally, IANA is asked to create and maintain a new registry entitled 707 "PvD ID Router Advertisement option Flags" reserving bit positions 708 from 0 to 15 to be used in the PvD ID Router Advertisement option 709 bitmask. Bit position 0, 1 and 2 are reserved by this document (as 710 specified in Figure 1). Future assignments require a Standard Track 711 RFC document. 713 9. Acknowledgements 715 Many thanks to M. Stenberg and S. Barth for their earlier work: 716 [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was 717 author of an early version of this document. 719 Thanks also to Marcus Keane, Mikael Abrahamson, Ray Bellis, Lorenzo 720 Colitti, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Lemon, Jen 721 Lenkova, Mark Townsley and James Woodyatt for useful and interesting 722 discussions. 724 Finally, special thanks to Thierry Danis and Wenqin Shao for their 725 valuable inputs and implementation efforts ([github]), Tom Jones for 726 his integration effort into the NEAT project and Rigil Salim for his 727 implementation work. 729 10. References 731 10.1. Normative references 733 [RFC1035] Mockapetris, P., "Domain names - implementation and 734 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 735 November 1987, . 737 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 738 DOI 10.17487/RFC1982, August 1996, 739 . 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 747 Discovery for IP Version 6 (IPv6)", RFC 2461, 748 DOI 10.17487/RFC2461, December 1998, 749 . 751 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 752 DOI 10.17487/RFC2818, May 2000, 753 . 755 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 756 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 757 2003, . 759 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 760 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 761 DOI 10.17487/RFC4861, September 2007, 762 . 764 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 765 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 766 2014, . 768 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 769 Writing an IANA Considerations Section in RFCs", BCP 26, 770 RFC 8126, DOI 10.17487/RFC8126, June 2017, 771 . 773 10.2. Informative references 775 [github] Cisco, "IPv6-mPvD github repository", 776 . 778 [I-D.kline-mif-mpvd-api-reqs] 779 Kline, E., "Multiple Provisioning Domains API 780 Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in 781 progress), November 2015. 783 [I-D.stenberg-mif-mpvd-dns] 784 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 785 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 786 (work in progress), October 2015. 788 [IEEE8021X] 789 IEEE, "IEEE Standards for Local and Metropolitan Area 790 Networks: Port based Network Access Control, IEEE Std". 792 [PEN] IANA, "Private Enterprise Numbers", 793 . 795 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 796 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 797 . 799 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 800 "SEcure Neighbor Discovery (SEND)", RFC 3971, 801 DOI 10.17487/RFC3971, March 2005, 802 . 804 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 805 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 806 November 2005, . 808 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 809 Extensions for Stateless Address Autoconfiguration in 810 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 811 . 813 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 814 Uniform Resource Identifiers (URIs)", RFC 5785, 815 DOI 10.17487/RFC5785, April 2010, 816 . 818 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 819 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 820 DOI 10.17487/RFC6105, February 2011, 821 . 823 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 824 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 825 . 827 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 828 "Default Address Selection for Internet Protocol Version 6 829 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 830 . 832 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 833 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 834 . 836 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 837 Hosts in a Multi-Prefix Network", RFC 8028, 838 DOI 10.17487/RFC8028, November 2016, 839 . 841 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 842 "IPv6 Router Advertisement Options for DNS Configuration", 843 RFC 8106, DOI 10.17487/RFC8106, March 2017, 844 . 846 Appendix A. Changelog 848 Note to RFC Editors: Remove this section before publication. 850 A.1. Version 00 852 Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke 853 and based on Basile's work. 855 A.2. Version 01 857 Major rewrite intended to focus on the the retained solution based on 858 corridors, online, and WG discussions. Edited by Pierre Pfister. 859 The following list only includes major changes. 861 PvD ID is an FQDN retrieved using a single RA option. This option 862 contains a sequence number for push-based updates, a new H-flag, 863 and a L-flag in order to link the PvD with the IPv4 DHCP server. 865 A lifetime is included in the PvD ID option. 867 Detailed Hosts and Routers specifications. 869 Additional Information is retrieved using HTTP-over-TLS when the 870 PvD ID Option H-flag is set. Retrieving the object is optional. 872 The PvD Additional Information object includes a validity date. 874 DNS-based approach is removed as well as the DNS-based encoding of 875 the PvD Additional Information. 877 Major cut in the list of proposed JSON keys. This document may be 878 extended later if need be. 880 Monetary discussion is moved to the appendix. 882 Clarification about the 'prefixes' contained in the additional 883 information. 885 Clarification about the processing of DHCPv6. 887 A.3. Version 02 889 The FQDN is now encoded with ASCII format (instead of DNS binary) 890 in the RA option. 892 The PvD ID option lifetime is removed from the object. 894 Use well known URI "https:///.well-known/pvd" 896 Reference RFC3339 for JSON timestamp format. 898 The PvD ID Sequence field has been extended to 16 bits. 900 Modified host behavior for DHCPv4 and DHCPv6. 902 Removed IKEv2 section. 904 Removed mention of RFC7710 Captive Portal option. A new I.D. 905 will be proposed to address the captive portal use case. 907 A.4. WG Document version 00 909 Document has been accepted as INTAREA working group document 911 IANA considerations follow RFC8126 [RFC8126] 913 PvD ID FQDN is encoded as per RFC 1035 [RFC1035] 915 PvD ID FQDN is prepended by a one-byte length field 917 Marcus Keane added as co-author 919 dnsZones key is added back 921 draft of a privacy consideration section and added that a 922 temporary address should be used to retrieve the PvD additional 923 information 925 per Bob Hinden's request: the document is now aiming at standard 926 track and security considerations have been moved to the main 927 section 929 A.5. WG Document version 01 931 Removing references to 'metered' and 'characteristics' keys. 932 Those may be in scope of the PvD work, but this document will 933 focus on essential parts only. 935 Removing appendix section regarding link quality and billing 936 information. 938 The PvD RA Option may now contain other RA options such that PvD- 939 aware hosts may receive configuration information otherwise 940 invisible to non-PvD-aware hosts. 942 Clarify that the additional PvD Additional Information is not 943 intended to modify host's networking stack behavior, but rather 944 provide information to the Application, used to select which PvDs 945 must be used and provide configuration parameters to the transport 946 layer. 948 The RA option padding is used to increase the option size to the 949 next 64 (was 32) bits boundary. 951 Better detail the Security model and Privacy considerations. 953 Authors' Addresses 955 Pierre Pfister 956 Cisco 957 11 Rue Camille Desmoulins 958 Issy-les-Moulineaux 92130 959 France 961 Email: ppfister@cisco.com 963 Eric Vyncke (editor) 964 Cisco 965 De Kleetlaan, 6 966 Diegem 1831 967 Belgium 969 Email: evyncke@cisco.com 971 Tommy Pauly 972 Apple 974 Email: tpauly@apple.com 975 David Schinazi 976 Apple 978 Email: dschinazi@apple.com