[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 draft-bruneau-intarea-provisioning-domains

intarea                                                       B. Bruneau
Internet-Draft                                       Ecole polytechnique
Intended status: Standards Track                          E. Vyncke, Ed.
Expires: September 3, 2017                                    P. Pfister
                                                                   Cisco
                                                             D. Schinazi
                                                                T. Pauly
                                                                   Apple
                                                           March 2, 2017


               Proposals to discover Provisioning Domains
                          draft-bruneau-pvd-00

Abstract

   This document describes different possibilities for hosts to retrieve
   additional information about their Internet access configuration.
   The set of configuration items required to access the Internet is
   called a Provisioning Domain (PvD) and is identified by a Fully
   Qualified Domain Name (or more generally a Uniform Resource Locator).

   This document separates the way of getting the Provisioning Domain
   identifier, the way of getting the Provisioning Domain information
   and the potential information contained in the Provisioning Domain.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 3, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Bruneau, et al.         Expires September 3, 2017               [Page 1]


Internet-Draft           Possibilities for PvDs               March 2017


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Retrieving the PvD ID . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Using One Router Advertisement per PvD  . . . . . . . . .   4
     3.2.  Rationale for not selecting other techniques  . . . . . .   4
       3.2.1.  Using DNS-SD  . . . . . . . . . . . . . . . . . . . .   4
       3.2.2.  Using Reverse DNS lookup  . . . . . . . . . . . . . .   5
     3.3.  Linking IPv4 Information to an IPv6 PvD . . . . . . . . .   5
   4.  Getting the PvD information . . . . . . . . . . . . . . . . .   6
     4.1.  Using the PvD Bootstrap Information Option  . . . . . . .   6
     4.2.  Downloading a JSON file over HTTPS  . . . . . . . . . . .   6
       4.2.1.  Advantages  . . . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Disadvantages . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Using DNS TXT ressource records (not selected)  . . . . .   7
       4.3.1.  Advantages  . . . . . . . . . . . . . . . . . . . . .   7
       4.3.2.  Disadvantages . . . . . . . . . . . . . . . . . . . .   7
       4.3.3.  Using DNS SRV ressource records . . . . . . . . . . .   8
   5.  PvD Information . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  PvD Name  . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Trust of the bootstrap PvD  . . . . . . . . . . . . . . .   9
     5.3.  Reachability  . . . . . . . . . . . . . . . . . . . . . .  10
     5.4.  Connectivity Characteristics  . . . . . . . . . . . . . .  10
     5.5.  Connection monetary cost  . . . . . . . . . . . . . . . .  12
       5.5.1.  Conditions  . . . . . . . . . . . . . . . . . . . . .  12
       5.5.2.  Price . . . . . . . . . . . . . . . . . . . . . . . .  13
       5.5.3.  Examples  . . . . . . . . . . . . . . . . . . . . . .  14
     5.6.  Private Extensions  . . . . . . . . . . . . . . . . . . .  15
     5.7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.7.1.  Using JSON  . . . . . . . . . . . . . . . . . . . . .  15
       5.7.2.  Using DNS TXT records . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative references  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative references  . . . . . . . . . . . . . . . . .  17



Bruneau, et al.         Expires September 3, 2017               [Page 2]


Internet-Draft           Possibilities for PvDs               March 2017


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   It has become very common in modern networks that hosts have Internet
   or more specific access through different networking interfaces,
   tunnels, or next-hop routers.  The concept of Provisioning Domain
   (PvD) was defined in RFC7556 [RFC7556] as a set of network
   configuration information which can be used by hosts in order to
   access the network.  In this document, PvDs are associated with a
   Fully Qualified Domain Name (called PvD ID) which is used within the
   host to identify correlated sets of configuration data and also used
   to retrieve additional information about the services that the
   network provides.

   Devices connected to the Internet through multiple interfaces would
   typically be provisioned with one PvD per interface, but it is worth
   noting that multiple PvDs with different PvD IDs could be provisioned
   on any host interface, as well as noting that the same PvD ID could
   be used on different interfaces in order to inform the host that both
   PvDs, on different interfaces, ultimately provide equivalent
   services.

   This document proposes multiple methods which could be used in order
   to retrieve the PvD ID associated with a set of networking
   configuration as well as the methods and format in order to retrieve
   the associated PvD Information.

2.  Terminology

   PvD               a provisioning domain, usually with a set of
                     provisioning domain information; for more
                     information, see [RFC7556].

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Retrieving the PvD ID

   In this document, each provisioning domain is identified by a PvD ID.
   The PvD ID is a Fully Qualified Domain Name which belongs to the
   network operator to avoid conflicts among network operators.  The
   same PvD ID can exist in several access networks if the set of
   configuration information is identical in all those networks (such as



Bruneau, et al.         Expires September 3, 2017               [Page 3]


Internet-Draft           Possibilities for PvDs               March 2017


   in all home networks of a residential subscriber).  Within a host,
   the PvD ID SHOULD be associated to all the configuration information
   associated to this PvD ID; this allows for easy update and removal of
   information while keeping a consistent state.

   This section assumes that IPv6 Router Advertisements are used to
   discover the PvD ID and explains why this technique was selected.

3.1.  Using One Router Advertisement per PvD

   Hosts receive implicit PvDs by the means of Router Advertisements
   (RA).

   A router MAY add a single PvD ID Option in its RAs.  The PvD ID
   specified in this option is then associated with all the Prefix
   Information Options (PIO) included in the RA (albeit it is expected
   that only one PIO will be included in the RA).  All other information
   contained in the RA (notably the RDNSS) are to be associated with the
   PvD.  The set of information contained in the RA forms the bootstrap
   (or hint) PvD.  A new RA option will be required.

   When a host receives an RA which does not include a PvD ID Option,
   the set of information included in the RA is attached to an implicit
   PvD identified by the local interface ID on which the RA is received,
   and by the link-local address of the router sending the RA.

   In the cases where a router should provide multiple independent PvDs
   to all hosts, including non-PvD aware hosts, it should send multiple
   RAs, as proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]
   using different source link-local addresses (LLA).

   Using RA allows for an early discovery of the PvD ID as it is early
   in the interface start-up.  As RA is usually processed in the kernel,
   this requires a host OS upgrade.  The RA SHOULD contain other PvD
   information as explained in section Section 4.1.

