<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC5739 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5739.xml">
<!ENTITY RFC6419 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6419.xml">
<!ENTITY RFC6418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6418.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY RFC6731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6731.xml">
<!ENTITY RFC6182 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6182.xml">
<!ENTITY RFC7078 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7078.xml">


<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-mif-mpvd-arch-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic trust200902
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="MPVD architecture">Multiple Provisioning Domain Architecture</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author role="editor" fullname="Dmitry Anipko" initials="D."
            surname="Anipko">
      <organization>Microsoft Corporation</organization>

      <address>
        <postal> 
          <street>One Microsoft Way</street>

          <!-- Reorder these if your country does things differently -->

          <city>Redmond</city>

          <region>WA</region>

          <code>98052</code>

          <country>USA</country>
        </postal>

        <phone>+1 425 703 7070</phone>

        <email>dmitry.anipko@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date day="03" month="May" year="2014" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup>MIF Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document is a product of the work of MIF architecture design team.
 It outlines a solution framework for some of the issues, experienced by 
nodes that can be attached to multiple networks. The framework defines the notion 
of a Provisioning Domain (PVD) - a consistent 
set of network configuration information, and PVD-aware nodes - nodes which 
learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs
for connectivity separately and consistently.</t>
    </abstract>
  </front>

  <middle>
<section title="Introduction">

<t>Nodes attached to multiple networks may encounter problems due to conflict 
of the networks configuration  and/or simultaneous use of the multiple 
available networks. While existing implementations apply various techniques (<xref
      target="RFC6419"></xref>) to tackle such problems, 
in many cases the issues may still appear. The MIF problem statement document <xref
      target="RFC6418"></xref> 
describes the general landscape as well as discusses many specific issues and scenarios details.</t>

<t>Problems, enumerated in <xref
      target="RFC6418"></xref>, can be grouped into 3 categories:

<list style="numbers">
          <t>Lack of consistent and distinctive management of configuration elements, associated 
 with different networks.</t>
          <t>Inappropriate mixed use of configuration elements, associated with different networks, 
in the course of a particular network activity / connection.</t>
          <t>Use of a particular network, not consistent with the intent of the scenario / involved parties, 
leading to connectivity failure and / or other undesired consequences.</t>
        </list>
An example of (1) is a single node-scoped list of DNS server IP addresses, learned
from different networks, leading to failures or delays in resolution of names from particular namespaces;
an example of (2) is use of an attempt to resolve a name of a HTTP proxy server, learned from a network A, 
with a DNS server, learned from a network B, that is likely to fail; an example of (3) is use of an employer-sponsored
VPN connection for peer-to-peer connectivity, unrelated to employment activities.</t>

<t>This architecture describes a solution to these categories of problems, respectively, by:
<list style="numbers">
<t>Introducing a formal notion of the PVD, including PVD identity, and ways for nodes to learn the intended 
associations among acquired network configuration information elements.</t>
<t>Introducing a reference model for a PVD-aware node, preventing inadvertent mixed use of the configuration 
information, which may belong to different PVDs.</t>
<t>Providing recommendations on PVD selection based on PVD identity and connectivity tests for common scenarios.</t>
</list></t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
</section>

<section anchor="pvd_definitions" title="Definitions and types of PVDs">

<t>Provisioning Domain: a consistent set of network configuration information.  
Classically, the entire set available on a single interface is provided by a single source, 
such as network administrator, and can therefore be treated as a single provisioning domain. 
In modern IPv6 networks, multihoming can result in more than one provisioning domain
being present on a single link. In some scenarios, it is also possible for elements
of the same domain to be present on multiple links.</t>

<t>
Typical examples of information in a provisioning domain, learned from the network, 
are: source address prefixes that can be used by connections within the provisioning domain,
IP address of DNS server, name of HTTP proxy server if available, DNS suffixes associated with the network,
default gateway address etc.</t>

<t>PVD-aware node: a node that supports association of network configuration information into PVDs, 
and using these PVDs to serve requests for network connections in ways,
consistent with recommendations of this architecture.</t>

    <section title="Explicit PVDs">
<t>A node may receive explicit information from the network and/or other sources, about presence 
of PVDs and association of particular network information with a particular PVD. 
PVDs, constructed based on such information, are referred to in this document as "explicit".</t> 

<t>Protocol changes/extensions will likely be required to support the explicit PVDs by IETF-defined mechanisms. As an example, 
one could think of one or several DHCP options, carrying PVD identity and / or its elements. 
A different approach could be to introduce a DHCP option, which only carries identity of a PVD, 
while the association of network information elements with that identity, is implemented by the 
respective protocols - such as e.g., with a <xref
        target="RFC4861">Router Discovery</xref> option associating
