RFC 6418

Multiple Interfaces and Provisioning Domains Problem Statement

📅 published November 2011, from ietf

RFC 6418: Multiple Interfaces and Provisioning Domains Problem Statement ✨

Okay bestie, let's get the paperwork out of the way first 📎🎀 This is RFC 6418, titled Multiple Interfaces and Provisioning Domains Problem Statement, published by the Internet Engineering Task Force (IETF). It's Informational, which means it's a "here's what's going on" doc, not a standards-track spec 🧚. The authors are M. Blanchet from Viagenie and P. Seite from France Telecom - Orange. It was published in November 2011, and its ISSN is 2070-1721 💜. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 💅.

Abstract

Here's the big picture 🌸. This doc looks at problems a node runs into when it's plugged into multiple provisioning domains at once. The node gets config info from each domain, and some of that config is global to the whole node while some belongs only to one interface 🦋. When the node-wide config conflicts and gets used the wrong way, you can end up sending traffic out the wrong interface, which is so not it 😭. Other headaches come from just being connected to several networks at the same time, like picking the right domain or dealing with addressing and naming spaces that overlap, and that happens no matter how the config was delivered 🔥. Even though multiple provisioning domains usually show up on nodes with several interfaces, the doc also talks about single-interface nodes 👑.

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🧚.

It is a product of the IETF and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6418 🔗.

Copyright (c) 2011 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), as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🎀.

Table of Contents

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scope and Existing Work .........................................4
   3.1. Interactions Below IP ......................................4
   3.2. MIF Node Characterization ..................................5
   3.3. Host Requirements ..........................................5
   3.4. Mobility and Other IP Protocols ............................6
   3.5. Address Selection ..........................................6
   3.6. Finding and Sharing IP Addresses with Peers ................7
   3.7. Provisioning Domain Selection ..............................7
   3.8. Session Management .........................................8
   3.9. Sockets API ................................................9
4. MIF Issues ......................................................9
   4.1. DNS Resolution Issues ......................................9
   4.2. Node Routing ..............................................12
   4.3. Conflicting Policies ......................................13
   4.4. Session Management ........................................14
   4.5. Single Interface on Multiple Provisioning Domains .........14
5. Underlying Problems and Causes .................................15
6. Security Considerations ........................................17
7. Contributors ...................................................18
8. Acknowledgements ...............................................18
9. Informative References .........................................18

1. Introduction 🦋

A multihomed node can have multiple provisioning domains, through physical interfaces, virtual ones, or both 🌈. For example, one node might be connected to a wired Ethernet LAN, an 802.11 LAN, a 3G cell network, one or several VPN connections, or one or several tunnels (automatic or manual) 💜. Today's laptops and smartphones usually have several access network interfaces, so they're often attached to different provisioning domains at the same time 📱✨.

A multihomed node gets config info from each network it's attached to, through mechanisms like DHCPv4 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661], and IPv6 Router Advertisements [RFC4861] 📡. Some of that config is specific to one interface, like the IP address and the link prefix 🎯. Other config is usually treated by implementations as global to the node. That includes routing info (for example, the default gateway), DNS server IP addresses, and address selection policies. This doc calls those "node-scoped" 👑.

When node-scoped config from different provisioning domains has different values, like different DNS server IP addresses, different default gateways, or different address selection policies, the node has to pick one or figure out how to merge them 😬.

Other issues come from being attached to several networks at once, such as addressing and naming space overlaps, no matter how the provisioning was done 🙈.

The next sections define the multiple interfaces (MIF) node and the scope of this work, describe related work, list issues, and then sum up the underlying problems 🧚.

There's also a companion doc, [RFC6419], that covers some current practices across different implementations when dealing with MIF 💅.

2. Terminology ✨

Administrative domain

A group of hosts, routers, and networks operated and managed by a single organization [RFC1136] 🏢.

Provisioning domain

A set of consistent configuration information (for example, default router, network prefixes, DNS) and the corresponding interface. One administrative domain can have multiple provisioning domains. Successfully attaching to a provisioning domain means the terminal attaches to the matching interface with the right configuration information 🎀.

