intarea                                                       B. Bruneau
Internet-Draft                                       Ecole polytechnique Polytechnique
Intended status: Informational                                P. Pfister
Expires: September 14, 2017 January 1, 2018                                           Cisco
                                                             D. Schinazi
                                                                T. Pauly
                                                                   Apple
                                                               E. Vyncke, Ed. Vyncke
                                                                   Cisco
                                                          March 13,
                                                           June 30, 2017

               Proposals to discover

             Discovering Provisioning Domains
             draft-bruneau-intarea-provisioning-domains-00 Domain Names and Data
             draft-bruneau-intarea-provisioning-domains-01

Abstract

   An increasing number of hosts and networks are connected to the
   Internet through multiple interfaces, some of which may provide
   multiple ways to access the internet by the mean of multiple IPv6
   prefix configurations.

   This document describes one possible a way for hosts to retrieve additional
   information about their Internet network access configuration. characteristics.  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. Name (FQDN).  This document separates the way of getting the Provisioning Domain identifier, retrieved using a new Router
   Advertisement (RA) option, is associated with the way set of getting the Provisioning Domain information
   and
   included within the potential RA and may later be used to retrieve additional
   information contained in associated to the Provisioning Domain. PvD by the mean of an HTTP request.

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 14, 2017. January 1, 2018.

Copyright Notice

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

   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.  Provisioning Domain Identification using Router
       Advertisements  . . . . . . .   4
   3.  Retrieving the PvD ID . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Using One Router Advertisement per  PvD ID Option for Router Advertisements . . . . . . . . .   4
     3.2.  Rationale for not selecting other techniques  . . . .  Router Behavior . .   5
       3.2.1.  Using DNS-SD  . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Using Reverse DNS lookup  . . . . . . . . . . . . . .   5
     3.3.  IoT Considerations  . . . . . . .  Host Behavior . . . . . . . . . . . .   6
     3.4.  Linking IPv4 Information to an IPv6 PvD . . . . . . . . .   6
   4.  Getting the full set of PvD information .   5
       3.3.1.  DHCPv6 configuration association  . . . . . . . . . .   6
     4.1.  Using the PvD Bootstrap Information Option  . . . . . . .   7
     4.2.  Downloading a JSON file over HTTPS  .
       3.3.2.  DHCPv4 configuration association  . . . . . . . . . .   7
       4.2.1.  Advantages  . . . . . . . . . . . .
       3.3.3.  Interconnection Sharing by the Host . . . . . . . . .   7
       4.2.2.  Disadvantages . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Using DNS TXT ressource records (not selected)  . . . . .   8
       4.3.1.  Advantages  . . . . . . . . . . . . . . . . . . . . .   8
       4.3.2.  Disadvantages . . . . . . . . . . . . . . . . . . . .   8
       4.3.3.  Using DNS SRV ressource records . . . .
   4.  Provisioning Domain Identification using IKEv2  . . . . . . .   8   7
   5.  PvD  Provisioning Domain Additional Information  . . . . . . . . . . . . . . . . . . . . . . .   9   8
     5.1.  Retrieving the PvD Name  . . . . . . . . . . . . . . . . Additional Information . . . . . . . .   9
     5.2.  Trust of  Providing the bootstrap PvD  . . . . . . . Additional Information  . . . . . . . .  10
     5.3.  Reachability  . . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  DNS Configuration . . . . . . . .  PvD Additional Information Format . . . . . . . . . . . .  12
     5.5.  10
       5.3.1.  Connectivity Characteristics Information  . . . . . .  12
       5.3.2.  Private Extensions  . . . . . . . .  13
     5.6.  Connection monetary cost . . . . . . . . .  12
       5.3.3.  Example . . . . . . .  14
       5.6.1.  Conditions . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . .  15
       5.6.2.  Price . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . .  15
       5.6.3.  Examples . . . . . . . . . . .  14
   8.  Acknowledgements  . . . . . . . . . . .  16
     5.7.  Private Extensions . . . . . . . . . . .  14
   9.  References  . . . . . . . .  17
     5.8.  Examples . . . . . . . . . . . . . . . . .  14
     9.1.  Normative references  . . . . . . .  17
       5.8.1.  Using JSON . . . . . . . . . . .  14
     9.2.  Informative references  . . . . . . . . . .  17
       5.8.2.  Using DNS TXT records . . . . . . .  15
   Appendix A.  Changelog  . . . . . . . . .  18
   6.  Use case examples . . . . . . . . . . . .  16
     A.1.  Version 00  . . . . . . . . . .  19
     6.1.  Multihoming . . . . . . . . . . . . .  16
     A.2.  Version 01  . . . . . . . . . .  19
     6.2.  VPN/Extranet example . . . . . . . . . . . . .  16
   Appendix B.  Connection monetary cost . . . . .  19
   7.  Security Considerations . . . . . . . . .  17
     B.1.  Conditions  . . . . . . . . . .  19
   8.  Acknowledgements . . . . . . . . . . . . .  17
     B.2.  Price . . . . . . . . .  19
   9.  References . . . . . . . . . . . . . . . . .  18
     B.3.  Examples  . . . . . . . .  19
     9.1.  Normative references  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative references  . . . . . . . . . . . . . . . . .  20

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   It has become very common in modern networks that hosts have Internet
   or more specific network 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 identified by Fully Qualified Domain Name (called Names
   called PvD ID) IDs, which is are included in Router Advertisements [RFC4861]
   as a new option and are 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.
   configuration data.

   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 identical services.

   This document proposes multiple methods allowing the host to also introduces a way for hosts to retrieve the PvD ID associated with additional
   information related to a set specific PvD by the mean of networking discover an HTTP-over-TLS
   query using an URI derived from the PvD and retrieve ID.  The retrieved JSON
   object contains additional network information that would typically
   be considered unfit, or too large, to be directly included in the PvD information.  It also explains configuration
   as well as
   Router Advertisements.  This information can be used by the methods and format in order
   networking stack, the applications, or even be partially displayed to retrieve some of
   the
   parameters that can describe users (e.g., by displaying a PvD. localized network service name).

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 addition, this document, each document uses the following terminology:

   PvD:   A Provisioning Domain, a set of network configuration
      information; for more information, see [RFC7556].

   PvD ID:   A Fully Qualified Domain Name (FQDN) used to identify a
      PvD.

   Explicit PvD:   A PvD uniquely identified with a PvD ID.

   Implicit PvD:   A PvD associated with a set of configuration
      information that, in the absence of a PvD ID, is associated with
      the advertising router.