an address range with a PVD.</t>

<t>Specific, existing or new, features of networking protocols to enable delivery of PVD identity 
and association with various network information elements will be defined in companion design documents.</t>

        
        <t>Link-specific and/or vendor-proprietary mechanisms for discovery of PVD information, different from the IETF-defined mechanisms,
            can be used by the nodes separately from or together with IETF-defined mechanisms,
            as long as they allow to discover necessary elements of the PVD(s). Another
            example of a delivery mechanism for PVDs are key exchange or tunneling
            protocols, such as  <xref target="RFC5996">IKEv2</xref> that allow transporting host
            configuration information. In all cases, by default nodes must
            ensure that the lifetime of all dynamically discovered PVD configuration is appropriately limited by
            the relevant events - for example, if an interface media state change was indicated,
            the previously discovered information may no longer be valid and needs to be re-discovered or confirmed.</t>

<t>It is expected, that how the host makes use of the PVD information, generally is independent of the specific
    particular mechanism/protocol that was used to receive the information.</t>

<t>It shall be possible for sources of PVD information to communicate that some of their configuration elements could be used within
a context of other networks/PVDs.
PVD-aware nodes, based on such declaration and their policies, may choose to inject such elements into some
or all other PVDs they connect to.</t>

        <t>In some network topologies, the network infrastructure elements may need to advertise multiple PVDs. The details of how
        this is done generally will be defined in the individual companion design documents. However, where different design choices
        are possible, the choice that requires smaller number of packets shall be preferred for efficiency.</t>

    </section>
    <section title="Implicit PVDs and incremental adoption of the explicit PVDs">

<t>It is likely that for a long time there may be networks which do not advertise explicit PVD information, 
since deployment of any new features in networking protocols is a relatively slow process.</t>
        
        
        <t>When connected to networks, which don't advertise explicit PVD information, PVD-aware node shall
            automatically create separate PVDs for received configuration.
            Such PVDs are referred to in this document as "implicit".</t>
   <t>
        With implicit PVDs, PVD-aware nodes may still provide benefits to their users as compared to non-PVD aware nodes, by
using network information from different interfaces separately and consistently to serve network 
connection requests, following best practices described in <xref target="Reference_Model"></xref>.</t>

<t>In the mixed mode, where e.g., multiple networks are available on the link the interface is attached to, 
and only some of the networks advertise PVD information, the PVD-aware node shall create explicit PVDs based 
on explicitly learned PVD information, and associate the rest of the configuration with an implicit 
PVD created for that interface.</t>

    </section>
    <section title="Relationship between PVDs and interfaces">
<t>By default, implicit PVDs are limited to network configuration information received on a single interface.
If additional information is available to the host through mechanisms out of scope of this document, the host
may form implicit PVDs with different granularity, such as e.g. spanning multiple interfaces (an example scenario,
where this may be useful, is a Homenet with a router that has multiple internal interfaces).</t>
<t>Explicit PVDs, in practice will often also be scoped to a configuration related to a particular interface,
however per this architecture there is no such requirement or limitation and as defined in this architecture, explicit 
PVDs may include information related to more than one interfaces, if the node learns presence of the same 
PVD on those interfaces and the authentication of the PVD ID meets the level required by the node policy
 (generally, authentication of a PVD ID may be also required in scenarios, involving only one connected interface and/or PVD).</t>
        
<t>It is an intent of this architecture to support such scenarios among others. Hence, it shall be noted that
    no hierarchical relationship exists between interfaces and PVDs: it is possible for multiple PVDs to be
simultaneously accessible over one interface, as well as single PVD to be simultaneously accessible over
multiple interfaces.</t>
    </section>

    <section title="PVD identity/naming">

<t>For explicit PVDs, PVD ID (globally unique ID, that possibly is human-readable) is received as part of that 
information. For implicit PVDs, the node assigns a locally generated with a high probability of being globally
    unique ID to each implicit PVD.</t>

<t>PVD-aware node may use these IDs to choose a PVD with matching ID for special-purpose connection requests, 
in accordance with node policy or choice by advanced applications, and/or to present human-readable representation of the IDs to the
end-user for selection of Internet-connected PVDs.</t>

<t>A single network provider may operate multiple networks, including networks at different locations. In such cases,
the provider may chose whether to advertise single or multiple PVD identities at all or some
of those networks, as it suits their business needs. This architecture doesn't impose specific requirements in this regard.</t>

<t>When multiple nodes are connected to the same link, where one or more explicit PVDs are available, this architecture assumes
that the information about all available PVDs is advertized by the networks to all the connected nodes.
At the same time, the connected nodes may have different heuristics, policies and/or other settings, including configured set of their trusted PVDs,
which may lead to different PVDs actually being used by different nodes for their connections.</t>