Reference to IP version

When a protocol keyword like IP, PPP, or DHCP appears in this document without a specific IP version, it means both IPv4 and IPv6 🌸. A version-specific keyword like DHCPv4 or DHCPv6 is meant only for that IP version 💖.

3. Scope and Existing Work 💜

This section covers existing related work and sets the scope of the problem 🔍.

3.1. Interactions Below IP 🧚

Some interface types have link-layer characteristics that can help decide how multiple provisioning domain issues get handled 🔐. For instance, link layers might have authentication and encryption features that could serve as criteria for picking an interface. However, network discovery and selection on lower layers, as defined by [RFC5113], is out of scope for this document 🙅‍♀️. Interoperability with lower-layer mechanisms is also out of scope, including the services defined in IEEE 802.21, which aim to make handovers between heterogeneous networks easier [MIH] 🔄.

Some mechanisms, like ones based on a virtual IP interface, let a single IP address be shared across several interfaces that go to networks with different access technologies 🦋. From the IP stack's point of view on the node, there's only one interface and one IP address, so this situation is out of scope for this problem statement 🙈. Link aggregation done under IP, where the IP stack is shown a single interface, is also out of scope 💅.

3.2. MIF Node Characterization 💖

A MIF node has these characteristics:

  • A MIF node is an [RFC1122] IPv4- and/or [RFC4294] IPv6-compliant node 🌈.
  • A MIF node is configured with more than one IP address (excluding loopback and link-local) 🌸.
  • A MIF node can attach to more than one provisioning domain, as presented to the IP stack 🔗.
  • The interfaces may be virtual or physical 🦋.
  • Configuration objects come from one or more administrative domains 🏢.
  • The IP addresses may be from the same or different address families, such as IPv4 and IPv6 ✨.
  • Communications using these IP addresses may happen simultaneously and independently 🧚.
  • Some communications using these IP addresses are possible on all the provisioning domains, while some are only possible on a smaller set of the provisioning domains 🎯.
  • While the MIF node may forward packets between its interfaces, forwarding is not taken into account in this definition and is out of scope for this document 🙅‍♀️.

3.3. Host Requirements 📜

"Requirements for Internet Hosts -- Communication Layers" [RFC1122] describes the multihomed node as having multiple IP addresses, which may be tied to one or more physical interfaces connected to the same or different networks 🌟.

Section 3.3.1.3 of [RFC1122] says the node keeps a route cache table where each entry holds the local IP address, the destination IP address, Type(s) of Service (which has been superseded by the Differentiated Services Code Point [RFC2474]), and the next-hop gateway IP address 🗂️. A route cache entry would also have data about path properties, like the average round-trip delay measured by a transport protocol ⏱️. These days, implementations aren't caching this info 🙃.

[RFC1122] defines two host models 🧠:

  • The "strong" host model defines a multihomed host as a set of logical hosts within the same physical host. In this model, a packet must be sent on an interface that corresponds to the source address of that packet 💪.
  • The "weak" host model describes a host that has some embedded gateway functionality. In the weak host model, the host can send and receive packets on any interface 🌊.

A multihomed node computes routes for outgoing datagrams differently depending on the model 🔀. Under the strong model, the route is computed from the source IP address, the destination IP address, and the Differentiated Services Code Point 🎀. Under the weak model, the source IP address isn't used, and only the destination IP address and the Differentiated Services Code Point are used 💅.

3.4. Mobility and Other IP Protocols 🦋

Okay so the scope of this doc is ONLY about nodes implementing [RFC1122] for IPv4 and [RFC4294] for IPv6, with no extra features or special-purpose support for transport layers, mobility, multihoming, or identifier-locator split mechanisms 🌸. Dealing with multiple interfaces with those mechanisms is related but it's its own separate problem, and it's being actively studied elsewhere in the IETF [RFC4960] [RFC5206] [RFC5533] [RFC5648] [RFC6182] 💅.