3.  Provisioning Domain Identification using Router Advertisements

   Each provisioning domain is identified by a PvD ID.  The PvD ID is a
   Fully Qualified Domain Name (FQDN) which belongs MUST belong to the network
   operator in order to avoid conflicts among network operators. ambiguity.  The same PvD ID can exist MAY be used in
   several access networks if the set of configuration information is
   identical in all those networks (such as (e.g. in all home networks of a residential subscriber).  Within a host,
   the PvD ID SHOULD be associated subscribed to all the configuration information
   associated to this same service).

3.1.  PvD ID; this allows ID Option for easy update and removal of
   information while keeping a consistent state.

   This section assumes that IPv6 Router Advertisements are used to
   discover

   This document introduces a new Router Advertisement (RA) option
   called the PvD ID and explains why this technique was selected.

3.1.  Using One Router Advertisement per PvD

   Hosts receive implicit PvDs by Option, used to convey the means of Router Advertisements
   (RA).

   A router MAY add
   FQDN identifying a single given PvD.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Seq  |H|L|     Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          PvD ID Option in its RAs.  The FQDN                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                PvD ID
   specified in this Router Advertisements Option format

   Type        :   (8 bits) To be defined by IANA.

   Length      :   (8 bits) The length of the option is then associated with all (including the Prefix Type
      and Length fields) in units of 8 octets.

   Seq         :   (4 bits) Sequence number for the PvD Additional
      Information, as described in Section 5.

   H-flag      :   (1 bit) Whether some PvD Additional Information Options (PIO) included is
      made available through HTTP over TLS, as described in Section 5.

   L-flag      :   (1 bit) Whether the RA (albeit it router is expected
   that only one PIO will also providing IPv4
      access using DHCPv4 (see Section 3.3.2).

   Reserved    :   (10 bits) Reserved for later use.  It MUST be included in set to
      zero by the RA).  All other information
   contained sender and ignored by the receiver.

   Lifetime    :   (32 bits) The length of time in seconds (relative to
      the RA (notably time the RDNSS and Route Information Option)
   are to be associated with packet is sent) that the PvD ID.  The set ID option is valid.  A
      value of information
   contained all one bits (0xffffffff) represents infinity.

   PvD ID FQDN :   The FQDN used as PvD ID in DNS binary format
      [RFC1035], padded until the RA forms next 8 octets boundary.  All the bootstrap (or hint) PvD.  A new RA
   option will bytes
      after the first empty DNS label MUST be required set to convey zero by the PvD ID.

   When a host receives an RA which does not sender
      and MUST be ignored by the receiver.  The DNS name compression
      technique described in [RFC1035] MUST NOT be used.

   Routers MUST NOT include a more than one PvD ID Option, Router Advertisement
   Option in each RA.  In case multiple PvD ID options are found in a
   given RA, hosts MUST ignore all but the set first PvD ID option.

   Note: The existence and/or size of information included in the RA (such as Recursive DNS
   server, IPv6 prefix) sequence number is attached subject to an implicit
   discussion.  The validity of a PvD identified by Additional Information object is
   included in the
   local interface ID on which object itself, but this only allows for 'pull based'
   updates, whereas the RA options usually provide 'push based' updates.

   Note: including the lifetime option is received, and by congruent with the link-local
   address lifetime
   option of the other RA option.  On the other hand, do we need it ?

3.2.  Router Behavior

   A router sending MAY insert at most one PvD ID Option in its RAs.  The
   included PvD ID is associated with all the RA.

   In other options included in
   the cases where a router should same RA (e.g., Prefix Information [RFC4861], Recursive DNS Server
   [RFC6106], Routing Information [RFC4191], Captive Portal [RFC7710]
   options).

   In order to provide multiple independent PvDs
   to all hosts, including non-PvD aware hosts, it should PvDs, a router MUST send
   multiple
   RAs, as proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming] RAs using different source link-local addresses (LLA); (LLA) (as
   proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]), each of
   which MAY include a PvD ID option.  In such cases, routers MAY
   originate the datalink layer
   (MAC) address could be different RAs using the same for all the different RA. datalink layer address.

   If the router is actually a VRRP instance, instance [RFC5798], then the
   procedure is identical except that the virtual link-layer datalink layer address
   is used as well as virtual
   link-layer IPv6 addresses.

   Using

3.3.  Host Behavior

   RAs are used to configure IPv6 hosts.  When a host receives a RA allows for an early discovery of the
   message including a PvD ID as Option with a non-zero lifetime, it is early
   in MUST
   associate all the interface start-up.  As RA is usually processed configuration options included in the kernel,
   this requires a host OS upgrade.  The RA SHOULD contain other (e.g.,
   Prefix Information [RFC4861], Recursive DNS Server [RFC6106], Routing
   Information [RFC4191], Captive Portal [RFC7710] options) with the PvD
   information as explained in section Section 4.1.