3.2.  Rationale for not selecting other techniques

   There are other techniques to discover the PvD ID that were not
   selected by the authors and reviewers, this section explains why.
   The design goal was to be as reliable as possible (do not depend on
   Internet connectivity) and as fast as possible.

3.2.1.  Using DNS-SD

   For each received RA including a RDNSS option as well as a DNS search
   list option, the host MAY retrieve the PvD ID by querying the
   configured DNS server for records of type PTR associated with



Bruneau, et al.         Expires September 3, 2017               [Page 4]


Internet-Draft           Possibilities for PvDs               March 2017


   _pvd.<DNS search name>.  If a PvD ID is configured, the DNS recursive
   resolver MUST reply with the PvD ID as a PTR record.  NXDOMAIN is
   returned otherwise.

   When the RDNSS address is link-local, the host MAY retrieve the PvD
   ID before configuring its global scope address(es).

   Relying on a valid DNS service at the interface bootstrap can lead
   into delay to start the interface or starting without enough
   information: for example when the RDNSS is a non local address and
   there is no Internet connectivity.

3.2.2.  Using Reverse DNS lookup

   [I-D.stenberg-mif-mpvd-dns] proposes a solution to get the name of
   the PvD using a reverse DNS lookup based on the host global
   address(es).  It merely relies on prepending a well-known prefix
   '_pvd' to the reverse lookup, for example ' _pvd....ip6.arpa.'.

   However, the PvD information is typically provided by the network
   operator, whereas the reverse DNS zone could be delegated from the
   operator to the network user, in which case it would not work.

   It also requires a fully functional global address to retrieve the
   information which may be too late for a correct host configuration.
   One advantage is that it does not require any change in the IPv6
   protocol and no change in the host kernel or even in the CPE.