When an app is using one interface and another interface with better characteristics pops up, the ongoing session could get transferred over to the new interface ✨. BUT, in some cases the ongoing session shall be kept on the current interface while the new session gets started on the new interface, so no chaos 🙈. The interface selection problem is part of the MIF scope and it may lean on specific node functions (Section 3.8). However, if you actually need to transfer an IP session, IP mobility mechanisms, such as [RFC6275], shall be used 🔥.

3.5. Address Selection 💖

"Default Address Selection for Internet Protocol version 6 (IPv6)" [RFC3484] is the one that defines the algorithms for picking source and destination IP addresses 🧚. Default address selection as defined in [RFC3484] is mandatory to implement in IPv6 nodes, and that also means dual-stack nodes 👑. There's a node-scoped policy table managed by the IP stack, and the mechanisms for updating that table are defined in [ADDR-SELECT-SOL] 🎀.

Issues with default address selection were found in [RFC5220] and [RFC5221] when there are multiple prefixes on the same link 😭.

3.6. Finding and Sharing IP Addresses with Peers 🌈

Interactive Connectivity Establishment (ICE) [RFC5245] is a NAT traversal technique for UDP-based (and TCP-based) media streams set up by the offer/answer model ✨. All the IP addresses, ports, and transport mechanisms in Session Description Protocol (SDP) offers get tested for connectivity through peer-to-peer connectivity checks, and the result is candidate IP addresses and ports for connecting to the other peer 🦋. Still, ICE does not solve the issues that show up when incompatible configuration objects are received on different interfaces 💀.

Some application protocols do referrals of IP addresses, port numbers, and transport for further exchanges 🫶. For example, applications can provide reachability information to themselves or to a third party. The general referral problem is related to the multiple-interface problem, because in this context, referrals must provide consistent information depending on which provisioning domain is used 🍓. Referrals are discussed in [REFERRAL-PS] and [SHIM6-APP-REFER] 💜.

3.7. Provisioning Domain Selection 🌸

In a MIF context, the node may handle multiple domains with totally different characteristics at the same time, especially when it's supporting multiple access technologies 😩. Selection is simple if the application is restricted to one specific provisioning domain: the application must start on the default provisioning domain if one is available, and otherwise, the application does not start 🙅‍♀️. But if the application can run on several provisioning domains, the selection problem can get pretty difficult 🥲.

There is no standard method for selecting a provisioning domain. There are some recommendations, though, as long as we keep the scope to the interface selection problem ✨. For example, [TS23.234] proposes a default mechanism for interface selection 🎀. This method uses the following information (non-exhaustive list):

  • preferences provided by the user
  • policies provided by the network operator
  • quality of the radio link
  • network resource considerations (e.g., available Quality of Service (QoS), IP connectivity check)
  • the application QoS requirements in order to map applications to the best interface

However, [TS23.234] is designed for one specific multiple-interfaces use case, and a generic way to handle all these characteristics is yet to be defined 🌈.

3.8. Session Management 💅

Some implementations, especially in the mobile world, rely on a higher-level session manager (also called a connection manager) to deal with the issues that come with being attached to multiple provisioning domains at once 📱. Typically, the session manager may handle interface selection and/or provisioning domain selection on behalf of the applications, or tackle complex stuff like how to resolve conflicting policies (Section 4.3) 🧠. As discussed in Section 3.7, the session manager can run into trouble because of the multiple and diverse criteria 😵‍💫.

Session managers usually use the link-layer interface to gather information (e.g., lower-layer authentication and encryption methods; see Section 3.1) and/or for control purposes 🔐. That link-layer interface may not provide all the services required to make a proper decision (e.g., interface selection) 🙃. Some OSes and terminals already implement session managers [RFC6419], and vendor-specific platforms sometimes provide a specific sockets API (Section 3.9) that a session manager can use 🧚. However, the generic architecture of a session manager and its associated API are not currently standardized, so session manager behavior may differ between OSes and platforms 🌸.

