summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7556.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7556.txt')
-rw-r--r--doc/rfc/rfc7556.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc7556.txt b/doc/rfc/rfc7556.txt
new file mode 100644
index 0000000..16286c5
--- /dev/null
+++ b/doc/rfc/rfc7556.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Anipko, Ed.
+Request for Comments: 7556 Unaffiliated
+Category: Informational June 2015
+ISSN: 2070-1721
+
+
+ Multiple Provisioning Domain Architecture
+
+Abstract
+
+ This document is a product of the work of the Multiple Interfaces
+ Architecture Design team. It outlines a solution framework for some
+ of the issues experienced by nodes that can be attached to multiple
+ networks simultaneously. The framework defines the concept of a
+ Provisioning Domain (PvD), which is a consistent set of network
+ configuration information. PvD-aware nodes learn PvD-specific
+ information from the networks they are attached to and/or other
+ sources. PvDs are used to enable separation and configuration
+ consistency in the presence of multiple concurrent connections.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7556.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anipko Informational [Page 1]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anipko Informational [Page 2]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 5
+ 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 6
+ 2.3. Relationship between PvDs and Interfaces . . . . . . . . 7
+ 2.4. PvD Identity/Naming . . . . . . . . . . . . . . . . . . . 8
+ 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 8
+ 3. Conveying PvD Information . . . . . . . . . . . . . . . . . . 9
+ 3.1. Separate Messages or One Message? . . . . . . . . . . . . 9
+ 3.2. Securing PvD Information . . . . . . . . . . . . . . . . 10
+ 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
+ 3.4. Retracting/Updating PvD Information . . . . . . . . . . . 10
+ 3.5. Conveying Configuration Information Using IKEv2 . . . . . 10
+ 4. Example Network Configurations . . . . . . . . . . . . . . . 11
+ 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . 12
+ 4.3. A Home Network and a Network Operator with Multiple PvDs 12
+ 5. Reference Model for the PvD-Aware Node . . . . . . . . . . . 13
+ 5.1. Constructions and Maintenance of Separate PvDs . . . . . 13
+ 5.2. Consistent Use of PvDs for Network Connections . . . . . 14
+ 5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 14
+ 5.2.2. Next-Hop and Source Address Selection . . . . . . . . 15
+ 5.2.3. Listening Applications . . . . . . . . . . . . . . . 16
+ 5.2.3.1. Processing of Incoming Traffic . . . . . . . . . 16
+ 5.2.4. Enforcement of Security Policies . . . . . . . . . . 17
+ 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . 18
+ 5.4. Relationship to Interface Management and Connection
+ Managers . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6. PvD Support in APIs . . . . . . . . . . . . . . . . . . . . . 19
+ 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . 20
+ 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . 20
+ 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . 21
+ 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . 21
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
+ 9. Informative References . . . . . . . . . . . . . . . . . . . 23
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+
+Anipko Informational [Page 3]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+1. Introduction
+
+ Nodes attached to multiple networks may encounter problems from
+ conflicting configuration between the networks or attempts to
+ simultaneously use more than one network. While various techniques
+ are currently used to tackle these problems [RFC6419], in many cases
+ issues may still appear. The Multiple Interfaces Problem Statement
+ document [RFC6418] describes the general landscape and discusses many
+ of the specific issues and scenario details.
+
+ Problems, enumerated in [RFC6418], can be grouped into 3 categories:
+
+ 1. Lack of consistent and distinctive management of configuration
+ elements associated with different networks.
+
+ 2. Inappropriate mixed use of configuration elements associated with
+ different networks during a particular network activity or
+ connection.
+
+ 3. Use of a particular network that is not consistent with the
+ intended use of the network, or the intent of the communicating
+ parties, leading to connectivity failure and/or other undesired
+ consequences.
+
+ 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 an attempt to resolve the name of an HTTP proxy server
+ learned from network A using a DNS server learned from network B; and
+ an example of (3) is the use of an employer-provided VPN connection
+ for peer-to-peer connectivity unrelated to employment activities.
+
+ This architecture provides solutions to these categories of problems,
+ respectively, by:
+
+ 1. Introducing the formal notion of PvDs, including identity for
+ PvDs, and describing mechanisms for nodes to learn the intended
+ associations between acquired network configuration information
+ elements.
+
+ 2. Introducing a reference model for PvD-aware nodes that prevents
+ the inadvertent mixed use of configuration information that may
+ belong to different PvDs.
+
+ 3. Providing recommendations on PvD selection based on PvD identity
+ and connectivity tests for common scenarios.
+
+
+
+
+
+Anipko Informational [Page 4]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+2. Definitions and Types of PvDs
+
+ Provisioning Domain:
+ A consistent set of network configuration information.
+ Classically, all of the configuration information available on a
+ single interface is provided by a single source (such as a 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 PvD to be present on multiple links.
+
+ Typical examples of information in a provisioning domain learned
+ from the network are:
+
+ * Source address prefixes for use by connections within the
+ provisioning domain
+
+ * IP address(es) of the DNS server(s)
+
+ * Name of the HTTP proxy server (if available)
+
+ * DNS suffixes associated with the network
+
+ * Default gateway address
+
+ PvD-aware node:
+ A node that supports the association of network configuration
+ information into PvDs and the use of these PvDs to serve requests
+ for network connections in ways consistent with the
+ recommendations of this architecture.
+
+ PvD-aware application:
+ An application that contains code and/or application-specific
+ configuration information explicitly aware of the notion of PvD
+ and/or specific types of PvD elements or properties.
+
+2.1. Explicit PvDs
+
+ A node may receive explicit information from the network and/or other
+ sources conveying the presence of PvDs and the association of
+ particular network information with a particular PvD. PvDs that are
+ constructed based on such information are referred to as "explicit"
+ in this document.
+
+
+
+
+
+
+
+Anipko Informational [Page 5]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ Protocol changes or extensions will likely be required to support
+ explicit PvDs through IETF-defined mechanisms. As an example, one
+ could think of one or more DHCP options carrying PvD identity and/or
+ its elements.
+
+ A different approach could be the introduction of a DHCP option that
+ only carries the identity of a PvD. Here, the associations between
+ network information elements with the identity is implemented by the
+ respective protocols, for example, with a Router Discovery [RFC4861]
+ option associating an address range with a PvD. Additional
+ discussion can be found in Section 3.
+
+ Other examples of a delivery mechanism for PvDs are key exchange or
+ tunneling protocols, such as the Internet Key Exchange Protocol
+ version 2 (IKEv2) [RFC7296] that allows the transport of host
+ configuration information.
+
+ Specific, existing, or new features of networking protocols that
+ enable the delivery of PvD identity and association with various
+ network information elements will be defined in companion design
+ documents.
+
+ Link-specific and/or vendor-proprietary mechanisms for the discovery
+ of PvD information (differing from IETF-defined mechanisms) can be
+ used by nodes either separate from or in conjunction with IETF-
+ defined mechanisms, providing they allow the discovery of the
+ necessary elements of the PvD(s).
+
+ In all cases, nodes must by default ensure that the lifetime of all
+ dynamically discovered PvD configuration is appropriately limited by
+ relevant events. For example, if an interface media state change is
+ indicated, previously discovered information relevant to that
+ interface may no longer be valid and thus needs to be confirmed or
+ re-discovered.
+
+ It is expected that the way a node makes use of PvD information is
+ generally independent of the specific mechanism/protocol that the
+ information was received by.
+
+ In some network topologies, network infrastructure elements may need
+ to advertise multiple PvDs. Generally, the details of how this is
+ performed will be defined in companion design documents.
+
+2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs
+
+ For the foreseeable future, there will be networks that do not
+ advertise explicit PvD information, because deployment of new
+ features in networking protocols is a relatively slow process.
+
+
+
+Anipko Informational [Page 6]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ When connected to networks that don't advertise explicit PvD
+ information, a PvD-aware node shall automatically create separate
+ PvDs for received configuration. Such PvDs are referred to in this
+ document as "implicit".
+
+ Through the use of implicit PvDs, PvD-aware nodes may still provide
+ benefits to their users (when compared to non-PvD-aware nodes) by
+ following the best practices described in Section 5.
+
+ PvD-aware nodes shall treat network information from different
+ interfaces, which is not identified as belonging explicitly to some
+ PvD, as belonging to separate PvDs, one per interface.
+
+ Implicit PvDs can also occur in a mixed mode, i.e., where of multiple
+ networks that are available on an attached link, only some advertise
+ PvD information. In this case, the PvD-aware node shall create
+ explicit PvDs from information explicitly labeled as belonging to
+ PvDs. It shall associate configuration information not labeled with
+ an explicit PvD with an implicit PvD(s) created for that interface.
+
+2.3. Relationship between PvDs and Interfaces
+
+ By default, implicit PvDs are limited to the network configuration
+ information received on a single interface, and by default, one such
+ PvD is formed for each 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. For example, PvDs spanning multiple interfaces such as
+ a home network with a router that has multiple internal interfaces or
+ multiple PvDs on a single interface such as a network that has
+ multiple uplink connections.
+
+ In the simplest case, explicit PvDs will be scoped for configuration
+ related only to a specific interface. However, there is no
+ requirement in this architecture for such a limitation. Explicit
+ PvDs may include information related to more than one interface if
+ the node learns the presence of the same PvD on those interfaces and
+ the authentication of the PvD ID meets the level required by the node
+ policy (authentication of a PvD ID may be also required in scenarios
+ involving only one connected interface and/or PvD; for additional
+ discussion of PvD Trust, see Section 7).
+
+ This architecture supports such scenarios. Hence, no hierarchical
+ relationship exists between interfaces and PvDs: it is possible for
+ multiple PvDs to be simultaneously accessible over one interface, as
+ well as a single PvD to be simultaneously accessible over multiple
+ interfaces.
+
+
+
+
+Anipko Informational [Page 7]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+2.4. PvD Identity/Naming
+
+ For explicit PvDs, the PvD ID is a value that is or has a high
+ probability of being globally unique and is received as part of PvD
+ information. It shall be possible to generate a human-readable form
+ of the PvD ID to present to the end user, either based on the PvD ID
+ itself or using metadata associated with the ID. For implicit PvDs,
+ the node assigns a locally generated ID with a high probability of
+ being globally unique to each implicit PvD.
+
+ We say that a PvD ID should be, or should have a high probability of
+ being, globally unique. The purpose of this is to make it unlikely
+ that any individual node will ever accidentally see the same PvD name
+ twice if it is not actually referring to the same PvD. Protection
+ against deliberate attacks involving name clashes requires that the
+ name be authenticated (see Section 7.2.1).
+
+ A PvD-aware node may use these IDs to select a PvD with a matching ID
+ for special-purpose connection requests in accordance with node
+ policy, as chosen by advanced applications, or to present a human-
+ readable representation of the IDs to the end user for selection of
+ PvDs.
+
+ 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 does not impose any specific requirements in this
+ regard.
+
+ When multiple nodes are connected to the same link with one or more
+ explicit PvDs available, this architecture assumes that the
+ information about all available PvDs is made available by the
+ networks to all the connected nodes. At the same time, connected
+ nodes may have different heuristics, policies, and/or other settings,
+ including their configured sets of trusted PvDs. This may lead to
+ different PvDs actually being used by different nodes for their
+ connections.
+
+ Possible extensions whereby networks advertise different sets of PvDs
+ to different connected nodes are out of scope of this document.
+
+2.5. The Relationship to Dual-Stack Networks
+
+ When applied to dual-stack networks, the PvD definition allows for
+ multiple PvDs to be created whereby each PvD contains information
+ relevant to only one address family, or for a single PvD containing
+ information for multiple address families. This architecture
+
+
+
+Anipko Informational [Page 8]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ requires that accompanying design documents describing PvD-related
+ protocol changes must support PvDs containing information from
+ multiple address families. PvD-aware nodes must be capable of
+ creating and using both single-family and multi-family PvDs.
+
+ For explicit PvDs, the choice of either of these approaches is a
+ policy decision for the network administrator and/or the 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, DHCPv6 Address Selection Policy Option
+ [RFC7078]), it is likely that dual-stack networks will deploy single
+ PvDs for both address families.
+
+ By default for implicit PvDs, PvD-aware nodes shall include multiple
+ IP families into a single implicit PvD created for an interface. At
+ the time of writing, in dual-stack networks it appears to be common
+ practice for the configuration of both address families to be
+ provided by a single source.
+
+ A PvD-aware node that provides an API to use, enumerate, and inspect
+ PvDs and/or their properties shall provide the ability to filter PvDs
+ and/or their properties by address family.
+
+3. Conveying PvD Information
+
+ DHCPv6 and Router Advertisements (RAs) are the two most common
+ methods of configuring hosts. To support the architecture described
+ in this document, these protocols would need to be extended to convey
+ explicit PvD information. The following sections describe topics
+ that must be considered before finalizing a mechanism to augment
+ DHCPv6 and RAs with PvD information.
+
+3.1. Separate Messages or One Message?
+
+ When information related to several PvDs is available from the same
+ configuration source, there are two possible ways of distributing
+ this information: One way is to send information from each different
+ provisioning domain in separate messages. The second method is
+ combining the information from multiple PvDs into a single message.
+ The latter method has the advantage of being more efficient but could
+ have problems with authentication and authorization, as well as
+ potential issues with accommodating information not tagged with any
+ PvD information.
+
+
+
+
+
+
+
+
+Anipko Informational [Page 9]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+3.2. Securing PvD Information
+
+ DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of
+ authentication to ensure the identity of the source as well as the
+ integrity of the secured message content. While this is useful,
+ determining authenticity does not tell a node whether the
+ configuration source is actually allowed to provide information from
+ a given PvD. To resolve this, there must be a mechanism for the PvD
+ owner to attach some form of authorization token or signature to the
+ configuration information that is delivered.
+
+3.3. Backward Compatibility
+
+ The extensions to RAs and DHCPv6 should be defined in such a manner
+ that unmodified hosts (i.e., hosts not aware of PvDs) will continue
+ to function as well as they did prior to PvD information being 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 correctly utilize legacy configuration sources
+ that do not provide PvD information. There are also several
+ initiatives that are aimed at adding some form of additional
+ information to prefixes [DHCPv6-CLASS-BASED-PREFIX]
+ [IPv6-PREFIX-PROPERTIES], and any new mechanism should try to
+ consider coexistence with such deployed mechanisms.
+
+3.4. Retracting/Updating PvD Information
+
+ After PvD information is provisioned to a host, it may become
+ outdated or superseded by updated information before the hosts would
+ normally request updates. To resolve this requires that the
+ mechanism be able to update and/or withdraw all (or some subset) of
+ the information related to a given PvD. For efficiency reasons,
+ there should be a way to specify that all information from the PvD
+ needs to be reconfigured instead of individually updating each item
+ associated with the PvD.
+
+3.5. Conveying Configuration Information Using IKEv2
+
+ IKEv2 [RFC7296] [RFC5739] is another widely used method of
+ configuring host IP information. For IKEv2, the provisioning domain
+ could be implicitly learned from the Identification - Responder (IDr)
+ payloads that the IKEv2 initiator and responder inject during their
+ IKEv2 exchange. The IP configuration may depend on the named IDr.
+ Another possibility could be adding a specific provisioning domain
+ identifying payload extensions to IKEv2. All of the considerations
+ for DHCPv6 and the RAs listed above potentially apply to IKEv2 as
+ well.
+
+
+
+
+Anipko Informational [Page 10]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+4. Example Network Configurations
+
+4.1. A Mobile Node
+
+ Consider a mobile node with two network interfaces: one to the mobile
+ network, the other to the Wi-Fi network. When the mobile node is
+ only connected to the mobile network, it will typically have one PvD,
+ implicit or explicit. When the mobile node discovers and connects to
+ a Wi-Fi network, it will have zero or more (typically one) additional
+ PvD(s).
+
+ Some existing OS implementations only allow one active network
+ connection. In this case, only the PvD(s) associated with the active
+ interface can be used at any given time.
+
+ As an example, the mobile network can explicitly deliver PvD
+ information through the Packet Data Protocol (PDP) context activation
+ process. Then, the PvD-aware mobile node will treat the mobile
+ network as an explicit PvD. Conversely, the legacy Wi-Fi network may
+ not explicitly communicate PvD information to the mobile node. The
+ PvD-aware mobile node will associate network configuration for the
+ Wi-Fi network with an implicit PvD in this case.
+
+ The following diagram illustrates the use of different PvDs in this
+ scenario:
+
+
+ <----------- Wi-Fi 'Internet' PvD -------->
+ +---------+
+ | +-----+ | +-----+ _ __ _ _
+ | |Wi-Fi| | | | ( ` ) ( ` )_
+ | |-IF + |----+ |---------------------------( `)
+ | | | | |Wi-Fi| ( ) ( Internet )
+ | +-----+ | | AP | ( ) ( )
+ | | | | ( Service ) ( )
+ | | +-----+ ( Provider's ) ( )
+ | | ( Networks - ( )
+ | +----+ | `_ ) ( )
+ | |CELL| | ( ) ( )
+ | |-IF +--|-------------------------------------( )
+ | | | | (_ __) (_ _)
+ | +----+ | `- -- `- __ _) -
+ +---------+
+ <------- Mobile 'Internet' PvD ----------->
+
+ Figure 1: An Example of PvD Use with Wi-Fi and Mobile Interfaces
+
+
+
+
+
+Anipko Informational [Page 11]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+4.2. A Node with a VPN Connection
+
+ If the node has established a VPN connection, zero or more (typically
+ one) additional PvD(s) will be created. These may be implicit or
+ explicit. The routing to IP addresses reachable within this PvD will
+ be set up via the VPN connection, and the routing of packets to
+ addresses outside the scope of this PvD will remain unaffected. If a
+ node already has N connected PvDs, after the VPN session has been
+ established typically there will be N+1 connected PvDs.
+
+ The following diagram illustrates the use of different PvDs in this
+ scenario:
+
+ <----------- 'Internet' PvD ------>
+ +--------+
+ | +----+ | +----+ _ __ _ _
+ | |Phy | | | | ( ` ) ( ` )_
+ | |-IF +-|----+ |--------------------( `)
+ | | | | | | ( ) (_ Internet _)
+ | +----+ | | | ( ) `- __ _) -
+ | | |Home| ( Service ) ||
+ | | |Gate| ( Provider's ) ||
+ | | |-way| ( Network - ||
+ | +----+ | | | `_ ) +---------+ +------------+
+ | |VPN | | | | ( ) | VPN | | |
+ | |-IF +-|----+ |---------------------+ Gateway |--+ Private |
+ | | | | | | (_ __) | | | Services |
+ | +----+ | +----+ `- -- +---------+ +------------+
+ +--------+
+ <-------------- Explicit 'VPN' PvD ----->
+
+ Figure 2: An Example of PvD Use with VPN
+
+4.3. A Home Network and a Network Operator with Multiple PvDs
+
+ An operator may use separate PvDs for individual services that they
+ offer to their customers. These may be used so that services can be
+ designed and provisioned to be completely independent of each other,
+ allowing for complete flexibility in combinations of services that
+ are offered to customers.
+
+ From the perspective of the home network and the node, this model is
+ functionally very similar to being multihomed to multiple upstream
+ operators: Each of the different services offered by the service
+ provider is its own PvD with associated PvD information. In this
+ case, the operator may provide a generic/default PvD (explicit or
+
+
+
+
+
+Anipko Informational [Page 12]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ implicit), which provides Internet access to the customer.
+ Additional services would then be provisioned as explicit PvDs for
+ subscribing customers.
+
+ The following diagram illustrates this, using video-on-demand as a
+ service-specific PvD:
+
+ <------ Implicit 'Internet' PvD ------>
+ +----+ +-----+ _ __ _ _
+ | | | | ( ` ) ( ` )_
+ | PC +-----+ |-------------------------( `)
+ | | | | ( ) (_ Internet _)
+ +----+ | | ( ) `- __ _) -
+ |Home | ( Service )
+ |Gate-| ( Provider's )
+ |way | ( Network -
+ +-----+ | | `_ ) +-----------+
+ | Set-| | | ( ) |ISP Video- |
+ | Top +----+ |--------------------------+on-Demand |
+ | Box | | | (_ __) | Service |
+ +-----+ +-----+ `- -- +-----------+
+ <-- Explicit 'Video-on-Demand' PvD -->
+
+ Figure 3: An Example of PvD Use with Wi-Fi and Mobile Interfaces
+
+ In this case, the number of PvDs that a single operator could
+ provision is based on the number of independently provisioned
+ services that they offer. Some examples may include:
+
+ o Real-time packet voice
+
+ o Streaming video
+
+ o Interactive video (n-way video conferencing)
+
+ o Interactive gaming
+
+ o Best effort / Internet access
+
+5. Reference Model for the PvD-Aware Node
+
+5.1. Constructions and Maintenance of Separate PvDs
+
+ It is assumed that normally, the 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.
+
+
+
+
+Anipko Informational [Page 13]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ Nevertheless, even when a PvD lacks some necessary configuration
+ information, merging of information associated with a different
+ PvD(s) shall not be done automatically as this will typically lead to
+ the issues described in [RFC6418].
+
+ A node may use other sources, for example: node local policy, user
+ input, or other mechanisms not defined by the IETF for any of the
+ following:
+
+ o Construction of a PvD in its entirety (analogous to statically
+ configuring IP on an interface)
+
+ o Supplementing some or all learned PvDs with particular
+ configuration elements
+
+ o Merging of information from different PvDs (if this is explicitly
+ allowed by policy)
+
+ As an example, a node administrator could configure the node to use a
+ specific DNS resolver on a particular interface, or for a particular
+ named PvD. In the case of a per-interface DNS resolver, this might
+ override or augment the DNS resolver configuration for PvDs that are
+ discovered on that interface. Such creation/augmentation of a PvD(s)
+ could be static or dynamic. The specific mechanism(s) for
+ implementing this is outside the scope of this document. Such a
+ merging or overriding of DNS resolver configuration might be contrary
+ to the policy that applies to a special-purpose connection, such as,
+ for example, those discussed in Sections 5.2.1 and 5.2.4. In such
+ cases, either the special-purpose connection should not be used or
+ the merging/overriding should not be performed.
+
+5.2. Consistent Use of PvDs for Network Connections
+
+ PvDs enable PvD-aware nodes to consistently use the correct set of
+ configuration elements to serve specific network requests from
+ beginning to end. This section provides examples of such use.
+
+5.2.1. Name Resolution
+
+ When a PvD-aware node needs to resolve the name of the destination
+ for use by a connection request, the node could use one or multiple
+ PvDs for a given name lookup.
+
+ The node shall choose a single PvD if, for example, the node policy
+ required the use of a particular PvD for a specific purpose (e.g., to
+ download a Multimedia Messaging Service (MMS) message using a
+ specific Access Point Name (APN) over a cellular connection or to
+ direct traffic of enterprise applications to a VPN connection to the
+
+
+
+Anipko Informational [Page 14]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ enterprise network). To make this selection, the node could use a
+ match between the PvD DNS suffix and a Fully Qualified Domain Name
+ (FQDN) that is being resolved or a match of the PvD ID, as determined
+ by the node policy.
+
+ The node may pick multiple PvDs if, for example, the PvDs are for
+ general purpose Internet connectivity, and the node is attempting to
+ maximize the probability of connectivity similar to the Happy
+ Eyeballs [RFC6555] approach. In this case, the node could perform
+ DNS lookups in parallel, or in sequence. Alternatively, the node may
+ use only one PvD for the lookup, based on the PvD connectivity
+ properties, user configuration of preferred Internet PvD, etc.
+
+ If an application implements an API that provides a way of explicitly
+ specifying the desired interface or PvD, that interface or PvD should
+ be used for name resolution (and the subsequent connection attempt),
+ provided that the host's configuration permits this.
+
+ In either case, by default a node uses information obtained via a
+ name service lookup to establish connections only within the same PvD
+ as the lookup results were obtained.
+
+ For clarification, when it is written that the name service lookup
+ results were obtained "from a PvD", it should be understood to mean
+ that the name service query was issued against a name service that is
+ configured for use in a particular PvD. In that sense, the results
+ are "from" that particular PvD.
+
+ Some nodes may support transports and/or APIs that provide an
+ abstraction of a single connection, aggregating multiple underlying
+ connections. Multipath TCP (MPTCP) [RFC6182] is an example of such a
+ transport protocol. For connections provided by such transports/
+ APIs, a PvD-aware node may use different PvDs for servicing that
+ logical connection, provided that all operations on the underlying
+ connections are performed consistently within their corresponding
+ PvD(s).
+
+5.2.2. Next-Hop and Source Address Selection
+
+ For the purpose of this example, let us assume that 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, the node could
+ determine such associations via matching the source address prefixes
+ / specific routes advertised by the router against known PvDs or by
+ receiving an explicit PvD affiliation advertised through a new Router
+ Discovery [RFC4861] option.
+
+
+
+
+Anipko Informational [Page 15]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ For each destination, once the best next hop is found, the node
+ selects the best source address according to rules defined in
+ [RFC6724], but with the 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 selecting the best
+ source address from multiple candidates.
+
+ When destination/source pairs are identified, they are sorted using
+ the [RFC6724] destination sorting rules and prefix policy table from
+ the used PvD.
+
+5.2.3. Listening Applications
+
+ Consider a host connected to several PvDs, running an application
+ that opens a listening socket / transport API object. The
+ application is authorized by the host policy to use a subset of
+ connected PvDs that may or may not be equal to the complete set of
+ the connected PvDs. As an example, in the case where there are
+ different PvDs on the Wi-Fi and cellular interfaces, for general
+ Internet traffic the host could 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 use one PvD as the
+ default for outgoing connections, while still allowing use of the
+ other PvDs simultaneously.
+
+ Another example is a host with an established VPN connection. Here,
+ security policy could be used to permit or deny an application's
+ access to the VPN PvD and other PvDs.
+
+ For non-PvD-aware applications, the operating system has policies
+ that 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 the common subset
+ produced between the OS policies and the set of PvD IDs or
+ characteristics provided by the application.
+
+ Application input could be provided on a per-application, per-
+ transport-API-object, or per-transport-API-call basis. The API for
+ application input may have an option for specifying whether the input
+ should be treated as a preference instead of a requirement.
+
+5.2.3.1. Processing of Incoming Traffic
+
+ Unicast IP packets are received on a specific IP address associated
+ with a PvD. For multicast packets, the host can derive the PvD
+ association from other configuration information, such as an explicit
+ PvD property or local policy.
+
+
+
+
+Anipko Informational [Page 16]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ The node OS or middleware may apply more advanced techniques for
+ determining the resultant PvD and/or authorization of the incoming
+ traffic. Those techniques are outside the scope of this document.
+
+ If the determined receiving PvD of a packet is not in the allowed
+ subset of PvDs for the particular application/transport API object,
+ the packet should be handled in the same way as if there were no
+ listener.
+
+5.2.3.1.1. Connection-Oriented APIs
+
+ For connection-oriented APIs, when the initial incoming packet is
+ received, the packet PvD is remembered for the established connection
+ and used for the handling of outgoing traffic for that connection.
+ While typically connection-oriented APIs use a connection-oriented
+ transport protocol, such as TCP, it is possible to have a connection-
+ oriented API that uses a generally connectionless transport protocol,
+ such as UDP.
+
+ For APIs/protocols that support multiple IP traffic flows associated
+ with a single transport API connection object (for example, Multipath
+ TCP), the processing rules may be adjusted accordingly.
+
+5.2.3.1.2. Connectionless APIs
+
+ For connectionless APIs, the host should provide an API that
+ PvD-aware applications can 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 in
+ Sections 5.2.1 and 5.2.2.
+
+5.2.4. Enforcement of Security Policies
+
+ By themselves, PvDs do not define, and cannot be used for
+ communication of, security policies. When implemented in a network,
+ this architecture provides the host with information about connected
+ networks. The actual behavior of the host then depends on the host's
+ policies (provisioned through mechanisms out of scope of this
+ document), applied by taking received PvD information into account.
+ In some scenarios, e.g., a VPN, such policies could require the host
+ to use only a particular VPN PvD for some/all of the application's
+ traffic (VPN 'disable split tunneling' also known as 'force
+ tunneling' behavior) or apply such restrictions only to selected
+ applications and allow the simultaneous use of the VPN PvD together
+ with the other connected PvDs by the other or all applications (VPN
+ 'split tunneling' behavior).
+
+
+
+
+
+Anipko Informational [Page 17]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+5.3. Connectivity Tests
+
+ 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 that are not
+ trusted by a given PvD-aware node.
+
+ An attempt to use such a PvD may lead to limited network connectivity
+ or application connection failures. To prevent the latter, a PvD-
+ aware node may perform a connectivity test for the PvD before using
+ it to serve application network connection requests. In current
+ implementations, some nodes already implement this, e.g., by trying
+ to reach a dedicated web server (see [RFC6419]).
+
+ Section 5.2 describes how a PvD-aware node shall maintain and use
+ multiple PvDs separately. The PvD-aware node shall perform a
+ 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., L2 problems and 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.
+
+ There may be cases where a connectivity test for PvD selection may
+ not be appropriate and should be complemented, or replaced, by PvD
+ selection based on other factors. For example, this could be
+ realized by leveraging some 3GPP and IEEE mechanisms, which would
+ allow the exposure of some PvD characteristics to the node (e.g.,
+ 3GPP Access Network Discovery and Selection Function (ANDSF)
+ [TS23402], Access Network Query Protocol (ANQP) [IEEE802.11u]).
+
+5.4. Relationship to Interface Management and Connection Managers
+
+ 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
+ configuration. These mechanisms or applications are commonly known
+ as connection managers [RFC6419].
+
+ Connection managers sometimes rely on policy servers to allow a node
+ that is connected to multiple networks to perform network selection.
+ They can also make use of routing guidance from the network (e.g.,
+ 3GPP ANDSF [TS23402]). Although connection managers solve some
+
+
+
+Anipko Informational [Page 18]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ connectivity problems, they rarely address network selection problems
+ in a comprehensive manner. With proprietary solutions, it is
+ challenging to present coherent behavior to the end user of the
+ device, as different platforms present different behaviors even when
+ connected to the same network, with the same type of interface, and
+ for the same purpose. The architecture described in this document
+ should improve the host's behavior by providing the hosts with tools
+ and guidance to make informed network selection decisions.
+
+6. PvD Support in APIs
+
+ For all levels of PvD support in APIs described in this chapter, it
+ is expected that the notifications about changes in the set of
+ available PvDs are exposed as part of the API surface.
+
+6.1. Basic
+
+ Applications are not PvD aware in any manner and only submit
+ connection requests. The node performs PvD selection implicitly,
+ without any application participation, based purely on node-specific
+ administrative policies and/or choices made by the user from a user
+ interface provided by the operating environment, not by the
+ application.
+
+ As an example, PvD selection can be done at the name service lookup
+ step by using the relevant configuration elements, such as those
+ described in [RFC6731]. As another example, PvD selection could be
+ made based on application identity or type (i.e., a node could always
+ use a particular PvD for a Voice over IP (VoIP) application).
+
+6.2. Intermediate
+
+ Applications indirectly participate in PvD selection by specifying
+ hard requirements and soft preferences. As an example, a real-time
+ communication application intending to use the connection for the
+ 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 the connection of an infrequently executed
+ background activity, which checks for application updates and
+ performs large downloads when updates are available. For such
+ connections, a cheaper or zero-cost PvD may be preferable, even if
+ such a connection has 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.
+
+
+
+Anipko Informational [Page 19]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+6.3. Advanced
+
+ PvDs are directly exposed to applications for enumeration and
+ selection. Node polices and/or user choices may still override the
+ applications' preferences and limit which PvD(s) can be enumerated
+ and/or used by the application, irrespective of any preferences that
+ the application may have specified. Depending on the implementation,
+ such restrictions (imposed by node policy and/or user choice) may or
+ may not be visible to the application.
+
+7. PvD Trust for PvD-Aware Node
+
+7.1. Untrusted PvDs
+
+ Implicit and explicit PvDs for which no trust relationship exists are
+ considered untrusted. Only PvDs that meet the requirements in
+ Section 7.2 are trusted; any other PvD is untrusted.
+
+ In order to avoid the various forms of misinformation that could
+ occur 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 makes this assumption will be
+ vulnerable to attacks where, for example, an open Wi-Fi hotspot might
+ assert that it was part of another PvD and thereby attempt to draw
+ traffic intended for that PvD onto its own network.
+
+ Since implicit PvD identifiers are synthesized by the node, this
+ issue cannot arise with implicit PvDs.
+
+ Mechanisms exist (for example, [RFC6731]) 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;
+ therefore, assertions of this type 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.
+
+7.2. Trusted PvDs
+
+ 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.
+
+
+
+
+Anipko Informational [Page 20]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ It shall be possible to validate the trust relationship for all
+ advertised elements of a trusted PvD, irrespective 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. The feasibility of
+ mechanisms to implement a trust relationship for all PvD elements
+ will be determined in the respective companion design documents.
+
+7.2.1. Authenticated PvDs
+
+ 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.
+
+ If authentication is done using a public key mechanism such as PKI
+ certificate chain validation or DNS-Based Authentication of Named
+ Entities (DANE), authentication by itself is not enough since
+ theoretically any PvD could be authenticated in this way. In
+ addition to authentication, the node would need configuration 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.
+
+7.2.2. PvDs Trusted by Attachment
+
+ In some cases, a trust relationship may be validated by some means
+ other than those described in Section 7.2.1 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.
+ 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.
+
+8. Security Considerations
+
+ There are at least three different forms of attacks that can be
+ performed using configuration sources that support multiple
+ provisioning domains.
+
+ Tampering with provided configuration information: An attacker may
+ attempt to modify information provided inside the PvD container
+ option. These attacks can easily be prevented by using message
+ integrity features provided by the underlying protocol used to
+ carry the configuration information. For example, SEcure Neighbor
+
+
+
+Anipko Informational [Page 21]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ Discovery (SEND) [RFC3971] would detect any form of tampering with
+ the RA contents and the DHCPv6 [RFC3315] 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 PvD, in which
+ case the mitigations proposed in the next subsection may be
+ helpful.
+
+ 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. For example, a
+ coffee shop WLAN may advertise configuration information
+ purporting to be from an enterprise and may try to attract
+ enterprise-related traffic. This may also occur accidentally if
+ two sites choose the same identifier (e.g., "linsky").
+
+ In order to detect and prevent this, the client must be able to
+ authenticate the identifier provided by the network. This means
+ that the client must have configuration information that maps the
+ PvD identifier to an identity and must be able to authenticate
+ that identity.
+
+ In addition, the network must provide information the client can
+ use to authenticate the identity. This could take the form of a
+ PKI-based or DNSSEC-based trust anchor, or a key remembered from a
+ previous leap-of-faith authentication of the identifier.
+
+ Because the PvD-specific information may come to the network
+ infrastructure with which the client is actually communicating
+ from some upstream provider, it is necessary in this case that the
+ PvD container and its contents be relayed to the client unchanged,
+ leaving the upstream provider's signature intact.
+
+ 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 a replay protection mechanism
+ such as a timestamp or a nonce inside the PvD container to ensure
+ the validity of the provided information.
+
+
+
+
+
+
+
+
+
+
+
+
+Anipko Informational [Page 22]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+9. Informative References
+
+ [DHCPv6-CLASS-BASED-PREFIX]
+ Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
+ Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
+ based prefix", Work in Progress, draft-bhandari-dhc-class-
+ based-prefix-05, July 2013.
+
+ [IEEE802.11u]
+ IEEE, "Local and Metropolitan networks - specific
+ requirements - Part II: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) specifications: Amendment
+ 9: Interworking with External Networks", IEEE Std 802.11u,
+ <http://standards.ieee.org/findstds/
+ standard/802.11u-2011.html>.
+
+ [IPv6-PREFIX-PROPERTIES]
+ Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
+ Liu, "IPv6 Prefix Mobility Management Properties", Work in
+ Progress, draft-korhonen-dmm-prefix-properties-03, October
+ 2012.
+
+ [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+ C., and M. Carney, "Dynamic Host Configuration Protocol
+ for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+ 2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+ "SEcure Neighbor Discovery (SEND)", RFC 3971,
+ DOI 10.17487/RFC3971, March 2005,
+ <http://www.rfc-editor.org/info/rfc3971>.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ DOI 10.17487/RFC4861, September 2007,
+ <http://www.rfc-editor.org/info/rfc4861>.
+
+ [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6
+ Configuration in Internet Key Exchange Protocol Version 2
+ (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010,
+ <http://www.rfc-editor.org/info/rfc5739>.
+
+ [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
+ Iyengar, "Architectural Guidelines for Multipath TCP
+ Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
+ <http://www.rfc-editor.org/info/rfc6182>.
+
+
+
+
+
+Anipko Informational [Page 23]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+ [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
+ Provisioning Domains Problem Statement", RFC 6418,
+ DOI 10.17487/RFC6418, November 2011,
+ <http://www.rfc-editor.org/info/rfc6418>.
+
+ [RFC6419] Wasserman, M. and P. Seite, "Current Practices for
+ Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
+ November 2011, <http://www.rfc-editor.org/info/rfc6419>.
+
+ [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
+ Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
+ 2012, <http://www.rfc-editor.org/info/rfc6555>.
+
+ [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
+ "Default Address Selection for Internet Protocol Version 6
+ (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
+ <http://www.rfc-editor.org/info/rfc6724>.
+
+ [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
+ Recursive DNS Server Selection for Multi-Interfaced
+ Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
+ <http://www.rfc-editor.org/info/rfc6731>.
+
+ [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
+ Address Selection Policy Using DHCPv6", RFC 7078,
+ DOI 10.17487/RFC7078, January 2014,
+ <http://www.rfc-editor.org/info/rfc7078>.
+
+ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+ Kivinen, "Internet Key Exchange Protocol Version 2
+ (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+ 2014, <http://www.rfc-editor.org/info/rfc7296>.
+
+ [TS23402] 3GPP, "Technical Specification Group Services and System
+ Aspects; Architecture enhancements for non-3GPP accesses",
+ Release 12, 3GPP TS 23.402, 2014.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anipko Informational [Page 24]
+
+RFC 7556 MPvD Architecture June 2015
+
+
+Acknowledgments
+
+ The authors would like to thank (in no specific order) Ian Farrer,
+ Markus Stenberg, and Mikael Abrahamsson for their review and
+ comments.
+
+Contributors
+
+ The following individuals contributed to this document (listed in no
+ specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding
+ (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu
+ (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com),
+ Dmitry Anipko (dmitry.anipko@gmail.com), Hui Deng
+ (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com),
+ Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos
+ Pentikousis (k.pentikousis@huawei.com), Marc Blanchet
+ (marc.blanchet@viagenie.ca), Margaret Wasserman
+ (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com),
+ Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen
+ (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com), and
+ Tim Chown (tjc@ecs.soton.ac.uk).
+
+Author's Address
+
+ Dmitry Anipko (editor)
+ Unaffiliated
+
+ Phone: +1 425 442 6356
+ EMail: dmitry.anipko@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anipko Informational [Page 25]
+