<t>Possible extensions, where different sets of PVDs may be advertised by the networks to different connected nodes,
are out of scope of this document.</t>
    </section>

    <section title="Relationship to dual-stack networks">

<t>When applied to dual-stack networks, the PVD definition allows for multiple PVDs to be created, 
where each PVD contain information for only one address family, or for a single PVD that contains 
information about multiple address families. This architecture requires that accompanying design documents 
for the PVD-related protocol changes must support PVDs containing information from multiple address families.
PVD-aware nodes must be capable of dealing with both single-family and multi-family PVDs.</t>

<t>For explicit PVDs, the choice of either of the approaches is a policy decision 
of a network administrator and/or node user/administrator. Since some of the IP configuration information 
that can be learned from the network can be applicable to multiple address families (for instance <xref
      target="RFC7078">DHCP address selection option</xref>),
it is likely that dual-stack networks will deploy single PVDs for both address families.</t>

<t>For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single 
implicit PVD created for an interface. At the time 
of writing of this document in dual-stack networks it appears to be a common practice  
for configuration of both address families to be provided by a single source.</t>
  
<t>A PVD-aware node that provides API to use / enumerate / inspect PVDs and/or their properties shall provide 
ability to filter PVDs and/or their properties by address family.</t>
    </section>

    <section title="Elements of PVD">
<t></t>
    </section>

</section>

<section title="Conveying PVD information using DHCPv6 and Router Advertisements">
    <t>DHCPv6 and Router Advertisements are the two most common methods
    of configuring hosts and they would need to be extended to convey
    explicit PVD information. There are several things that need to
    be considered before finalizing a mechanism to augment DHCPv6 and
    RAs with PvD information.</t>
    
    <section title="Separate messages or one message">
    <t>When information from several PVDs is available at the same
    configuration source, there are two possibilities regarding how
    to send these out. One way is to send information from different
    provisioning domains in separate messages. The other is to
    combine information from several PVDs onto one message. The
    latter method has the advantage of being more efficient but could
    have issues due to authentication and authorization issues as
    well as potential issues with accommodating common information
    and information not tagged with any PVD information.</t>
    </section>
    
    <section title="Securing the PVD information">
    <t>DHCPv6 and RAs both provide some form of authentication that
    ensures the identity of the source as well as the integrity of
    the contents that have been secured. While this is useful, the
    authenticity of the information provides no information whether
    the configuration source is actually allowed to provide
    information from a given PVD. In order to do be able to do this,
    there must be a mechanism for the owner of the PVD to attach some
    form of authorization token to the configuration information that
    is delivered.</t>
    </section>
        
    <section title="Backward compatibility">
    <t>The extensions to RAs and DHCPv6 should be defined in such a
    manner than unmodified hosts (i.e. hosts not aware of PvDs) will
    continue to function as well as they did before the PvD
    information got added. This could imply that some information may
    need to be duplicated in order to be conveyed to legacy
    hosts. Similarly PvD aware hosts need to be able to handle legacy
    configuration sources which do not provide PvD information. There
    are also several initiatives ongoing that are aimed at adding
    some form of additional information to prefixes [refs to
    draft-bhandari and draft-korhonen] and any new mechanism should
    try to consider co-existence with these existing mechanisms.</t>
    </section>
        
    <section title="Selective propagation">
    <t>When a configuration source has information regarding several
    PvDs it is not clear whether it should provide information about
    all of them to any host that requests info from it. While it may
    be reasonable in some cases, this might become an unreasonable
    burden once the number of PvDs starts increasing. One way to
    restrict the propagation of useless information is for the host
    to select the PvD information they desire in their request to the
    configuration source. One way this could be accomplished is by
    using an ORO with the PvDs that are of interest. The
    configuration source can then respond with only the requested
    information.</t>
    
    <t>By default, a configuration source SHOULD provide information related to
    all provisioning domains without expecting the client to request the
    PvD(s) it requires. This is necessary to ensure that hosts that do not
    support requesting selective PvD information will continue to work. Also
    note that IPv6 neighbor discovery does not provide any functionality
    analogous to the DHCPv6 ORO.</t>
    
    <t>In this case, when a host receives PvD information it does not require,
    the information can simply be discarded. Also, in constrained networks
    such as LLNs, the amount of configuration information needs to be
    restricted to ensure that the load on the hosts is bearable while
    keeping the information identical across all the hosts.</t>
    
    <t>In case selective propogation is required, some form of PvD
    discovery mechanism needs to be specified so that
    hosts/applications can be pre-provisioned to request a specific
    PvD. Alternately, the set of PvDs that the network can provide to
    the host can be propogated to the host using RAs or stateless
    DHCPv6. The discovery mechanism may potentially support the
    discovery of available PvDs on a per-host basis.</t>
    </section>

    <section title="Retracting/updating PvD information">
    
    <t>After the PvD information is provided to the host it may be
    outdated or updated with newer information before the hosts would
    normally request updates. Thos would require the mchanism to be
    able to update and/or withdraw all (or some subset) of
    information related to a given PvD. For efficiency reasons, there
    should be a way to specify that all the information from the PvD
    needs to be reconfigured instead of individually updating each
    item associated with the PvD.</t>
    </section>
    
    <section title="Conveying configuration information using IKEv2">
    <t>
    Internet Key Exchange protocol version 2 (IKEv2)
    <xref target="RFC5996"></xref> <xref target="RFC5739"></xref> is another widely used and a popular method of
    configuring IP information in a host. In the case of IKEv2 the
    provisioning domain could actually be implicitly learnt from the
    Identification - Responder (IDr) payloads the IKEv2 initiator and
    the responder inject during the IKEv2 exchange. The IP
    configuration may depend on the named IDr. Another possibility
    could be adding specific provisioning domain identifying payload
    extensions to IKEv2. All of the considerations listed above for
    DHCPv6 and RAs potentialy apply to IKEv2 as well.</t>
        
    </section>
    