Managing multiple interfaces sometimes relies on a virtual interface 🦋. For instance, a virtual interface allows support of multihoming, inter-technology handovers, and IP flow mobility in a Proxy Mobile IPv6 network [LOGICAL-IF-SUPPORT] ✨. This virtual interface lets a multiple-interface node share a set of IP addresses across multiple physical interfaces, and it can also add benefits to multi-access scenarios like Third Generation Partnership Project (3GPP) Multi Access Packet Data Network (PDN) Connectivity [TS23.402] 💖. In most cases, the virtual interface will map several physical network interfaces, and the session manager should control the configuration of each of these virtual and physical interfaces, as well as the mapping between the virtual and sub-interfaces 👑.

In a situation with multiple interfaces, active application sessions should survive path failures 🥹. The session manager may come into play here, but only by relying on existing mechanisms to manage multipath TCP (MPTCP) [RFC6182] or failover (Mobile IPv6 (MIP6) [RFC6275], Shim6 [RFC5533]) 🔁. A description of how these mechanisms interact with the session manager is out of scope for this document 🙈.

3.9. Sockets API 🎀

An Application Programming Interface (API) may expose objects that user applications or session managers use to deal with multiple interfaces 🧚‍♀️. For example, [RFC3542] defines how an application using the advanced sockets API can specify the interface or the source IP address through a simple bind() operation or with the IPV6_PKTINFO socket option 💜.

Other APIs have been defined to solve issues similar to MIF 🌈. For instance, [RFC5014] defines an API to influence the default address selection mechanism by specifying attributes of the source addresses it prefers ✨. [RFC6316] gives another example in a multihoming context, defining a sockets API that enables interactions between applications and the multihoming shim layer for advanced locator management, plus access to information about failure detection and path exploration 🦋.

4. MIF Issues 🚨

This section describes the various issues that come up when using a MIF node that has already received configuration objects from its various provisioning domains, or when multiple interfaces are used and result in wrong domain selection, addressing, or naming space overlaps 😤. They occur, for example, when:

  1. one interface is on the Internet and one is on a corporate private network. The latter may be through VPN 🏢.
  2. one interface is on one access network (i.e., WiFi) and the other one is on another access network (3G) with specific services 📶.

4.1. DNS Resolution Issues 💖

okay so picture this 🎀 a MIF node (M1) has an active interface (I1) on network (N1), and N1 has its own DNS servers, with S1 as the primary. M1 also has another active interface (I2) on network (N2), which has its DNS servers too, with S2 as the primary. S1 runs a private namespace called private.example.com. The user or an app asks for a.private.example.com, which lives inside S1's private namespace and can only be resolved by S1. Any of the following situations may occur 👀:

  1. The M1 stack checks its routing table and uses I2 to reach S1 to resolve a.private.example.com. M1 never reaches S1, so the name doesn't resolve. 💀
  2. M1 only keeps one set of DNS server addresses from the configuration objects it received. Let's say it keeps S2's address as the primary DNS server. M1 sends the forward DNS query for a.private.example.com to S2, and S2 replies with NXDOMAIN (a nonexistent domain error). The name doesn't resolve. This also happens with reverse DNS lookups. In that same situation, the reverse DNS query fails too. 😭
  3. Same deal, M1 keeps only S2's address. M1 sends the DNS query for a.private.example.com to S2. S2 asks its upstream DNS and gets back an IP address for a.private.example.com. But it's not the same one S1 would have given! So the app tries to connect to the wrong destination node, or the wrong interface, which can cause security issues or a lack of service. yikes 🙈
  4. S1 or S2 has been used to resolve a.private.example.com to an [RFC1918] address. Both N1 and N2 are [RFC1918]-addressed networks. If the addresses overlap, traffic may be sent out the wrong interface. This one isn't really about getting multiple configuration objects. It's about an address overlap between interfaces or the networks attached to them. 🌸
  5. M1 resolves a Fully Qualified Domain Name (FQDN) to an IP address that's only valid locally when it's connected to N1. If the node loses its connection to N1, it may try to connect via N2 to that same IP address, but since the address was only locally valid, the connection setup fails. Similarly, M1 may have received NXDOMAIN for an FQDN while connected to N1. After detaching from N1, the node should not assume the FQDN is still nonexistent on N2. 🦋
  6. M1 requests an AAAA record from a DNS server on a network that uses protocol translators and DNS64 [RFC6147]. If M1 gets a synthesized AAAA record, it's only guaranteed to be valid on the network where it was learned. If M1 uses that synthesized AAAA on any other network interface, traffic may be lost, dropped, or forwarded to the wrong network. 🚨