3.2.  Rationale for
   ID).

   If the received RA does not selecting other techniques

   There are other techniques to discover include a PvD ID Option, or whenever the
   included PvD ID that were not
   selected Option has a lifetime set to zero, the host MUST
   associate the options included in the RA with an implicit PvD.  This
   implicit PvD is identified by the authors link-local address of the router
   sending the RA and reviewers, this section explains why.
   The design goal the interface on which the RA was to be as reliable as possible (do received.

   This document does not depend on
   Internet connectivity) and as fast as possible.

3.2.1.  Using DNS-SD

   For update the way Router Advertisement options
   are processed.  But in addition to the option processing defined in
   other documents, hosts implementing this specification MUST associate
   each created or updated object (e.g. address, default route, more
   specific route, DNS server list) with the PvD associated with the
   received RA including a RDNSS option as well as a DNS search
   list option, the host MAY retrieve interface and link-local address of the
   router which last updated the object.

   Each configuration object has a PvD validity timer set to the PvD ID by querying
   option lifetime whenever an RA that updates the
   configured DNS server for records of type PTR associated with
   _pvd.<DNS search name>. object is received.
   If the received RA does not include a PvD ID is configured, the DNS recursive
   resolver MUST reply with option, or whenever the
   PvD ID as a PTR record.  NXDOMAIN option lifetime is
   returned otherwise.

   When zero, the RDNSS address is link-local, associated objects are
   immediately associated with an implicit PvD, as mentioned in the host MAY retrieve
   previous paragraph.  Similarly, whenever an object's PvD timer
   reaches zero, the object is immediately associated with an implicit
   PvD
   ID before configuring its global scope address(es).

   Relying on a valid DNS service at identified by the link-local address and interface bootstrap can lead
   into delay to start of the interface or starting without enough
   information: for example when router
   which last updated the RDNSS is a non local object.

   While resolving names, executing the default address selection
   algorithm [RFC6724] or executing the default router selection
   algorithm ([RFC2461], [RFC4191] and
   there is no Internet connectivity.

3.2.2.  Using Reverse DNS lookup

   [I-D.stenberg-mif-mpvd-dns] proposes a solution to get [RFC8028]), hosts MAY consider
   only the name configuration associated with an arbitrary set of
   the PvD using PvDs.

   For example, a reverse DNS lookup based on the host global
   address(es).  It merely relies on prepending MAY associate 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 given process with a specific
   PvD, or a specific set of PvDs, while associating another process
   with another PvD.  A PvD-aware application might also be delegated from the
   operator able to the network user, in which case it would not work.

   It also requires
   select, on a fully functional global address to retrieve the
   information per-connection basis, which may PvDs should be too late used for a correct host configuration.
   One advantage
   given connection.  And particularly constrained devices such as small
   battery operated devices (e.g. IoT), or devices with limited CPU or
   memory resources may purposefully use a single PvD while ignoring
   some received RAs containing different PvD IDs.

   The way an application expresses its desire to use a given PvD, or a
   set of PvDs, or the way this selection is that it does not require any change in enforced, is out of the IPv6
   protocol and no change
   scope of this document.  Useful insights about these considerations
   can be found in the [I-D.kline-mif-mpvd-api-reqs].

3.3.1.  DHCPv6 configuration association

   When a host kernel or even in retrieves configuration information from DHCPv6, the CPE.

3.3.  IoT Considerations

   TBD: should state that when end-host (IoT) cannot impletement
   completely this RFC it MAY select any of
   configured elements MUST be associated with the PvD explicit or implicit
   PvD of the router SHOULD
   send a single unicast RA (hence a single PvD) in response to received on the RS
   or none if it detects that it cannot offer same interface with the right O-flag set of network
   services.

3.4.  Linking IPv4 Information to an IPv6 PvD

   The document describes IPv6-only PvD but there are

   [RFC4861].  If multiple ways to
   link RAs with the O-flag set of IPv4 configuration information and associated with
   different PvDs are received by DHCPv4:

   o  correlation based on the data-link layer same interface, the link-local
   address of the source, if
      the IPv6 RA and DHCPv6 server MAY be compared with the DHCPv4 response have routers' link-
   local addresses in order to disambiguate.  If the same data-link layer
      address, disambiguation is
   impossible, then the DHCPv6 configuration information contained in the IPv4 DHCP can MUST be
      linked
   associated with an implicit PvD.

   This process requires hosts to keep track of received RAs, associated
   PvD IDs, and routers link-local addresses.

3.3.2.  DHCPv4 configuration association

   When a host retrieves configuration from DHCPv4 on an interface, the IPv6 PvD;

   o  correlation based
   configured elements MUST be associated with the explicit PvD,
   received on the interface when there same interface, whose PVD ID Options L-flag is no data-link set.
   If multiple different PvDs are found, the datalink layer address on used
   by the link (such as a 3GPP link), then DHCPv4 server/relay MAY be compared with the information
      contained datalink layer
   address used by on-link advertising routers in order to disambiguate.
   If no RA associated with a PvD ID option with the L-flag set is
   found, or if the disambiguation fails, the IPv4 PDP context can configuration
   information MUST be linked associated with an implicit PvD.