</section>
      
<section title="Example network configurations and number of PVDs">

<t></t>
</section>

<section anchor="Reference_Model" title="Reference model of PVD-aware node">

    <section title="Constructions and maintenance of separate PVDs">
        <t>It is assumed that normally, configuration information contained in a single PVD, shall be sufficient for
            a node to fulfill a network connection request by an application, and hence there should be no
            need to attempt to merge information across different PVDs.</t>
        
        <t>Nevertheless, even when a PVD lack some parts of the configuration,
            merging of information from different PVD(s) shall not be done automatically, since typically it would lead
            to issues described in <xref target="RFC6418"></xref>.</t>
        
        <t>A node may use other sources, such as e.g., node local policy, user input or other
            mechanisms, not defined by IETF, to either construct a PVD entirely (analogously to static IP configuration
            of an interface), or supplement with particular elements all or some PVDs learned from the network, or potentially
            merge information from different PVDs, if such merge is known to the node to be safe, based on explicit policies.</t>
        
        <t>
            As an example, node administrator could inject a not ISP-specific DNS server into PVDs for any
            of the networks the node could become attached to. Such creation / augmentation of PVD(s) could be static or dynamic.
            The particular implementation mechanisms are outside of the scope of this document.</t>
        

    </section>

    <section anchor="Reference_Model_Consistent_Use" title="Consistent use of PVDs for network connections">

        <t>PVDs enable PVD-aware nodes to use consistently a correct set of configuration elements to serve 
the specific network requests from beginning to end. This section describes specific examples of such 
consistent use.</t>

        <section title="Name resolution">

<t>When PVD-aware node needs to resolve a name of the destination used by a connection request, 
the node could decide to use one, or multiple PVDs for a given name lookup.</t>

<t> The node shall chose one PVD, if e.g., the node policy required to use a particular PVD for a 
particular purpose (e.g. to download an MMS using a specific APN over a cellular connection). 
To make the choice, the node could use a match of 
the PVD DNS suffix or other form of PVD ID, as determined by the node policy.</t>

<t>The node may pick multiple PVDs, if e.g., they are general purpose PVDs providing connectivity to
 the Internet, and the node desires to maximize chances for connectivity in Happy Eyeballs style. 
In this case, the node could do the lookups in parallel, or in sequence. Alternatively, the node 
may use for the lookup only one PVD, based on the PVD connectivity properties, 
user choice of the preferred Internet PVD, etc.</t>

<t>In either case, by default the node uses information obtained in
   a name service lookup to establish connections only within the
   same PVD from which the lookup results were obtained.</t>

<t>For simplicity, when we say that name service lookup results were
   obtained from a PVD, what we mean is that the name service query
   was issued against a name service the configuration of which is
   present in a particular PVD.   In that sense, the results are
   "from" that particular PVD.</t>

<t>Some nodes may support transports and/or APIs, which provide an abstraction of a single connection, aggregating multiple
underlying connections. <xref
        target="RFC6182">MPTCP</xref> is an example of such transport protocol.
For the connections provided by such transports/APIs, a PVD-aware node may use different PVDs for servicing of that logical connection,
provided that all operations on the underlying connections are done consistently within their corresponding
PVD(s).</t>
        </section>
        <section title="Next-hop and source address selection">

<t>For the purpose of this discussion, let's assume the preceding name lookup succeeded in a particular PVD.  
For each obtained destination address, the node shall perform a next-hop lookup among routers, 
associated with that PVD. As an example, such association could be determined by the node via matching 
the source address prefixes/specific routes advertized by the router against known PVDs, 
or receiving explicit PVD affiliation advertized through a new <xref
        target="RFC4861">Router Discovery</xref> option.</t>