Some networks make you authenticate on a captive web portal before giving you Internet access. If that redirection happens by modifying the DNS reply, some specific issues can pop up 🥺. Picture a MIF node (M1) with an active interface (I1) on a network (N1), which has its DNS server (S1), plus another active interface (I2) on a network (N2), which has its DNS server (S2). Until the user authenticates, S1 is set up to answer any A or AAAA query with the IP address of a captive portal, so web browsers get redirected to an access control portal page. That captive portal can only be reached through I1. Once the user has authenticated, M1 can resolve an FQDN while connected to N1. But if the address is only locally valid on N1, any of the issues described above may happen. Until the user has authenticated, any of the following situations may occur:

  1. M1 only keeps one set of DNS server addresses from the configuration objects it received, and it kept S2's address. M1 sends the forward DNS query for a.example.com to S2, and S2 gives the correct answer, R1. M1 tries to contact R1 through I1. Either the connection fails, or it succeeds by bypassing the security policy on N1, which could expose the owner of M1 to prosecution. 😬
  2. M1 only keeps one set of DNS server addresses from the configuration objects it received, and it kept S1's address. M1 sends the DNS query for a.example.com to S1, and S1 gives back the address of its captive portal. M1 tries to contact that IP address using I1. The application fails to connect, which means a lack of service. Or the application connects successfully, but it's connected to the captive portal instead of the intended destination, which is still a lack of service. (This is an IP connectivity check issue, as described in Section 4.4.) 🙃

4.2. Node Routing 🛣️

Let's look at a MIF node (M1) with an active interface (I1) connected to a network (N1), and another active interface (I2) connected to a network (N2). The user or the application is trying to reach an IP address (IP1). Any of the following situations may occur:

  1. For IP1, M1 has one default route (R1) via network (N1). To reach IP1, the M1 stack uses R1 and sends through I1. If IP1 is only reachable through N2, then IP1 is never reached, or it's not the right target. 🙅‍♀️
  2. For the IP1 address family, M1 has one default route per network (R1 and R2, for N1 and N2). IP1 is reachable through both networks, but the N2 path has better characteristics, like better round-trip time, lowest cost, better bandwidth, and so on. These preferences could be defined by the user, provisioned by the network operator, or otherwise appropriately configured. The M1 stack uses R1 and tries to send through I1. IP1 is reached, but the service would be better via I2. ✨
  3. For the IP1 address family, M1 has a default route (R1), a more specific X.0.0.0/8 route R1B (for example, but not restricted to, an [RFC1918] prefix) to N1, and a default route (R2) to N2. IP1 is reachable only through N2, but the prefix X.0.0.0/8 is used on both networks. Because the most specific route R1B wins, the M1 stack sends packets through I2, and those packets never reach the target. 💀

A MIF node may have multiple routes to a destination. However, by default, it has no hint about which interface would be the best one to use for that destination. First-hop selection may rely on local routing policy, which lets some actors (for example, a network operator or service provider) influence the routing table, meaning they can make the call on which interface gets used. For instance, a user on a multihomed node might want a local policy to decide which interface gets used based on various conditions. Some Standards Development Organizations (SDOs) have defined policy-based routing selection mechanisms. For example, the Access Network Discovery and Selection Function (ANDSF) [TS23.402] gives terminals with both a 3GPP interface and non-3GPP interfaces inter-system routing policies. Still, routing selection can be hard because of disjoint criteria, as discussed in Section 3.8. Plus, the information needed to make the right decision may not be available. For instance, interfaces to a lower layer may not provide all the hints needed for selection (for example, information on interface quality). 📡

A node usually has a node-scoped routing table. But a MIF node is connected to multiple provisioning domains. If each of those domains pushes routing policies to the node, conflicts between policies may happen, and the node has no easy way to merge or reconcile them. 🌀