3.3.3.  Interconnection Sharing by the Host

   The situation when a host becomes also a router by acting as a router
   or ND proxy on a different interface (such as WiFi) to share the IPv6
   connectivity of another interface (such as cellular), also known as
   "tethering" is TBD but it is expected that the one or several PvD
      (*** TO BE VERIFIED before going -01);

   o  correlation based on
   associated to the DNS search list, if shared interface will be also advertised to the
   clients.

4.  Provisioning Domain Identification using IKEv2

   RFC 7296 defines Internet Key Exchange version 2 (IKEv2) which
   includes in sections 2.19 and 3.15 a Configuration Payload (CP) which
   may be used by an IPsec client to request configuration items (e.g.,
   addresses, recursive DNS search lists
      are identical between servers).  IKEv2 also negatiates traffic
   selectors which represent the IPv6 RDNSS 5-tuple(s) to be protected by the
   Security Association (SA) negotiated by IKEv2.  This set of
   information is another PvD and may include INTERNAL_IP6_ADDRESS,
   INTERNAL_IP6_LINK, INTERNAL_IP6_SUBNET (to be used to route traffic
   to this subent), INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN.

   The PvD ID Configuration option for IKEv2 has the DHCPV4 response, then following structure
   (similar to the information contained RA option):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|  Attribute Type             |              Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Seq  |H|L|     Reserved                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          PvD ID FQDN                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           PvD ID IKEv2 Configuration Payload Attributes format

   R-bit  Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].

   Attribute Type  (15 bits) tbd by IANA PVD_ID.

   Length  Length (2 octets, unsigned integer) - Length of PvD ID FQDN +
      2.

   Seq  Sequence number (4 bits) for the IPv4 DHCP response can PvD Additional Information, as
      described in Section 5.

   H-flag  (1 bit) Whether some PvD Additional Information is made
      available through HTTP over TLS, as described in Section 5.

   L-flag  (1 bit) must be linked set to 0 if the Configuration Payload
      contains only IPv6 PvD.

   The correlation could information, else it must be useful set to 1.

   Reserved  (10 bits) Reserved for some later use.  It MUST be set to zero
      by the sender and ignored by the receiver.

   PvD information such ID FQDN  The FQDN used as
   Internet reachability, use of captive portal, display name of PvD ID in DNS binary format [RFC1035],
      padded until the
   PvD, ...

   In cases where next 8 octets boundary.  All the IPv4 configuration information could not be
   associated with a PvD, hosts bytes after the
      first empty DNS label MUST consider it as attached be set to an
   independent implicit PvD containing no other information than what is
   provided through DHCPv4.

4.  Getting zero by the full set of PvD information

   Once sender and MUST
      be ignored by the receiver.  The DNS name compression technique
      described in [RFC1035] MUST NOT be used.

5.  Provisioning Domain Additional Information

   Once a new PvD ID is known, discovered, it MAY may be used to retrieve
   additional
   information. information about the characteristics of the provided
   connectivity.  This set of information is called PvD Information Additional
   Information, and is modeled encoded as a key-value dictionary
   which keys are ASCII strings JSON object [RFC7159].

   The purpose of arbitrary length, and values are
   either strings (encoding can vary), ordered list this additional set of values
   (recursively), or information is to securely
   provide additional information to hosts about the connectivity that
   is provided using a dictionary (recursively).

   The PvD Information may given interface and source address pair.  It
   typically includes data that would be retrieved from multiple sources (from the
   bootstrap PvD considered too large, or not
   critical enough, to be provided with an RA option.  The information
   contained in this object MAY be used by the RA operating system, network
   libraries, applications, or users, in order to the secondary/extended PvD decide which set of
   PvDs should be used for which connection, as described in this section);
   Section 3.3.

5.1.  Retrieving the PvD ID is then used to correlate Additional Information

   When the
   information from different sources.  The way a host should operate
   when receiving conflicting information is TBD but it SHOULD at least
   override information from less authenticated sources (RA) by more
   authenticated sources (via TLS).

4.1.  Using H-flag of the PvD Bootstrap Information ID Option

   Routers is set, hosts MAY transmit, in addition attempt to
   retrieve the PvD ID option, a PvD
   Bootstrap Additional Information option, containing associated with a first subset of PvD
   information.  The additional pieces of bootstrap given PvD information data
   set are transmitted using
   by performing an HTTP over TLS [RFC2818] GET query to https://<PvD-
   ID>/pvd.json [RFC5785].  On the short-hand notation proposed in
   Section 5.  This requires another RA option.

   As there other hand, hosts MUST NOT do so
   whenever the H-flag is a size limit on not set.

   Note: Should the amount of information PvD AI retrieval be a single RA can
   convey, MAY or a SHOULD ? Could the
   object contain critical data, or should it is likely only contain informational
   data ?

   Note that the DNS name resolution of <PvD-ID> as well as the actual
   query MUST be performed in the PvD Bootstrap Information option may
   not contain context associated to the whole set of PvD Information.  The ID.
   In other words, the name resolution, source address selection, as
   well as the next-hop router selection MUST be performed while using
   exclusively the set of PvD configuration information included in attached with the RA is called PvD Bootstrap Information.

4.2.  Downloading a JSON file over HTTPS

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

   The host MUST perform an HTTP query to https://<PvD-ID>/v1.json. Section 3.3.

   If the HTTP status of the answer is greater than or equal to 400 the
   host MUST abandon and consider that there is no additional PvD
   information.  If the HTTP status of the answer is between 300
   included and 400 399 included it MUST follow the redirection(s).  If the
   HTTP status of the answer is between 200 included and 300 299 included
   the host MAY get a file containing a single JSON object.

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