<t>For each destination, once the best next-hop is found, the node selects best source address according 
to the <xref target="RFC6724"></xref> rules, but with a constraint that the source address 
must belong to a range associated 
with the used PVD. If needed, the node would use the prefix policy from the same PVD for the best source
 address selection among multiple candidates.</t>

<t>When destination/source pairs are identified, then they are sorted using the 
<xref target="RFC6724"></xref> 
destination sorting rules and the prefix policy table from the used PVD.</t>

        </section>
        <section title="Listening applications">
            <t>Consider a host, connected to several PVDs and running an application that opens a listening socket/transport
                API object, where the application authorized by the host policy to use a subset connected PVDs,
                that may or may not be equal to the complete set of the connected PVDs.
                For example, in case there are different PVDs on a Wi-Fi and a cellular interfaces, for general internet traffic
                the host could decide to use only one preferred PVD at a time (and accordingly, advertise to remote peers
                the host name and addresses associated with that PVD), or it could decide to use one PVD as a preferred one
                by default for outgoing connections, while still allowing use of the other PVDs simultaneously.
                Another example is where a host established a VPN connection. Depending on the security policies provisioned on the host,
                all or some applications may or may not be allowed to use the VPN PVD and/or other PVDs.</t>

            <t>For non-PVD aware applications, the OS policies determine the authorized set of PVDs and the preferred outgoing PVD.
            For PVD-aware applications, both the authorized set of PVDs and the default outgoing PVD can be determined as a meet
            of the subset produced by the OS policies and the set of PVD IDs or characteristics, provided by the application.
            The application input could be provided on per-application, per-transport-API-object or per-transport-API-call basis.
            The API for application input may have an option for to specify whether the input should be treated as a preference
            instead of a requirement.</t>

            <section title="Processing of incoming traffic">
                <t>Unicast IP packets are received on a specific IP address, associated with a PVD.
                    For multicast packets, the host can derive the association with a PVD from other configuration information,
                    such as an explicit PVD property or local policy. (Note - do we need to be more specific? If yes, what would be be
                    a good method?).
                </t>
                <t>Similarly to strong-host and weak-host models, the host may apply cross-PVD filtering, where subject to host policies
                    a packet may be permitted to be received packets in a PVD different from the PVD packet came from. Such filtering may
                    be straightforward to implement in the case where the PVDs are associated with different interface.
                    For multiple PVDs on a single interface, the host may apply the reverse path next hop consistency check within
                    the identified PVD for the packet source IP address and link-layer addresses. (Note - is there a better way?)
                </t>
                <t>If the determined receiving PVD of the packet is not in the allowed subset of PVDs for the particular
                    app/transport API object, the packet should be handled in the same way as if there were no listener
                    (alternatives - error message 'administratively prohibited', or just refer to pre-PVD behavior for legacy behavior for
                    interface-scoped binds).
                    </t>
                <section title="Connection-oriented APIs">
                    <t>For connection-oriented APIs, when the initial incoming packet is received, the packet PVD is remembered for
                        the established connection, and used for handling of the outgoing traffic for that connection.
                        While typically the connection-oriented APIs use connection-oriented transport protocol, such as TCP,
                        it is possible to have a connection-oriented API, which uses generally connection-less transport protocol, such as UDP.
                        For APIs/protocols, which support multiple IP traffic flows associated with a single transport API connection object
                        (such as e.g. multi path TCP), the processing rules may be adjusted accordingly.</t>
                </section>
                <section title="Connection-less APIs">
                    <t>For connection-less APIs, the host should provide an API, which PVD-aware applications could use to query
                        the PVD associated with the packet. For outgoing traffic on this transport API object, the OS should use
                        the selected outgoing PVDs, determined as described above.</t>
                </section>
            </section>
        </section>
        <section title="Enforcement of security policies">
            <t>PVDs by themselves don't define and can't be used for communication of security policies.
            When implemented in a network, this architecture provides the host with information about the connected networks.
            The actual behavior of the host then depends on the host policies (provisioned through mechanisms out of scope
            of this document), applied taking received PVD information into account. In some scenarios, such as e.g . VPN,
            such policies could require the host to use only a particular VPN PVD for some/all of the applications' traffic
                (VPN 'disable split tunneling' also known as 'force tunneling' behavior), or apply such restrictions only
                to select applications and allow simultaneous use of the VPN PVD togetheer with the other connected
            PVDs by the other or all applications (VPN 'split tunneling' behavior).</t>
        </section>
    </section>
    <section title="Connectivity tests">
    <t>Although some PVDs may appear as valid candidates for PVD selection
        (e.g. good link quality, consistent connection parameters, etc.), they may provide limited or no connectivity
        to the desired network or the Internet. For example, some PVDs provide limited
        IP connectivity (e.g., scoped to the link or to the access network), but require
        the node to authenticate through a web portal to get full access to the Internet.
        This may be more likely to happen for PVDs, which are not trusted by the given PVD-aware node.</t>
        
        <t>
        An attempt to use such PVD may lead to limited network connectivity or connection failures for applications.
        To prevent the latter, a PVD-aware node may perform connectivity test for the PVD, before using it
        to serve network connection requests of the applications.
        In current implementations, some nodes do that, for instance, by trying to reach a dedicated web server
        (e.g., see <xref target="RFC6419"></xref>). </t>
       
        <t>Per <xref target="Reference_Model_Consistent_Use"></xref>, a PVD-aware node shall maintain and use
            multiple PVDs separately. The PVD-aware node shall perform connectivity test and, only after validation of the PVD,
            consider using it to serve application connections requests.
            Ongoing connectivity tests are also required, since during the IP session, the end-to-end connectivity could be disrupted for various reasons
            (e.g. poor L2, IP QoS issues); hence a connectivity monitoring function is needed to check the connectivity status
            and remove the PVD from the set of usable PVDs if necessary.</t>
        
        <t>There may be cases where a connectivity test for PVD selection may be not appropriate and
            should be complemented, or replaced, by PVD selection based on other factors. This could be
            realized e.g., by leveraging some 3GPP and IEEE mechanisms,
            which would allow to expose some PVD characteristics to the node
            (e.g. <xref target="TS23.402">3GPP Access Network Discovery and Selection Function (ANDSF)</xref>, <xref target="IEEE802.11u">IEEE 802.11u</xref>/ANQP). </t>
    
    </section>

    <section title="Relationship to interface management and connection managers">
    <t>
        Current devices such as mobile handsets make use of proprietary mechanisms and custom applications to manage connectivity
        in environments with multiple interfaces and multiple sets of network configurations.
        These mechanisms or applications are commonly known as connection managers <xref target="RFC6419"></xref>.
    </t>
    <t>
        Connection managers sometimes rely on policy servers to allow the node, connected to multiple networks, perform the network selection.
        They can also make use of routing guidance from the network (e.g. <xref target="TS23.402">3GPP ANDSF</xref>).
        Although connection managers solve some connectivity problems, they rarely address the network selection problems in a comprehensive manner.
        With proprietary solutions, it is challenging to present a coherent behaviour to the end user of the device,
        as different platforms present different behaviours even when connected to the same network, with the same type of interface,
        and for the same purpose.
    </t>
    </section>