On a MIF node, some source addresses aren't valid if used on some interfaces. For example, an [RFC1918] source address might be fine on the VPN interface but not on the public interface of the MIF node. If the source address isn't chosen appropriately, packets may be filtered along the path if source address filtering is in place ([RFC2827], [RFC3704]), and reply packets may never make it back to the source. 🫠

4.3. Conflicting Policies 🥊

Distributing configuration policies (for example, address selection, routing, and DNS selection) to end nodes is being discussed. Examples include ANDSF in [TS23.402] and [DHCPv6-ROUTE-OPTIONS]. If these mechanisms are implemented in multiple provisioning domains, they may conflict and create issues for the multihomed node. Take a MIF node (M1) with an active interface (I1) connected to a network (N1) and another active interface (I2) connected to a network (N2). The following conflicts may occur:

  1. M1 receives an update of its default address selection policy from both networks (N1 and N2). However, the policies are specific to each network. The M1 stack merges the policies. Based on the merged policy, the chosen source address comes from N1, but the packets are sent to N2. That source address isn't reachable from N2, so the return packet is lost. Merging address selection policies can have big impacts on routing. 😵
  2. A node usually has a node-scoped routing table. But each of the connected provisioning domains (N1 and N2) may push routing policies to the node. Conflicts between those policies may then happen, and the node has no easy way to merge or reconcile them. 🤯
  3. M1 receives an update of its access selection policy from one of the networks, for example via 3GPP/ANDSF [TS23.402]. However, that policy conflicts with the local policy (for example, a user-defined or default OS policy). Assuming the network provides a list of overloaded access networks, if the policy sent by the network is ignored, the packet may be sent to an access network with poor quality of communication. 📉

4.4. Session Management 🎬

Say a node has selected an interface and managed to configure it, meaning it got a valid IP address from the network. But Internet connectivity still isn't available. That could be due to one of these reasons:

  1. The network requires web-based authentication (for example, the access network is a WiFi hot spot). In this case, the user can only reach a captive portal. For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has authenticated. 🔐
  2. The IP interface is configured as active, but Layer 2 is so poor (for example, bad radio conditions) that no Layer 3 traffic can succeed. 📶

In this situation, the session manager should be able to perform IP connectivity checks before selecting an interface. 🧐

Session issues can also show up when the node discovers a new provisioning domain. Picture a MIF node (M1) with an active interface (I1) connected to a network (N1), where an application is running a TCP session. Then a new network (N2) becomes available. If N2 gets selected (for example, because of better quality of communication), M1 gets IP connectivity to N2 and updates its routing table priority. So if there's no specific route to the correspondent node, and the node implements the weak host model [RFC1122], the TCP connection breaks as soon as the next hop changes. To keep talking to the correspondent node, M1 should try to reconnect to the server via N2. In some situations, it could be better to keep current sessions on N1 while new sessions start on N2. 🌈

4.5. Single Interface on Multiple Provisioning Domains ✨

okay so this one is lowkey the same drama as before but with one interface 🫠 when a node on a single interface connects to multiple networks, like different default routers, similar issues to the ones we just covered totally show up 💅 even with just one interface, a node might wanna connect to more than one provisioning domain. that means it can use more than one IP source address and have more than one default router 🌸 the node may want to reach services that only work through one specific provisioning domain. so it needs to use the right outgoing source address and the right default gateway to get there 🎀 and in that situation, the node may also need different DNS servers to resolve domain names from those different provisioning domains 🧚 it's giving multitasking chaos, bestie 😭

5. Underlying Problems and Causes

