Internet Engineering Task Force (IETF) D. Anipko, Ed. Request for Comments: 7556 Unaffiliated Category: Informational June 2015 ISSN: 2070-1721 Multiple Provisioning Domain Architecture
AbstractThis 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.
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.
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 184.108.40.206. 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
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.
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.
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. 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.
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.
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.
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. DHCPv6-CLASS-BASED-PREFIX] [IPv6-PREFIX-PROPERTIES], and any new mechanism should try to consider coexistence with such deployed mechanisms. 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.
<----------- 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
<----------- '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
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
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.
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). RFC4861] option.
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.
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. Sections 5.2.1 and 5.2.2.
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]). 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
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. 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).
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.
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. 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.
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.
[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>.
[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.