</section>

<section title="PVD support in APIs">
<t> In all cases changes in available PVDs must be somehow exposed, appropriately for each of the approaches.</t>

    <section title="Basic">
<t>Applications are not PVD-aware in any manner, and only submit
   connection requests.  The node performs PVD selection implicitly,
   without any otherwise applications participation, and based purely on
   node-specific administrative policies and/or choices made by the user
   in a user interface provided by the operating environment, not by the application.</t>
<t>As an example, such PVD selection can be done at the name service lookup step, by using
the relevant configuration elements, such as e.g., those described in <xref
        target="RFC6731"></xref>.
As another example, the PVD selection could be done based on application identity or type (i.e., a 
node could always use a particular PVD for a VOIP application).</t>
    </section>

    <section title="Intermediate">
<t>Applications indirectly participate in selection of PVD by specifying hard requirements and 
soft preferences. As an example, a real time communication application, intending to use the connection
for exchange of real time audio/video data, may indicate a preference or a requirement for connection quality,
which could affect PVD selection (different PVDs could correspond to Internet connections
with different loss rates and latencies). Another example is a connection of an infrequently executed background
activity, which checks for availability of applications updates and performs large downloads - for such connections,
a cheaper or zero cost PVD may be preferrable, even if such connection will have a higher relative loss rate or lower bandwidth.
The node performs PVD selection, based on applications inputs and policies and/or
user preferences. Some / all properties of the resultant PVD may be exposed to applications.</t>
    </section>

    <section title="Advanced">
<t>PVDs are directly exposed to applications, for enumeration and selection. Node polices and/or user choices, 
may still override the application preferences and limit which PVD(s) can be enumerated and/or used by the application, 
irrespectively of any preferences which application may have specified. Depending on the implementation, such restrictions,
imposed per node policy and/or user choice, may or may not be visible to the application.</t>
    </section>
</section>

<section title="PVD-aware nodes trust to PVDs">

    <section title="Untrusted PVDs">