this section breaks down the underlying problems, and what causes them, that lead to the issues we just talked about 🦋 the problems fall into five categories: 1) configuration, 2) DNS resolution, 3) routing, 4) address selection, and 5) session management and APIs. here they are, bestie 💖

  1. Configuration. In a MIF context, configuration information specific to a provisioning domain may get ignored because:
    • A. Configuration objects (e.g., DNS servers, NTP servers) are node-scoped. So the IP stack can't keep track of which configuration goes with which provisioning domain 🙈
    • B. The same configuration objects (e.g., DNS server addresses, NTP server addresses) received from multiple provisioning domains may get overwritten 💀
    • C. Host implementations usually don't keep separate network configurations (such as DNS server addresses) for each provisioning domain 😭
  2. DNS resolution
    • A. Some FQDNs can only be resolved by sending queries to the right server (e.g., intranet services). But a DNS query could get sent to the wrong interface, because DNS server addresses may be node-scoped 🫶
    • B. A DNS answer may only be valid on one specific provisioning domain, but applications may not know about that mapping, because DNS answers may not be kept together with the provisioning they came from 🌈
  3. Routing
    • A. In the MIF context, routing information could be specific to each interface. This could cause routing issues, because in current node implementations, routing tables are node-scoped 🍓
    • B. Current node implementations don't take the Differentiated Services Code Point or path characteristics into account in the routing table 🌸
    • C. Even if implementations do take path characteristics into account, the node has no way to properly merge or reconcile provisioning domain preferences 🔥
    • D. A node attached to multiple provisioning domains could be handed incompatible selection policies. If the different actors (e.g., user and network operator) are allowed to provide their own policies, the node has no way to properly merge or reconcile multiple selection policies 👑
    • E. The problem of first-hop selection couldn't be solved through configuration (Section 3.7), and it may need to lean on sophisticated and specific mechanisms (Section 3.8) ✨
  4. Address selection
    • A. Default address selection policies may be specific to their corresponding provisioning domain. But a MIF node may not be able to manage address selection policies per provisioning domain, because default address selection policies are node-scoped 🧚
    • B. On a MIF node, some source addresses aren't valid if used on some interfaces, or even on some default routers on the same interface. In this situation, the source address should be taken into account in the routing table, but current node implementations don't support that feature 🙈
    • C. Source address or address selection policies could be specified by applications. However, there are no advanced APIs that support such applications 🥺
  5. Session management and APIs
    • A. Some implementations, especially in the mobile world, have higher-level APIs and/or session managers (aka connection managers) to address MIF issues. These mechanisms aren't standardized, and they don't necessarily behave the same way across different OSes and/or platforms when MIF problems show up. This lack of consistency is an issue for the user and operator, who could experience different session manager behaviors depending on the terminal 💅
    • B. Session managers usually lean on an interface to the link layer to gather information (e.g., lower-layer authentication and encryption methods) and/or for control purposes. But that link-layer interface may not provide all the services they need (e.g., it may not provide all the information that would allow a proper interface selection) 🫠
    • C. A MIF node can support different session managers, which may have contradictory ways of solving MIF issues. For instance, because of different selection algorithms, two session managers could pick different domains in the same context. Or, when dealing with different domain selection policies, one session manager may give precedence to user policy while another favors mobile operator policy 🍓
    • D. When host routing gets updated, and if the weak host model is supported, ongoing TCP sessions may break if routes change for those sessions. When TCP sessions should be bound to the interface, the strong host model should be used 🌈
    • E. When policies are provided by different actors (e.g., user, network, default OS), they may conflict and therefore need to be reconciled at the host level. Policy conflict resolution may impact other functions (e.g., naming, routing) 👑
    • F. Even if the node has managed to configure an interface, Internet connectivity could still be unavailable. This could be due to an access control function kicking in above Layer 3, or because of poor Layer 2 conditions. An IP connectivity check should be performed before selecting an interface 🫶

6. Security Considerations

okay this section is SERIOUS bestie, so read it carefully 😭🔥 the problems in this document have security implications, like when packets sent on the wrong interface might leak some confidential information 🙈 configuration parameters from one provisioning domain could cause a denial of service on another provisioning domain (e.g., DNS issues) 💀 and the undetermined behavior of IP stacks in the multihomed context brings extra threats, where an interface on a multihomed node might get used to launch attacks aimed at the networks connected through the other interfaces 🥺 > corrupted provisioning domain selection policy may induce a node to make decisions that cause certain traffic to be forwarded to the attacker 🚨