3.3.  Linking IPv4 Information to an IPv6 PvD

   The document describes IPv6-only PvD but there are multiple ways to
   link the set of IPv4 configuration information received by DHCPv4:

   o  correlation based on the data-link layer address of the source, if
      the IPv6 RA and the DHCPv4 response have the same data-link layer
      address, then the information contained in the IPv4 DHCP can be
      linked to the IPv6 PvD;

   o  correlation based on the interface when there is no data-link
      address on the link (such as a 3GPP link), then the information
      contained in the IPv4 PDP context can be linked to the IPv6 PvD
      (*** TO BE VERIFIED before going -01);

   o  correlation based on the DNS search list, if the DNS search lists
      are identical between the IPv6 RDNSS and the DHCPV4 response, then
      the information contained in the IPv4 DHCP response can be linked
      to the IPv6 PvD.




Bruneau, et al.         Expires September 3, 2017               [Page 5]


Internet-Draft           Possibilities for PvDs               March 2017


   The correlation could be useful for some PvD information such as
   Internet reachability, use of captive portal, display name of the
   PvD, ...

   In cases where the IPv4 configuration information could not be
   associated with a PvD, hosts MUST consider it as attached to an
   independent implicit PvD containing no other information than what is
   provided through DHCPv4.

4.  Getting the PvD information

   Once the PvD ID is known, it MAY be used to retrieve additional
   information.  PvD Information is modeled as a key-value dictionary
   which keys are ASCII strings of arbitrary length, and values are
   either strings (encoding can vary), ordered list of values
   (recursively), or a dictionary (recursively).

   The PvD Information may be retrieved from multiple sources (from the
   bootstrap PvD contained in the RA to the secondary/extended PvD
   described in this section); the PvD ID is then used to correlate the
   information from different sources.  The way a host should operate
   when receiving conflicting information is TBD.

4.1.  Using the PvD Bootstrap Information Option

   Routers MAY transmit, in addition to the PvD ID option, a PvD
   Bootstrap Information option, containing a first subset of PvD
   information.

   As there is a size limit on the amount of information a single RA can
   convey, it is likely that the PvD Bootstrap Information option may
   not contain the whole set of PvD Information.  The set of PvD
   information included in the RA is therefore called PvD Bootstrap
   Information.

4.2.  Downloading a JSON file over HTTPS

   The host SHOULD try to download a JSON formatted file over HTTPS in
   order to get more PvD information.

   The host MUST perform an HTTP query to https://<PvD-ID>/v1.json.  If
   the HTTP status of the answer is greater than 400 the host MUST
   abandon and consider that there is no PvD.  If the HTTP status of the
   answer is between 300 and 400 it MUST follow the redirection(s).  If
   the HTTP status of the answer is between 200 and 300 the host MAY get
   a file containing a single JSON object.





Bruneau, et al.         Expires September 3, 2017               [Page 6]


Internet-Draft           Possibilities for PvDs               March 2017


   The host MUST respect the cache information in the HTTP header if any
   and at expiration of the downloaded object, it must fetch a fresher
   version if any.

4.2.1.  Advantages

   The JSON format allows advanced structures.

   It can be secured using HTTPS (and DNSSEC).

   It is easier to update a file on a web server than to edit DNS
   records.  It can be especially important if we want providers to be
   able to often update the remaining phone plan of the user.

4.2.2.  Disadvantages

   It is slower than using DNS because HTTPS uses TCP and TLS and needs
   more packets to be exchanged to get the file.

   An additional HTTPS server must be deployed and configured.

