idnits 2.17.1 draft-bruneau-pvd-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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2017) is 2606 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) ** Downref: Normative reference to an Informational RFC: RFC 7556 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: Standards Track E. Vyncke, Ed. 5 Expires: September 3, 2017 P. Pfister 6 Cisco 7 D. Schinazi 8 T. Pauly 9 Apple 10 March 2, 2017 12 Proposals to discover Provisioning Domains 13 draft-bruneau-pvd-00 15 Abstract 17 This document describes different possibilities for hosts to retrieve 18 additional information about their Internet access configuration. 19 The set of configuration items required to access the Internet is 20 called a Provisioning Domain (PvD) and is identified by a Fully 21 Qualified Domain Name (or more generally a Uniform Resource Locator). 23 This document separates the way of getting the Provisioning Domain 24 identifier, the way of getting the Provisioning Domain information 25 and the potential information contained in the Provisioning Domain. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 3, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. Retrieving the PvD ID . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Using One Router Advertisement per PvD . . . . . . . . . 4 66 3.2. Rationale for not selecting other techniques . . . . . . 4 67 3.2.1. Using DNS-SD . . . . . . . . . . . . . . . . . . . . 4 68 3.2.2. Using Reverse DNS lookup . . . . . . . . . . . . . . 5 69 3.3. Linking IPv4 Information to an IPv6 PvD . . . . . . . . . 5 70 4. Getting the PvD information . . . . . . . . . . . . . . . . . 6 71 4.1. Using the PvD Bootstrap Information Option . . . . . . . 6 72 4.2. Downloading a JSON file over HTTPS . . . . . . . . . . . 6 73 4.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 7 74 4.2.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Using DNS TXT ressource records (not selected) . . . . . 7 76 4.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 7 77 4.3.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 7 78 4.3.3. Using DNS SRV ressource records . . . . . . . . . . . 8 79 5. PvD Information . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. PvD Name . . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.2. Trust of the bootstrap PvD . . . . . . . . . . . . . . . 9 82 5.3. Reachability . . . . . . . . . . . . . . . . . . . . . . 10 83 5.4. Connectivity Characteristics . . . . . . . . . . . . . . 10 84 5.5. Connection monetary cost . . . . . . . . . . . . . . . . 12 85 5.5.1. Conditions . . . . . . . . . . . . . . . . . . . . . 12 86 5.5.2. Price . . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.5.3. Examples . . . . . . . . . . . . . . . . . . . . . . 14 88 5.6. Private Extensions . . . . . . . . . . . . . . . . . . . 15 89 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.7.1. Using JSON . . . . . . . . . . . . . . . . . . . . . 15 91 5.7.2. Using DNS TXT records . . . . . . . . . . . . . . . . 16 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. Normative references . . . . . . . . . . . . . . . . . . 17 96 8.2. Informative references . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 It has become very common in modern networks that hosts have Internet 103 or more specific access through different networking interfaces, 104 tunnels, or next-hop routers. The concept of Provisioning Domain 105 (PvD) was defined in RFC7556 [RFC7556] as a set of network 106 configuration information which can be used by hosts in order to 107 access the network. In this document, PvDs are associated with a 108 Fully Qualified Domain Name (called PvD ID) which is used within the 109 host to identify correlated sets of configuration data and also used 110 to retrieve additional information about the services that the 111 network provides. 113 Devices connected to the Internet through multiple interfaces would 114 typically be provisioned with one PvD per interface, but it is worth 115 noting that multiple PvDs with different PvD IDs could be provisioned 116 on any host interface, as well as noting that the same PvD ID could 117 be used on different interfaces in order to inform the host that both 118 PvDs, on different interfaces, ultimately provide equivalent 119 services. 121 This document proposes multiple methods which could be used in order 122 to retrieve the PvD ID associated with a set of networking 123 configuration as well as the methods and format in order to retrieve 124 the associated PvD Information. 126 2. Terminology 128 PvD a provisioning domain, usually with a set of 129 provisioning domain information; for more 130 information, see [RFC7556]. 132 2.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in RFC 137 2119 [RFC2119]. 139 3. Retrieving the PvD ID 141 In this document, each provisioning domain is identified by a PvD ID. 142 The PvD ID is a Fully Qualified Domain Name which belongs to the 143 network operator to avoid conflicts among network operators. The 144 same PvD ID can exist in several access networks if the set of 145 configuration information is identical in all those networks (such as 146 in all home networks of a residential subscriber). Within a host, 147 the PvD ID SHOULD be associated to all the configuration information 148 associated to this PvD ID; this allows for easy update and removal of 149 information while keeping a consistent state. 151 This section assumes that IPv6 Router Advertisements are used to 152 discover the PvD ID and explains why this technique was selected. 154 3.1. Using One Router Advertisement per PvD 156 Hosts receive implicit PvDs by the means of Router Advertisements 157 (RA). 159 A router MAY add a single PvD ID Option in its RAs. The PvD ID 160 specified in this option is then associated with all the Prefix 161 Information Options (PIO) included in the RA (albeit it is expected 162 that only one PIO will be included in the RA). All other information 163 contained in the RA (notably the RDNSS) are to be associated with the 164 PvD. The set of information contained in the RA forms the bootstrap 165 (or hint) PvD. A new RA option will be required. 167 When a host receives an RA which does not include a PvD ID Option, 168 the set of information included in the RA is attached to an implicit 169 PvD identified by the local interface ID on which the RA is received, 170 and by the link-local address of the router sending the RA. 172 In the cases where a router should provide multiple independent PvDs 173 to all hosts, including non-PvD aware hosts, it should send multiple 174 RAs, as proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] 175 using different source link-local addresses (LLA). 177 Using RA allows for an early discovery of the PvD ID as it is early 178 in the interface start-up. As RA is usually processed in the kernel, 179 this requires a host OS upgrade. The RA SHOULD contain other PvD 180 information as explained in section Section 4.1. 182 3.2. Rationale for not selecting other techniques 184 There are other techniques to discover the PvD ID that were not 185 selected by the authors and reviewers, this section explains why. 186 The design goal was to be as reliable as possible (do not depend on 187 Internet connectivity) and as fast as possible. 189 3.2.1. Using DNS-SD 191 For each received RA including a RDNSS option as well as a DNS search 192 list option, the host MAY retrieve the PvD ID by querying the 193 configured DNS server for records of type PTR associated with 194 _pvd.. If a PvD ID is configured, the DNS recursive 195 resolver MUST reply with the PvD ID as a PTR record. NXDOMAIN is 196 returned otherwise. 198 When the RDNSS address is link-local, the host MAY retrieve the PvD 199 ID before configuring its global scope address(es). 201 Relying on a valid DNS service at the interface bootstrap can lead 202 into delay to start the interface or starting without enough 203 information: for example when the RDNSS is a non local address and 204 there is no Internet connectivity. 206 3.2.2. Using Reverse DNS lookup 208 [I-D.stenberg-mif-mpvd-dns] proposes a solution to get the name of 209 the PvD using a reverse DNS lookup based on the host global 210 address(es). It merely relies on prepending a well-known prefix 211 '_pvd' to the reverse lookup, for example ' _pvd....ip6.arpa.'. 213 However, the PvD information is typically provided by the network 214 operator, whereas the reverse DNS zone could be delegated from the 215 operator to the network user, in which case it would not work. 217 It also requires a fully functional global address to retrieve the 218 information which may be too late for a correct host configuration. 219 One advantage is that it does not require any change in the IPv6 220 protocol and no change in the host kernel or even in the CPE. 222 3.3. Linking IPv4 Information to an IPv6 PvD 224 The document describes IPv6-only PvD but there are multiple ways to 225 link the set of IPv4 configuration information received by DHCPv4: 227 o correlation based on the data-link layer address of the source, if 228 the IPv6 RA and the DHCPv4 response have the same data-link layer 229 address, then the information contained in the IPv4 DHCP can be 230 linked to the IPv6 PvD; 232 o correlation based on the interface when there is no data-link 233 address on the link (such as a 3GPP link), then the information 234 contained in the IPv4 PDP context can be linked to the IPv6 PvD 235 (*** TO BE VERIFIED before going -01); 237 o correlation based on the DNS search list, if the DNS search lists 238 are identical between the IPv6 RDNSS and the DHCPV4 response, then 239 the information contained in the IPv4 DHCP response can be linked 240 to the IPv6 PvD. 242 The correlation could be useful for some PvD information such as 243 Internet reachability, use of captive portal, display name of the 244 PvD, ... 246 In cases where the IPv4 configuration information could not be 247 associated with a PvD, hosts MUST consider it as attached to an 248 independent implicit PvD containing no other information than what is 249 provided through DHCPv4. 251 4. Getting the PvD information 253 Once the PvD ID is known, it MAY be used to retrieve additional 254 information. PvD Information is modeled as a key-value dictionary 255 which keys are ASCII strings of arbitrary length, and values are 256 either strings (encoding can vary), ordered list of values 257 (recursively), or a dictionary (recursively). 259 The PvD Information may be retrieved from multiple sources (from the 260 bootstrap PvD contained in the RA to the secondary/extended PvD 261 described in this section); the PvD ID is then used to correlate the 262 information from different sources. The way a host should operate 263 when receiving conflicting information is TBD. 265 4.1. Using the PvD Bootstrap Information Option 267 Routers MAY transmit, in addition to the PvD ID option, a PvD 268 Bootstrap Information option, containing a first subset of PvD 269 information. 271 As there is a size limit on the amount of information a single RA can 272 convey, it is likely that the PvD Bootstrap Information option may 273 not contain the whole set of PvD Information. The set of PvD 274 information included in the RA is therefore called PvD Bootstrap 275 Information. 277 4.2. Downloading a JSON file over HTTPS 279 The host SHOULD try to download a JSON formatted file over HTTPS in 280 order to get more PvD information. 282 The host MUST perform an HTTP query to https:///v1.json. If 283 the HTTP status of the answer is greater than 400 the host MUST 284 abandon and consider that there is no PvD. If the HTTP status of the 285 answer is between 300 and 400 it MUST follow the redirection(s). If 286 the HTTP status of the answer is between 200 and 300 the host MAY get 287 a file containing a single JSON object. 289 The host MUST respect the cache information in the HTTP header if any 290 and at expiration of the downloaded object, it must fetch a fresher 291 version if any. 293 4.2.1. Advantages 295 The JSON format allows advanced structures. 297 It can be secured using HTTPS (and DNSSEC). 299 It is easier to update a file on a web server than to edit DNS 300 records. It can be especially important if we want providers to be 301 able to often update the remaining phone plan of the user. 303 4.2.2. Disadvantages 305 It is slower than using DNS because HTTPS uses TCP and TLS and needs 306 more packets to be exchanged to get the file. 308 An additional HTTPS server must be deployed and configured. 310 4.3. Using DNS TXT ressource records (not selected) 312 This approach was not selected during the design team meeting but has 313 kept here for reference, it will be removed after global consensus is 314 reached. 316 The host could perform a DNS query for TXT resource records (RR) for 317 the FQDN used as PvD ID. For each retrieved PvD ID, the DNS query 318 MUST be sent to the DNS server configured from the same router 319 advertisement as the PvD ID. Syntax of the TXT response is defined 320 in Section 5 (Section 5). 322 4.3.1. Advantages 324 It requires a single round-time trip in order to retrieve the PvD 325 Information. 327 It can be secured using DNSSEC. 329 4.3.2. Disadvantages 331 A TXT record is limited to 65535 characters in theory but large size 332 of TXT records could require either DNS over TCP (so loosing the 333 1-RTT advantage) or fragmented UDP packets (which could be dropped by 334 a bad choice of security policy). Large TXT records could also be 335 used to mount an amplification attack. 337 4.3.3. Using DNS SRV ressource records 339 It is expected that the DNS TXT records will be sufficient for the 340 host to configure itself with basic networking and policy 341 configuration. Nevertheless, if further information is required, or 342 when a different security model shall be used to access the PvD 343 Information, a SRV Resource Record including a full URL MAY be 344 included as a response, expecting the host to query this URL in order 345 to retrieve additional PvD information. 347 5. PvD Information 349 PvD information is a set of key-value pairs. Keys are ASCII 350 character strings. Values are either a character string, an ordered 351 list of values, or an embedded dictionary. Value types and default 352 behavior with respect to some specific keys MAY be further specified 353 (recursively). Some keys have a default value as described in the 354 following sections. When there is an expiration time in a PvD, then 355 the information MUST be refreshed before the expiration time. The 356 behavior of a host when the refresh operation is not successful is 357 TBD. 359 Note, the DNS TXT key has been kept even if not selected by the 360 design team but has been kept here for reference. 362 5.1. PvD Name 364 PvD SHOULD have a human readable name in order to be presented on a 365 GUI. The name can also be localized. 367 +------+--------------+-----------------+----------------+----------+ 368 | DNS | JSON key | Description | Type | Example | 369 | TXT | | | | | 370 | key | | | | | 371 +------+--------------+-----------------+----------------+----------+ 372 | n | name | User-visible | human-readable | "Foobar | 373 | | | service name, | UTF-8 string | Service" | 374 | | | SHOULD be part | | | 375 | | | of the | | | 376 | | | bootstrap PvD | | | 377 | nl10 | localizedNam | Localized user- | human-readable | "Service | 378 | n | e | visible service | UTF-8 string | Blabla" | 379 | | | name, language | | | 380 | | | can be selected | | | 381 | | | based on the | | | 382 | | | HTTP Accept- | | | 383 | | | Language header | | | 384 | | | in the request. | | | 385 +------+--------------+-----------------+----------------+----------+ 387 5.2. Trust of the bootstrap PvD 389 The content of the bootstrap PvD (from the original RA) cannot be 390 trusted as it is not authenticated. But, the extended PvD can be 391 associated with the PvD ID (as the PvD ID is used to construct the 392 extended PvD URL) and trusted by the used of TLS. The extended PvD 393 SHOULD therefore include the following information elements and, if 394 they are present, the host MUST verify that the PIO of the RA fits 395 into the master prefix list. The values of the bootstrap PvD (RDNSS, 396 ...) are overwritten by the values contained in the extended PvD if 397 they are present. 399 +-----+------------------+-------------+----------+-----------------+ 400 | DNS | JSON key | Description | Type | Example | 401 | TXT | | | | | 402 | key | | | | | 403 +-----+------------------+-------------+----------+-----------------+ 404 | mp6 | masterIpv6Prefix | All the | Array of | ["2001:db8::/32 | 405 | | | IPv6 | IPv6 | "] | 406 | | | prefixes | prefixes | | 407 | | | linked to | | | 408 | | | this PvD | | | 409 | | | (such as a | | | 410 | | | /29 for the | | | 411 | | | ISP). | | | 412 +-----+------------------+-------------+----------+-----------------+ 414 5.3. Reachability 416 The following set of keys can be used to specify the set of services 417 for which the respective PvD should be used. If present they MUST be 418 honored by the client, i.e., if the PvD is marked as not usable for 419 Internet access (walled garden), then it MUST NOT be used for 420 Internet access. If the usability is limited to a certain set of 421 domain or address prefixes (typical VPN access), then a different PvD 422 MUST be used for other destinations. 424 +-----+-------------+---------------+-----------+-------------------+ 425 | DNS | JSON key | Description | Type | Example | 426 | TXT | | | | | 427 | key | | | | | 428 +-----+-------------+---------------+-----------+-------------------+ 429 | s | noInternet | Internet | boolean | true | 430 | | | inaccessible | | | 431 | lp | loginPortal | Presence of a | boolean | false | 432 | | | login portal | | | 433 | z | dnsZones | DNS zones | array of | ["foo.com","sub.b | 434 | | | accessible | DNS zone | ar.com"] | 435 | | | and | | | 436 | | | searchable | | | 437 | 6 | prefixes6 | IPv6-prefixes | array of | ["2001:db8:a::/48 | 438 | | | accessible | IPv6 | ","2001:db8:b:c:: | 439 | | | via this PvD | prefixes | /64"] | 440 | 4 | prefixes4 | IPv4-prefixes | array of | ["192.0.2.0/24"," | 441 | | | accessible | IPv4 | 2.3.0.0/16"] | 442 | | | | prefixes | | 443 | | | | in CIDR | | 444 | | | | reachable | | 445 | | | | via this | | 446 | | | | PvD | | 447 +-----+-------------+---------------+-----------+-------------------+ 449 5.4. Connectivity Characteristics 451 NOTE: open question to the authors/reviewers: should this document 452 include this section or is it useless? 454 The following set of keys can be used to signal certain 455 characteristics of the connection towards the PvD. 457 They should reflect characteristics of the overall access technology 458 which is not limited to the link the host is connected to, but rather 459 a combination of the link technology, CPE upstream connectivity, and 460 further quality of service considerations. 462 +------+------------------+------------+--------------+-------------+ 463 | DNS | JSON key | Descriptio | Type | Example | 464 | TXT | | n | | | 465 | key | | | | | 466 +------+------------------+------------+--------------+-------------+ 467 | tp | throughputMax | Maximum | object({down | {"down": | 468 | | | achievable | (int), | 10000, | 469 | | | throughput | up(int)}) in | "up": 5000} | 470 | | | (e.g. CPE | kb/s | | 471 | | | downlink/u | | | 472 | | | plink) | | | 473 | lt | latencyMin | Minimum | object({down | {"down": | 474 | | | achievable | (int), | 10, "up": | 475 | | | latency | up(int)}) in | 20} | 476 | | | | ms | | 477 | rl | reliabilityMax | Maximum | object({down | {"down": | 478 | | | achievable | (int), | 1000, "up": | 479 | | | reliabilit | up(int)}) in | 800} | 480 | | | y | 1/1000 | | 481 | cp | captiveUrl | Captive | URL of the | "https://ex | 482 | | | portal | portal | ample.com" | 483 | nat | nat | IPv4 NAT | boolean | true | 484 | | | in place | | | 485 | srh | segmentRoutingHe | The IPv6 | Binary | ... | 486 | | ader | Segment | string | | 487 | | | Routing | | | 488 | | | Header to | | | 489 | | | be used | | | 490 | | | between | | | 491 | | | the IPv6 | | | 492 | | | header and | | | 493 | | | any other | | | 494 | | | headers | | | 495 | | | when using | | | 496 | | | this PvD | | | 497 | srhD | segmentRoutingHe | The DNS | Ascii string | srh.pvd-foo | 498 | NS | aderDnsFQDN | FQDN which | | .example.or | 499 | | | is used to | | g | 500 | | | retrieved | | | 501 | | | the actual | | | 502 | | | IPv6 | | | 503 | | | Segment | | | 504 | | | Routing | | | 505 | | | Header to | | | 506 | | | be used | | | 507 | | | between | | | 508 | | | the IPv6 | | | 509 | | | header and | | | 510 | | | any other | | | 511 | | | headers | | | 512 | | | when using | | | 513 | | | this PvD | | | 514 | cost | cost | Cost of | object | See Section | 515 | | | using the | | 5.5 | 516 | | | connection | | | 517 +------+------------------+------------+--------------+-------------+ 519 5.5. Connection monetary cost 521 NOTE: This section is included as a request for comment on the 522 potential use and syntax. 524 The billing of a connection can be done in a lot of different ways. 525 The user can have a global traffic threshold per month, after which 526 his throughput is limited, or after which he/she pays each megabyte. 527 He/she can also have an unlimited access to some websites, or an 528 unlimited access during the week-ends. 530 We propose to split the final billing in elementary billings, which 531 have conditions (a start date, an end date, a destination IP 532 address...). The global billing is an ordered list of elementary 533 billings. To know the cost of a transmission, the host goes through 534 the list, and the first elementary billing whose the conditions are 535 fulfilled gives the cost. If no elementary billing conditions match 536 the request, the host MUST NOT make any assumption about the cost. 538 5.5.1. Conditions 540 Here are the potential conditions for an elementary billing. All 541 conditions MUST be fulfilled. 543 Note: the final version should use shorter key names. 545 +-----------+-------------+---------------+-------------------------+ 546 | Key | Description | Type | Example | 547 +-----------+-------------+---------------+-------------------------+ 548 | beginDate | Date before | ISO 8601 | "1977-04-22T06:00:00Z" | 549 | | which the | | | 550 | | billing is | | | 551 | | not valid | | | 552 | endDate | Date after | ISO 8601 | "1977-04-22T06:00:00Z" | 553 | | which the | | | 554 | | billing is | | | 555 | | not valid | | | 556 | domains | FQDNs whose | array(string) | ["deezer.com","spotify. | 557 | | the billing | | com"] | 558 | | is limited | | | 559 | prefixes4 | IPv4 | array(string) | ["78.40.123.182/32","78 | 560 | | prefixes | | .40.123.183/32"] | 561 | | whose the | | | 562 | | billing is | | | 563 | | limited | | | 564 | prefixes6 | IPv6 | array(string) | ["2a00:1450:4007:80e::2 | 565 | | prefixes | | 00e/64"] | 566 | | whose the | | | 567 | | billing is | | | 568 | | limited | | | 569 +-----------+-------------+---------------+-------------------------+ 571 5.5.2. Price 573 Here are the different possibilities for the cost of an elementary 574 billing. A missing key means "all/unlimited/unrestricted". If the 575 elementary billing selected has a trafficRemaining of 0 kb, then it 576 means that the user has no access to the network. Actually, if the 577 last elementary billing has a trafficRemaining parameter, it means 578 that when the user will reach the threshold, he/she will not have 579 access to the network anymore. 581 +------------------+------------------+--------------+--------------+ 582 | Key | Description | Type | Example | 583 +------------------+------------------+--------------+--------------+ 584 | pricePerGb | The price per | float | 2 | 585 | | Gigabit | (currency | | 586 | | | per Gb) | | 587 | currency | The currency | ISO 4217 | "EUR" | 588 | | used | | | 589 | throughputMax | The maximum | float (kb/s) | 1000 | 590 | | achievable | | | 591 | | throughput | | | 592 | trafficRemaining | The traffic | float (kb) | 96000000 | 593 | | remaining | | | 594 +------------------+------------------+--------------+--------------+ 596 5.5.3. Examples 598 Example for a user with 20 GB per month for 40 EUR, then reach a 599 threshold, and with unlimited data during week-ends and to the server 600 "deezer": 602 [ 603 { 604 "domains": ["deezer.com"] 605 }, 606 { 607 "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] 608 }, 609 { 610 "beginDate": "2016-07-16T00:00:00Z", 611 "endDate": "2016-07-17T23:59:59Z", 612 }, 613 { 614 "beginDate": "2016-06-20T00:00:00Z", 615 "endDate": "2016-07-19T23:59:59Z", 616 "trafficRemaining": 96000000 617 }, 618 { 619 "throughputMax": 1000 620 } 621 ] 623 If the host tries to download data from deezer.com, the conditions of 624 the first elementary billing are fulfilled, so the host takes this 625 elementary billing, finds no cost indication in it and so deduces 626 that it is totally free. If the host tries to exchange data with 627 youtube.com and the date is 2016-07-14T19:00:00Z, the conditions of 628 the first, second and third elementary billing are not fulfilled. 630 But the conditions of the fourth are. So the host takes this 631 elementary billing and sees that there is a threshold, 12 GB are 632 remaining. 634 Another example for a user abroad, who has 3 GB per year abroad, and 635 then pay each MB: 637 [ 638 { 639 "beginDate": "2016-02-10T00:00:00Z", 640 "endDate": "2017-02-09T23:59:59Z", 641 "trafficRemaining": 9200000 642 }, 643 { 644 "pricePerGb": 30, 645 "currency": "EUR" 646 } 647 ] 649 5.6. Private Extensions 651 keys starting with "x-" are reserved for private use and can be 652 utilized to provide vendor-, user- or enterprise-specific 653 information. It is RECOMMENDED to use one of the patterns "x-FQDN- 654 KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or 655 PEN is a private enterprise number [PEN] under control of the author 656 of the extension to avoid collisions. 658 5.7. Examples 660 5.7.1. Using JSON 661 { 662 "name": "Orange France", 663 "localizedName": "Orange France", 664 "dnsServers": ["8.8.8.8", "8.8.4.4"], 665 "throughputMax": { 666 "down": 100000, 667 "up": 20000 668 }, 669 "cost": [ 670 { 671 "domains": ["deezer.com"] 672 }, 673 { 674 "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] 675 }, 676 { 677 "beginDate": "2016-07-16T00:00:00Z", 678 "endDate": "2016-07-17T23:59:59Z", 679 }, 680 { 681 "beginDate": "2016-06-20T00:00:00Z", 682 "endDate": "2016-07-19T23:59:59Z", 683 "trafficRemaining": 96000000 684 }, 685 { 686 "throughputMax": 1000 687 } 688 ] 689 } 691 5.7.2. Using DNS TXT records 693 n=Orange France 694 r=8.8.8.8,8.8.4.4 695 tp=100000,20000 696 cost+0+domains=deezer.com 697 cost+1+prefixes4=78.40.123.182/32,78.40.123.183/32 698 cost+2+beginDate=2016-07-16T00:00:00Z 699 cost+2+endDate=2016-07-17T23:59:59Z 700 cost+3+beginDate=2016-06-20T00:00:00Z 701 cost+3+endDate=2016-07-19T23:59:59Z 702 cost+3+trafficRemaining=96000000 703 cost+4+throughputMax=1000 705 6. Security Considerations 707 While the PvD ID can be forged easily, if the host retrieve the 708 extended PvD via TLS, then the host can trust the content of the 709 extended PvD and verifies that the RA prefix(es) are indeed included 710 in the extended PvD. 712 7. Acknowledgements 714 Many thanks to M. Stenberg and S. Barth: Section 5.3, Section 5.4 715 and Section 5.6 are from their document [I-D.stenberg-mif-mpvd-dns]. 717 Thanks also to Ray Bellis, Lorenzo Colitti, Erik Kline, Mark Townsley 718 and James Woodyatt for useful and interesting brainstorming sessions. 720 8. References 722 8.1. Normative references 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 730 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 731 . 733 8.2. Informative references 735 [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] 736 Baker, F., Bowers, C., and J. Linkova, "Enterprise 737 Multihoming using Provider-Assigned Addresses without 738 Network Prefix Translation: Requirements and Solution", 739 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work 740 in progress), October 2016. 742 [I-D.stenberg-mif-mpvd-dns] 743 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 744 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 745 (work in progress), October 2015. 747 [PEN] IANA, "Private Enterprise Numbers", 748 . 750 Authors' Addresses 752 Basile Bruneau 753 Ecole polytechnique 754 Vannes 56000 755 France 757 Email: basile.bruneau@polytechnique.edu 759 Eric Vyncke (editor) 760 Cisco 761 De Kleetlaan, 6 762 Diegem 1831 763 Belgium 765 Email: evyncke@cisco.com 767 Pierre Pfister 768 Cisco 769 11 Rue Camille Desmoulins 770 Issy-les-Moulineaux 92130 771 France 773 Email: ppfister@cisco.com 775 David Schinazi 776 Apple 778 Email: dschinazi@apple.com 780 Tommy Pauly 781 Apple 783 Email: tpauly@apple.com