4.2.1.  Advantages

   The JSON format allows advanced structures.

   It can
   object could not be secured using HTTPS (and DNSSEC).

   It is easier to update retrieved, an error message SHOULD be logged and/
   or displayed in a file on rate-limited fashion.

   After retrieval of the PvD Additional Information, hosts MUST watch
   the PvD ID Seq field for change.  In case a web server different value 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
   one in the user.

4.2.2.  Disadvantages

   It RA Seq field is slower than using DNS because HTTPS uses TCP and TLS and needs
   more packets to be exchanged to get observed, or whenever 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 validity time
   included in the design team meeting but has
   kept here for reference, it will be removed after global consensus object is
   reached.

   The host could expired, hosts MUST either perform a DNS new
   query for TXT resource records (RR) for and retrieve a new version of the FQDN used as PvD ID (alternatively for _pvd.<PvD-ID>).  For each
   retrieved PvD ID, object, or deprecate the DNS query
   object and stop using it.

   Hosts retrieving a new PvD Additional Information object MUST be sent to the DNS server
   configured from the same router advertisement as check
   for the PvD ID.  Syntax presence and validity of the TXT response is defined in mandatory fields 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 5.3.  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)
   retrieved object including an outdated expiration time or fragmented UDP packets (which could be dropped by missing a bad choice of security policy).  Large TXT records could also
   mandatory element, MUST be
   used ignored.  In order to mount an amplification attack.

4.3.3.  Using DNS SRV ressource records

   It is expected that avoid traffic spikes
   toward the DNS TXT records will be sufficient for server hosting the
   host to configure itself with basic networking and policy
   configuration.  Nevertheless, if further information is required, or PvD Additional Information when an
   object expires, a different security model shall be used to access the PvD
   Information, host which last retrieved an object at a SRV Resource Record time A,
   including a full URL MAY be
   included as a response, expecting validity time B, SHOULD renew the host to query this URL object at a uniformly
   random time in the interval [(B-A)/2,A].

   In order to retrieve additional prevent PvD information.

5. spoofing by malicious or misconfigured
   routers, PvD Additional Information

   PvD information is object includes 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 IPv6
   prefixes which MUST be further specified
   (recursively).  Some keys have a default value as described in checked against all the
   following sections.  When there is an expiration time Prefix Information
   Options advertised in a PvD, then
   the information MUST be refreshed before the expiration time.  The
   behavior Router Advertisement.  If any of a host when the refresh operation
   prefixes included in the Prefix Information Options is not successful is
   TBD.

   Nodes using the PvD MUST support the two encodings:

      JSON syntax for in the complete set
   of PvD information;

      short-hand notation for the bootstrap PvD.

   When the PvD information is transferred as a JSON file, then the key
   used is the second column of the following table.  The syntax of the
   JSON file is obvioulsy JSON and is richer than the short-hand
   notation specified prefixes contained in the next paragraph.

   When transmitting more information than additional information, the PvD ID (the one
   included in the RA (or when
   DNS TXT resource records are used), the shorthand notataion for PvD
   information is used and consists of a string containing several
   "key=value;" substrings.  The "key" is the first column of the
   following tables, the value is encoded as:

   Shorthand notation for values:

      integer: expressed in decimal format with a '.' (dot) used for
      decimals;

      string: expressed as UTF-8 encoded string, delimited by single
      quote character, the single quote character can additional information) MUST be expressed by
      two consecutive single quote character;

      boolean: expressed as '0' for false
   considered unsafe and '1' for true;

      IPv6 address: printed as RFC5952 [RFC5952].

5.1.  PvD Name

   PvD SHOULD have a human readable name in order to MUST NOT be presented on used.  While this does not prevent
   a
   GUI.  The name malicious network provider, it can also be localized.

   +------------+------------+---------------+--------------+----------+
   | DNS TXT ke | JSON key   | Description   | Type         | used to detect
   misconfiguration.

   The server serving the JSON     |
   | y/Bootstra |            |               |              | Example  |
   | p PvD key  |            |               |              |          |
   +------------+------------+---------------+--------------+----------+
   | n          | name       | User-visible  | human-       | "Foobar  |
   |            |            | service name, | readable     | Service" |
   |            |            | files SHOULD be     | UTF-8 string |          |
   |            |            | also check whether the
   client address is part of the   |              |          |
   |            |            | bootstrap PvD |              |          |
   | nl10n      | localizedN | Localized     | human-       | "Service |
   |            | ame        | user-visible  | readable     | Blabla"  |
   |            |            | service name, | UTF-8 string |          |
   |            |            | language can  |              |          |
   |            |            | be selected   |              |          |
   |            |            | based on the  |              |          |
   |            |            | HTTP Accept-  |              |          |
   |            |            | Language      |              |          |
   |            |            | header in the |              |          |
   |            |            | request.      |              |          |
   +------------+------------+---------------+--------------+----------+

5.2.  Trust of prefixes listed into the bootstrap PvD additional
   information and SHOULD return a 403 response code if there is no
   match.  The content of server MAY also use the bootstrap PvD (from client address to select the original RA) cannot
   right JSON object to be
   trusted as it is not authenticated.  But, the extended PvD can returned.

   Note: In a similar way, a DNS server names list could be
   associated with the PvD ID (as included in
   the PvD ID AI in order to avoid rogue APs from inserting a different DNS
   resolver.  But this would also prevent CPEs from advertising
   themselves as default DNS (which is used usually done).  SPs which really
   want to use CPEs as DNS, for caching reasons, might find 'creative'
   ways to construct go around this rule.

5.2.  Providing the
   extended PvD URL) and trusted by Additional Information

   Whenever the H-flag is set in the used of TLS.  The extended PvD
   SHOULD therefore include RA Option, a valid PvD
   Additional Information object MUST be made available to all hosts
   receiving the following information elements and, if
   they are RA.  In particular, when a captive portal is present, the host
   hosts MUST verify that the all PIO of still be allowed to access the RA
   fits object, even before logging
   into the master prefix list.  If any PIO prefix from captive portal.

   Routers MAY increment the
   bootstrap PvD does not fit PVD ID Sequence number (Seq) in the master prefix array, then all
   information received by the bootstrap order to
   inform host that a new PvD must be invalidated.  In
   short, the masterIPv6Prefix received over TLS Additional Information object is used to authenticate
   the bootstrap PvD. available
   and should be retrieved.