4.3.  Using DNS TXT ressource records (not selected)

   This approach was not selected during the design team meeting but has
   kept here for reference, it will be removed after global consensus is
   reached.

   The host could perform a DNS query for TXT resource records (RR) for
   the FQDN used as PvD ID.  For each retrieved PvD ID, the DNS query
   MUST be sent to the DNS server configured from the same router
   advertisement as the PvD ID.  Syntax of the TXT response is defined
   in Section 5 (Section 5).

4.3.1.  Advantages

   It requires a single round-time trip in order to retrieve the PvD
   Information.

   It can be secured using DNSSEC.

4.3.2.  Disadvantages

   A TXT record is limited to 65535 characters in theory but large size
   of TXT records could require either DNS over TCP (so loosing the
   1-RTT advantage) or fragmented UDP packets (which could be dropped by
   a bad choice of security policy).  Large TXT records could also be
   used to mount an amplification attack.




Bruneau, et al.         Expires September 3, 2017               [Page 7]


Internet-Draft           Possibilities for PvDs               March 2017


4.3.3.  Using DNS SRV ressource records

   It is expected that the DNS TXT records will be sufficient for the
   host to configure itself with basic networking and policy
   configuration.  Nevertheless, if further information is required, or
   when a different security model shall be used to access the PvD
   Information, a SRV Resource Record including a full URL MAY be
   included as a response, expecting the host to query this URL in order
   to retrieve additional PvD information.

5.  PvD Information

   PvD information is a set of key-value pairs.  Keys are ASCII
   character strings.  Values are either a character string, an ordered
   list of values, or an embedded dictionary.  Value types and default
   behavior with respect to some specific keys MAY be further specified
   (recursively).  Some keys have a default value as described in the
   following sections.  When there is an expiration time in a PvD, then
   the information MUST be refreshed before the expiration time.  The
   behavior of a host when the refresh operation is not successful is
   TBD.

   Note, the DNS TXT key has been kept even if not selected by the
   design team but has been kept here for reference.

5.1.  PvD Name

   PvD SHOULD have a human readable name in order to be presented on a
   GUI.  The name can also be localized.






















Bruneau, et al.         Expires September 3, 2017               [Page 8]


Internet-Draft           Possibilities for PvDs               March 2017


   +------+--------------+-----------------+----------------+----------+
   | DNS  | JSON key     | Description     | Type           | Example  |
   | TXT  |              |                 |                |          |
   | key  |              |                 |                |          |
   +------+--------------+-----------------+----------------+----------+
   | n    | name         | User-visible    | human-readable | "Foobar  |
   |      |              | service name,   | UTF-8 string   | Service" |
   |      |              | SHOULD be part  |                |          |
   |      |              | of the          |                |          |
   |      |              | bootstrap PvD   |                |          |
   | nl10 | localizedNam | Localized user- | human-readable | "Service |
   | n    | e            | visible service | UTF-8 string   | Blabla"  |
   |      |              | name, language  |                |          |
   |      |              | can be selected |                |          |
   |      |              | based on the    |                |          |
   |      |              | HTTP Accept-    |                |          |
   |      |              | Language header |                |          |
   |      |              | in the request. |                |          |
   +------+--------------+-----------------+----------------+----------+