<t>Implicit and explicit PVDs for which no trust relationship exists
   are considered untrusted.   Only PVDs, which meet the requirements in
   <xref target="Trusted_PVDs"></xref>, are trusted; any other PVD is untrusted.</t>

<t>
   In order to avoid various forms of misinformation that can be asserted
   when PVDs are untrusted, nodes that implement PVD separation cannot assume
   that two explicit PVDs with the same identifier are actually the same PVD.
   A node that did make this assumption would be vulnerable to attacks where
   for example an open Wifi hotspot might assert that it was part of another PVD, 
   and thereby might draw traffic intended for that PVD onto its own
   network.</t>

<t>Since implicit PVD identifiers are synthesized by the node, this issue
   cannot arise with implicit PVDs.</t>

<t>
   Mechanisms exist (for example, <xref
        target="RFC6731"></xref>) whereby a PVD can
   provide configuration information that asserts special knowledge about
   the reachability of resources through that PVD.   Such assertions
   cannot be validated unless the node has a trust relationship with
   the PVD; assertions of this type therefore must be ignored by
   nodes that receive them from untrusted PVDs.   Failure to ignore
   such assertions could result in traffic being diverted from legitimate
   destinations to spoofed destinations.</t>

    </section>
    <section anchor="Trusted_PVDs" title="Trusted PVDs">
<t>
Trusted PVDs are PVDs for which two conditions apply.   First, a trust
   relationship must exist between the node that is using the PVD configuration
   and the source that provided that configuration; this is the authorization
   portion of the trust relationship.   Second, there must
   be some way to validate the trust relationship.   This is the authentication
   portion of the trust relationship.   Two mechanisms for
   validating the trust relationship are defined.
</t>
<t>
It shall be possible to validate the trust relationship for all
advertised elements of a trusted PVD, irrespectively of whether the
PVD elements are communicated as a whole, e.g. in a single DHCP option, or
separately, e.g. in supplementary RA options. Whether or not this is
feasible to provide mechanisms to implement trust relationship for all PVD elements, 
will be determined in the respective companion design documents.
</t>
        <section anchor="Authenticated_PVDs" title="Authenticated PVDs">
<t>One way to validate the trust relationship between a node and the
   source of a PVD is through the combination of cryptographic
   authentication and an identifier configured on the node.   In some
   cases, the two could be the same; for example, if authentication is
   done with a shared secret, the secret would have to be associated
   with the PVD identifier.   Without a (PVD Identifier, shared key)
   tuple, authentication would be impossible, and hence authentication
   and authorization are combined.</t>

<t>However, if authentication is done using
   some public key mechanism such as a TLS cert or DANE, authentication
   by itself isn't enough, since theoretically any PVD could be
   authenticated in this way.   In addition to authentication, the node
   would need to be configured to trust the identifier being authenticated.
   Validating the authenticated PVD name against a list of PVD names
   configured as trusted on the node would constitute the authorization
   step in this case.</t>

        </section>
        <section title="PVDs trusted by attachment">
<t>In some cases a trust relationship may be validated by some means
   other than described in <xref target="Authenticated_PVDs"></xref>, simply by virtue of the connection
   through which the PVD was obtained.   For instance, a handset connected
   to a mobile network may know through the mobile network infrastructure
   that it is connected to a trusted PVD, and whatever mechanism was used
   to validate that connection constitutes the authentication portion of
   the PVD trust relationship.   Presumably such a handset would be configured
   from the factory, or else through mobile operator or user preference settings, to trust
   the PVD, and this would constitute the authorization portion of this
   type of trust relationship.</t>
        </section>
    </section>

</section>

<!--
    <section title="Subsections and Tables">
      <section title="A Subsection">
        <t>By default 3 levels of nesting show in table of contents but that
        can be adjusted with the value of the "tocdepth" processing
        instruction.</t>
      </section>

      <section title="Tables">
        <t>.. are very similar to figures:</t>

        <texttable anchor="table_example" title="A Very Simple Table">
          <preamble>Tables use ttcol to define column headers and widths.
          Every cell then has a "c" element for its content.</preamble>

          <ttcol align="center">ttcol #1</ttcol>

          <ttcol align="center">ttcol #2</ttcol>

          <c>c #1</c>

          <c>c #2</c>

          <c>c #3</c>

          <c>c #4</c>

          <c>c #5</c>

          <c>c #6</c>

          <postamble>which is a very simple example.</postamble>
        </texttable>
      </section>
    </section>
-->
<!--
    <section anchor="nested_lists" title="More about Lists">
      <t>Lists with 'hanging labels': the list item is indented the amount of
      the hangIndent: <list hangIndent="8" style="hanging">
          <t hangText="short">With a label shorter than the hangIndent.</t>

          <t hangText="fantastically long label">With a label longer than the
          hangIndent.</t>

          <t hangText="vspace_trick"><vspace blankLines="0" />Forces the new
          item to start on a new line.</t>
        </list></t>

   
      <?rfc needLines="12" ?>

      <t>Simulating more than one paragraph in a list item using
      &lt;vspace&gt;: <list style="letters">
          <t>First, a short item.</t>

          <t>Second, a longer list item.<vspace blankLines="1" /> And
          something that looks like a separate pararaph..</t>
        </list></t>

      <t>Simple indented paragraph using the "empty" style: <list
          hangIndent="10" style="empty">
          <t>The quick, brown fox jumped over the lazy dog and lived to fool
          many another hunter in the great wood in the west.</t>
        </list></t>

      <section title="Numbering Lists across Lists and Sections">
        <t>Numbering items continuously although they are in separate
        &lt;list&gt; elements, maybe in separate sections using the "format"
        style and a "counter" variable.</t>

        <t>First list: <list counter="reqs" hangIndent="4" style="format R%d">
            <t>#1</t>

            <t>#2</t>

            <t>#3</t>
          </list> Specify the indent explicitly so that all the items line up
        nicely.</t>

        <t>Second list: <list counter="reqs" hangIndent="4" style="format R%d">
            <t>#4</t>

            <t>#5</t>

            <t>#6</t>
          </list></t>
      </section>
      <section title="Where the List Numbering Continues">
        <t>List continues here.</t>

        <t>Third list: <list counter="reqs" hangIndent="4" style="format R%d">
            <t>#7</t>

            <t>#8</t>

            <t>#9</t>

            <t>#10</t>
          </list> The end of the list.</t>
      </section>
    </section>
-->
    <section anchor="Acknowledgements" title="Acknowledgements">
        <t>
        This document was created as a product of a MIF architecture design team.
        </t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
        <t>There are at least three different form of attacks that can be performed using
            configuration sources that use multiple provisioning domains.
        
        <list style="hanging">
            <t hangText="Tampering with configuration information provided">
                An attacker may attempt to modify the information provided inside the
                PVD container option.  These attacks can easily be prevented by using
                the message integrity features provided by the underlying protocol used
                to carry the configuration information. e.g.  <xref target="RFC3971">SEND</xref> would detect
                any form of tampering with the RA contents and the 
                <xref target="RFC3315">DHCPv6</xref> AUTH option that would detect any form of tampering with the DHCPv6
                message contents. This attack can also be performed by a compromised
                configuration source by modifying information inside a specific , in
                which case the mitigations proposed in the next subsection may be helpful.</t>
            
            <t hangText="Rogue configuration source">
                A compromised configuration source such as a router or a DHCPv6 server
                may advertise information about PvDs that it is not authorized to
                advertise. e.g. A coffee shop may advertise configuration information
                purporting to be from an enterprise and may try to attract enterprise
                related traffic. The only real way to avoid this is that the PvD related
                configuration container contains embedded authentication and
                authorization information from the owner of the PvD. Then, this attack
                can be detected by the client by verifying the authentication and
                authorization information provided inside the PVD container option after
                verifying its trust towards the PvD owner (e.g. a certificate with a
                well-known/common trust anchor).</t>
            
            <t hangText="Replay attacks">
                A compromised configuration source or an on-link attacker may try to
                capture advertised configuration information and replay it on a
                different link or at a future point in time. This can be avoided by
                including some replay protection mechanism such as a timestamp or a
                nonce inside the PvD container to ensure freshness of the provided
                information.</t>
        </list>
        </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    &RFC2119;
<!--
      <reference anchor="min_ref">

        <front>
          <title>Minimal Reference</title>

          <author initials="authInitials" surname="authSurName">
            <organization></organization>
          </author>

          <date year="2006" />
        </front>
      </reference>-->
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC6419;
      
      &RFC6418;

      &RFC4861;

      &RFC5996;

      &RFC5739;
        


      &RFC6724;

      &RFC6731;

      &RFC6182;
        
      &RFC3315;
        
      &RFC3971; 

      &RFC7078;

      <reference anchor="IEEE802.11u">
        <front>
          <title>IEEE Standard 802.11u-2011 (Amendment 9: Interworking with External Networks)</title>

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

          <date year="2011" />
        </front>
      </reference>
      <reference anchor="TS23.402">
          <front>
              <title>3GPP TS 23.402; Architecture enhancements for non-3GPP accesses; release 12</title>
              
              <author>
                  <organization>3GPP</organization>
              </author>
              
              <date year="" />
          </front>
      </reference>
    </references>
    
<!--
    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
-->
    <!-- Change Log

v00 2013-07-13  EBD   Initial version

  -->
  </back>
</rfc>
