idnits 2.17.00 (12 Aug 2021) /tmp/idnits64083/draft-bruneau-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 (June 30, 2017) is 1785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7296' is mentioned on line 352, but not defined ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 7710 (Obsoleted by RFC 8910) 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 B. Bruneau 3 Internet-Draft Ecole Polytechnique 4 Intended status: Informational P. Pfister 5 Expires: January 1, 2018 Cisco 6 D. Schinazi 7 T. Pauly 8 Apple 9 E. Vyncke 10 Cisco 11 June 30, 2017 13 Discovering Provisioning Domain Names and Data 14 draft-bruneau-intarea-provisioning-domains-01 16 Abstract 18 An increasing number of hosts and networks are connected to the 19 Internet through multiple interfaces, some of which may provide 20 multiple ways to access the internet by the mean of multiple IPv6 21 prefix configurations. 23 This document describes a way for hosts to retrieve additional 24 information about their network access characteristics. The set of 25 configuration items required to access the Internet is called a 26 Provisioning Domain (PvD) and is identified by a Fully Qualified 27 Domain Name (FQDN). This identifier, retrieved using a new Router 28 Advertisement (RA) option, is associated with the set of information 29 included within the RA and may later be used to retrieve additional 30 information associated to the PvD by the mean of an HTTP request. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 1, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Provisioning Domain Identification using Router 69 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4 71 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3.1. DHCPv6 configuration association . . . . . . . . . . 6 74 3.3.2. DHCPv4 configuration association . . . . . . . . . . 7 75 3.3.3. Interconnection Sharing by the Host . . . . . . . . . 7 76 4. Provisioning Domain Identification using IKEv2 . . . . . . . 7 77 5. Provisioning Domain Additional Information . . . . . . . . . 8 78 5.1. Retrieving the PvD Additional Information . . . . . . . . 9 79 5.2. Providing the PvD Additional Information . . . . . . . . 10 80 5.3. PvD Additional Information Format . . . . . . . . . . . . 10 81 5.3.1. Connectivity Characteristics Information . . . . . . 12 82 5.3.2. Private Extensions . . . . . . . . . . . . . . . . . 12 83 5.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 9.1. Normative references . . . . . . . . . . . . . . . . . . 14 89 9.2. Informative references . . . . . . . . . . . . . . . . . 15 90 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16 91 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 16 92 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 16 93 Appendix B. Connection monetary cost . . . . . . . . . . . . . . 17 94 B.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 17 95 B.2. Price . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 B.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 100 1. Introduction 102 It has become very common in modern networks that hosts have Internet 103 or more specific network access through different networking 104 interfaces, tunnels, or next-hop routers. The concept of 105 Provisioning Domain (PvD) was defined in [RFC7556] as a set of 106 network configuration information which can be used by hosts in order 107 to access the network. 109 In this document, PvDs are identified by Fully Qualified Domain Names 110 called PvD IDs, which are included in Router Advertisements [RFC4861] 111 as a new option and are used to identify correlated sets of network 112 configuration data. 114 Devices connected to the Internet through multiple interfaces would 115 typically be provisioned with one PvD per interface, but it is worth 116 noting that multiple PvDs with different PvD IDs could be provisioned 117 on any host interface, as well as noting that the same PvD ID could 118 be used on different interfaces in order to inform the host that both 119 PvDs, on different interfaces, ultimately provide identical services. 121 This document also introduces a way for hosts to retrieve additional 122 information related to a specific PvD by the mean of an HTTP-over-TLS 123 query using an URI derived from the PvD ID. The retrieved JSON 124 object contains additional network information that would typically 125 be considered unfit, or too large, to be directly included in the 126 Router Advertisements. This information can be used by the 127 networking stack, the applications, or even be partially displayed to 128 the users (e.g., by displaying a localized network service name). 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 In addition, this document uses the following terminology: 139 PvD: A Provisioning Domain, a set of network configuration 140 information; for more information, see [RFC7556]. 142 PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a 143 PvD. 145 Explicit PvD: A PvD uniquely identified with a PvD ID. 147 Implicit PvD: A PvD associated with a set of configuration 148 information that, in the absence of a PvD ID, is associated with 149 the advertising router. 151 3. Provisioning Domain Identification using Router Advertisements 153 Each provisioning domain is identified by a PvD ID. The PvD ID is a 154 Fully Qualified Domain Name (FQDN) which MUST belong to the network 155 operator in order to avoid ambiguity. The same PvD ID MAY be used in 156 several access networks if the set of configuration information is 157 identical (e.g. in all home networks subscribed to the same service). 159 3.1. PvD ID Option for Router Advertisements 161 This document introduces a new Router Advertisement (RA) option 162 called the PvD ID Router Advertisement Option, used to convey the 163 FQDN identifying a given PvD. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | Seq |H|L| Reserved | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Lifetime | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | PvD ID FQDN | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 PvD ID Router Advertisements Option format 177 Type : (8 bits) To be defined by IANA. 179 Length : (8 bits) The length of the option (including the Type 180 and Length fields) in units of 8 octets. 182 Seq : (4 bits) Sequence number for the PvD Additional 183 Information, as described in Section 5. 185 H-flag : (1 bit) Whether some PvD Additional Information is 186 made available through HTTP over TLS, as described in Section 5. 188 L-flag : (1 bit) Whether the router is also providing IPv4 189 access using DHCPv4 (see Section 3.3.2). 191 Reserved : (10 bits) Reserved for later use. It MUST be set to 192 zero by the sender and ignored by the receiver. 194 Lifetime : (32 bits) The length of time in seconds (relative to 195 the time the packet is sent) that the PvD ID option is valid. A 196 value of all one bits (0xffffffff) represents infinity. 198 PvD ID FQDN : The FQDN used as PvD ID in DNS binary format 199 [RFC1035], padded until the next 8 octets boundary. All the bytes 200 after the first empty DNS label MUST be set to zero by the sender 201 and MUST be ignored by the receiver. The DNS name compression 202 technique described in [RFC1035] MUST NOT be used. 204 Routers MUST NOT include more than one PvD ID Router Advertisement 205 Option in each RA. In case multiple PvD ID options are found in a 206 given RA, hosts MUST ignore all but the first PvD ID option. 208 Note: The existence and/or size of the sequence number is subject to 209 discussion. The validity of a PvD Additional Information object is 210 included in the object itself, but this only allows for 'pull based' 211 updates, whereas the RA options usually provide 'push based' updates. 213 Note: including the lifetime option is congruent with the lifetime 214 option of the other RA option. On the other hand, do we need it ? 216 3.2. Router Behavior 218 A router MAY insert at most one PvD ID Option in its RAs. The 219 included PvD ID is associated with all the other options included in 220 the same RA (e.g., Prefix Information [RFC4861], Recursive DNS Server 221 [RFC6106], Routing Information [RFC4191], Captive Portal [RFC7710] 222 options). 224 In order to provide multiple independent PvDs, a router MUST send 225 multiple RAs using different source link-local addresses (LLA) (as 226 proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]), each of 227 which MAY include a PvD ID option. In such cases, routers MAY 228 originate the different RAs using the same datalink layer address. 230 If the router is actually a VRRP instance [RFC5798], then the 231 procedure is identical except that the virtual datalink layer address 232 is used as well as virtual IPv6 addresses. 234 3.3. Host Behavior 236 RAs are used to configure IPv6 hosts. When a host receives a RA 237 message including a PvD ID Option with a non-zero lifetime, it MUST 238 associate all the configuration options included in the RA (e.g., 239 Prefix Information [RFC4861], Recursive DNS Server [RFC6106], Routing 240 Information [RFC4191], Captive Portal [RFC7710] options) with the PvD 241 ID). 243 If the received RA does not include a PvD ID Option, or whenever the 244 included PvD ID Option has a lifetime set to zero, the host MUST 245 associate the options included in the RA with an implicit PvD. This 246 implicit PvD is identified by the link-local address of the router 247 sending the RA and the interface on which the RA was received. 249 This document does not update the way Router Advertisement options 250 are processed. But in addition to the option processing defined in 251 other documents, hosts implementing this specification MUST associate 252 each created or updated object (e.g. address, default route, more 253 specific route, DNS server list) with the PvD associated with the 254 received RA as well as the interface and link-local address of the 255 router which last updated the object. 257 Each configuration object has a PvD validity timer set to the PvD ID 258 option lifetime whenever an RA that updates the object is received. 259 If the received RA does not include a PvD ID option, or whenever the 260 PvD ID option lifetime is zero, the associated objects are 261 immediately associated with an implicit PvD, as mentioned in the 262 previous paragraph. Similarly, whenever an object's PvD timer 263 reaches zero, the object is immediately associated with an implicit 264 PvD identified by the link-local address and interface of the router 265 which last updated the object. 267 While resolving names, executing the default address selection 268 algorithm [RFC6724] or executing the default router selection 269 algorithm ([RFC2461], [RFC4191] and [RFC8028]), hosts MAY consider 270 only the configuration associated with an arbitrary set of PvDs. 272 For example, a host MAY associate a given process with a specific 273 PvD, or a specific set of PvDs, while associating another process 274 with another PvD. A PvD-aware application might also be able to 275 select, on a per-connection basis, which PvDs should be used for a 276 given connection. And particularly constrained devices such as small 277 battery operated devices (e.g. IoT), or devices with limited CPU or 278 memory resources may purposefully use a single PvD while ignoring 279 some received RAs containing different PvD IDs. 281 The way an application expresses its desire to use a given PvD, or a 282 set of PvDs, or the way this selection is enforced, is out of the 283 scope of this document. Useful insights about these considerations 284 can be found in [I-D.kline-mif-mpvd-api-reqs]. 286 3.3.1. DHCPv6 configuration association 288 When a host retrieves configuration information from DHCPv6, the 289 configured elements MUST be associated with the explicit or implicit 290 PvD of the RA received on the same interface with the O-flag set 292 [RFC4861]. If multiple RAs with the O-flag set and associated with 293 different PvDs are received on the same interface, the link-local 294 address of the DHCPv6 server MAY be compared with the routers' link- 295 local addresses in order to disambiguate. If the disambiguation is 296 impossible, then the DHCPv6 configuration information MUST be 297 associated with an implicit PvD. 299 This process requires hosts to keep track of received RAs, associated 300 PvD IDs, and routers link-local addresses. 302 3.3.2. DHCPv4 configuration association 304 When a host retrieves configuration from DHCPv4 on an interface, the 305 configured elements MUST be associated with the explicit PvD, 306 received on the same interface, whose PVD ID Options L-flag is set. 307 If multiple different PvDs are found, the datalink layer address used 308 by the DHCPv4 server/relay MAY be compared with the datalink layer 309 address used by on-link advertising routers in order to disambiguate. 310 If no RA associated with a PvD ID option with the L-flag set is 311 found, or if the disambiguation fails, the IPv4 configuration 312 information MUST be associated with an implicit PvD. 314 3.3.3. Interconnection Sharing by the Host 316 The situation when a host becomes also a router by acting as a router 317 or ND proxy on a different interface (such as WiFi) to share the 318 connectivity of another interface (such as cellular), also known as 319 "tethering" is TBD but it is expected that the one or several PvD 320 associated to the shared interface will be also advertised to the 321 clients. 323 4. Provisioning Domain Identification using IKEv2 325 RFC 7296 defines Internet Key Exchange version 2 (IKEv2) which 326 includes in sections 2.19 and 3.15 a Configuration Payload (CP) which 327 may be used by an IPsec client to request configuration items (e.g., 328 addresses, recursive DNS servers). IKEv2 also negatiates traffic 329 selectors which represent the 5-tuple(s) to be protected by the 330 Security Association (SA) negotiated by IKEv2. This set of 331 information is another PvD and may include INTERNAL_IP6_ADDRESS, 332 INTERNAL_IP6_LINK, INTERNAL_IP6_SUBNET (to be used to route traffic 333 to this subent), INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN. 335 The PvD ID Configuration option for IKEv2 has the following structure 336 (similar to the RA option): 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |R| Attribute Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Seq |H|L| Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Lifetime | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | PvD ID FQDN | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 PvD ID IKEv2 Configuration Payload Attributes format 352 R-bit Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. 354 Attribute Type (15 bits) tbd by IANA PVD_ID. 356 Length Length (2 octets, unsigned integer) - Length of PvD ID FQDN + 357 2. 359 Seq Sequence number (4 bits) for the PvD Additional Information, as 360 described in Section 5. 362 H-flag (1 bit) Whether some PvD Additional Information is made 363 available through HTTP over TLS, as described in Section 5. 365 L-flag (1 bit) must be set to 0 if the Configuration Payload 366 contains only IPv6 information, else it must be set to 1. 368 Reserved (10 bits) Reserved for later use. It MUST be set to zero 369 by the sender and ignored by the receiver. 371 PvD ID FQDN The FQDN used as PvD ID in DNS binary format [RFC1035], 372 padded until the next 8 octets boundary. All the bytes after the 373 first empty DNS label MUST be set to zero by the sender and MUST 374 be ignored by the receiver. The DNS name compression technique 375 described in [RFC1035] MUST NOT be used. 377 5. Provisioning Domain Additional Information 379 Once a new PvD ID is discovered, it may be used to retrieve 380 additional information about the characteristics of the provided 381 connectivity. This set of information is called PvD Additional 382 Information, and is encoded as a JSON object [RFC7159]. 384 The purpose of this additional set of information is to securely 385 provide additional information to hosts about the connectivity that 386 is provided using a given interface and source address pair. It 387 typically includes data that would be considered too large, or not 388 critical enough, to be provided with an RA option. The information 389 contained in this object MAY be used by the operating system, network 390 libraries, applications, or users, in order to decide which set of 391 PvDs should be used for which connection, as described in 392 Section 3.3. 394 5.1. Retrieving the PvD Additional Information 396 When the H-flag of the PvD ID Option is set, hosts MAY attempt to 397 retrieve the PvD Additional Information associated with a given PvD 398 by performing an HTTP over TLS [RFC2818] GET query to https:///pvd.json [RFC5785]. On the other hand, hosts MUST NOT do so 400 whenever the H-flag is not set. 402 Note: Should the PvD AI retrieval be a MAY or a SHOULD ? Could the 403 object contain critical data, or should it only contain informational 404 data ? 406 Note that the DNS name resolution of as well as the actual 407 query MUST be performed in the PvD context associated to the PvD ID. 408 In other words, the name resolution, source address selection, as 409 well as the next-hop router selection MUST be performed while using 410 exclusively the set of configuration information attached with the 411 PvD, as defined in Section 3.3. 413 If the HTTP status of the answer is greater than or equal to 400 the 414 host MUST abandon and consider that there is no additional PvD 415 information. If the HTTP status of the answer is between 300 416 included and 399 included it MUST follow the redirection(s). If the 417 HTTP status of the answer is between 200 included and 299 included 418 the host MAY get a file containing a single JSON object. When a JSON 419 object could not be retrieved, an error message SHOULD be logged and/ 420 or displayed in a rate-limited fashion. 422 After retrieval of the PvD Additional Information, hosts MUST watch 423 the PvD ID Seq field for change. In case a different value than the 424 one in the RA Seq field is observed, or whenever the validity time 425 included in the object is expired, hosts MUST either perform a new 426 query and retrieve a new version of the object, or deprecate the 427 object and stop using it. 429 Hosts retrieving a new PvD Additional Information object MUST check 430 for the presence and validity of the mandatory fields Section 5.3. A 431 retrieved object including an outdated expiration time or missing a 432 mandatory element, MUST be ignored. In order to avoid traffic spikes 433 toward the server hosting the PvD Additional Information when an 434 object expires, a host which last retrieved an object at a time A, 435 including a validity time B, SHOULD renew the object at a uniformly 436 random time in the interval [(B-A)/2,A]. 438 In order to prevent PvD spoofing by malicious or misconfigured 439 routers, PvD Additional Information object includes a set of IPv6 440 prefixes which MUST be checked against all the Prefix Information 441 Options advertised in the Router Advertisement. If any of the 442 prefixes included in the Prefix Information Options is not in the set 443 of prefixes contained in the additional information, the PvD (the one 444 included in the RA and in the additional information) MUST be 445 considered unsafe and MUST NOT be used. While this does not prevent 446 a malicious network provider, it can be used to detect 447 misconfiguration. 449 The server serving the JSON files SHOULD also check whether the 450 client address is part of the prefixes listed into the additional 451 information and SHOULD return a 403 response code if there is no 452 match. The server MAY also use the client address to select the 453 right JSON object to be returned. 455 Note: In a similar way, a DNS server names list could be included in 456 the PvD AI in order to avoid rogue APs from inserting a different DNS 457 resolver. But this would also prevent CPEs from advertising 458 themselves as default DNS (which is usually done). SPs which really 459 want to use CPEs as DNS, for caching reasons, might find 'creative' 460 ways to go around this rule. 462 5.2. Providing the PvD Additional Information 464 Whenever the H-flag is set in the PvD RA Option, a valid PvD 465 Additional Information object MUST be made available to all hosts 466 receiving the RA. In particular, when a captive portal is present, 467 hosts MUST still be allowed to access the object, even before logging 468 into the captive portal. 470 Routers MAY increment the PVD ID Sequence number (Seq) in order to 471 inform host that a new PvD Additional Information object is available 472 and should be retrieved. 474 5.3. PvD Additional Information Format 476 The PvD Additional Information is a JSON object. 478 The following array presents the mandatory keys which MUST be 479 included in the object: 481 +----------+-------------------+-----------+------------------------+ 482 | JSON key | Description | Type | Example | 483 +----------+-------------------+-----------+------------------------+ 484 | name | Human-readable | UTF-8 | "Awesome Wifi" | 485 | | service name | string | | 486 | expires | Date after which | ISO 8601 | "2017-07-23T06:00:00Z" | 487 | | this object is | | | 488 | | not valid | | | 489 | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | 490 | | prefixes valid | strings | "2001:db8:4::/48"] | 491 | | for this PVD | | | 492 +----------+-------------------+-----------+------------------------+ 494 A retrieved object which does not include a valid string associated 495 with the "name" key at the root of the object, or a valid date 496 associated with the "expiration" key, also at the root of the object, 497 MUST be ignored. In such cases, an error message SHOULD be logged 498 and/or displayed in a rate-limited fashion. 500 The following table presents some optional keys which MAY be included 501 in the object. 503 +-----------------+-----------------------+---------+---------------+ 504 | JSON key | Description | Type | Example | 505 +-----------------+-----------------------+---------+---------------+ 506 | localizedName | Localized user- | UTF-8 | "Wifi Genial" | 507 | | visible service name, | string | | 508 | | language can be | | | 509 | | selected based on the | | | 510 | | HTTP Accept-Language | | | 511 | | header in the | | | 512 | | request. | | | 513 | noInternet | No Internet, set when | boolean | true | 514 | | the PvD only provides | | | 515 | | restricted access to | | | 516 | | a set of services. | | | 517 | characteristics | Connectivity | JSON | See Section | 518 | | characteristics | object | 5.3.1 | 519 | metered | metered, when the | boolean | false | 520 | | access volume is | | | 521 | | limited. | | | 522 +-----------------+-----------------------+---------+---------------+ 524 It is worth noting that the JSON format allows for extensions. 525 Whenever an unknown key is encountered, it MUST be ignored along with 526 its associated elements, unless specified otherwise in future 527 updating documents. 529 5.3.1. Connectivity Characteristics Information 531 The following set of keys can be used to signal certain 532 characteristics of the connection towards the PvD. 534 They should reflect characteristics of the overall access technology 535 which is not limited to the link the host is connected to, but rather 536 a combination of the link technology, CPE upstream connectivity, and 537 further quality of service considerations. 539 +---------------+--------------+---------------------+--------------+ 540 | JSON key | Description | Type | Example | 541 +---------------+--------------+---------------------+--------------+ 542 | maxThroughput | Maximum | object({down(int), | {"down": | 543 | | achievable | up(int)}) in kb/s | 10000, "up": | 544 | | throughput | | 5000} | 545 | minLatency | Minimum | object({down(int), | {"down": 10, | 546 | | achievable | up(int)}) in ms | "up": 20} | 547 | | latency | | | 548 | rl | Maximum | object({down(int), | {"down": | 549 | | achievable | up(int)}) in losses | 0.1, "up": | 550 | | reliability | every 1000 packets | 1} | 551 +---------------+--------------+---------------------+--------------+ 553 5.3.2. Private Extensions 555 JSON keys starting with "x-" are reserved for private use and can be 556 utilized to provide information that is specific to vendor, user or 557 enterprise. It is RECOMMENDED to use one of the patterns "x-FQDN- 558 KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or 559 PEN is a private enterprise number [PEN] under control of the author 560 of the extension to avoid collisions. 562 5.3.3. Example 564 Here are two examples based on the keys defined in this section. 566 { 567 "name": "Foo Wireless", 568 "localizedName": "Foo-France Wifi", 569 "expires": "2017-07-23T06:00:00Z", 570 "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"], 571 "characteristics": { 572 "maxThroughput": { "down":200000, "up": 50000 }, 573 "minLatency": { "down": 0.1, "up": 1 } 574 } 575 } 576 { 577 "name": "Bar 4G", 578 "localizedName": "Bar US 4G", 579 "expires": "2017-07-23T06:00:00Z", 580 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 581 "metered": true, 582 "characteristics": { 583 "maxThroughput": { "down":80000, "up": 20000 } 584 } 585 } 587 6. Security Considerations 589 Although some solutions such as IPSec or SEND [RFC3971] can be used 590 in order to secure the IPv6 Neighbor Discovery Protocol, actual 591 deployments largely rely on link layer or physical layer security 592 mechanisms (e.g. 802.1x [IEEE8021X]). 594 This specification does not improve the Neighbor Discovery Protocol 595 security model, but extends the purely link-local configuration 596 retrieval mechanisms with HTTP-over-TLS communications. 598 During the exchange, the server authenticity is verified by the mean 599 of a certificate, validated based on the FQDN found in the Router 600 Advertisement (e.g. using a list of pre-installed CA certificates, or 601 DNSSec [RFC4035] with DNS Based Authentication of Named Entities 602 [RFC6698]). This authentication creates a secure binding between the 603 information provided by the trusted Router Advertisement, and the 604 HTTP server. 606 The IPv6 prefixes list included in the PvD Additional Information 607 JSON object is used to validate that the prefixes included in the 608 Router Advertisements are really part of the PvD. 610 Note: The previous point does not protect against attacker performing 611 NAT66. It would if we mandate the source-address validation on the 612 server side, but not protect against tunnels. In other words, 613 address based security will not protect against rogue APs, but may 614 prevent the use of NAT66. 616 For privacy reasons, it is desirable that the PvD Additional 617 Information object may only be retrieved by the hosts using the given 618 PvD. Host identity SHOULD be validated based on the client address 619 that is used during the HTTP query. 621 7. IANA Considerations 623 IANA is kindly requested to allocate a new IPv6 Neighbor Discovery 624 option number for the PvD ID Router Advertisement option and a new 625 IKEv2 Configuration Payload Attribute Types for PVD_ID. 627 TBD: JSON keys will need a new register. 629 8. Acknowledgements 631 Many thanks to M. Stenberg and S. Barth for their earlier work: 632 [I-D.stenberg-mif-mpvd-dns]. 634 Thanks also to Ray Bellis, Lorenzo Colitti, Thierry Danis, Marcus 635 Keane, Erik Kline, Jen Lenkova, Mark Townsley and James Woodyatt for 636 useful and interesting discussions. 638 Finally, many thanks to Thierry Danis for his implementation work: 639 [github]. 641 9. References 643 9.1. Normative references 645 [RFC1035] Mockapetris, P., "Domain names - implementation and 646 specification", STD 13, RFC 1035, November 1987. 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 652 Discovery for IP Version 6 (IPv6)", RFC 2461, December 653 1998. 655 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 656 RFC2818, May 2000, 657 . 659 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 660 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 661 September 2007. 663 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 664 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 665 10.17487/RFC5785, April 2010, 666 . 668 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 669 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 670 2014, . 672 9.2. Informative references 674 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 675 Neighbor Discovery (SEND)", RFC 3971, March 2005. 677 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 678 Rose, "Protocol Modifications for the DNS Security 679 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 680 . 682 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 683 More-Specific Routes", RFC 4191, November 2005. 685 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 686 Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/ 687 RFC5798, March 2010, 688 . 690 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 691 "IPv6 Router Advertisement Options for DNS Configuration", 692 RFC 6106, November 2010. 694 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 695 of Named Entities (DANE) Transport Layer Security (TLS) 696 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 697 2012, . 699 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 700 "Default Address Selection for Internet Protocol Version 6 701 (IPv6)", RFC 6724, September 2012. 703 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 704 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 705 . 707 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 708 "Captive-Portal Identification Using DHCP or Router 709 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 710 December 2015, . 712 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 713 Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/ 714 RFC8028, November 2016, 715 . 717 [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] 718 Baker, F., Bowers, C., and J. Linkova, "Enterprise 719 Multihoming using Provider-Assigned Addresses without 720 Network Prefix Translation: Requirements and Solution", 721 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work 722 in progress), October 2016. 724 [I-D.stenberg-mif-mpvd-dns] 725 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 726 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 727 (work in progress), October 2015. 729 [I-D.kline-mif-mpvd-api-reqs] 730 Kline, E., "Multiple Provisioning Domains API 731 Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in 732 progress), November 2015. 734 [PEN] IANA, "Private Enterprise Numbers", . 737 [IEEE8021X] 738 IEEE, "IEEE Standards for Local and Metropolitan Area 739 Networks: Port based Network Access Control, IEEE Std", . 741 [github] Cisco, "IPv6-mPvD github repository", . 744 Appendix A. Changelog 746 Note to RFC Editors: Remove this section before publication. 748 A.1. Version 00 750 Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke 751 and based on Basile's work. 753 A.2. Version 01 755 Major rewrite intended to focus on the the retained solution based on 756 corridors, online, and WG discussions. Edited by Pierre Pfister. 757 The following list only includes major changes. 759 PvD ID is an FQDN retrieved using a single RA option. This option 760 contains a sequence number for push-based updates, a new H-flag, 761 and a L-flag in order to link the PvD with the IPv4 DHCP server. 763 A lifetime is included in the PvD ID option. 765 Detailed Hosts and Routers specifications. 767 Additional Information is retrieved using HTTP-over-TLS when the 768 PvD ID Option H-flag is set. Retrieving the object is optional. 770 The PvD Additional Information object includes a validity date. 772 DNS-based approach is removed as well as the DNS-based encoding of 773 the PvD Additional Information. 775 Major cut in the list of proposed JSON keys. This document may be 776 extended later if need be. 778 Monetary discussion is moved to the appendix. 780 Clarification about the 'prefixes' contained in the additional 781 information. 783 Clarification about the processing of DHCPv6. 785 Appendix B. Connection monetary cost 787 NOTE: This section is included as a request for comment on the 788 potential use and syntax. 790 The billing of a connection can be done in a lot of different ways. 791 The user can have a global traffic threshold per month, after which 792 his throughput is limited, or after which he/she pays each megabyte. 793 He/she can also have an unlimited access to some websites, or an 794 unlimited access during the weekends. 796 An option is to split the bill in elementary billings, which have 797 conditions (a start date, an end date, a destination IP address...). 798 The global billing is an ordered list of elementary billings. To 799 know the cost of a transmission, the host goes through the list, and 800 the first elementary billing whose the conditions are fulfilled gives 801 the cost. If no elementary billing conditions match the request, the 802 host MUST make no assumption about the cost. 804 B.1. Conditions 806 Here are the potential conditions for an elementary billing. All 807 conditions MUST be fulfill. 809 +-----------+-------------+---------------+-------------------------+ 810 | Key | Description | Type | JSON Example | 811 +-----------+-------------+---------------+-------------------------+ 812 | beginDate | Date before | ISO 8601 | "1977-04-22T06:00:00Z" | 813 | | which the | | | 814 | | billing is | | | 815 | | not valid | | | 816 | endDate | Date after | ISO 8601 | "1977-04-22T06:00:00Z" | 817 | | which the | | | 818 | | billing is | | | 819 | | not valid | | | 820 | domains | FQDNs whose | array(string) | ["deezer.com","spotify. | 821 | | the billing | | com"] | 822 | | is limited | | | 823 | prefixes4 | IPv4 | array(string) | ["78.40.123.182/32","78 | 824 | | prefixes | | .40.123.183/32"] | 825 | | whose the | | | 826 | | billing is | | | 827 | | limited | | | 828 | prefixes6 | IPv6 | array(string) | ["2a00:1450:4007:80e::2 | 829 | | prefixes | | 00e/64"] | 830 | | whose the | | | 831 | | billing is | | | 832 | | limited | | | 833 +-----------+-------------+---------------+-------------------------+ 835 B.2. Price 837 Here are the different possibilities for the cost of an elementary 838 billing. A missing key means "all/unlimited/unrestricted". If the 839 elementary billing selected has a trafficRemaining of 0 kb, then it 840 means that the user has no access to the network. Actually, if the 841 last elementary billing has a trafficRemaining parameter, it means 842 that when the user will reach the threshold, he/she will not have 843 access to the network anymore. 845 +------------------+------------------+--------------+--------------+ 846 | Key | Description | Type | JSON Example | 847 +------------------+------------------+--------------+--------------+ 848 | pricePerGb | The price per | float | 2 | 849 | | Gigabit | (currency | | 850 | | | per Gb) | | 851 | currency | The currency | ISO 4217 | "EUR" | 852 | | used | | | 853 | throughputMax | The maximum | float (kb/s) | 100000 | 854 | | achievable | | | 855 | | throughput | | | 856 | trafficRemaining | The traffic | float (kB) | 12000000 | 857 | | remaining | | | 858 +------------------+------------------+--------------+--------------+ 860 B.3. Examples 862 Example for a user with 20 GB per month for 40 EUR, then reach a 863 threshold, and with unlimited data during weekends and to 864 example.com: 866 [ 867 { 868 "domains": ["example.com"] 869 }, 870 { 871 "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] 872 }, 873 { 874 "beginDate": "2016-07-16T00:00:00Z", 875 "endDate": "2016-07-17T23:59:59Z", 876 }, 877 { 878 "beginDate": "2016-06-20T00:00:00Z", 879 "endDate": "2016-07-19T23:59:59Z", 880 "trafficRemaining": 12000000 881 }, 882 { 883 "throughputMax": 100000 884 } 885 ] 887 If the host tries to download data from example.com, the conditions 888 of the first elementary billing are fulfilled, so the host takes this 889 elementary billing, finds no cost indication in it and so deduces 890 that it is totally free. If the host tries to exchange data with 891 foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of 892 the first, second and third elementary billing are not fulfilled. 894 But the conditions of the fourth are. So the host takes this 895 elementary billing and sees that there is a threshold, 12 GB are 896 remaining. 898 Another example for a user abroad, who has 3 GB per year abroad, and 899 then pay each MB: 901 [ 902 { 903 "beginDate": "2016-02-10T00:00:00Z", 904 "endDate": "2017-02-09T23:59:59Z", 905 "trafficRemaining": 3000000 906 }, 907 { 908 "pricePerGb": 30, 909 "currency": "EUR" 910 } 911 ] 913 Authors' Addresses 915 Basile Bruneau 916 Ecole Polytechnique 917 Vannes 56000 918 France 920 Email: basile.bruneau@polytechnique.edu 922 Pierre Pfister 923 Cisco 924 11 Rue Camille Desmoulins 925 Issy-les-Moulineaux 92130 926 France 928 Email: ppfister@cisco.com 930 David Schinazi 931 Apple 933 Email: dschinazi@apple.com 935 Tommy Pauly 936 Apple 938 Email: tpauly@apple.com 939 Eric Vyncke 940 Cisco 941 De Kleetlaan, 6 942 Diegem 1831 943 Belgium 945 Email: evyncke@cisco.com