5.2.  Trust of the bootstrap PvD

   The content of the bootstrap PvD (from the original RA) cannot be
   trusted as it is not authenticated.  But, the extended PvD can be
   associated with the PvD ID (as the PvD ID is used to construct the
   extended PvD URL) and trusted by the used of TLS.  The extended PvD
   SHOULD therefore include the following information elements and, if
   they are present, the host MUST verify that the PIO of the RA fits
   into the master prefix list.  The values of the bootstrap PvD (RDNSS,
   ...) are overwritten by the values contained in the extended PvD if
   they are present.

   +-----+------------------+-------------+----------+-----------------+
   | DNS | JSON key         | Description | Type     | Example         |
   | TXT |                  |             |          |                 |
   | key |                  |             |          |                 |
   +-----+------------------+-------------+----------+-----------------+
   | mp6 | masterIpv6Prefix | All the     | Array of | ["2001:db8::/32 |
   |     |                  | IPv6        | IPv6     | "]              |
   |     |                  | prefixes    | prefixes |                 |
   |     |                  | linked to   |          |                 |
   |     |                  | this PvD    |          |                 |
   |     |                  | (such as a  |          |                 |
   |     |                  | /29 for the |          |                 |
   |     |                  | ISP).       |          |                 |
   +-----+------------------+-------------+----------+-----------------+





Bruneau, et al.         Expires September 3, 2017               [Page 9]


Internet-Draft           Possibilities for PvDs               March 2017


5.3.  Reachability

   The following set of keys can be used to specify the set of services
   for which the respective PvD should be used.  If present they MUST be
   honored by the client, i.e., if the PvD is marked as not usable for
   Internet access (walled garden), then it MUST NOT be used for
   Internet access.  If the usability is limited to a certain set of
   domain or address prefixes (typical VPN access), then a different PvD
   MUST be used for other destinations.

   +-----+-------------+---------------+-----------+-------------------+
   | DNS | JSON key    | Description   | Type      | Example           |
   | TXT |             |               |           |                   |
   | key |             |               |           |                   |
   +-----+-------------+---------------+-----------+-------------------+
   | s   | noInternet  | Internet      | boolean   | true              |
   |     |             | inaccessible  |           |                   |
   | lp  | loginPortal | Presence of a | boolean   | false             |
   |     |             | login portal  |           |                   |
   | z   | dnsZones    | DNS zones     | array of  | ["foo.com","sub.b |
   |     |             | accessible    | DNS zone  | ar.com"]          |
   |     |             | and           |           |                   |
   |     |             | searchable    |           |                   |
   | 6   | prefixes6   | IPv6-prefixes | array of  | ["2001:db8:a::/48 |
   |     |             | accessible    | IPv6      | ","2001:db8:b:c:: |
   |     |             | via this PvD  | prefixes  | /64"]             |
   | 4   | prefixes4   | IPv4-prefixes | array of  | ["192.0.2.0/24"," |
   |     |             | accessible    | IPv4      | 2.3.0.0/16"]      |
   |     |             |               | prefixes  |                   |
   |     |             |               | in CIDR   |                   |
   |     |             |               | reachable |                   |
   |     |             |               | via this  |                   |
   |     |             |               | PvD       |                   |
   +-----+-------------+---------------+-----------+-------------------+

5.4.  Connectivity Characteristics

   NOTE: open question to the authors/reviewers: should this document
   include this section or is it useless?

   The following set of keys can be used to signal certain
   characteristics of the connection towards the PvD.

   They should reflect characteristics of the overall access technology
   which is not limited to the link the host is connected to, but rather
   a combination of the link technology, CPE upstream connectivity, and
   further quality of service considerations.




Bruneau, et al.         Expires September 3, 2017              [Page 10]


Internet-Draft           Possibilities for PvDs               March 2017


   +------+------------------+------------+--------------+-------------+
   | DNS  | JSON key         | Descriptio | Type         | Example     |
   | TXT  |                  | n          |              |             |
   | key  |                  |            |              |             |
   +------+------------------+------------+--------------+-------------+
   | tp   | throughputMax    | Maximum    | object({down | {"down":    |
   |      |                  | achievable | (int),       | 10000,      |
   |      |                  | throughput | up(int)}) in | "up": 5000} |
   |      |                  | (e.g. CPE  | kb/s         |             |
   |      |                  | downlink/u |              |             |
   |      |                  | plink)     |              |             |
   | lt   | latencyMin       | Minimum    | object({down | {"down":    |
   |      |                  | achievable | (int),       | 10, "up":   |
   |      |                  | latency    | up(int)}) in | 20}         |
   |      |                  |            | ms           |             |
   | rl   | reliabilityMax   | Maximum    | object({down | {"down":    |
   |      |                  | achievable | (int),       | 1000, "up": |
   |      |                  | reliabilit | up(int)}) in | 800}        |
   |      |                  | y          | 1/1000       |             |
   | cp   | captiveUrl       | Captive    | URL of the   | "https://ex |
   |      |                  | portal     | portal       | ample.com"  |
   | nat  | nat              | IPv4 NAT   | boolean      | true        |
   |      |                  | in place   |              |             |
   | srh  | segmentRoutingHe | The IPv6   | Binary       | ...         |
   |      | ader             | Segment    | string       |             |
   |      |                  | Routing    |              |             |
   |      |                  | Header to  |              |             |
   |      |                  | be used    |              |             |
   |      |                  | between    |              |             |
   |      |                  | the IPv6   |              |             |
   |      |                  | header and |              |             |
   |      |                  | any other  |              |             |
   |      |                  | headers    |              |             |
   |      |                  | when using |              |             |
   |      |                  | this PvD   |              |             |
   | srhD | segmentRoutingHe | The DNS    | Ascii string | srh.pvd-foo |
   | NS   | aderDnsFQDN      | FQDN which |              | .example.or |
   |      |                  | is used to |              | g           |
   |      |                  | retrieved  |              |             |
   |      |                  | the actual |              |             |
   |      |                  | IPv6       |              |             |
   |      |                  | Segment    |              |             |
   |      |                  | Routing    |              |             |
   |      |                  | Header to  |              |             |
   |      |                  | be used    |              |             |
   |      |                  | between    |              |             |
   |      |                  | the IPv6   |              |             |
   |      |                  | header and |              |             |



Bruneau, et al.         Expires September 3, 2017              [Page 11]


Internet-Draft           Possibilities for PvDs               March 2017


   |      |                  | any other  |              |             |
   |      |                  | headers    |              |             |
   |      |                  | when using |              |             |
   |      |                  | this PvD   |              |             |
   | cost | cost             | Cost of    | object       | See Section |
   |      |                  | using the  |              | 5.5         |
   |      |                  | connection |              |             |
   +------+------------------+------------+--------------+-------------+

5.5.  Connection monetary cost

   NOTE: This section is included as a request for comment on the
   potential use and syntax.

   The billing of a connection can be done in a lot of different ways.
   The user can have a global traffic threshold per month, after which
   his throughput is limited, or after which he/she pays each megabyte.
   He/she can also have an unlimited access to some websites, or an
   unlimited access during the week-ends.

   We propose to split the final billing in elementary billings, which
   have conditions (a start date, an end date, a destination IP
   address...).  The global billing is an ordered list of elementary
   billings.  To know the cost of a transmission, the host goes through
   the list, and the first elementary billing whose the conditions are
   fulfilled gives the cost.  If no elementary billing conditions match
   the request, the host MUST NOT make any assumption about the cost.

5.5.1.  Conditions

   Here are the potential conditions for an elementary billing.  All
   conditions MUST be fulfilled.

   Note: the final version should use shorter key names.

















Bruneau, et al.         Expires September 3, 2017              [Page 12]


Internet-Draft           Possibilities for PvDs               March 2017


   +-----------+-------------+---------------+-------------------------+
   | Key       | Description | Type          | Example                 |
   +-----------+-------------+---------------+-------------------------+
   | beginDate | Date before | ISO 8601      | "1977-04-22T06:00:00Z"  |
   |           | which the   |               |                         |
   |           | billing is  |               |                         |
   |           | not valid   |               |                         |
   | endDate   | Date after  | ISO 8601      | "1977-04-22T06:00:00Z"  |
   |           | which the   |               |                         |
   |           | billing is  |               |                         |
   |           | not valid   |               |                         |
   | domains   | FQDNs whose | array(string) | ["deezer.com","spotify. |
   |           | the billing |               | com"]                   |
   |           | is limited  |               |                         |
   | prefixes4 | IPv4        | array(string) | ["78.40.123.182/32","78 |
   |           | prefixes    |               | .40.123.183/32"]        |
   |           | whose the   |               |                         |
   |           | billing is  |               |                         |
   |           | limited     |               |                         |
   | prefixes6 | IPv6        | array(string) | ["2a00:1450:4007:80e::2 |
   |           | prefixes    |               | 00e/64"]                |
   |           | whose the   |               |                         |
   |           | billing is  |               |                         |
   |           | limited     |               |                         |
   +-----------+-------------+---------------+-------------------------+

5.5.2.  Price

   Here are the different possibilities for the cost of an elementary
   billing.  A missing key means "all/unlimited/unrestricted".  If the
   elementary billing selected has a trafficRemaining of 0 kb, then it
   means that the user has no access to the network.  Actually, if the
   last elementary billing has a trafficRemaining parameter, it means
   that when the user will reach the threshold, he/she will not have
   access to the network anymore.
















Bruneau, et al.         Expires September 3, 2017              [Page 13]


Internet-Draft           Possibilities for PvDs               March 2017


   +------------------+------------------+--------------+--------------+
   | Key              | Description      | Type         | Example      |
   +------------------+------------------+--------------+--------------+
   | pricePerGb       | The price per    | float        | 2            |
   |                  | Gigabit          | (currency    |              |
   |                  |                  | per Gb)      |              |
   | currency         | The currency     | ISO 4217     | "EUR"        |
   |                  | used             |              |              |
   | throughputMax    | The maximum      | float (kb/s) | 1000         |
   |                  | achievable       |              |              |
   |                  | throughput       |              |              |
   | trafficRemaining | The traffic      | float (kb)   | 96000000     |
   |                  | remaining        |              |              |
   +------------------+------------------+--------------+--------------+

5.5.3.  Examples

   Example for a user with 20 GB per month for 40 EUR, then reach a
   threshold, and with unlimited data during week-ends and to the server
   "deezer":

   [
     {
       "domains": ["deezer.com"]
     },
     {
       "prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
     },
     {
       "beginDate": "2016-07-16T00:00:00Z",
       "endDate": "2016-07-17T23:59:59Z",
     },
     {
       "beginDate": "2016-06-20T00:00:00Z",
       "endDate": "2016-07-19T23:59:59Z",
       "trafficRemaining": 96000000
     },
     {
       "throughputMax": 1000
     }
   ]

   If the host tries to download data from deezer.com, the conditions of
   the first elementary billing are fulfilled, so the host takes this
   elementary billing, finds no cost indication in it and so deduces
   that it is totally free.  If the host tries to exchange data with
   youtube.com and the date is 2016-07-14T19:00:00Z, the conditions of
   the first, second and third elementary billing are not fulfilled.



Bruneau, et al.         Expires September 3, 2017              [Page 14]


Internet-Draft           Possibilities for PvDs               March 2017


   But the conditions of the fourth are.  So the host takes this
   elementary billing and sees that there is a threshold, 12 GB are
   remaining.

   Another example for a user abroad, who has 3 GB per year abroad, and
   then pay each MB:

   [
     {
       "beginDate": "2016-02-10T00:00:00Z",
       "endDate": "2017-02-09T23:59:59Z",
       "trafficRemaining": 9200000
     },
     {
       "pricePerGb": 30,
       "currency": "EUR"
     }
   ]

5.6.  Private Extensions

   keys starting with "x-" are reserved for private use and can be
   utilized to provide vendor-, user- or enterprise-specific
   information.  It is RECOMMENDED to use one of the patterns "x-FQDN-
   KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or
   PEN is a private enterprise number [PEN] under control of the author
   of the extension to avoid collisions.

5.7.  Examples

5.7.1.  Using JSON




















Bruneau, et al.         Expires September 3, 2017              [Page 15]


Internet-Draft           Possibilities for PvDs               March 2017


   {
     "name": "Orange France",
     "localizedName": "Orange France",
     "dnsServers": ["8.8.8.8", "8.8.4.4"],
     "throughputMax": {
       "down": 100000,
       "up": 20000
     },
     "cost": [
       {
         "domains": ["deezer.com"]
       },
       {
         "prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
       },
       {
         "beginDate": "2016-07-16T00:00:00Z",
         "endDate": "2016-07-17T23:59:59Z",
       },
       {
         "beginDate": "2016-06-20T00:00:00Z",
         "endDate": "2016-07-19T23:59:59Z",
         "trafficRemaining": 96000000
       },
       {
         "throughputMax": 1000
       }
     ]
   }

5.7.2.  Using DNS TXT records

   n=Orange France
   r=8.8.8.8,8.8.4.4
   tp=100000,20000
   cost+0+domains=deezer.com
   cost+1+prefixes4=78.40.123.182/32,78.40.123.183/32
   cost+2+beginDate=2016-07-16T00:00:00Z
   cost+2+endDate=2016-07-17T23:59:59Z
   cost+3+beginDate=2016-06-20T00:00:00Z
   cost+3+endDate=2016-07-19T23:59:59Z
   cost+3+trafficRemaining=96000000
   cost+4+throughputMax=1000








Bruneau, et al.         Expires September 3, 2017              [Page 16]


Internet-Draft           Possibilities for PvDs               March 2017


6.  Security Considerations

   While the PvD ID can be forged easily, if the host retrieve the
   extended PvD via TLS, then the host can trust the content of the
   extended PvD and verifies that the RA prefix(es) are indeed included
   in the extended PvD.

7.  Acknowledgements

   Many thanks to M.  Stenberg and S.  Barth: Section 5.3, Section 5.4
   and Section 5.6 are from their document [I-D.stenberg-mif-mpvd-dns].

   Thanks also to Ray Bellis, Lorenzo Colitti, Erik Kline, Mark Townsley
   and James Woodyatt for useful and interesting brainstorming sessions.

8.  References

8.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <http://www.rfc-editor.org/info/rfc7556>.

8.2.  Informative references

   [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]
              Baker, F., Bowers, C., and J. Linkova, "Enterprise
              Multihoming using Provider-Assigned Addresses without
              Network Prefix Translation: Requirements and Solution",
              draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work
              in progress), October 2016.

   [I-D.stenberg-mif-mpvd-dns]
              Stenberg, M. and S. Barth, "Multiple Provisioning Domains
              using Domain Name System", draft-stenberg-mif-mpvd-dns-00
              (work in progress), October 2015.

   [PEN]      IANA, "Private Enterprise Numbers",
              <https://www.iana.org/assignments/enterprise-numbers>.







Bruneau, et al.         Expires September 3, 2017              [Page 17]


Internet-Draft           Possibilities for PvDs               March 2017


Authors' Addresses

   Basile Bruneau
   Ecole polytechnique
   Vannes  56000
   France

   Email: basile.bruneau@polytechnique.edu


   Eric Vyncke (editor)
   Cisco
   De Kleetlaan, 6
   Diegem  1831
   Belgium

   Email: evyncke@cisco.com


   Pierre Pfister
   Cisco
   11 Rue Camille Desmoulins
   Issy-les-Moulineaux  92130
   France

   Email: ppfister@cisco.com


   David Schinazi
   Apple

   Email: dschinazi@apple.com


   Tommy Pauly
   Apple

   Email: tpauly@apple.com













Bruneau, et al.         Expires September 3, 2017              [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/