additional security concerns come up with possible future mechanisms that give the node more information, so it can make a smarter decision about the issues in this document ✨ those future mechanisms may themselves be vulnerable, and they may not be easy to protect in the general case 🫠 be careful out there, bestie 🦋

7. Contributors

this document is a joint effort with the authors of the MIF requirements document [MIF-REQ] 🫶 the contributors, in alphabetical order, are: Jacni Qin, Carl Williams, and Peng Yang 🌸

8. Acknowledgements

the documents written before the MIF working group existed, plus the discussions during the MIF Birds of a Feather (BOF) meeting and around the MIF charter scope on the mailing list, brought in really good input for the problem statement 💜 this document steals a lot of text from those discussions and initial documents (e.g., [MIF-REQ], [IP-MULTIPLE-CONN], [MIF-DNS-SERVER-SELECT]) 🙈 so the authors would like to thank the following people (in no specific order), whose text got borrowed: Jari Arkko, Keith Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis-Courmont, Alexandru Petrescu, Zhen Cao, Gaetan Feige, Telemaco Melia, and Juan-Carlos Zuniga 🎀 apologies to anyone who got accidentally left off the list 🥹💖

part 4 done, bestie! the MIF saga keeps going 🧚

9. Informative References ✨

okay bestie, this is the "for your reading list" pile 📚🫶 these ones are informative, so they're not part of the spec itself, but they're the receipts and background behind the whole thing. some are still drafts ("Work in Progress") and some are official RFCs, IEEE, and 3GPP stuff 💅

  • [ADDR-SELECT-SOL] Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution approaches for address-selection problems", Work in Progress, March 2010. 🌸
  • [DHCPv6-ROUTE-OPTIONS] Dec, W., Ed., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Route Options", Work in Progress, September 2011. 🎀
  • [IP-MULTIPLE-CONN] Hui, M. and H. Deng, "Problem Statement and Requirement of Simple IP Multi-homing of the Host", Work in Progress, March 2009. ✨
  • [LOGICAL-IF-SUPPORT] Melia, T., Ed., and S. Gundavelli, Ed., "Logical Interface Support for multi-mode IP Hosts", Work in Progress, October 2011. 🦋
  • [MIF-DNS-SERVER-SELECT] Savolainen, T., Kato, J., and T. Lemon, "Improved DNS Server Selection for Multi-Interfaced Nodes", Work in Progress, October 2011. 🧚
  • [MIF-REQ] Yang, P., Seite, P., Williams, C., and J. Qin, "Requirements on multiple Interface (MIF) of simple IP", Work in Progress, February 2009. 💜
  • [MIH] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std. 802.21-2008, January 2009. 📡
  • [REFERRAL-PS] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011. 🍓
  • [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 👑
  • [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, December 1989. 🌈
  • [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 💖
  • [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🫶
  • [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. ⭐
  • [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 🔥
  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. 🛡️
  • [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🎀
  • [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. 🦋
  • [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. ✨
  • [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 🌸
  • [RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006. 🧚
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 💜
  • [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. 📡
  • [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. 🍓
  • [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008. 👑
  • [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. 🌈
  • [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. 💖
  • [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Requirements for Address Selection Mechanisms", RFC 5221, July 2008. 🫶
  • [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. ⭐
  • [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. 🔥
  • [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. 🛡️
  • [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. 🎀
  • [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. 🦋
  • [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. ✨
  • [RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011. 🌸
  • [RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011. 🧚
  • [SHIM6-APP-REFER] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005. 💜
  • [TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking", TS 23.234, December 2009. 📡
  • [TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", TS 23.402, December 2010. 🍓

Authors' Addresses 💌

Marc Blanchet is at Viagenie, and this is where you find them 🌷

Marc Blanchet
Viagenie
2875 boul. Laurier, suite D2-630
Quebec, QC  G1V 2M2
Canada

EMail: Marc.Blanchet@viagenie.ca
URI:   http://viagenie.ca

Pierrick Seite is at France Telecom - Orange, and here's the info for them too 🫶

Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne  35512
France

EMail: pierrick.seite@orange.com

and that's the whole document, bestie!! 🌈🎉 ✨

📦 where this page comes from