<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc autobreaks="yes"?>
<?rfc compact="yes"?>
<?rfc strict='yes'?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-ietf-intarea-provisioning-domains-00"
     ipr="trust200902">
  <front>
    <title abbrev="Provisioning Domains">Discovering Provisioning Domain Names
    and Data</title>

    <author fullname="Pierre Pfister" initials="P" surname="Pfister">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>11 Rue Camille Desmoulins</street>

          <city>Issy-les-Moulineaux</city>

          <code>92130</code>

          <country>France</country>
        </postal>

        <email>ppfister@cisco.com</email>
      </address>
    </author>

    <author fullname="Eric Vyncke" initials="E" role="editor" surname="Vyncke">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>De Kleetlaan, 6</street>

          <city>Diegem</city>

          <code>1831</code>

          <country>Belgium</country>
        </postal>

        <email>evyncke@cisco.com</email>
      </address>
    </author>

    <author fullname="Tommy Pauly" initials="T" surname="Pauly">
      <organization>Apple</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>tpauly@apple.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="David Schinazi" initials="D" surname="Schinazi">
      <organization>Apple</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>dschinazi@apple.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Marcus Keane" initials="M" surname="Keane">
      <organization>Microsoft</organization>

      <address>
        <postal>
          <street>Sandyford Industrial Estate</street>

          <city>Dublin 18</city>

          <region/>

          <code/>

          <country>Ireland</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>Marcus.Keane@microsoft.com</email>

        <uri/>
      </address>
    </author>

    <date day="30" month="October" year="2017"/>

    <area>Internet</area>

    <workgroup>intarea</workgroup>

    <keyword>PVD</keyword>

    <keyword>provisioning domain</keyword>

    <keyword>host configuration</keyword>

    <abstract>
      <t>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 means of multiple IPv6 prefix
      configurations.</t>

      <t>This document describes a way for hosts to retrieve additional
      information about their network access characteristics. The set of
      configuration items required to access the Internet is called a
      Provisioning Domain (PvD). The PvD is identified by a Fully Qualified
      Domain Name (FQDN). This identifier, retrieved using a new Router
      Advertisement (RA) option, is associated with the set of information
      included within the RA and may later be used to retrieve additional
      information associated with the PvD by way of an HTTP-over-TLS
      request.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>It has become very common in modern networks for hosts to access the
      network through different network interfaces, tunnels, or next-hop
      routers. To describe the set of network configurations associated with
      %% each access method, the concept of Provisioning Domain (PvD) was
      defined in <xref target="RFC7556"/>.</t>

      <t>This specification provides a way to identify explicit PvDs with
      Fully Qualified Domain Names (FQDN). The FQDN is thus called PvD ID in
      this document. The PvD IDs is included in a Router Advertisement <xref
      target="RFC4861"/> option. This new option, when present, associates the
      set of configurations with the PvD ID in the same RA message. 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 all PvDs with the same PvD ID, on different interfaces, ultimately
      provide identical services.</t>

      <t>This document also introduces a way for hosts to retrieve additional
      information related to a specific PvD by the mean of an HTTP-over-TLS
      query using an URI derived from the PvD ID. The retrieved JSON object
      contains additional network information that would typically be
      considered unfit, or too large, to be directly included in the Router
      Advertisements. This information can be used by the networking stack,
      the applications, or even be partially displayed to the users (e.g., by
      displaying a localized network service name).</t>
    </section>

    <section title="Terminology">
      <t>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 <xref
      target="RFC2119"/>.</t>

      <t>In addition, this document uses the following terminology: <list
          style="hanging">
          <t hangText="PvD: ">A Provisioning Domain, a set of network
          configuration information; for more information, see <xref
          target="RFC7556"/>.</t>

          <t hangText="PvD ID: ">A Fully Qualified Domain Name (FQDN) used to
          identify a PvD.</t>

          <t hangText="Explicit PvD: ">A PvD uniquely identified with a PvD
          ID. for more information, see <xref target="RFC7556"/>.</t>

          <t hangText="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.</t>
        </list></t>
    </section>

    <section anchor="ra"
             title="Provisioning Domain Identification using Router Advertisements">
      <t>Each provisioning domain is identified by a PvD ID. The PvD ID is a
      Fully Qualified Domain Name (FQDN) which MUST belong to the network
      operator in order to avoid ambiguity. The same PvD ID MAY be used in
      several access networks when the set of configuration information is
      identical (e.g. in all home networks subscribed to the same
      service).</t>

      <section title="PvD ID Option for Router Advertisements">
        <t>This document introduces a Router Advertisement (RA) option called
        the PvD ID Router Advertisement Option, used to convey the FQDN
        identifying a given PvD.</t>

        <figure title="PvD ID Router Advertisements Option format">
          <preamble/>

          <artwork><![CDATA[
 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     |H|L|         Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Sequence            |                             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             ...
...                         PvD ID FQDN                       ...
...             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |                  Padding                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>

          <postamble/>
        </figure>

        <t><list style="hanging">
            <t hangText="Type        : ">(8 bits) To be defined by IANA.
            Current experimentation uses the value of 253.</t>

            <t hangText="Length      : ">(8 bits) The length of the option
            (including the Type and Length fields) in units of 8 octets.</t>

            <t hangText="H-flag      : ">(1 bit) Whether some PvD Additional
            Information is made available through HTTP over TLS, as described
            in <xref target="data"/>.</t>

            <t hangText="L-flag      : ">(1 bit) Whether the router is also
            providing IPv4 information using DHCPv4 (see <xref
            target="dhcpv4"/>).</t>

            <t hangText="Reserved    : ">(14 bits) Reserved for later use. It
            MUST be set to zero by the sender and ignored by the receiver.</t>

            <t hangText="Sequence    : ">(16 bits) Sequence number for the PvD
            Additional Information, as described in <xref target="data"/>.</t>

            <t hangText="PvD ID FQDN : ">The FQDN used as PvD ID encoded as
            described in Section 3.1 of <xref target="RFC1035">RFC1035</xref>.
            Note that for simple decoding, the domain names MUST NOT be
            encoded in the compressed form described in Section 4.1.4 of <xref
            target="RFC1035">RFC1035</xref>. This encoding is the same as the
            one used in <xref target="RFC8106">RFC8106</xref>. The encoding
            MUST end with a null (zero-length) label.</t>

            <t hangText="Padding     : ">Zero or more padding octets such as
            to set the option length (Type and Length fields included) to
            eight times the value of the Length field. It MUST be set to zero
            by the sender and ignored by the receiver.</t>
          </list></t>

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

        <!--t>Note: The existence and/or size of the sequence number is subject
        to discussion. The validity of a PvD Additional Information object is
        included in the object itself, but this only allows for 'pull based'
        updates, whereas the RA options usually provide 'push based'
        updates.</t-->

        <!--t>Note to be removed before publication. Previously, the PvD ID FQDN
        was described as "An ASCII string representation of the FQDN used as
        PvD ID. The string ends at the first byte set to zero, or the end of
        the option, whichever comes first.".</t-->
      </section>

      <section title="Router Behavior">
        <t>A router MAY insert only one PvD ID Option in an RA. The included
        PvD ID is associated with all the other options included in the same
        RA (for example, and not limited to: Prefix Information <xref
        target="RFC4861"/>, Recursive DNS Server <xref target="RFC8106"/>,
        Routing Information <xref target="RFC4191"/> options).</t>

        <t>In order to provide multiple independent PvDs, a router MUST send
        multiple RAs using different source link-local addresses (LLA) (as
        proposed in <xref
        target="I-D.bowbakova-rtgwg-enterprise-pa-multihoming"/>), each of
        which MAY include a PvD ID option. In such cases, routers MAY
        originate the different RAs using the same datalink layer address.</t>

        <t>If the router is actually a VRRP instance <xref target="RFC5798"/>,
        then the procedure is identical except that the virtual datalink layer
        address is used as well as the virtual IPv6 LLA.</t>
      </section>

      <section anchor="host" title="Host Behavior">
        <t>RAs provide configuration information for IPv6 hosts. When a host
        receives an RA message including a PvD ID Option, it MUST associate
        all the configuration objects which are updated by the received RA
        (the same types as in <xref target="host"/>) with the PvD identified
        by the PvD ID Option, even if some objects are already associated with
        a different explicit or implicit PvD. PvD ID are compared in a
        case-insensitive manner (i.e., A=a), assuming ASCII with zero parity.
        Non-alphabetic codes must match exactly (see also Section 3.1 of <xref
        target="RFC1035"/>).</t>

        <t>If the received RA does not include a PvD ID Option, the host MUST
        associate the configuration objects which are updated by the received
        RA with an implicit PvD, even if some objects were already associated
        with a different explicit or implicit PvD. This implicit PvD MUST be
        identified by the LLA of the router sending the RA and the interface
        on which the RA was received.</t>

        <t>This document does not 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.</t>

        <!--t>Note: There is a discussion whether there can be multiple implicit
        PvDs on a single interface (i.e. whether the router link-local address
        should be used to identify the implicit PvDs).</t-->

        <t>While resolving names, executing the default address selection
        algorithm <xref target="RFC6724"/> or executing the default router
        selection algorithm (<xref target="RFC2461"/>, <xref
        target="RFC4191"/> and <xref target="RFC8028"/>), hosts MAY consider
        only the configuration associated with an arbitrary set of PvDs.</t>

        <t>For example, a host MAY associate a 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 able to select, on
        a per-connection basis, which PvDs should be used for a given
        connection. In particular, 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.</t>

        <t>The way an application expresses its desire to use a given PvD, or
        a set of PvDs, or the way this selection is enforced, is out of the
        scope of this document. Useful insights about these considerations can
        be found in <xref target="I-D.kline-mif-mpvd-api-reqs"/>.</t>

        <section title="DHCPv6 configuration association">
          <t>When a host retrieves configuration elements using DHCPv6, they
          MUST be associated with the explicit or implicit PvD of the RA
          received on the same interface, sent from the same LLA, and with the
          O-flag set <xref target="RFC4861"/>. If no such PvD is found, or
          whenever multiple different PvDs are found, the host behavior is
          unspecified.</t>

          <t>This process requires hosts to keep track of received RAs,
          associated PvD IDs, and routers LLA; it also assumes that the router
          either acts as a DHCPv6 server or relay and uses the same LLA for
          DHCPv6 and RA traffic (which may not be the case when the router
          uses VRRP to send its RA).</t>
        </section>

        <section anchor="dhcpv4" title="DHCPv4 configuration association">
          <t>When a host retrieves configuration elements from DHCPv4, they
          MUST be associated with the explicit PvD received on the same
          interface, whose PVD ID Options L-flag is set and, in the case of a
          non point-to-point link, using the same datalink address. If no such
          PvD is found, or whenever multiple different PvDs are found, the
          configuration elements coming from DHCPv4 MUST be associated with an
          IPv4-only implicit PvD identified by the interface on which the
          DHCPv4 transaction happened. The case of multiple explicit PvD for
          an IPv4 interface is undefined.</t>

          <!--t>Note: some reviewers suggested to remove the link with the legacy
          IPv4.</t-->
        </section>

        <section title="Interconnection Sharing by the Host">
          <t>The situation when a node receives RA on one interface (e.g.
          cellular) and shares this connectivity by also acting as a router by
          transmitting RA on another interface (e.g. WiFi) is known as
          'tethering'. It can be done as ND proxy. The exact behavior is TBD
          but it is expected that the one or several PvD associated to the
          shared interface (e.g. cellular) will also be advertised to the
          clients on the other interface (e.g. WiFi).</t>
        </section>
      </section>
    </section>

    <section anchor="data" title="Provisioning Domain Additional Information">
      <t>Once a new PvD ID is discovered, it may be used to retrieve
      additional information about the characteristics of the provided
      connectivity. This set of information is called PvD Additional
      Information, and is encoded as a JSON object <xref
      target="RFC7159"/>.</t>

      <t>The purpose of this additional set of information is to securely
      provide additional information to hosts about the connectivity that is
      provided using a given interface and source address pair. It typically
      includes data that would be considered too large, or not critical
      enough, to be provided within an RA option. The information contained in
      this object MAY be used by the operating system, network libraries,
      applications, or users, in order to decide which set of PvDs should be
      used for which connection, as described in <xref target="host"/>.</t>

      <section anchor="retr" title="Retrieving the PvD Additional Information">
        <t>When the H-flag of the PvD ID Option is set, hosts MAY attempt to
        retrieve the PvD Additional Information associated with a given PvD by
        performing an HTTP over TLS <xref target="RFC2818"/> GET query to
        https://&lt;PvD-ID&gt;/.well-known/pvd <xref target="RFC5785"/>.
        Inversely, hosts MUST NOT do so whenever the H-flag is not set.</t>

        <!--t>Note: Should the PvD AI retrieval be a MAY or a SHOULD ? Could the
        object contain critical data, or should it only contain informational
        data ?</t-->

        <t>Note that the DNS name resolution of &lt;PvD-ID&gt; as well as the
        actual query MUST be performed using the PvD associated with the PvD
        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 configuration information attached with the
        PvD, as defined in <xref target="host"/>. In some cases, it may
        therefore be necessary to wait for an address to be available for use
        (e.g., once the Duplicate Address Detection or DHCPv6 processes are
        complete) before initiating the HTTP over TLS query. If the PvD allows
        for temporary address per <xref target="RFC4941"/>, then host SHOULD
        use a temporary address to fetch the PvD Additional Information and
        SHOULD deprecate the used temporary address and generate a new
        temporary address.</t>

        <t>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 and 399,
        inclusive, it MUST follow the redirection(s). If the HTTP status of
        the answer is between 200 and 299, inclusive, the host MAY get a file
        containing a single JSON object. When a JSON object could not be
        retrieved, an error message SHOULD be logged and/or displayed in a
        rate-limited fashion.</t>

        <t>After retrieval of the PvD Additional Information, hosts MUST watch
        the PvD ID Sequence field for change. In case a different value than
        the one in the RA Sequence field is observed, or whenever the validity
        time included in the PVD Additional Information JSON object is
        expired, hosts MUST either perform a new query and retrieve a new
        version of the object, or, failing that, deprecate the object and stop
        using it.</t>

        <t>Hosts retrieving a new PvD Additional Information object MUST check
        for the presence and validity of the mandatory fields <xref
        target="aiformat"/>. A retrieved object including an outdated
        expiration time or missing a mandatory element MUST be ignored. In
        order to avoid traffic spikes toward the server hosting the PvD
        Additional Information when an object expires, a host which last
        retrieved an object at a time A, including a validity time B, SHOULD
        renew the object at a uniformly random time in the interval
        [(B-A)/2,A].</t>

        <t>The PvD Additional Information object includes a set of IPv6
        prefixes (under the key "prefixes") which MUST be checked against all
        the Prefix Information Options advertised in the RA. If any of the
        prefixes included in the PIO is not covered by at least one of the
        listed prefixes, the PvD associated with the tested prefix MUST be
        considered unsafe and MUST NOT be used. While this does not prevent a
        malicious network provider, it does complicate some attack scenarios,
        and may help detecting misconfiguration.</t>

        <t>The server providing the JSON files SHOULD also check whether the
        client address is part of the prefixes listed into the additional
        information and SHOULD return a 403 response code if there is no
        match. The server MAY also use the client address to select the right
        JSON object to be returned.</t>
      </section>

      <section title="Providing the PvD Additional Information">
        <t>Whenever the H-flag is set in the PvD RA Option, a valid PvD
        Additional Information object MUST be made available to all hosts
        receiving the RA by the network operator. In particular, when a
        captive portal is present, hosts MUST still be allowed to access the
        object, even before logging into the captive portal.</t>

        <t>Routers MAY increment the PVD ID Sequence number in order to inform
        host that a new PvD Additional Information object is available and
        should be retrieved.</t>
      </section>

      <section anchor="aiformat" title="PvD Additional Information Format">
        <t>The PvD Additional Information is a JSON object.</t>

        <t>The following array presents the mandatory keys which MUST be
        included in the object:</t>

        <texttable>
          <ttcol>JSON key</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Type</ttcol>

          <ttcol width="20%">Example</ttcol>

          <c>name</c>

          <c>Human-readable service name</c>

          <c>UTF-8 string <xref target="RFC3629"/></c>

          <c>"Awesome Wifi"</c>

          <c>expires</c>

          <c>Date after which this object is not valid</c>

          <c><xref target="RFC3339"/></c>

          <c>"2017-07-23T06:00:00Z"</c>

          <c>prefixes</c>

          <c>Array of IPv6 prefixes valid for this PVD</c>

          <c>Array of strings</c>

          <c>["2001:db8:1::/48", "2001:db8:4::/48"]</c>
        </texttable>

        <t>A retrieved object which does not include a valid string associated
        with the "name" key at the root of the object, or a valid date
        associated with the "expires" key, also at the root of the object,
        MUST be ignored. In such cases, an error message SHOULD be logged
        and/or displayed in a rate-limited fashion. If the PIO of the received
        RA is not included in the "prefixes" key, the retrieved object SHOULD
        be ignored.</t>

        <t>The following table presents some optional keys which MAY be
        included in the object.</t>

        <texttable>
          <ttcol>JSON key</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Type</ttcol>

          <ttcol width="20%">Example</ttcol>

          <c>localizedName</c>

          <c>Localized user-visible service name, language can be selected
          based on the HTTP Accept-Language header in the request.</c>

          <c>UTF-8 string</c>

          <c>"Wifi G&eacute;nial"</c>

          <c>dnsZones</c>

          <c>DNS zones searchable and accessible</c>

          <c>array of DNS zones</c>

          <c>["example.com","sub.example.org"]</c>

          <c>noInternet</c>

          <c>No Internet, set when the PvD only provides restricted access to
          a set of services</c>

          <c>boolean</c>

          <c>true</c>

          <c>characteristics</c>

          <c>Connectivity characteristics</c>

          <c>JSON object</c>

          <c>See <xref target="c"/></c>

          <c>metered</c>

          <c>metered, when the access volume is limited</c>

          <c>boolean</c>

          <c>false</c>
        </texttable>

        <t>It is worth noting that the JSON format allows for extensions.
        Whenever an unknown key is encountered, it MUST be ignored along with
        its associated elements.</t>

        <section anchor="c" title="Connectivity Characteristics Information">
          <t>The following set of keys can be used to signal certain
          characteristics of the connection towards the PvD.</t>

          <t>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.</t>

          <texttable>
            <ttcol>JSON key</ttcol>

            <ttcol>Description</ttcol>

            <ttcol>Type</ttcol>

            <ttcol width="20%">Example</ttcol>

            <c>maxThroughput</c>

            <c>Maximum achievable throughput</c>

            <c>object({down(int), up(int)}) in kbit/s</c>

            <c>{"down": 10000, "up": 5000}</c>

            <c>minLatency</c>

            <c>Minimum achievable latency</c>

            <c>object({down(int), up(int)}) in msec</c>

            <c>{"down": 10, "up": 20}</c>

            <c>rl</c>

            <c>Maximum achievable reliability</c>

            <c>object({down(int), up(int)}) in losses every 1000 packets</c>

            <c>{"down": 0.1, "up": 1}</c>
          </texttable>
        </section>

        <section anchor="keys-private" title="Private Extensions">
          <t>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 patterns
          "x-FQDN-KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain
          name or PEN is a <xref target="PEN">private enterprise number</xref>
          under control of the author of the extension to avoid
          collisions.</t>
        </section>

        <section anchor="ex" title="Example">
          <t>Here are two examples based on the keys defined in this
          section.</t>

          <figure>
            <artwork><![CDATA[
{
  "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 }
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[
{
  "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 }
  }
}
]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="misconfig"
               title="Detecting misconfiguration and misuse">
        <t>Although some solutions such as IPsec or SEND <xref
        target="RFC3971"/> can be used in order to secure the IPv6 Neighbor
        Discovery Protocol, actual deployments largely rely on link layer or
        physical layer security mechanisms (e.g. 802.1x <xref
        target="IEEE8021X"/>) in conjunction with RA Guard <xref
        target="RFC6105"/>.</t>

        <t>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 and some checks
        to detect misconfiguration and some misuses.</t>

        <t>When a host retrieves the PvD Additional Information, it MUST
        verify that the HTTPS server certificate is valid and that the Subject
        Name is equal to the PvD ID expressed as an FQDN. This authentication
        creates a secure binding between the information provided by the
        trusted Router Advertisement, and the HTTPS server. But this does not
        mean the Advertising Router and the PvD server belong to the same
        entity.</t>

        <t>When the "prefixes" key is included in the PvD Additional
        Information, then host MUST verify that all prefixes in the RA PIO are
        covered by a prefixes from the PvD Additional Informaion. An
        adversarial router willing to fake the use of a given explicit PvD,
        without any access to the actual PvD Additional Information, would
        need to perform NAT66 in order to circumvent this check.</t>

        <t>It is also RECOMMENDED that the HTTPS server checks the source
        addresses of incoming connections (see <xref target="retr"/>). This
        checks give reasonable assurance that NAT66 was not used and also
        restrict the information to the valid network users.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>It must be noted that the <xref target="misconfig"/> of this document
      only provides reasonable assurance against misconfiguration but does not
      prevent an hostile network access provider to wrong information that
      could lead applications or hosts to select an hostile PvD. Users should
      always apply caution when connecting to an unknown network.</t>
    </section>

    <section title="Privacy Considerations">
      <t>When a host retrieves via HTTPS the additional information, all nodes
      on the path (including the HTTPS server) can detect that the node is
      active.</t>

      <t>As it can be expected that the HTTPS server is located in the same
      management domain as the client (usually, it will be within an
      enterprise network, WiFi hotspot, or Service Provider network), the
      network operator as usually other means to also detect the new active
      node (DHCP, Neighbor Discovery Protocol cache inspection or DNS request
      logging). In this case, privacy is not worsened by using PvD.</t>

      <t>It must also be noted that most operating systems implement a system
      to detect the presence of a captive portal and also connect to a
      well-known web site over the Internet, for example to
      http://captive.example.com/hotspot-detect.html. This detection mechanism
      is exposing the activity of the detecting node not only within the
      management domain but also to all nodes outside this domain on the path
      to the captive.example.com server. As PvD can also be used to detect
      captive portal, then the PvD actually preserves privacy.</t>

      <t>Finally, the fetching of additional information is an option and
      could be disabled by the host.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is asked to assign the value TBD from the IPv6 Neighbor
      Discovery Option Formats registry for the PvD ID Router Advertisement
      option.</t>

      <t>IANA is asked to assign the value "pvd" from the Well-Known URIs
      registry.</t>

      <t>IANA is asked to create and maintain a new registry entitled
      "Additional Information PvD Keys" containing ASCII strings. The initial
      content of this registry are given below; future assignements are to be
      made through Expert Review [BCP36].</t>
    </section>

    <section title="Acknowledgements">
      <t>Many thanks to M. Stenberg and S. Barth for their earlier work: <xref
      target="I-D.stenberg-mif-mpvd-dns"/>.</t>

      <t>Thanks also to Mikael Abrahamson, Ray Bellis, Lorenzo Colitti,
      Thierry Danis, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Lemon, Jen
      Lenkova, Mark Townsley, James Woodyatt for useful and interesting
      discussions.</t>

      <t>Finally, many thanks to Thierry Danis for his implementation work
      (<xref target="github"/>), Tom Jones for his integration effort into the
      Neat project and Rigil Salim for his implementation work.</t>
    </section>

    <section title="Contributor">
      <t>Basile Bruneau was a co-author of this document while he was studying
      at the Polytechnique Paris.</t>
    </section>
  </middle>

  <back>
    <references title="Normative references">
      <?rfc include="reference.RFC.1035.xml"?>

      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.2461.xml"?>

      <?rfc include="reference.RFC.2818.xml"?>

      <?rfc include="reference.RFC.3629.xml"?>

      <?rfc include="reference.RFC.4861.xml"?>

      <?rfc include="reference.RFC.7159.xml"?>

      <?rfc include="reference.RFC.8126.xml"?>

      <?rfc include="reference.I-D.bowbakova-rtgwg-enterprise-pa-multihoming.xml"?>
    </references>

    <references title="Informative references">
      <?rfc include="reference.RFC.3339.xml"?>

      <?rfc include="reference.RFC.3971.xml"?>

      <?rfc include="reference.RFC.4191.xml"?>

      <?rfc include="reference.RFC.4941.xml"?>

      <?rfc include="reference.RFC.5785.xml"?>

      <?rfc include="reference.RFC.5798.xml"?>

      <?rfc include="reference.RFC.6105.xml"?>

      <?rfc include="reference.RFC.6724.xml"?>

      <?rfc include="reference.RFC.7556.xml"?>

      <?rfc include="reference.RFC.8028.xml"?>

      <?rfc include="reference.RFC.8106.xml"?>

      <?rfc include="reference.I-D.stenberg-mif-mpvd-dns"?>

      <?rfc include="reference.I-D.kline-mif-mpvd-api-reqs"?>

      <reference anchor="PEN"
                 target="https://www.iana.org/assignments/enterprise-numbers">
        <front>
          <title>Private Enterprise Numbers</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IEEE8021X">
        <front>
          <title>IEEE Standards for Local and Metropolitan Area Networks: Port
          based Network Access Control, IEEE Std</title>

          <author>
            <organization>IEEE</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="github" target="https://github.com/IPv6-mPvD">
        <front>
          <title>IPv6-mPvD github repository</title>

          <author>
            <organization>Cisco</organization>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <section title="Changelog">
      <t>Note to RFC Editors: Remove this section before publication.</t>

      <section title="Version 00">
        <t>Initial version of the draft. Edited by Basile Bruneau + Eric
        Vyncke and based on Basile's work.</t>
      </section>

      <section title="Version 01">
        <t>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. <list>
            <t>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 PvD with the IPv4 DHCP
            server.</t>

            <t>A lifetime is included in the PvD ID option.</t>

            <t>Detailed Hosts and Routers specifications.</t>

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

            <t>The PvD Additional Information object includes a validity
            date.</t>

            <t>DNS-based approach is removed as well as the DNS-based encoding
            of the PvD Additional Information.</t>

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

            <t>Monetary discussion is moved to the appendix.</t>

            <t>Clarification about the 'prefixes' contained in the additional
            information.</t>

            <t>Clarification about the processing of DHCPv6.</t>
          </list></t>
      </section>

      <section title="Version 02">
        <t><list>
            <t>The FQDN is now encoded with ASCII format (instead of DNS
            binary) in the RA option.</t>

            <t>The PvD ID option lifetime is removed from the object.</t>

            <t>Use well known URI "https://&lt;PvD-ID&gt;/.well-known/pvd"</t>

            <t>Reference RFC3339 for JSON timestamp format.</t>

            <t>The PvD ID Sequence field has been extended to 16 bits.</t>

            <t>Modified host behavior for DHCPv4 and DHCPv6.</t>

            <t>Removed IKEv2 section.</t>

            <t>Removed mention of RFC7710 Captive Portal option. A new I.D.
            will be proposed to address the captive portal use case.</t>
          </list></t>
      </section>

      <section title="WG Document version 00">
        <t><list>
            <t>Document has been accepted as INTAREA working group
            document</t>

            <t>IANA considerations follow <xref
            target="RFC8126">RFC8126</xref></t>

            <t>PvD ID FQDN is encoded as per <xref target="RFC1035">RFC
            1035</xref></t>

            <t>PvD ID FQDN is prepended by a one-byte length field</t>

            <t>Marcus Keane added as co-author</t>

            <t>dnsZones key is added back</t>

            <t>draft of a privacy consideration section and added that a
            temporary address should be used to retrieve the PvD additional
            information</t>

            <t>per Bob Hinden's request: the document is now aiming at
            standard track and security considerations have been moved to the
            main section</t>
          </list></t>
      </section>
    </section>

    <section anchor="keys-cost" title="Connection monetary cost">
      <t>NOTE: This section is included as a request for comment on the
      potential use and syntax.</t>

      <t>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.</t>

      <t>An option is to split the 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.</t>

      <section anchor="billing-conditions" title="Conditions">
        <t>Here are the potential conditions for an elementary billing. All
        conditions MUST be fulfill.</t>

        <texttable>
          <ttcol>Key</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Type</ttcol>

          <ttcol width="20%">JSON Example</ttcol>

          <c>beginDate</c>

          <c>Date before which the billing is not valid</c>

          <c>ISO 8601</c>

          <c>"1977-04-22T06:00:00Z"</c>

          <c>endDate</c>

          <c>Date after which the billing is not valid</c>

          <c>ISO 8601</c>

          <c>"1977-04-22T06:00:00Z"</c>

          <c>domains</c>

          <c>FQDNs whose the billing is limited</c>

          <c>array(string)</c>

          <c>["deezer.com","spotify.com"]</c>

          <c>prefixes4</c>

          <c>IPv4 prefixes whose the billing is limited</c>

          <c>array(string)</c>

          <c>["78.40.123.182/32","78.40.123.183/32"]</c>

          <c>prefixes6</c>

          <c>IPv6 prefixes whose the billing is limited</c>

          <c>array(string)</c>

          <c>["2a00:1450:4007:80e::200e/64"]</c>
        </texttable>
      </section>

      <section anchor="billing-price" title="Price">
        <t>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.</t>

        <texttable>
          <ttcol>Key</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Type</ttcol>

          <ttcol width="20%">JSON Example</ttcol>

          <c>pricePerGb</c>

          <c>The price per Gigabit</c>

          <c>float (currency per Gb)</c>

          <c>2</c>

          <c>currency</c>

          <c>The currency used</c>

          <c>ISO 4217</c>

          <c>"EUR"</c>

          <c>throughputMax</c>

          <c>The maximum achievable throughput</c>

          <c>float (kb/s)</c>

          <c>100000</c>

          <c>trafficRemaining</c>

          <c>The traffic remaining</c>

          <c>float (kB)</c>

          <c>12000000</c>
        </texttable>
      </section>

      <section anchor="billing-examples" title="Examples">
        <t>Example for a user with 20 GB per month for 40 EUR, then reach a
        threshold, and with unlimited data during weekends and to
        example.com:</t>

        <figure>
          <artwork><![CDATA[
[
  {
    "domains": ["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": 12000000
  },
  {
    "throughputMax": 100000
  }
]
            ]]></artwork>
        </figure>

        <t>If the host tries to download data from 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 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.</t>

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

        <figure>
          <artwork><![CDATA[
[
  {
    "beginDate": "2016-02-10T00:00:00Z",
    "endDate": "2017-02-09T23:59:59Z",
    "trafficRemaining": 3000000
  },
  {
    "pricePerGb": 30,
    "currency": "EUR"
  }
]
            ]]></artwork>
        </figure>
      </section>
    </section>
  </back>
</rfc>
