idnits 2.17.1 draft-bruneau-intarea-provisioning-domains-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: September 14, 2017 Cisco 6 D. Schinazi 7 T. Pauly 8 Apple 9 E. Vyncke, Ed. 10 Cisco 11 March 13, 2017 13 Proposals to discover Provisioning Domains 14 draft-bruneau-intarea-provisioning-domains-00 16 Abstract 18 This document describes one possible way for hosts to retrieve 19 additional information about their Internet access configuration. 20 The set of configuration items required to access the Internet is 21 called a Provisioning Domain (PvD) and is identified by a Fully 22 Qualified Domain Name. 24 This document separates the way of getting the Provisioning Domain 25 identifier, the way of getting the Provisioning Domain information 26 and the potential information contained in the Provisioning Domain. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 14, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 3. Retrieving the PvD ID . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Using One Router Advertisement per PvD . . . . . . . . . 4 67 3.2. Rationale for not selecting other techniques . . . . . . 5 68 3.2.1. Using DNS-SD . . . . . . . . . . . . . . . . . . . . 5 69 3.2.2. Using Reverse DNS lookup . . . . . . . . . . . . . . 5 70 3.3. IoT Considerations . . . . . . . . . . . . . . . . . . . 6 71 3.4. Linking IPv4 Information to an IPv6 PvD . . . . . . . . . 6 72 4. Getting the full set of PvD information . . . . . . . . . . . 6 73 4.1. Using the PvD Bootstrap Information Option . . . . . . . 7 74 4.2. Downloading a JSON file over HTTPS . . . . . . . . . . . 7 75 4.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 7 76 4.2.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Using DNS TXT ressource records (not selected) . . . . . 8 78 4.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 8 79 4.3.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 8 80 4.3.3. Using DNS SRV ressource records . . . . . . . . . . . 8 81 5. PvD Information . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.1. PvD Name . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.2. Trust of the bootstrap PvD . . . . . . . . . . . . . . . 10 84 5.3. Reachability . . . . . . . . . . . . . . . . . . . . . . 11 85 5.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 12 86 5.5. Connectivity Characteristics . . . . . . . . . . . . . . 13 87 5.6. Connection monetary cost . . . . . . . . . . . . . . . . 14 88 5.6.1. Conditions . . . . . . . . . . . . . . . . . . . . . 15 89 5.6.2. Price . . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . 16 91 5.7. Private Extensions . . . . . . . . . . . . . . . . . . . 17 92 5.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.8.1. Using JSON . . . . . . . . . . . . . . . . . . . . . 17 94 5.8.2. Using DNS TXT records . . . . . . . . . . . . . . . . 18 95 6. Use case examples . . . . . . . . . . . . . . . . . . . . . . 19 96 6.1. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 19 97 6.2. VPN/Extranet example . . . . . . . . . . . . . . . . . . 19 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 9.1. Normative references . . . . . . . . . . . . . . . . . . 19 102 9.2. Informative references . . . . . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 It has become very common in modern networks that hosts have Internet 108 or more specific access through different networking interfaces, 109 tunnels, or next-hop routers. The concept of Provisioning Domain 110 (PvD) was defined in RFC7556 [RFC7556] as a set of network 111 configuration information which can be used by hosts in order to 112 access the network. In this document, PvDs are associated with a 113 Fully Qualified Domain Name (called PvD ID) which is used within the 114 host to identify correlated sets of configuration data and also used 115 to retrieve additional information about the services that the 116 network provides. 118 Devices connected to the Internet through multiple interfaces would 119 typically be provisioned with one PvD per interface, but it is worth 120 noting that multiple PvDs with different PvD IDs could be provisioned 121 on any host interface, as well as noting that the same PvD ID could 122 be used on different interfaces in order to inform the host that both 123 PvDs, on different interfaces, ultimately provide equivalent 124 services. 126 This document proposes multiple methods allowing the host to to 127 retrieve the PvD ID associated with a set of networking discover the 128 PvD and retrieve the PvD information. It also explains configuration 129 as well as the methods and format in order to retrieve some of the 130 parameters that can describe a PvD. 132 2. Terminology 134 PvD A provisioning domain, usually with a set of 135 provisioning domain information; for more 136 information, see [RFC7556]. 138 2.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in RFC 143 2119 [RFC2119]. 145 3. Retrieving the PvD ID 147 In this document, each provisioning domain is identified by a PvD ID. 148 The PvD ID is a Fully Qualified Domain Name which belongs to the 149 network operator to avoid conflicts among network operators. The 150 same PvD ID can exist in several access networks if the set of 151 configuration information is identical in all those networks (such as 152 in all home networks of a residential subscriber). Within a host, 153 the PvD ID SHOULD be associated to all the configuration information 154 associated to this PvD ID; this allows for easy update and removal of 155 information while keeping a consistent state. 157 This section assumes that IPv6 Router Advertisements are used to 158 discover the PvD ID and explains why this technique was selected. 160 3.1. Using One Router Advertisement per PvD 162 Hosts receive implicit PvDs by the means of Router Advertisements 163 (RA). 165 A router MAY add a single PvD ID Option in its RAs. The PvD ID 166 specified in this option is then associated with all the Prefix 167 Information Options (PIO) included in the RA (albeit it is expected 168 that only one PIO will be included in the RA). All other information 169 contained in the RA (notably the RDNSS and Route Information Option) 170 are to be associated with the PvD ID. The set of information 171 contained in the RA forms the bootstrap (or hint) PvD. A new RA 172 option will be required to convey the PvD ID. 174 When a host receives an RA which does not include a PvD ID Option, 175 the set of information included in the RA (such as Recursive DNS 176 server, IPv6 prefix) is attached to an implicit PvD identified by the 177 local interface ID on which the RA is received, and by the link-local 178 address of the router sending the RA. 180 In the cases where a router should provide multiple independent PvDs 181 to all hosts, including non-PvD aware hosts, it should send multiple 182 RAs, as proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] 183 using different source link-local addresses (LLA); the datalink layer 184 (MAC) address could be the same for all the different RA. If the 185 router is actually a VRRP instance, then the procedure is identical 186 except that the virtual link-layer address is used as well as virtual 187 link-layer addresses. 189 Using RA allows for an early discovery of the PvD ID as it is early 190 in the interface start-up. As RA is usually processed in the kernel, 191 this requires a host OS upgrade. The RA SHOULD contain other PvD 192 information as explained in section Section 4.1. 194 3.2. Rationale for not selecting other techniques 196 There are other techniques to discover the PvD ID that were not 197 selected by the authors and reviewers, this section explains why. 198 The design goal was to be as reliable as possible (do not depend on 199 Internet connectivity) and as fast as possible. 201 3.2.1. Using DNS-SD 203 For each received RA including a RDNSS option as well as a DNS search 204 list option, the host MAY retrieve the PvD ID by querying the 205 configured DNS server for records of type PTR associated with 206 _pvd.. If a PvD ID is configured, the DNS recursive 207 resolver MUST reply with the PvD ID as a PTR record. NXDOMAIN is 208 returned otherwise. 210 When the RDNSS address is link-local, the host MAY retrieve the PvD 211 ID before configuring its global scope address(es). 213 Relying on a valid DNS service at the interface bootstrap can lead 214 into delay to start the interface or starting without enough 215 information: for example when the RDNSS is a non local address and 216 there is no Internet connectivity. 218 3.2.2. Using Reverse DNS lookup 220 [I-D.stenberg-mif-mpvd-dns] proposes a solution to get the name of 221 the PvD using a reverse DNS lookup based on the host global 222 address(es). It merely relies on prepending a well-known prefix 223 '_pvd' to the reverse lookup, for example ' _pvd....ip6.arpa.'. 225 However, the PvD information is typically provided by the network 226 operator, whereas the reverse DNS zone could be delegated from the 227 operator to the network user, in which case it would not work. 229 It also requires a fully functional global address to retrieve the 230 information which may be too late for a correct host configuration. 231 One advantage is that it does not require any change in the IPv6 232 protocol and no change in the host kernel or even in the CPE. 234 3.3. IoT Considerations 236 TBD: should state that when end-host (IoT) cannot impletement 237 completely this RFC it MAY select any of the PvD or the router SHOULD 238 send a single unicast RA (hence a single PvD) in response to the RS 239 or none if it detects that it cannot offer the right set of network 240 services. 242 3.4. Linking IPv4 Information to an IPv6 PvD 244 The document describes IPv6-only PvD but there are multiple ways to 245 link the set of IPv4 configuration information received by DHCPv4: 247 o correlation based on the data-link layer address of the source, if 248 the IPv6 RA and the DHCPv4 response have the same data-link layer 249 address, then the information contained in the IPv4 DHCP can be 250 linked to the IPv6 PvD; 252 o correlation based on the interface when there is no data-link 253 address on the link (such as a 3GPP link), then the information 254 contained in the IPv4 PDP context can be linked to the IPv6 PvD 255 (*** TO BE VERIFIED before going -01); 257 o correlation based on the DNS search list, if the DNS search lists 258 are identical between the IPv6 RDNSS and the DHCPV4 response, then 259 the information contained in the IPv4 DHCP response can be linked 260 to the IPv6 PvD. 262 The correlation could be useful for some PvD information such as 263 Internet reachability, use of captive portal, display name of the 264 PvD, ... 266 In cases where the IPv4 configuration information could not be 267 associated with a PvD, hosts MUST consider it as attached to an 268 independent implicit PvD containing no other information than what is 269 provided through DHCPv4. 271 4. Getting the full set of PvD information 273 Once the PvD ID is known, it MAY be used to retrieve additional 274 information. PvD Information is modeled as a key-value dictionary 275 which keys are ASCII strings of arbitrary length, and values are 276 either strings (encoding can vary), ordered list of values 277 (recursively), or a dictionary (recursively). 279 The PvD Information may be retrieved from multiple sources (from the 280 bootstrap PvD contained in the RA to the secondary/extended PvD 281 described in this section); the PvD ID is then used to correlate the 282 information from different sources. The way a host should operate 283 when receiving conflicting information is TBD but it SHOULD at least 284 override information from less authenticated sources (RA) by more 285 authenticated sources (via TLS). 287 4.1. Using the PvD Bootstrap Information Option 289 Routers MAY transmit, in addition to the PvD ID option, a PvD 290 Bootstrap Information option, containing a first subset of PvD 291 information. The additional pieces of bootstrap PvD information data 292 set are transmitted using the short-hand notation proposed in 293 Section 5. This requires another RA option. 295 As there is a size limit on the amount of information a single RA can 296 convey, it is likely that the PvD Bootstrap Information option may 297 not contain the whole set of PvD Information. The set of PvD 298 information included in the RA is called PvD Bootstrap Information. 300 4.2. Downloading a JSON file over HTTPS 302 The host SHOULD try to download a JSON formatted file over HTTPS in 303 order to get more PvD information. 305 The host MUST perform an HTTP query to https:///v1.json. If 306 the HTTP status of the answer is greater than 400 the host MUST 307 abandon and consider that there is no additional PvD information. If 308 the HTTP status of the answer is between 300 and 400 it MUST follow 309 the redirection(s). If the HTTP status of the answer is between 200 310 and 300 the host MAY get a file containing a single JSON object. 312 The host MUST respect the cache information in the HTTP header, if 313 any, and at expiration of the downloaded object, it must fetch a 314 fresher version if any. 316 4.2.1. Advantages 318 The JSON format allows advanced structures. 320 It can be secured using HTTPS (and DNSSEC). 322 It is easier to update a file on a web server than to edit DNS 323 records. It can be especially important if we want providers to be 324 able to often update the remaining phone plan of the user. 326 4.2.2. Disadvantages 328 It is slower than using DNS because HTTPS uses TCP and TLS and needs 329 more packets to be exchanged to get the file. 331 An additional HTTPS server must be deployed and configured. 333 4.3. Using DNS TXT ressource records (not selected) 335 This approach was not selected during the design team meeting but has 336 kept here for reference, it will be removed after global consensus is 337 reached. 339 The host could perform a DNS query for TXT resource records (RR) for 340 the FQDN used as PvD ID (alternatively for _pvd.). For each 341 retrieved PvD ID, the DNS query MUST be sent to the DNS server 342 configured from the same router advertisement as the PvD ID. Syntax 343 of the TXT response is defined in Section 5 (Section 5). 345 4.3.1. Advantages 347 It requires a single round-time trip in order to retrieve the PvD 348 Information. 350 It can be secured using DNSSEC. 352 4.3.2. Disadvantages 354 A TXT record is limited to 65535 characters in theory but large size 355 of TXT records could require either DNS over TCP (so loosing the 356 1-RTT advantage) or fragmented UDP packets (which could be dropped by 357 a bad choice of security policy). Large TXT records could also be 358 used to mount an amplification attack. 360 4.3.3. Using DNS SRV ressource records 362 It is expected that the DNS TXT records will be sufficient for the 363 host to configure itself with basic networking and policy 364 configuration. Nevertheless, if further information is required, or 365 when a different security model shall be used to access the PvD 366 Information, a SRV Resource Record including a full URL MAY be 367 included as a response, expecting the host to query this URL in order 368 to retrieve additional PvD information. 370 5. PvD Information 372 PvD information is a set of key-value pairs. Keys are ASCII 373 character strings. Values are either a character string, an ordered 374 list of values, or an embedded dictionary. Value types and default 375 behavior with respect to some specific keys MAY be further specified 376 (recursively). Some keys have a default value as described in the 377 following sections. When there is an expiration time in a PvD, then 378 the information MUST be refreshed before the expiration time. The 379 behavior of a host when the refresh operation is not successful is 380 TBD. 382 Nodes using the PvD MUST support the two encodings: 384 JSON syntax for the complete set of PvD information; 386 short-hand notation for the bootstrap PvD. 388 When the PvD information is transferred as a JSON file, then the key 389 used is the second column of the following table. The syntax of the 390 JSON file is obvioulsy JSON and is richer than the short-hand 391 notation specified in the next paragraph. 393 When transmitting more information than the PvD ID in the RA (or when 394 DNS TXT resource records are used), the shorthand notataion for PvD 395 information is used and consists of a string containing several 396 "key=value;" substrings. The "key" is the first column of the 397 following tables, the value is encoded as: 399 Shorthand notation for values: 401 integer: expressed in decimal format with a '.' (dot) used for 402 decimals; 404 string: expressed as UTF-8 encoded string, delimited by single 405 quote character, the single quote character can be expressed by 406 two consecutive single quote character; 408 boolean: expressed as '0' for false and '1' for true; 410 IPv6 address: printed as RFC5952 [RFC5952]. 412 5.1. PvD Name 414 PvD SHOULD have a human readable name in order to be presented on a 415 GUI. The name can also be localized. 417 +------------+------------+---------------+--------------+----------+ 418 | DNS TXT ke | JSON key | Description | Type | JSON | 419 | y/Bootstra | | | | Example | 420 | p PvD key | | | | | 421 +------------+------------+---------------+--------------+----------+ 422 | n | name | User-visible | human- | "Foobar | 423 | | | service name, | readable | Service" | 424 | | | SHOULD be | UTF-8 string | | 425 | | | part of the | | | 426 | | | bootstrap PvD | | | 427 | nl10n | localizedN | Localized | human- | "Service | 428 | | ame | user-visible | readable | Blabla" | 429 | | | service name, | UTF-8 string | | 430 | | | language can | | | 431 | | | be selected | | | 432 | | | based on the | | | 433 | | | HTTP Accept- | | | 434 | | | Language | | | 435 | | | header in the | | | 436 | | | request. | | | 437 +------------+------------+---------------+--------------+----------+ 439 5.2. Trust of the bootstrap PvD 441 The content of the bootstrap PvD (from the original RA) cannot be 442 trusted as it is not authenticated. But, the extended PvD can be 443 associated with the PvD ID (as the PvD ID is used to construct the 444 extended PvD URL) and trusted by the used of TLS. The extended PvD 445 SHOULD therefore include the following information elements and, if 446 they are present, the host MUST verify that the all PIO of the RA 447 fits into the master prefix list. If any PIO prefix from the 448 bootstrap PvD does not fit in the master prefix array, then all 449 information received by the bootstrap PvD must be invalidated. In 450 short, the masterIPv6Prefix received over TLS is used to authenticate 451 the bootstrap PvD. 453 The values of the bootstrap PvD (RDNSS, ...) are overwritten by the 454 values contained in the trusted extended PvD if they are present. 456 +-----+------------------+-------------+----------+-----------------+ 457 | DNS | JSON key | Description | Type | JSON Example | 458 | TXT | | | | | 459 | key | | | | | 460 +-----+------------------+-------------+----------+-----------------+ 461 | mp6 | masterIpv6Prefix | All the | Array of | ["2001:db8::/32 | 462 | | | IPv6 | IPv6 | "] | 463 | | | prefixes | prefixes | | 464 | | | linked to | | | 465 | | | this PvD | | | 466 | | | (such as a | | | 467 | | | /29 for the | | | 468 | | | ISP). | | | 469 +-----+------------------+-------------+----------+-----------------+ 471 5.3. Reachability 473 The following set of keys can be used to specify the set of services 474 for which the respective PvD should be used. If present they MUST be 475 honored by the client, i.e., if the PvD is marked as not usable for 476 Internet access (walled garden), then it MUST NOT be used for 477 Internet access. If the usability is limited to a certain set of 478 domain or address prefixes (typical VPN access), then a different PvD 479 MUST be used for other destinations. 481 +-----+---------------+---------------+-----------+-----------------+ 482 | DNS | JSON key | Description | Type | JSON Example | 483 | TXT | | | | | 484 | key | | | | | 485 +-----+---------------+---------------+-----------+-----------------+ 486 | s | noInternet | Internet | boolean | true | 487 | | | inaccessible | | | 488 | cp | captivePortal | Presence of a | boolean | false | 489 | | | captive | | | 490 | | | portal | | | 491 | z | dnsZones | DNS zones | array of | ["foo.com","sub | 492 | | | accessible | DNS zone | .bar.com"] | 493 | | | and | | | 494 | | | searchable | | | 495 | 6 | prefixes6 | IPv6-prefixes | array of | ["2001:db8:a::/ | 496 | | | accessible | IPv6 | 48","2001:db8:b | 497 | | | via this PvD | prefixes | :c::/64"] | 498 | 4 | prefixes4 | IPv4-prefixes | array of | ["192.0.2.0/24" | 499 | | | accessible | IPv4 | ,"2.3.0.0/16"] | 500 | | | | prefixes | | 501 | | | | in CIDR | | 502 | | | | reachable | | 503 | | | | via this | | 504 | | | | PvD | | 505 +-----+---------------+---------------+-----------+-----------------+ 507 5.4. DNS Configuration 509 The following set of keys can be used to specify the DNS 510 configuration for the respective PvD. If present, they MUST be 511 honored and used by the client whenever it wishes to access a 512 resource described by the PvD. 514 +-----+------------+-------------+-----------+----------------------+ 515 | DNS | JSON key | Description | Value | JSON Example | 516 | TXT | | | | | 517 | key | | | | | 518 +-----+------------+-------------+-----------+----------------------+ 519 | r | dnsServers | Recursive | array of | ["2001:db8::1","192. | 520 | | | DNS server | IPv6 and | 0.2.2"] | 521 | | | | IPv4 | | 522 | | | | addresses | | 523 | d | dnsSearch | DNS search | array of | ["foo.com","sub.bar. | 524 | | | domains | search | com"] | 525 | | | | domains | | 526 +-----+------------+-------------+-----------+----------------------+ 528 5.5. Connectivity Characteristics 530 NOTE: open question to the authors/reviewers: should this document 531 include this section or is it useless? 533 The following set of keys can be used to signal certain 534 characteristics of the connection towards the PvD. 536 They should reflect characteristics of the overall access technology 537 which is not limited to the link the host is connected to, but rather 538 a combination of the link technology, CPE upstream connectivity, and 539 further quality of service considerations. 541 +------+------------------+------------+--------------+-------------+ 542 | DNS | JSON key | Descriptio | Type | JSON | 543 | TXT | | n | | Example | 544 | key | | | | | 545 +------+------------------+------------+--------------+-------------+ 546 | tp | throughputMax | Maximum | object({down | {"down": | 547 | | | achievable | (int), | 10000, | 548 | | | throughput | up(int)}) in | "up": 5000} | 549 | | | (e.g. CPE | kb/s | | 550 | | | downlink/u | | | 551 | | | plink) | | | 552 | lt | latencyMin | Minimum | object({down | {"down": | 553 | | | achievable | (int), | 10, "up": | 554 | | | latency | up(int)}) in | 20} | 555 | | | | ms | | 556 | rl | reliabilityMax | Maximum | object({down | {"down": | 557 | | | achievable | (int), | 1000, "up": | 558 | | | reliabilit | up(int)}) in | 800} | 559 | | | y | 1/1000 | | 560 | cp | captivePortal | Captive | URL of the | "https://ex | 561 | | | portal | portal | ample.com" | 562 | nat | NAT | IPv4 NAT | boolean | true | 563 | | | in place | | | 564 | natt | NAT Time-out | The value | Integer | 30 | 565 | o | | in seconds | | | 566 | | | of the NAT | | | 567 | | | time-out | | | 568 | srh | segmentRoutingHe | The IPv6 | Binary | ... | 569 | | ader | Segment | string | | 570 | | | Routing | | | 571 | | | Header to | | | 572 | | | be used | | | 573 | | | between | | | 574 | | | the IPv6 | | | 575 | | | header and | | | 576 | | | any other | | | 577 | | | headers | | | 578 | | | when using | | | 579 | | | this PvD | | | 580 | srhD | segmentRoutingHe | The DNS | Ascii string | srh.pvd-foo | 581 | NS | aderDnsFQDN | FQDN which | | .example.or | 582 | | | is used to | | g | 583 | | | retrieved | | | 584 | | | the actual | | | 585 | | | IPv6 | | | 586 | | | Segment | | | 587 | | | Routing | | | 588 | | | Header to | | | 589 | | | be used | | | 590 | | | between | | | 591 | | | the IPv6 | | | 592 | | | header and | | | 593 | | | any other | | | 594 | | | headers | | | 595 | | | when using | | | 596 | | | this PvD | | | 597 | cost | cost | Cost of | object | See Section | 598 | | | using the | | 5.6 | 599 | | | connection | | | 600 +------+------------------+------------+--------------+-------------+ 602 5.6. Connection monetary cost 604 NOTE: This section is included as a request for comment on the 605 potential use and syntax. 607 The billing of a connection can be done in a lot of different ways. 608 The user can have a global traffic threshold per month, after which 609 his throughput is limited, or after which he/she pays each megabyte. 610 He/she can also have an unlimited access to some websites, or an 611 unlimited access during the weekends. 613 We propose to split the final billing in elementary billings, which 614 have conditions (a start date, an end date, a destination IP 615 address...). The global billing is an ordered list of elementary 616 billings. To know the cost of a transmission, the host goes through 617 the list, and the first elementary billing whose the conditions are 618 fulfilled gives the cost. If no elementary billing conditions match 619 the request, the host MUST make no assumption about the cost. 621 5.6.1. Conditions 623 Here are the potential conditions for an elementary billing. All 624 conditions MUST be fulfill. 626 Note: the final version should use short-hand key names. 628 +-----------+-------------+---------------+-------------------------+ 629 | Key | Description | Type | JSON Example | 630 +-----------+-------------+---------------+-------------------------+ 631 | beginDate | Date before | ISO 8601 | "1977-04-22T06:00:00Z" | 632 | | which the | | | 633 | | billing is | | | 634 | | not valid | | | 635 | endDate | Date after | ISO 8601 | "1977-04-22T06:00:00Z" | 636 | | which the | | | 637 | | billing is | | | 638 | | not valid | | | 639 | domains | FQDNs whose | array(string) | ["deezer.com","spotify. | 640 | | the billing | | com"] | 641 | | is limited | | | 642 | prefixes4 | IPv4 | array(string) | ["78.40.123.182/32","78 | 643 | | prefixes | | .40.123.183/32"] | 644 | | whose the | | | 645 | | billing is | | | 646 | | limited | | | 647 | prefixes6 | IPv6 | array(string) | ["2a00:1450:4007:80e::2 | 648 | | prefixes | | 00e/64"] | 649 | | whose the | | | 650 | | billing is | | | 651 | | limited | | | 652 +-----------+-------------+---------------+-------------------------+ 654 5.6.2. Price 656 Here are the different possibilities for the cost of an elementary 657 billing. A missing key means "all/unlimited/unrestricted". If the 658 elementary billing selected has a trafficRemaining of 0 kb, then it 659 means that the user has no access to the network. Actually, if the 660 last elementary billing has a trafficRemaining parameter, it means 661 that when the user will reach the threshold, he/she will not have 662 access to the network anymore. 664 +------------------+------------------+--------------+--------------+ 665 | Key | Description | Type | JSON Example | 666 +------------------+------------------+--------------+--------------+ 667 | pricePerGb | The price per | float | 2 | 668 | | Gigabit | (currency | | 669 | | | per Gb) | | 670 | currency | The currency | ISO 4217 | "EUR" | 671 | | used | | | 672 | throughputMax | The maximum | float (kb/s) | 1000 | 673 | | achievable | | | 674 | | throughput | | | 675 | trafficRemaining | The traffic | float (kb) | 96000000 | 676 | | remaining | | | 677 +------------------+------------------+--------------+--------------+ 679 5.6.3. Examples 681 Example for a user with 20 GB per month for 40 EUR, then reach a 682 threshold, and with unlimited data during weekends and to deezer: 684 [ 685 { 686 "domains": ["deezer.com"] 687 }, 688 { 689 "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] 690 }, 691 { 692 "beginDate": "2016-07-16T00:00:00Z", 693 "endDate": "2016-07-17T23:59:59Z", 694 }, 695 { 696 "beginDate": "2016-06-20T00:00:00Z", 697 "endDate": "2016-07-19T23:59:59Z", 698 "trafficRemaining": 96000000 699 }, 700 { 701 "throughputMax": 1000 702 } 703 ] 705 If the host tries to download data from deezer.com, the conditions of 706 the first elementary billing are fulfilled, so the host takes this 707 elementary billing, finds no cost indication in it and so deduces 708 that it is totally free. If the host tries to exchange data with 709 youtube.com and the date is 2016-07-14T19:00:00Z, the conditions of 710 the first, second and third elementary billing are not fulfilled. 711 But the conditions of the fourth are. So the host takes this 712 elementary billing and sees that there is a threshold, 12 GB are 713 remaining. 715 Another example for a user abroad, who has 3 GB per year abroad, and 716 then pay each MB: 718 [ 719 { 720 "beginDate": "2016-02-10T00:00:00Z", 721 "endDate": "2017-02-09T23:59:59Z", 722 "trafficRemaining": 9200000 723 }, 724 { 725 "pricePerGb": 30, 726 "currency": "EUR" 727 } 728 ] 730 5.7. Private Extensions 732 keys starting with "x-" are reserved for private use and can be 733 utilized to provide vendor-, user- or enterprise-specific 734 information. It is RECOMMENDED to use one of the patterns "x-FQDN- 735 KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or 736 PEN is a private enterprise number [PEN] under control of the author 737 of the extension to avoid collisions. 739 5.8. Examples 741 5.8.1. Using JSON 742 { 743 "name": "Orange France", 744 "localizedName": "Orange France", 745 "dnsServers": ["8.8.8.8", "8.8.4.4"], 746 "throughputMax": { 747 "down": 100000, 748 "up": 20000 749 }, 750 "cost": [ 751 { 752 "domains": ["deezer.com"] 753 }, 754 { 755 "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] 756 }, 757 { 758 "beginDate": "2016-07-16T00:00:00Z", 759 "endDate": "2016-07-17T23:59:59Z", 760 }, 761 { 762 "beginDate": "2016-06-20T00:00:00Z", 763 "endDate": "2016-07-19T23:59:59Z", 764 "trafficRemaining": 96000000 765 }, 766 { 767 "throughputMax": 1000 768 } 769 ] 770 } 772 5.8.2. Using DNS TXT records 774 n=Orange France 775 r=8.8.8.8,8.8.4.4 776 tp=100000,20000 777 cost+0+domains=deezer.com 778 cost+1+prefixes4=78.40.123.182/32,78.40.123.183/32 779 cost+2+beginDate=2016-07-16T00:00:00Z 780 cost+2+endDate=2016-07-17T23:59:59Z 781 cost+3+beginDate=2016-06-20T00:00:00Z 782 cost+3+endDate=2016-07-19T23:59:59Z 783 cost+3+trafficRemaining=96000000 784 cost+4+throughputMax=1000 786 6. Use case examples 788 TBD: 1 or 2 examples when PvD are critical 790 6.1. Multihoming 792 First example could be multihoming (very much in-line with bowbakova 793 draft). 795 6.2. VPN/Extranet example 797 using PvD to reach a specific destination (such as VPN or extranet). 799 7. Security Considerations 801 While the PvD ID can be forged easily, if the host retrieve the 802 extended PvD via TLS, then the host can trust the content of the 803 extended PvD and verifies that the RA prefix(es) are indeed included 804 in the master prefixed of the extended PvD. 806 8. Acknowledgements 808 Many thanks to M. Stenberg and S. Barth: Section 5.3, Section 5.5 809 and Section 5.7 are from their document [I-D.stenberg-mif-mpvd-dns]. 811 Thanks also to Ray Bellis, Lorenzo Colitti, Marcus Keane, Erik Kline, 812 Jen Lenkova, Mark Townsley and James Woodyatt for useful and 813 interesting brainstorming sessions. 815 9. References 817 9.1. Normative references 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, 821 DOI 10.17487/RFC2119, March 1997, 822 . 824 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 825 Address Text Representation", RFC 5952, 826 DOI 10.17487/RFC5952, August 2010, 827 . 829 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 830 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 831 . 833 9.2. Informative references 835 [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] 836 Baker, F., Bowers, C., and J. Linkova, "Enterprise 837 Multihoming using Provider-Assigned Addresses without 838 Network Prefix Translation: Requirements and Solution", 839 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work 840 in progress), October 2016. 842 [I-D.stenberg-mif-mpvd-dns] 843 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 844 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 845 (work in progress), October 2015. 847 [PEN] IANA, "Private Enterprise Numbers", 848 . 850 Authors' Addresses 852 Basile Bruneau 853 Ecole polytechnique 854 Vannes 56000 855 France 857 Email: basile.bruneau@polytechnique.edu 859 Pierre Pfister 860 Cisco 861 11 Rue Camille Desmoulins 862 Issy-les-Moulineaux 92130 863 France 865 Email: ppfister@cisco.com 867 David Schinazi 868 Apple 870 Email: dschinazi@apple.com 872 Tommy Pauly 873 Apple 875 Email: tpauly@apple.com 876 Eric Vyncke (editor) 877 Cisco 878 De Kleetlaan, 6 879 Diegem 1831 880 Belgium 882 Email: evyncke@cisco.com