summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6418.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6418.txt')
-rw-r--r--doc/rfc/rfc6418.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc6418.txt b/doc/rfc/rfc6418.txt
new file mode 100644
index 0000000..9dcdf90
--- /dev/null
+++ b/doc/rfc/rfc6418.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Blanchet
+Request for Comments: 6418 Viagenie
+Category: Informational P. Seite
+ISSN: 2070-1721 France Telecom - Orange
+ November 2011
+
+
+ Multiple Interfaces and Provisioning Domains Problem Statement
+
+Abstract
+
+ This document describes issues encountered by a node attached to
+ multiple provisioning domains. This node receives configuration
+ information from each of its provisioning domains, where some
+ configuration objects are global to the node and others are local to
+ the interface. Issues such as selecting the wrong interface to send
+ traffic happen when conflicting node-scoped configuration objects are
+ received and inappropriately used. Moreover, other issues are the
+ result of simultaneous attachment to multiple networks, such as
+ domain selection or addressing and naming space overlaps, regardless
+ of the provisioning mechanism. While multiple provisioning domains
+ are typically seen on nodes with multiple interfaces, this document
+ also discusses situations involving single-interface nodes.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6418.
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 1]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+Copyright Notice
+
+ 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) 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 ....................................................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
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 2]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+1. Introduction
+
+ A multihomed node may have multiple provisioning domains (via
+ physical and/or virtual interfaces). For example, a node may be
+ simultaneously connected to a wired Ethernet LAN, an 802.11 LAN, a 3G
+ cell network, one or multiple VPN connections, or one or multiple
+ tunnels (automatic or manual). Current laptops and smartphones
+ typically have multiple access network interfaces and, thus, are
+ often connected to different provisioning domains.
+
+ A multihomed node receives configuration information from each of its
+ attached networks, through various mechanisms such as DHCPv4
+ [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661], and IPv6 Router
+ Advertisements [RFC4861]. Some received configuration objects are
+ specific to an interface, such as the IP address and the link prefix.
+ Others are typically considered by implementations as being global to
+ the node, such as the routing information (e.g., default gateway),
+ DNS server IP addresses, and address selection policies, herein
+ referred to as "node-scoped".
+
+ When the received node-scoped configuration objects have different
+ values from each provisioning domain, such as different DNS server IP
+ addresses, different default gateways, or different address selection
+ policies, the node has to decide which one to use or how it will
+ merge them.
+
+ Other issues are the result of simultaneous attachment to multiple
+ networks, such as addressing and naming space overlaps, regardless of
+ the provisioning mechanism.
+
+ The following sections define the multiple interfaces (MIF) node and
+ the scope of this work, describe related work, list issues, and then
+ summarize the underlying problems.
+
+ A companion document, [RFC6419], discusses some current practices of
+ various implementations dealing with MIF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 3]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+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 (e.g., default
+ router, network prefixes, DNS) and the corresponding interface.
+ One administrative domain may have multiple provisioning domains.
+ Successful attachment to the provisioning domain implies that the
+ terminal attaches to the corresponding interface with appropriate
+ configuration information.
+
+ Reference to IP version
+
+ When a protocol keyword such as IP, PPP, or DHCP is used in this
+ document without any reference to a specific IP version, then it
+ implies both IPv4 and IPv6. A specific IP version keyword such as
+ DHCPv4 or DHCPv6 is meant to be specific to that IP version.
+
+3. Scope and Existing Work
+
+ This section describes existing related work and defines the scope of
+ the problem.
+
+3.1. Interactions Below IP
+
+ Some types of interfaces have link-layer characteristics that may be
+ used in determining how multiple provisioning domain issues will be
+ dealt with. For instance, link layers may have authentication and
+ encryption characteristics that could be used as criteria for
+ interface selection. However, network discovery and selection on
+ lower layers as defined by [RFC5113] is out of scope of this
+ document. Moreover, interoperability with lower-layer mechanisms
+ such as services defined in IEEE 802.21, which aims at facilitating
+ handover between heterogeneous networks [MIH], is also out of scope.
+
+ Some mechanisms (e.g., based on a virtual IP interface) allow sharing
+ a single IP address over multiple interfaces to networks with
+ disparate access technologies. From the IP-stack view on the node,
+ there is only a single interface and single IP address. Therefore,
+ this situation is out of scope of this problem statement.
+ Furthermore, link aggregation done under IP where a single interface
+ is shown to the IP stack is also out of scope.
+
+
+
+
+Blanchet & Seite Informational [Page 4]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+3.2. MIF Node Characterization
+
+ A MIF node has the following characteristics:
+
+ o A MIF node is an [RFC1122] IPv4- and/or [RFC4294] IPv6-compliant
+ node.
+
+ o A MIF node is configured with more than one IP address (excluding
+ loopback and link-local).
+
+ o A MIF node can attach to more than one provisioning domain, as
+ presented to the IP stack.
+
+ o The interfaces may be virtual or physical.
+
+ o Configuration objects come from one or more administrative
+ domains.
+
+ o The IP addresses may be from the same or different address
+ families, such as IPv4 and IPv6.
+
+ o Communications using these IP addresses may happen simultaneously
+ and independently.
+
+ o 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.
+
+ o While the MIF node may forward packets between its interfaces, the
+ forwarding of packets 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 if it has multiple IP addresses,
+ which may be associated with one or more physical interfaces
+ connected to the same or different networks.
+
+ Section 3.3.1.3 of [RFC1122] states that the node maintains a route
+ cache table where each entry contains the local IP address, the
+ destination IP address, Type(s) of Service (superseded by the
+ Differentiated Services Code Point [RFC2474]), and the next-hop
+ gateway IP address. The route cache entry would have data about the
+ properties of the path, such as the average round-trip delay measured
+ by a transport protocol. Nowadays, implementations are not caching
+ this information.
+
+
+
+
+Blanchet & Seite Informational [Page 5]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ [RFC1122] defines two host models:
+
+ o 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.
+
+ o 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.
+
+ The multihomed node computes routes for outgoing datagrams
+ differently, depending on the model. Under the strong model, the
+ route is computed based on the source IP address, the destination IP
+ address, and the Differentiated Services Code Point. Under the weak
+ model, the source IP address is not used; only the destination IP
+ address and the Differentiated Services Code Point are used.
+
+3.4. Mobility and Other IP Protocols
+
+ The scope of this document is only about nodes implementing [RFC1122]
+ for IPv4 and [RFC4294] for IPv6 without additional features or
+ special-purpose support for transport layers, mobility, multihoming,
+ or identifier-locator split mechanisms. Dealing with multiple
+ interfaces with such mechanisms is related but considered as a
+ separate problem and is under active study elsewhere in the IETF
+ [RFC4960] [RFC5206] [RFC5533] [RFC5648] [RFC6182].
+
+ When an application is using one interface while another interface
+ with better characteristics becomes available, the ongoing
+ application session could be transferred to the newly enabled
+ interface. However, in some cases, the ongoing session shall be kept
+ on the current interface while initiating the new session on the new
+ interface. The problem of interface selection is within the MIF
+ scope and may leverage specific node functions (Section 3.8).
+ However, if transfer of an IP session is required, IP mobility
+ mechanisms, such as [RFC6275], shall be used.
+
+3.5. Address Selection
+
+ "Default Address Selection for Internet Protocol version 6 (IPv6)"
+ [RFC3484] defines algorithms for source and destination IP address
+ selections. Default address selection as defined in [RFC3484] is
+ mandatory to implement in IPv6 nodes, which also means dual-stack
+ nodes. A node-scoped policy table managed by the IP stack is
+ defined. Mechanisms to update the policy table are defined in
+ [ADDR-SELECT-SOL].
+
+
+
+
+Blanchet & Seite Informational [Page 6]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ Issues on using default address selection were found in [RFC5220] and
+ [RFC5221] in the context of multiple prefixes on the same link.
+
+3.6. Finding and Sharing IP Addresses with Peers
+
+ Interactive Connectivity Establishment (ICE) [RFC5245] is a technique
+ for NAT traversal for UDP-based (and TCP-based) media streams
+ established by the offer/answer model. The multiplicity of IP
+ addresses, ports, and transport mechanisms in Session Description
+ Protocol (SDP) offers are tested for connectivity by peer-to-peer
+ connectivity checks. The result is candidate IP addresses and ports
+ for establishing a connection with the other peer. However, ICE does
+ not solve issues 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 instance,
+ applications can provide reachability information to themselves or to
+ a third party. The general problem of referrals is related to the
+ multiple-interface problem, since, 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 simultaneously handle multiple domains
+ with disparate characteristics, especially when 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 available; otherwise, the
+ application does not start. However, if the application can be run
+ on several provisioning domains, the selection problem can be
+ difficult.
+
+ There is no standard method for selecting a provisioning domain, but
+ some recommendations exist while restricting the scope to the
+ interface selection problem. For example, [TS23.234] proposes a
+ default mechanism for the interface selection. This method uses the
+ following information (non-exhaustive list):
+
+ o preferences provided by the user
+
+ o policies provided by the network operator
+
+ o quality of the radio link
+
+
+
+
+
+Blanchet & Seite Informational [Page 7]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ o network resource considerations (e.g., available Quality of
+ Service (QoS), IP connectivity check)
+
+ o the application QoS requirements in order to map applications to
+ the best interface
+
+ However, [TS23.234] is designed for a specific multiple-interfaces
+ use case. A generic way to handle 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 issues brought by simultaneous attachment to multiple
+ provisioning domains. Typically, the session manager may deal with
+ the selection of the interface, and/or the provisioning domain, on
+ behalf of the applications, or tackle complex issues such as how to
+ resolve conflicting policies (Section 4.3). As discussed in
+ Section 3.7, the session manager may encounter difficulties because
+ of multiple and diverse criteria.
+
+ Session managers usually leverage the link-layer interface to gather
+ information (e.g., lower-layer authentication and encryption methods;
+ see Section 3.1) and/or for control purposes. Such a link-layer
+ interface may not provide all required services to make a proper
+ decision (e.g., interface selection). Some OSes or 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.
+
+ Management of 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 allows a multiple-interface node sharing a set of IP
+ addresses on multiple physical interfaces and can also add benefits
+ to multi-access scenarios such as 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 one of these virtual and physical
+ interfaces, as well as the mapping between the virtual and
+ sub-interfaces.
+
+
+
+
+
+Blanchet & Seite Informational [Page 8]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ In a situation involving multiple interfaces, active application
+ sessions should survive path failures. Here, the session manager may
+ come into play but only relying on existing mechanisms to manage
+ multipath TCP (MPTCP) [RFC6182] or failover (Mobile IPv6 (MIP6)
+ [RFC6275], Shim6 [RFC5533]). A description of the interaction
+ between these mechanisms and the session manager is out of scope of
+ this document.
+
+3.9. Sockets API
+
+ An Application Programming Interface (API) may expose objects that
+ user applications or session managers use for dealing with multiple
+ interfaces. For example, [RFC3542] defines how an application using
+ the advanced sockets API specifies 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, by defining a sockets API enabling interactions between
+ applications and the multihoming shim layer for advanced locator
+ management, and access to information about failure detection and
+ path exploration.
+
+4. MIF Issues
+
+ This section describes the various issues 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
+
+ A MIF node (M1) has an active interface (I1) connected to a network
+ (N1), which has its DNS servers (S1 as primary DNS server) and
+ another active interface (I2) connected to a network (N2), which has
+ its DNS servers (S2 as primary DNS server). S1 serves some private
+
+
+
+
+
+Blanchet & Seite Informational [Page 9]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ namespace, "private.example.com". The user or the application uses a
+ name "a.private.example.com", which is within the private namespace
+ of S1 and only resolvable by S1. Any of the following situations may
+ occur:
+
+ 1. The M1 stack, based on its routing table, uses I2 to reach S1 to
+ resolve "a.private.example.com". M1 never reaches S1. The name
+ is not resolved.
+
+ 2. M1 keeps only one set of DNS server addresses from the received
+ configuration objects. Let us assume that M1 keeps S2's address
+ as the primary DNS server. M1 sends the forward DNS query for
+ a.private.example.com to S2. S2 responds with an error for a
+ nonexistent domain (NXDOMAIN). The name is not resolved. This
+ issue also arises when performing a reverse DNS lookup. In the
+ same situation, the reverse DNS query fails.
+
+ 3. M1 keeps only one set of DNS server addresses from the received
+ configuration objects. Let us assume that M1 keeps S2's address.
+ M1 sends the DNS query for a.private.example.com to S2. S2
+ queries its upstream DNS and gets an IP address for
+ a.private.example.com. However, the IP address is not the same
+ one that S1 would have given. Therefore, the application tries
+ to connect to the wrong destination node, or to the wrong
+ interface, which may imply security issues or result in lack of
+ service.
+
+ 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 addresses overlap, traffic may be sent using the
+ wrong interface. This issue is not related to receiving multiple
+ configuration objects, but to an address overlap between
+ interfaces or attaching networks.
+
+ 5. M1 has resolved a Fully Qualified Domain Name (FQDN) to a locally
+ valid IP address when connected to N1. If the node loses
+ connection to N1, the node may try to connect, via N2, to the
+ same IP address as earlier, but as the address was only locally
+ valid, connection setup fails. Similarly, M1 may have received
+ NXDOMAIN for an FQDN when connected to N1. After detachment from
+ N1, the node should not assume the FQDN continues to be
+ nonexistent on N2.
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 10]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ 6. M1 requests a AAAA record from a DNS server on a network that
+ uses protocol translators and DNS64 [RFC6147]. If M1 receives a
+ synthesized AAAA record, it is guaranteed to be valid only on the
+ network from which it was learned. If M1 uses synthesized AAAA
+ on any other network interface, traffic may be lost, dropped, or
+ forwarded to the wrong network.
+
+ Some networks require the user to authenticate on a captive web
+ portal before providing Internet connectivity. If this redirection
+ is achieved by modifying the DNS reply, specific issues may occur.
+ Consider a MIF node (M1) with an active interface (I1) connected to a
+ network (N1), which has its DNS server (S1), and another active
+ interface (I2) connected to a network (N2), which has its DNS server
+ (S2). Until the user has not authenticated, S1 is configured to
+ respond to any A or AAAA record query with the IP address of a
+ captive portal, so as to redirect web browsers to an access control
+ portal web page. This captive portal can be reached only via I1.
+ When the user has authenticated to the captive portal, M1 can resolve
+ an FQDN when connected to N1. However, if the address is only
+ locally valid on N1, any of the issues described above may occur.
+ When the user has not authenticated, any of the following situations
+ may occur:
+
+ 1. M1 keeps only one set of DNS server addresses from the received
+ configuration objects and kept S2 address. M1 sends the forward
+ DNS query for a.example.com to S2. S2 responds with the correct
+ answer, R1. M1 attempts to contact R1 by way of I1. The
+ connection fails. Or, the connection succeeds, bypassing the
+ security policy on N1, possibly exposing the owner of M1 to
+ prosecution.
+
+ 2. M1 keeps only one set of DNS server addresses from the received
+ configuration objects and kept S1 address. M1 sends the DNS
+ query for a.example.com to S1. S1 provides the address of its
+ captive portal. M1 attempts to contact this IP address using I1.
+ The application fails to connect, resulting in lack of service.
+ Or, the application succeeds in connecting but connects to the
+ captive portal rather than the intended destination, resulting in
+ lack of service (i.e., an IP connectivity check issue, as
+ described in Section 4.4).
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 11]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+4.2. Node Routing
+
+ Consider 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 by N2, IP1 is never reached or is not the right
+ target.
+
+ 2. For the IP1 address family, M1 has one default route (R1, R2) per
+ network (N1, N2). IP1 is reachable by both networks, but the N2
+ path has better characteristics, such as better round-trip time,
+ least cost, better bandwidth, etc. 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
+ 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 by N2 only, but the prefix (X.0.0.0/8) is used in
+ both networks. Because of the most specific route R1B, 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 does not have any hint concerning which interface would
+ be the best to use for that destination. The first-hop selection may
+ leverage on local routing policy, allowing some actors (e.g., network
+ operator or service provider) to influence the routing table, i.e.,
+ make a decision regarding which interface to use. For instance, a
+ user on such a multihomed node might want a local policy to influence
+ which interface will be used based on various conditions. Some
+ Standards Development Organizations (SDOs) have defined policy-based
+ routing selection mechanisms. For instance, the Access Network
+ Discovery and Selection Function (ANDSF) [TS23.402] provides
+ inter-system routing policies to terminals with both a 3GPP interface
+ and non-3GPP interfaces. However, the routing selection may still be
+ difficult, due to disjoint criteria as discussed in Section 3.8.
+ Moreover, information required to make the right decision may not be
+ available. For instance, interfaces to a lower layer may not provide
+ all required hints concerning the selection (e.g., information on
+ interface quality).
+
+
+
+
+Blanchet & Seite Informational [Page 12]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ A node usually has a node-scoped routing table. However, a MIF node
+ is connected to multiple provisioning domains; if each of these
+ domains pushes routing policies to the node, then conflicts between
+ policies may happen, and the node has no easy way to merge or
+ reconcile them.
+
+ On a MIF node, some source addresses are not valid if used on some
+ interfaces. For example, an [RFC1918] source address might be
+ appropriate on the VPN interface but not on the public interface of
+ the MIF node. If the source address is not chosen appropriately,
+ then packets may be filtered in the path if source address filtering
+ is in place ([RFC2827], [RFC3704]), and reply packets may never come
+ back to the source.
+
+4.3. Conflicting Policies
+
+ The distribution of configuration policies (e.g., address selection,
+ routing, DNS selection) to end nodes is being discussed (e.g., ANDSF
+ in [TS23.402], [DHCPv6-ROUTE-OPTIONS]). If implemented in multiple
+ provisioning domains, such mechanisms may conflict and create issues
+ for the multihomed node. Considering 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 from both networks (N1 and N2) an update of its
+ default address selection policy. However, the policies are
+ specific to each network. The policies are merged by the M1
+ stack. Based on the merged policy, the chosen source address is
+ from N1, but packets are sent to N2. The source address is not
+ reachable from N2; therefore, the return packet is lost. Merging
+ address selection policies may have important impacts on routing.
+
+ 2. A node usually has a node-scoped routing table. However, each of
+ the connected provisioning domains (N1 and N2) may push routing
+ policies to the node; conflicts between policies may then happen,
+ and the node has no easy way to merge or reconcile them.
+
+ 3. M1 receives from one of the networks an update of its access
+ selection policy, e.g., via the 3GPP/ANDSF [TS23.402]. However,
+ the policy is in conflict with the local policy (e.g., user-
+ defined or default OS policy). Assuming that 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.
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 13]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+4.4. Session Management
+
+ Consider that a node has selected an interface and managed to
+ configure it (i.e., the node obtained a valid IP address from the
+ network). However, Internet connectivity is not available. The
+ problem could be due to the following reasons:
+
+ 1. The network requires a web-based authentication (e.g., the access
+ network is a WiFi hot spot). In this case, the user can only
+ access a captive portal. For instance, the network may perform
+ HTTP redirection or modify DNS behavior (Section 4.1) until the
+ user has not authenticated.
+
+ 2. The IP interface is configured as active, but Layer 2 is so poor
+ (e.g., poor radio condition) 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 may also arise when the node discovers a new
+ provisioning domain. Consider a MIF node (M1) with an active
+ interface (I1) connected to a network (N1) where an application is
+ running a TCP session. A new network (N2) becomes available. If N2
+ is selected (e.g., because of better quality of communication), M1
+ gets IP connectivity to N2 and updates the routing table priority.
+ So, if no specific route to the correspondent node is in place, and
+ if the node implements the weak host model [RFC1122], the TCP
+ connection breaks as the next hop changes. In order to continue
+ communicating with the correspondent node, M1 should try to reconnect
+ to the server via N2. In some situations, it could be preferable to
+ maintain current sessions on N1 while new sessions start on N2.
+
+4.5. Single Interface on Multiple Provisioning Domains
+
+ When a node using a single interface is connected to multiple
+ networks, such as different default routers, similar issues to those
+ described above will happen. Even with a single interface, a node
+ may wish to connect to more than one provisioning domain: that node
+ may use more than one IP source address and may have more than one
+ default router. The node may want to access services that can only
+ be reached using one of the provisioning domains. In this case, it
+ needs to use the right outgoing source address and default gateway to
+ reach that service. In this situation, that node may also need to
+ use different DNS servers to get domain names in those different
+ provisioning domains.
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 14]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+5. Underlying Problems and Causes
+
+ This section lists the underlying problems, and their causes, that
+ lead to the issues discussed in the previous section. The problems
+ can be divided into five categories: 1) configuration, 2) DNS
+ resolution, 3) routing, 4) address selection, and 5) session
+ management and APIs. They are shown below:
+
+ 1. Configuration. In a MIF context, configuration information
+ specific to a provisioning domain may be ignored because:
+
+ A. Configuration objects (e.g., DNS servers, NTP servers) are
+ node-scoped. So, the IP stack is not able to maintain the
+ mapping between configuration information and the
+ corresponding provisioning domain.
+
+ B. The same configuration objects (e.g., DNS server addresses,
+ NTP server addresses) received from multiple provisioning
+ domains may be overwritten.
+
+ C. Host implementations usually do not keep separate network
+ configurations (such as DNS server addresses) per
+ provisioning domain.
+
+ 2. DNS resolution
+
+ A. Some FQDNs can be resolvable only by sending queries to the
+ right server (e.g., intranet services). However, a DNS query
+ could be sent to the wrong interface because DNS server
+ addresses may be node-scoped.
+
+ B. A DNS answer may be only valid on a specific provisioning
+ domain, but applications may not be aware of that mapping
+ because DNS answers may not be kept with the provisioning
+ from which the answer comes.
+
+ 3. Routing
+
+ A. In the MIF context, routing information could be specific to
+ each interface. This could lead to routing issues because,
+ in current node implementations, routing tables are node-
+ scoped.
+
+ B. Current node implementations do not take into account the
+ Differentiated Services Code Point or path characteristics in
+ the routing table.
+
+
+
+
+
+Blanchet & Seite Informational [Page 15]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ C. Even if implementations take into account path
+ characteristics, the node has no way to properly merge or
+ reconcile the provisioning domain preferences.
+
+ D. A node attached to multiple provisioning domains could be
+ provided with 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 could not be solved via
+ configuration (Section 3.7), and may leverage on
+ sophisticated and specific mechanisms (Section 3.8).
+
+ 4. Address selection
+
+ A. Default address selection policies may be specific to their
+ corresponding provisioning domain. However, 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 are not 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 do not support such a 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 are not
+ standardized and do not necessarily behave the same way
+ across different OSes and/or platforms in the presence of MIF
+ problems. This lack of consistency is an issue for the user
+ and operator, who could experience different session manager
+ behaviors, depending on the terminal.
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 16]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ B. Session managers usually leverage on an interface to the link
+ layer to gather information (e.g., lower-layer authentication
+ and encryption methods) and/or for control purposes.
+ However, such a link-layer interface may not provide all
+ required services (e.g., may not provide all 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 different
+ session managers could select 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 could favor mobile operator policy.
+
+ D. When host routing is updated and if the weak host model is
+ supported, ongoing TCP sessions may break if routes change
+ for these sessions. When TCP sessions should be bound to the
+ interface, the strong host model should be used.
+
+ E. When provided by different actors (e.g., user, network,
+ default OS), policies may conflict and, thus, 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 be unavailable. This could be
+ due to an access control function coming into play above
+ Layer 3, or because of poor Layer 2 conditions. An IP
+ connectivity check should be performed before selecting an
+ interface.
+
+6. Security Considerations
+
+ The problems discussed in this document have security implications,
+ such as when packets sent on the wrong interface might be leaking
+ some confidential information. Configuration parameters from one
+ provisioning domain could cause a denial of service on another
+ provisioning domain (e.g., DNS issues). Moreover, the undetermined
+ behavior of IP stacks in the multihomed context brings additional
+ threats where an interface on a multihomed node might be used to
+ conduct attacks targeted to the networks connected by the other
+ interfaces. Corrupted provisioning domain selection policy may
+ induce a node to make decisions causing certain traffic to be
+ forwarded to the attacker.
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 17]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ Additional security concerns are raised by possible future mechanisms
+ that provide additional information to the node so that it can make a
+ more intelligent decision with regards to the issues discussed in
+ this document. Such future mechanisms may themselves be vulnerable
+ and may not be easy to protect in the general case.
+
+7. Contributors
+
+ This document is a joint effort with the authors of the MIF
+ requirements document [MIF-REQ]. This includes, in alphabetical
+ order: Jacni Qin, Carl Williams, and Peng Yang.
+
+8. Acknowledgements
+
+ The documents written prior to the existence of the MIF working
+ group, and the discussions during the MIF Birds of a Feather (BOF)
+ meeting and around the MIF charter scope on the mailing list, brought
+ very good input to the problem statement. This document steals a lot
+ of text from these discussions and initial documents (e.g.,
+ [MIF-REQ], [IP-MULTIPLE-CONN], [MIF-DNS-SERVER-SELECT]). Therefore,
+ the authors would like to acknowledge the following people (in no
+ specific order), from whom some text has been taken: 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 any contributors who have
+ inadvertently not been named.
+
+9. Informative References
+
+ [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.
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 18]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ [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.
+
+
+
+
+Blanchet & Seite Informational [Page 19]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ [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.
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 20]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 21]
+
+RFC 6418 Multiple Interfaces Problem Statement November 2011
+
+
+Authors' Addresses
+
+ 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
+ France Telecom - Orange
+ 4, rue du Clos Courtel, BP 91226
+ Cesson-Sevigne 35512
+ France
+
+ EMail: pierrick.seite@orange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Seite Informational [Page 22]
+