5.3.  PvD Additional Information Format

   The values of the bootstrap PvD (RDNSS, ...) are overwritten by Additional Information is a JSON object.

   The following array presents the
   values contained mandatory keys which MUST be
   included in the trusted extended PvD if they are present.

   +-----+------------------+-------------+----------+-----------------+
   | DNS object:

   +----------+-------------------+-----------+------------------------+
   | JSON key | Description       | Type      | JSON Example                |
   +----------+-------------------+-----------+------------------------+
   | TXT |                  | name     | Human-readable    | UTF-8     | "Awesome Wifi"         | key
   |          | service name      | string    |                        |
   +-----+------------------+-------------+----------+-----------------+
   | mp6 expires  | masterIpv6Prefix Date after which  | All the ISO 8601  | Array of "2017-07-23T06:00:00Z" | ["2001:db8::/32
   |          | this object is    |           | IPv6                        | IPv6
   | "]          | not valid         |           |                        | prefixes
   | prefixes | Array of IPv6     | Array of  | ["2001:db8:1::/48",    |
   | linked to          | prefixes valid    | strings   | "2001:db8:4::/48"]     |
   |          | for this PvD    |          | PVD      |           |                        |                  | (such as
   +----------+-------------------+-----------+------------------------+

   A retrieved object which does not include a  |          |                 |
   |     |                  | /29 for valid string associated
   with the |          |                 |
   |     |                  | ISP).       |          |                 |
   +-----+------------------+-------------+----------+-----------------+

5.3.  Reachability

   The following set of keys can be used to specify "name" key at the set root of services
   for which the respective PvD should be used.  If present they MUST be
   honored by object, or a valid date
   associated with the client, i.e., if "expiration" key, also at the PvD is marked as not usable for
   Internet access (walled garden), then it root of the object,
   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 ignored.  In such cases, an error message SHOULD be logged
   and/or displayed in a different PvD
   MUST rate-limited fashion.

   The following table presents some optional keys which MAY be used for other destinations.

   +-----+---------------+---------------+-----------+-----------------+
   | DNS included
   in the object.

   +-----------------+-----------------------+---------+---------------+
   | JSON key        | Description           | Type    | JSON Example       |
   +-----------------+-----------------------+---------+---------------+
   | TXT |               |               |           |                 |
   | key |               |               |           |                 |
   +-----+---------------+---------------+-----------+-----------------+
   | s   | noInternet    | Internet      | boolean   | true            |
   |     |               | inaccessible  |           |                 |
   | cp  | captivePortal | Presence of a | boolean   | false           |
   |     |               | captive       |           |                 |
   |     |               | portal        | localizedName   | Localized user-       | UTF-8   | z "Wifi Genial" | dnsZones
   | DNS zones                 | array of visible service name, | ["foo.com","sub string  |               |
   |                 | accessible language can be       | DNS zone         | .bar.com"]               |
   |                 | selected based on the | and         |               |
   |                 | HTTP Accept-Language  |         | searchable               |
   |                 | header in the         | 6         | prefixes6               | IPv6-prefixes
   | array of                 | ["2001:db8:a::/ request.              |         |               |
   | accessible noInternet      | IPv6 No Internet, set when | 48","2001:db8:b boolean | true          |
   |                 | via this the PvD only provides | prefixes  | :c::/64"]       |
   | 4   | prefixes4     | IPv4-prefixes | array of  | ["192.0.2.0/24"         |               |
   |                 | accessible restricted access to  | IPv4         | ,"2.3.0.0/16"]               |
   |                 | a set of services.    |         | prefixes               |
   | characteristics | Connectivity          | JSON    | See Section   | in CIDR
   |                 | characteristics       | object  | 5.3.1         |
   | reachable metered         | metered, when the     | boolean | false         |
   |                 | via this access volume is      |         |               |
   |                 | limited.              | PvD         |               |
   +-----+---------------+---------------+-----------+-----------------+

5.4.  DNS Configuration

   The following set of keys can be used to specify
   +-----------------+-----------------------+---------+---------------+

   It is worth noting that the DNS
   configuration JSON format allows for the respective PvD.  If present, they extensions.
   Whenever an unknown key is encountered, it MUST be
   honored and used by the client whenever it wishes to access a
   resource described by the PvD.

   +-----+------------+-------------+-----------+----------------------+
   | DNS | JSON key   | Description | Value     | JSON Example         |
   | TXT |            |             |           |                      |
   | key |            |             |           |                      |
   +-----+------------+-------------+-----------+----------------------+
   | r   | dnsServers | Recursive   | array of  | ["2001:db8::1","192. |
   |     |            | DNS server  | IPv6 and  | 0.2.2"]              |
   |     |            |             | IPv4      |                      |
   |     |            |             | addresses |                      |
   | d   | dnsSearch  | DNS search  | array of  | ["foo.com","sub.bar. |
   |     |            | domains     | search    | com"]                |
   |     |            |             | domains   |                      |
   +-----+------------+-------------+-----------+----------------------+

5.5. ignored along with
   its associated elements, unless specified otherwise in future
   updating documents.

5.3.1.  Connectivity Characteristics

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

   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.

   +------+------------------+------------+--------------+-------------+
   | DNS

   +---------------+--------------+---------------------+--------------+
   | JSON key      | Descriptio Description  | Type                | JSON        |
   | TXT  |                  | n          |              | Example      |
   +---------------+--------------+---------------------+--------------+
   | key  |                  |            |              |             |
   +------+------------------+------------+--------------+-------------+
   | tp   | throughputMax maxThroughput | Maximum      | object({down object({down(int),  | {"down":     |
   |               |                  | achievable   | (int),       | 10000,      |
   |      |                  | throughput | up(int)}) in | "up": 5000} |
   |      |                  | (e.g. CPE  | kb/s   | 10000, "up": |
   |               |                  | downlink/u |              |             |
   |      |                  | plink)     | throughput   |                     | 5000}        | lt
   | latencyMin minLatency    | Minimum      | object({down object({down(int),  | {"down":    |
   |      |                  | achievable | (int),       | 10, "up": |
   |               |                  | latency achievable   | up(int)}) in ms     | "up": 20}    |
   |               | latency      |                     | ms           |              |
   | rl            | reliabilityMax   | Maximum      | object({down object({down(int),  | {"down":     |
   |               |                  | achievable   | (int),       | 1000, "up": |
   |      |                  | reliabilit | up(int)}) in losses | 800}        |
   |      |                  | y          | 1/1000 0.1, "up":   |
   |               | cp reliability  | captivePortal every 1000 packets  | Captive 1}           | URL
   +---------------+--------------+---------------------+--------------+

5.3.2.  Private Extensions

   JSON keys starting with "x-" are reserved for private use and can be
   utilized to provide information that is specific to vendor, user or
   enterprise.  It is RECOMMENDED to use one of the   | "https://ex |
   |      |                  | portal     | portal       | ample.com"  |
   | nat  | NAT              | IPv4 NAT   | boolean      | true        |
   |      |                  | in place   |              |             |
   | natt | NAT Time-out     | The value  | Integer      | 30          |
   | o    |                  | in seconds |              |             |
   |      |                  | 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 NAT |              |             |
   |      |                  | time-out   |              |             |
   | srh  | segmentRoutingHe | The IPv6   | Binary       | ...         |
   |      | ader             | Segment    | string       |             |
   |      |                  | Routing    |              |             |
   |      |                  | Header author
   of the extension to  |              |             |
   |      |                  | avoid collisions.

5.3.3.  Example

   Here are two examples based on the keys defined in this section.

   {
     "name": "Foo Wireless",
     "localizedName": "Foo-France Wifi",
     "expires": "2017-07-23T06:00:00Z",
     "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"],
     "characteristics": {
      "maxThroughput": { "down":200000, "up": 50000 },
      "minLatency": { "down": 0.1, "up": 1 }
     }
   }
   {
     "name": "Bar 4G",
     "localizedName": "Bar US 4G",
     "expires": "2017-07-23T06:00:00Z",
     "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
     "metered": true,
     "characteristics": {
       "maxThroughput": { "down":80000, "up": 20000 }
     }
   }

6.  Security Considerations

   Although some solutions such as IPSec or SEND [RFC3971] can be used    |              |             |
   |      |                  | between    |              |             |
   |      |                  |
   in order to secure the IPv6   |              |             |
   |      |                  | header and |              |             |
   |      |                  | any other  |              |             |
   |      |                  | headers    |              |             |
   |      |                  | when Neighbor Discovery Protocol, actual
   deployments largely rely on link layer or physical layer security
   mechanisms (e.g. 802.1x [IEEE8021X]).

   This specification does not improve the Neighbor Discovery Protocol
   security model, but extends the purely link-local configuration
   retrieval mechanisms with HTTP-over-TLS communications.

   During the exchange, the server authenticity is verified by the mean
   of a certificate, validated based on the FQDN found in the Router
   Advertisement (e.g. using |              |             |
   |      |                  | this PvD   |              |             |
   | srhD | segmentRoutingHe | The a list of pre-installed CA certificates, or
   DNSSec [RFC4035] with DNS    | Ascii string | srh.pvd-foo |
   | NS   | aderDnsFQDN      | FQDN which |              | .example.or |
   |      |                  | Based Authentication of Named Entities
   [RFC6698]).  This authentication creates a secure binding between the
   information provided by the trusted Router Advertisement, and the
   HTTP server.

   The IPv6 prefixes list included in the PvD Additional Information
   JSON object is used to |              | g           |
   |      |                  | validate that the prefixes included in the
   Router Advertisements are really part of the PvD.

   Note: The previous point does not protect against attacker performing
   NAT66.  It would if we mandate the source-address validation on the
   server side, but not protect against tunnels.  In other words,
   address based security will not protect against rogue APs, but may
   prevent the use of NAT66.

   For privacy reasons, it is desirable that the PvD Additional
   Information object may only be retrieved  |              |             |
   |      |                  | by the actual |              |             |
   |      |                  | IPv6       |              |             |
   |      |                  | Segment    |              |             |
   |      |                  | Routing    |              |             |
   |      |                  | Header to  |              |             |
   |      |                  | hosts using the given
   PvD.  Host identity SHOULD be validated based on the client address
   that is used    |              |             |
   |      |                  | between    |              |             |
   |      |                  | during the HTTP query.

7.  IANA Considerations

   IANA is kindly requested to allocate a new IPv6   |              |             |
   |      |                  | header Neighbor Discovery
   option number for the PvD ID Router Advertisement option and |              |             |
   |      |                  | any other  |              |             |
   |      |                  | headers    |              |             |
   |      |                  | when a new
   IKEv2 Configuration Payload Attribute Types for PVD_ID.

   TBD: JSON keys will need a new register.

8.  Acknowledgements

   Many thanks to M. Stenberg and S. Barth for their earlier work:
   [I-D.stenberg-mif-mpvd-dns].

   Thanks also to Ray Bellis, Lorenzo Colitti, Thierry Danis, Marcus
   Keane, Erik Kline, Jen Lenkova, Mark Townsley and James Woodyatt for
   useful and interesting discussions.

   Finally, many thanks to Thierry Danis for his implementation work:
   [github].

9.  References

9.1.  Normative references

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
              RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, DOI
              10.17487/RFC5785, April 2010,
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <http://www.rfc-editor.org/info/rfc7159>.

9.2.  Informative references

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC5798]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/
              RFC5798, March 2010,
              <http://www.rfc-editor.org/info/rfc5798>.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <http://www.rfc-editor.org/info/rfc6698>.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

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

   [RFC7710]  Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng,
              "Captive-Portal Identification Using DHCP or Router
              Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710,
              December 2015, <http://www.rfc-editor.org/info/rfc7710>.

   [RFC8028]  Baker, F. and B. Carpenter, "First-Hop Router Selection by
              Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/
              RFC8028, November 2016,
              <http://www.rfc-editor.org/info/rfc8028>.

   [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.

   [I-D.kline-mif-mpvd-api-reqs]
              Kline, E., "Multiple Provisioning Domains API
              Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in
              progress), November 2015.

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

   [IEEE8021X]
              IEEE, "IEEE Standards for Local and Metropolitan Area
              Networks: Port based Network Access Control, IEEE Std", .

   [github]   Cisco, "IPv6-mPvD github repository", <https://github.com/
              IPv6-mPvD>.

Appendix A.  Changelog

   Note to RFC Editors: Remove this PvD   |              |             |
   | cost | cost             | Cost section before publication.

A.1.  Version 00

   Initial version of    | object       | See Section |
   |      |                  | the draft.  Edited by Basile Bruneau + Eric Vyncke
   and based on Basile's work.

A.2.  Version 01

   Major rewrite intended to focus on the the retained solution based on
   corridors, online, and WG discussions.  Edited by Pierre Pfister.
   The following list only includes major changes.

      PvD ID is an FQDN retrieved using a single RA option.  This option
      contains a sequence number for push-based updates, a new H-flag,
      and a L-flag in order to link the  |              | 5.6         |
   |      |                  | connection |              |             |
   +------+------------------+------------+--------------+-------------+

5.6. PvD with the IPv4 DHCP server.

      A lifetime is included in the PvD ID option.

      Detailed Hosts and Routers specifications.

      Additional Information is retrieved using HTTP-over-TLS when the
      PvD ID Option H-flag is set.  Retrieving the object is optional.

      The PvD Additional Information object includes a validity date.

      DNS-based approach is removed as well as the DNS-based encoding of
      the PvD Additional Information.

      Major cut in the list of proposed JSON keys.  This document may be
      extended later if need be.

      Monetary discussion is moved to the appendix.

      Clarification about the 'prefixes' contained in the additional
      information.

      Clarification about the processing of DHCPv6.

Appendix B.  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 weekends.

   We propose

   An option is to split the final billing bill 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 make no assumption about the cost.

5.6.1.

B.1.  Conditions

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

   Note: the final version should use short-hand key names.

   +-----------+-------------+---------------+-------------------------+
   | Key       | Description | Type          | JSON 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.6.2.

B.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.

   +------------------+------------------+--------------+--------------+
   | Key              | Description      | Type         | JSON 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 100000       |
   |                  | achievable       |              |              |
   |                  | throughput       |              |              |
   | trafficRemaining | The traffic      | float (kb) (kB)   | 96000000 12000000     |
   |                  | remaining        |              |              |
   +------------------+------------------+--------------+--------------+

5.6.3.

B.3.  Examples

   Example for a user with 20 GB per month for 40 EUR, then reach a
   threshold, and with unlimited data during weekends and to deezer:
   example.com:

   [
     {
       "domains": ["deezer.com"] ["example.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 12000000
     },
     {
       "throughputMax": 1000 100000
     }
   ]

   If the host tries to download data from deezer.com, example.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
   foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of
   the first, second and third elementary billing are not fulfilled.

   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 3000000
     },
     {
       "pricePerGb": 30,
       "currency": "EUR"
     }
   ]

5.7.  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.8.  Examples

5.8.1.  Using JSON
   {
     "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.8.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

6.  Use case examples

   TBD: 1 or 2 examples when PvD are critical

6.1.  Multihoming

   First example could be multihoming (very much in-line with bowbakova
   draft).

6.2.  VPN/Extranet example

   using PvD to reach a specific destination (such as VPN or extranet).

7.  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 master prefixed of the extended PvD.

8.  Acknowledgements

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

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

9.  References

9.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>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <http://www.rfc-editor.org/info/rfc5952>.

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

9.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>.

Authors' Addresses

   Basile Bruneau
   Ecole polytechnique Polytechnique
   Vannes  56000
   France

   Email: basile.bruneau@polytechnique.edu

   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
   Eric Vyncke (editor)
   Cisco
   De Kleetlaan, 6
   Diegem  1831
   Belgium

   Email: evyncke@cisco.com