RFC 7556
Multiple Provisioning Domain Architecture
RFC 7556: Multiple Provisioning Domain Architecture 🎀
Part 1 of 5 💖
Okay bestie, let's get the basics out of the way first. This one's by D. Anipko, Ed. (Unaffiliated) 🧚, it's Informational (so it's not a Standards Track spec, just published for info 📚), and it dropped in June 2015 with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there ✨.
Abstract
This document is a product of the work of the Multiple Interfaces Architecture Design team. 🦋 It's giving solution framework for the mess that happens when a node is plugged into multiple networks at the same time 🌈. The big idea is the Provisioning Domain (PvD), which is just a consistent set of network configuration info 💅. PvD-aware nodes learn PvD-specific info from the networks they're attached to and/or other sources 🫶. PvDs are how we get separation and configuration consistency when there are multiple concurrent connections, and that's honestly so iconic 👑.
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 💀.
Info about the current status of this doc, any errata, and how to give feedback can be found 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. 🙈
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 . . . . . . . . . . . . . . . . . . . . . . . . 251. Introduction ✨
Nodes attached to multiple networks can run into trouble from conflicting config between those networks, or from attempts to use more than one network at once 😬. Various techniques are used today to tackle these problems [RFC6419], but in lots of cases issues still pop up 🙃. The Multiple Interfaces Problem Statement document [RFC6418] describes the general landscape and talks through a bunch of the specific issues and scenario details 📖.
Problems, listed in [RFC6418], can be sorted into 3 categories 🗂️:
- Lack of consistent and distinctive management of configuration elements associated with different networks.
- Inappropriate mixed use of configuration elements associated with different networks during a particular network activity or connection.
- 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.
Example of (1): a single, node-scoped list of DNS server IP addresses learned from different networks, which leads to failures or delays resolving names from particular namespaces 😭. Example of (2): trying to resolve the name of an HTTP proxy server learned from network A using a DNS server learned from network B 💀. Example of (3): using an employer-provided VPN connection for peer-to-peer connectivity that has nothing to do with work 🙈.
This architecture gives solutions to each of these categories, in order, by 💅:
- 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 🧠.
- Introducing a reference model for PvD-aware nodes that prevents the inadvertent mixed use of configuration information that may belong to different PvDs 🛡️.
- Providing recommendations on PvD selection based on PvD identity and connectivity tests for common scenarios 🎯.
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. 🎀
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 ✨
okay so for the foreseeable future there are gonna be networks that don't advertise explicit PvD info 🥺 bc shipping new networking features is a pretty slow process 🐢
when a PvD-aware node connects to a network that doesn't advertise explicit PvD info, it shall automatically create separate PvDs for the config it receives. this doc calls these "implicit" PvDs 🦋
even with implicit PvDs, PvD-aware nodes can still give their users perks compared to non-PvD-aware nodes, as long as they follow the best practices in Section 5 💅
PvD-aware nodes shall treat network info from different interfaces, which isn't identified as belonging to some PvD, as belonging to separate PvDs, one per interface. 🎀
implicit PvDs can also happen in a mixed mode 🌈, aka when only some of the multiple networks available on an attached link advertise PvD info. in that case the PvD-aware node shall create explicit PvDs from the info explicitly labeled as belonging to PvDs. it shall associate config info that isn't labeled with an explicit PvD with the implicit PvD(s) created for that interface.
2.3. Relationship between PvDs and Interfaces 🎀
by default, implicit PvDs are limited to the network config info received on a single interface, and by default one such PvD is formed for each interface. if the host has extra info (through mechanisms that are out of scope for this doc 🙈), it may form implicit PvDs with different granularity. for example: PvDs spanning multiple interfaces, like a home network with a router that has multiple internal interfaces, or multiple PvDs on a single interface, like a network that has multiple uplink connections.
in the simplest case, explicit PvDs will be scoped for config related only to a specific interface. but there's no requirement in this architecture for that limit. explicit PvDs may include info related to more than one interface if the node learns that the same PvD is present on those interfaces and the authentication of the PvD ID meets the level required by the node policy (authentication of a PvD ID may also be required in scenarios involving only one connected interface and/or PvD; for more on PvD Trust, see Section 7) 🔐
this architecture supports these scenarios. so there's no hierarchical relationship between interfaces and PvDs 👑: multiple PvDs can be simultaneously accessible over one interface, and a single PvD can be simultaneously accessible over multiple interfaces.
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 it's received as part of the PvD info. it shall be possible to generate a human-readable form of the PvD ID to show 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.
so a PvD ID should be, or should have a high probability of being, globally unique 🌸. the point is to make it unlikely that any individual node ever accidentally sees the same PvD name twice when it isn't actually the same PvD. protection against deliberate name-clash attacks 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 apps, or to present a human-readable version of the IDs to the end user so they can pick a PvD 💜
a single network provider may operate multiple networks, including networks at different locations. in that case the provider may choose 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 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 the networks make info about all available PvDs available 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. so different nodes may actually end up using different PvDs for their connections 🤷♀️
possible extensions where networks advertise different sets of PvDs to different connected nodes are out of scope for this document 🙅♀️
2.5. The Relationship to Dual-Stack Networks 👯
when applied to dual-stack networks, the PvD definition allows multiple PvDs to be created, where each PvD contains info relevant to only one address family, or a single PvD containing info for multiple address families. this architecture requires that accompanying design documents describing PvD-related protocol changes must support PvDs containing info from multiple address families. PvD-aware nodes must be capable of creating and using both single-family and multi-family PvDs 🔥
for explicit PvDs, choosing either approach is a policy decision for the network administrator and/or the node user/administrator. since some of the IP config info that can be learned from the network applies to multiple address families (for instance, DHCPv6 Address Selection Policy Option [RFC7078]), it's 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 in a single implicit PvD created for an interface. at the time of writing, it appears to be common practice in dual-stack networks for the config of both address families to come from 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 info. the following sections describe topics that must be considered before finalizing a mechanism to augment DHCPv6 and RAs with PvD info 💖
3.1. Separate Messages or One Message? 💌
when info related to several PvDs is available from the same config source, there are two possible ways to distribute it. one way is to send info from each different provisioning domain in separate messages. the second method is to combine the info from multiple PvDs into a single message. the latter is more efficient, but it could have problems with authentication and authorization, as well as potential issues with accommodating info not tagged with any PvD info 🤔
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. that's useful, but determining authenticity doesn't tell a node whether the config source is actually allowed to provide info 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 config info that gets 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 before PvD info was added. this could mean some info may need to be duplicated so it can be conveyed to legacy hosts. similarly, PvD-aware hosts need to be able to correctly utilize legacy config sources that don't provide PvD info. there are also several initiatives aimed at adding some form of additional info 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 info is provisioned to a host, it may become outdated or superseded by updated info before the host would normally request updates. to resolve this, the mechanism must be able to update and/or withdraw all (or some subset) of the info related to a given PvD. for efficiency reasons, there should be a way to specify that all info 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 info. 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 config may depend on the named IDr. another possibility could be adding a specific provisioning-domain-identifying payload extension to IKEv2. all of the considerations for DHCPv6 and the RAs listed above potentially apply to IKEv2 as well 🦋
4. Example Network Configurations 🧚
4.1. A Mobile Node ✨
Okay so picture a mobile node with two network interfaces, one to the mobile network and one to Wi-Fi 📱. When it's only connected to the mobile network, it'll typically have one PvD, either implicit or explicit. Then when it finds and joins a Wi-Fi network, it gets zero or more (typically one) extra PvD(s) 🧚
Some existing OS implementations only let you have one active network connection 🙈 So only the PvD(s) tied to the active interface can be used at any given time.
For example, the mobile network can explicitly deliver PvD information during the Packet Data Protocol (PDP) context activation process 💅 Then the PvD-aware mobile node treats the mobile network as an explicit PvD. Meanwhile, the legacy Wi-Fi network might not explicitly communicate any PvD information, so the PvD-aware mobile node will associate that Wi-Fi network configuration with an implicit PvD 🦋
Here's how the different PvDs look 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 Interfaces4.2. A Node with a VPN Connection 🔐
If the node sets up a VPN connection, zero or more (typically one) additional PvD(s) will get created 🎀 These can be implicit or explicit. Routing to IP addresses reachable inside this PvD gets set up via the VPN connection, while routing for packets going to addresses outside this PvD stays unaffected. So if a node already has N connected PvDs, after the VPN session is established you'll typically have N+1 connected PvDs ✨
Here's the picture 🌸
<----------- '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 VPN4.3. A Home Network and a Network Operator with Multiple PvDs 🏠
An operator can use separate PvDs for each individual service they offer their customers 🍓 That way, services can be designed and provisioned completely independently of each other, which gives the operator total flexibility in how they bundle services together 💜
From the home network's and the node's point of view, this setup is basically the same vibe as being multihomed to several upstream operators 🫶 Each service the provider offers is its own PvD with its own PvD information. The operator can also hand out a generic/default PvD (explicit or implicit) that gives customers Internet access. Extra services then get provisioned as explicit PvDs for the customers who subscribe 🌈
Here's the video-on-demand example, where the service-specific PvD is video-on-demand 📺
<------ 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 InterfacesHere, the number of PvDs a single operator could provision depends on how many independently provisioned services they offer 💅 A few examples:
- Real-time packet voice 🎤
- Streaming video 🍿
- Interactive video (n-way video conferencing) 📹
- Interactive gaming 🎮
- Best effort / Internet access 🌐
5. Reference Model for the PvD-Aware Node 🧠
5.1. Constructions and Maintenance of Separate PvDs 🛠️
It's assumed that normally, the configuration information in a single PvD shall be enough for a node to handle a network connection request from an application, so there should be no need to try merging information across different PvDs 💖
Even so, when a PvD is missing some configuration information it needs, merging information from other PvD(s) shall not be done automatically 🚫 Doing that would typically lead to the issues described in [RFC6418] 😭
A node may use other sources, like node local policy, user input, or other mechanisms not defined by the IETF, for any of the following:
- Construction of a PvD in its entirety (analogous to statically configuring IP on an interface)
- Supplementing some or all learned PvDs with particular configuration elements
- Merging of information from different PvDs (if this is explicitly allowed by policy)
For example, a node administrator could set the node to use a specific DNS resolver on a particular interface, or for a particular named PvD 🔧 With a per-interface DNS resolver, this might override or augment the DNS resolver configuration for PvDs discovered on that interface. That creation or augmentation of PvD(s) could be static or dynamic, and the specific mechanism(s) for doing it are outside the scope of this document 🦋 Merging or overriding DNS resolver configuration might clash with the policy for a special-purpose connection, such as the ones discussed in Sections 5.2.1 and 5.2.4 🙈 In those 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 let PvD-aware nodes consistently use the right set of configuration elements to serve specific network requests from beginning to end 🎀 This section gives examples of that 💅
5.2.1. Name Resolution 🔍
When a PvD-aware node needs to resolve the name of a destination for a connection request, it could use one or multiple PvDs for that name lookup 🌷
The node shall choose a single PvD if, for example, the node policy requires a particular PvD for a specific purpose (like downloading a Multimedia Messaging Service (MMS) message over a cellular connection using a specific Access Point Name (APN), or sending enterprise app traffic through a VPN connection to the enterprise network) 🏢 To make that choice, the node could match the PvD DNS suffix against the Fully Qualified Domain Name (FQDN) being resolved, or match 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 trying to maximize the chance of connectivity, similar to the Happy Eyeballs [RFC6555] approach 🏃♀️ In that case, the node could do DNS lookups in parallel or in sequence 🔁 Or the node may use only one PvD for the lookup, based on PvD connectivity properties, user configuration of a preferred Internet PvD, etc. 🎯
If an application uses an API that lets it explicitly specify the desired interface or PvD, that interface or PvD should be used for name resolution (and the connection attempt that follows), as long as the host's configuration allows it 🫶
Either way, by default a node only uses information from a name service lookup to establish connections within the same PvD that the lookup results came from 🚧
Just to clarify 💁♀️ when it says the name service lookup results were obtained "from a PvD," it means the name service query was sent to a name service configured for use in that particular PvD. In that sense, the results are "from" that PvD 🌈
Some nodes may support transports and/or APIs that give an abstraction of a single connection by bundling multiple underlying connections together 🧵 Multipath TCP (MPTCP) [RFC6182] is one example of a transport protocol like that. For connections provided by such transports/APIs, a PvD-aware node may use different PvDs to service that logical connection, as long as all operations on the underlying connections are carried out consistently within their corresponding PvD(s) 👑
5.2.2. Next-Hop and Source Address Selection
okay so for this example, let's say the name lookup we just talked about succeeded in a particular PvD 💖. For each destination address we got back, the node shall do a next-hop lookup among the routers associated with that PvD. The node could figure out those associations by matching the source address prefixes / specific routes the router advertises against known PvDs, or by receiving an explicit PvD affiliation advertised through a new Router Discovery [RFC4861] option ✨.
For each destination, once the best next hop is found, the node picks the best source address using the rules in [RFC6724] 💅. There's a catch though: the source address has to belong to a range associated with the PvD being used. If needed, the node would use the prefix policy from that same PvD to choose the best source address out of several candidates 🎀.
Once destination/source pairs are identified, they get sorted using the [RFC6724] destination sorting rules and the prefix policy table from the used PvD 🌸.
5.2.3. Listening Applications
Picture a host connected to several PvDs, running an app that opens a listening socket / transport API object 🎧. The app is authorized by the host policy to use a subset of the connected PvDs, and that subset may or may not be the whole set 👀. Like, if there are different PvDs on the Wi-Fi and cellular interfaces, the host could use just one preferred PvD at a time for general Internet traffic (and advertise the host name and addresses tied to that PvD to remote peers). OR it could use one PvD as the default for outgoing connections while still letting the other PvDs be used at the same time 🦋.
Another example: 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 the application provides 🧚.
Application input could be given per-application, per-transport-API-object, or per-transport-API-call. The API for application input may have an option for saying whether the input should be treated as a preference instead of a requirement 🍓.
5.2.3.1. Processing of Incoming Traffic
Unicast IP packets get received on a specific IP address associated with a PvD. For multicast packets, the host can derive the PvD association from other configuration info, like an explicit PvD property or local policy 🫶.
The node OS or middleware may apply more advanced techniques for working out the resultant PvD and/or authorization of 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 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 arrives, the packet PvD gets remembered for the established connection and used for handling outgoing traffic on that connection. While connection-oriented APIs typically use a connection-oriented transport protocol, such as TCP, it's 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 gives the host 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 they could 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) 🔥.
5.3. Connectivity Tests
Okay, this one is important bestie. Although some PvDs may look like valid candidates for PvD selection (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 (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.
Using 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 do 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 connection 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 use 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 let a node connected to multiple networks 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's challenging to present coherent behavior to the end user, since different platforms behave differently 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 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, notifications about changes in the set of available PvDs are expected to be exposed as part of the API surface 📣.
6.1. Basic
Apps aren't 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 the user makes 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 app intending to use the connection for exchanging real-time audio/video data may indicate a preference or 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 app 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.
6.3. Advanced
PvDs are directly exposed to applications for enumeration and selection. Node policies 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 with no trust relationship are considered untrusted, bestie 🫶 Only PvDs that meet the requirements in Section 7.2 count as trusted. Anything else is untrusted.
So nodes that do PvD separation cannot assume that two explicit PvDs with the same identifier are actually the same PvD 🙈 Doing that is how misinformation sneaks in when PvDs are untrusted. If a node makes that assumption, it's wide open to attacks. An open Wi-Fi hotspot could claim to be part of some other PvD and try to pull that PvD's traffic onto its own network. Not it 💀
Implicit PvD identifiers are made up by the node itself, so this issue can't happen with implicit PvDs ✨
There are mechanisms (for example, [RFC6731]) that let a PvD hand over configuration info claiming special knowledge about which resources are reachable through it. Those claims can't be validated unless the node has a trust relationship with the PvD, so nodes must ignore these assertions when they come from untrusted PvDs. If they didn't, traffic could get redirected from legit destinations to spoofed ones 😭 That's a hard no.
7.2. Trusted PvDs 👑
Trusted PvDs are PvDs where two things are true. First, a trust relationship has to exist between the node using the PvD configuration and the source that provided it. That's the authorization part 🎀 Second, there has to be some way to validate that trust relationship. That's the authentication part. The original spells out two mechanisms for validating it.
Here's the vibe: it shall be possible to validate the trust relationship for every advertised element of a trusted PvD. That's true whether the elements come all together, like in one DHCP option, or separately, like in supplementary RA options. Whether a trust relationship can be set up for all PvD elements will be figured out 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 to combine cryptographic authentication with an identifier configured on the node.
If authentication uses a public key mechanism, like PKI certificate chain validation or DNS-Based Authentication of Named Entities (DANE), then authentication alone isn't enough. Honestly, any PvD could be authenticated that way 🙈 So the node also needs configuration telling it to trust the identifier being authenticated. Checking the authenticated PvD name against a list of PvD names configured as trusted on the node is the authorization step in this case 💖
7.2.2. PvDs Trusted by Attachment 📶
Sometimes a trust relationship can be validated by something other than what's in Section 7.2.1, just because of the connection the PvD came through. For example, a handset on a mobile network may know through the mobile network infrastructure that it's connected to a trusted PvD. Whatever mechanism validated that connection is the authentication part of the trust relationship 🦋
Presumably, a handset like that is configured at the factory, or through mobile operator or user preference settings, to trust the PvD. That setup is the authorization part of this kind of trust relationship 🌸
8. Security Considerations 🚨
There are at least three different forms of attacks that can be carried out using configuration sources that support multiple provisioning domains. Pay attention, this part is serious 😭
Tampering with provided configuration information: An attacker might try to change information inside the PvD container option 😈 These attacks can be stopped by using the message integrity features of the underlying protocol that carries the configuration info. For example, SEcure Neighbor Discovery (SEND) [RFC3971] would catch any tampering with the RA contents, and the DHCPv6 [RFC3315] AUTH option would catch any tampering with the DHCPv6 message contents. A compromised configuration source can also do this by modifying info inside a specific PvD. In that case, the mitigations in the next subsection may help 🛡️
Rogue configuration source: A compromised configuration source, like a router or a DHCPv6 server, may advertise info about PvDs it isn't authorized to advertise. For example, a coffee shop WLAN might advertise config info pretending to be from an enterprise, then try to lure enterprise traffic over 🫠 This can also happen by accident if two sites pick the same identifier, like "linsky" 🙃
To catch and prevent this, the client must be able to authenticate the identifier the network provides. That means the client must have configuration info that maps the PvD identifier to an identity, and it must be able to authenticate that identity.
The network must also provide info the client can use to authenticate the identity. That could be a PKI-based or DNSSEC-based trust anchor, or a key remembered from an earlier leap-of-faith authentication of the identifier 🔑
Because the PvD-specific info may reach the network the client is actually talking to from some upstream provider, the PvD container and its contents must be relayed to the client unchanged, with the upstream provider's signature left intact. Don't touch it 🙅♀️
Replay attacks: A compromised configuration source, or an attacker on the link, may try to capture advertised configuration info and replay it on a different link or at a later time. This can be prevented by including a replay protection mechanism, like a timestamp or a nonce, inside the PvD container. That keeps the provided info valid 💜
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>.
[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.Acknowledgments 🫶
The authors would like to thank (in no specific order) Ian Farrer, Markus Stenberg, and Mikael Abrahamsson for their review and comments. Thank you, legends ✨
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). The whole squad 💖
Author's Address 🦋
Dmitry Anipko (editor)
Unaffiliated
Phone: +1 425 442 6356
EMail: dmitry.anipko@gmail.com📦 where this page comes from
- ietf: rfc7556 2015-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms