One document matched: draft-ietf-mif-problem-statement-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-ietf-mif-problem-statement-08.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="Multiple Interfaces Problem Statement"> Multiple Interfaces and Provisioning Domains Problem Statement</title>
<author initials="M." surname="Blanchet" fullname="Marc Blanchet">
<organization>Viagenie</organization>
<address>
<postal>
<street>2875 boul. Laurier, suite D2-630</street>
<city>Quebec</city>
<region>QC</region>
<code>G1V 2M2</code>
<country>Canada</country>
</postal>
<email>Marc.Blanchet@viagenie.ca</email>
<uri>http://viagenie.ca</uri>
</address>
</author>
<author initials="P." surname="Seite" fullname="Pierrick Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange-ftgroup.com</email>
</address>
</author>
<date month="October" year="2010"/>
<abstract>
<t>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, others are local to the interface. Issues such as
selecting the wrong interface to send trafic happen when conflicting node-scoped configuration
objects are received and inappropriately used. Moreover, other issues are the result of simulatenous
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 single interface nodes situation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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, a 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.</t>
<t> A multihomed node receives configuration information from each of its attached networks, through various mechanisms such as DHCPv4 <xref target="RFC2131"/>, DHCPv6 <xref target="RFC3315"/>, PPP <xref target="RFC1661"/> and IPv6 Router Advertisements <xref target="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 servers IP addresses, and address selection policies, herein named "node-scoped".</t>
<t>When the received node-scoped configuration objects have different values from each provisioning domains, such as different DNS servers IP addresses, different default gateways or different address selection policies, the node has to decidewhich one to use or how it will merge them.</t>
<t>Other issues are the result of simulatenous attachment to multiple networks, such as addressing and naming space overlaps, regardless of the provisioning mechanism.</t>
<t> The following sections define the multiple interfaces (MIF) node, the scope of this work, describe related work, list issues and then summarize the underlying problems.</t>
<t> A companion document <xref target="I-D.ietf-mif-current-practices"/> discusses some current practices of various implementations dealing with MIF.</t>
</section>
<section title="Terminology">
<t>
Administrative domain
<vspace blankLines="1" />
<list style='empty'>
<t> A group of hosts, routers, and networks operated and managed by a single organization <xref target="RFC1136"/>.</t>
</list>
</t>
<t>
Provisioning domain
<vspace blankLines="1" />
<list style='empty'>
<t>A set of consistent configuration information (e.g. Default router, Network prefixes, DNS,...). One administrative domain may have multiple provisioning domains.</t>
</list>
</t>
<t>
Reference to IP version
<vspace blankLines="1" />
<list style='empty'>
<t>When a protocol keyword such as IP, PPP, 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.
</t>
</list>
</t>
</section>
<section title="Scope and Existing Work">
<t> This section describes existing related work and defines the scope of the problem. </t>
<section title="Below IP Interaction">
<t>Some types of interfaces have link layer characteristics which may be used in determining how
multiple provisioning domain issues will be dealt with. For instance, link layers may have
authentication and encryption characteristics which could be used as criteria for interface selection.
However, network discovery and selection on lower layers as defined by <xref target="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 <xref target="802.21"/>, is also out of scope.</t>
<t> Some mechanisms (e.g., based on a logical IP interface) allow sharing a single IP address over multiple interfaces to networks with disparate access techologies. 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 current problem statement. Furthermore, link aggregation done under IP where a single interface is shown to the IP stack is also out of scope. </t>
</section>
<section title="MIF node Characterization">
<t>
A MIF node has the following characteristics:
<vspace blankLines="1" />
<list style='symbols'>
<t>A <xref target="RFC1122"/> IPv4 and/or <xref target="RFC4294"/> IPv6 compliant node</t>
<t>A MIF node is configured with more than one IP addresses (excluding loopback and link-local)</t>
<t>A MIF node can attach to more than one provisioning domains, as presented to the IP stack. </t>
<t>The interfaces may be logical, virtual or physical. </t>
<t>Configuration objects come from one or more administrative domains.</t>
<t>The IP addresses may be from the same or from different address families, such as IPv4 and IPv6. </t>
<t>Communications using these IP addresses may happen simultaneously and independently.</t>
<t>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.</t>
<t>While the MIF node may forward packets between its interfaces, forwarding packets is not taken into account in this definition and is out of scope for this document.</t>
</list>
</t>
</section>
<section title="Hosts Requirements">
<t>The requirements for Internet Hosts <xref target="RFC1122"/> describe 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.</t>
<t>The requirements states that The node maintains a route cache table where each entry contains the local IP address, the destination IP address, Type-of-Service and 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 these informations. </t>
<t>
<xref target="RFC1122"/> defines two host models:
<list style='symbols'>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t> 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 Type-of-Service. Under the weak model, the source IP address is not used, but only the destination IP address and the Type-of-Service.</t>
</section>
<section title="Mobility and other IP protocols">
<t>
The scope of this document is only about nodes implementing <xref target="RFC1122"/> for IPv4 and <xref target="RFC4294"/> for IPv6 without additional features or special-purpose support for transport layers, mobility, multi-homing, 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 <xref target="RFC4960"/>, <xref target="RFC5206"/>, <xref target="RFC5533"/>, <xref target="RFC5648"/>, <xref target="I-D.ietf-mptcp-architecture"/>.</t>
<t>
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 sessions on the new interface. The problem of the interface selection is within the MIF scope and may leverage specific node functions (<xref target="CM"/>). However, if transfer of IP session is required, IP mobility mechanisms, such as [RFC3775], shall be used.</t>
</section>
<section title="Address Selection">
<t> The Default Address Selection specification <xref target="RFC3484"/> defines algorithms for source and destination IP address selections. It is mandatory to be implemented 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 being defined <xref target="I-D.ietf-6man-addr-select-sol"/> to update the policy table.</t>
<t>Issues on using the Default Address Selection were found in <xref target="RFC5220"/> and <xref target="RFC5221"/> in the context of multiple prefixes on the same link.</t>
</section>
<section title="Finding and Sharing IP Addresses with Peers">
<t> Interactive Connectivity Establishment (<xref target="RFC5245">ICE</xref>) is a technique for NAT traversal for UDP-based (and TCP) media streams established by the offer/answer model. The multiplicity of IP addresses, ports and transport in 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. </t>
<t> Some application protocols do referrals of IP addresses, port numbers and transport for further exchanges. For instance, applications can provide reachability information to itself 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 <xref target="I-D.carpenter-behave-referral-object"/> and <xref target="I-D.ietf-shim6-app-refer"/>.
</t>
</section>
<section title="Interface and Provisioning domain selection" anchor = "INTF-SEL">
<t> In a MIF context, the node may handle simultaneously 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 is difficult. </t>
<t>For example, the interface selection mechanism defined in <xref target="TS23.234"/> uses the following information:
<vspace blankLines="1" />
<list style="symbols">
<t>preferences provided by the user,</t>
<t>policies provided by network operator,</t>
<t>quality of the radio link,</t>
<t>network resource considerations (e.g. available QoS, IP connectivity check,...),</t>
<t>the application QoS requirements in order to map applications to the best interface</t>
<t>and so on...</t>
</list>
</t>
<t> However, <xref target="TS23.234"/> is designed for a specific multiple-interfaces use-case. A generic way to handle these characteristics is yet to be defined.</t>
</section>
<section title="Connection manager" anchor = "CM">
<t> Some implementations, specially in the mobile world, rely on higher-level connection managers to deal with issues brought by multiple provisioning domains. Typically, the connection manager manages the interface and provisioning domain selection on behalf of applications. As discussed previously in <xref target="INTF-SEL"/>, the connection manager has the same issues to making decisions in the general way in front of multiple and diverse criteria.</t>
<t>Connection managers usually leverage the link-layer interface to gather information and/or for control purpose. Such link-layer interface may not provide all required services to make a proper decision (e.g. interface selection). Some connection managers use specific MIF socket API (<xref target="API"/>) available in some vendor-specific platforms. The connection manager generic architecture and requirements are not currently standardized. Known connection managers behaviors have been documented in <xref target="I-D.ietf-mif-current-practices"/>.
</t>
</section>
<section title="Socket API" anchor = "API">
<t> An Application Programming Interface (API) may expose objects that user applications, or connection managers, use for dealing with multiple interfaces. For example, <xref target="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.</t>
<t>Other APIs have been defined to solve similar issues to MIF.<xref target="RFC5014"/> defines an API to influence the default address selection mechanism by specifying attributes of the source addresses it prefers. <xref target="I-D.ietf-shim6-multihome-shim-api"/> gives another example in a multihoming context, by defining a socket API enabling interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.</t>
</section>
</section>
<section title="MIF Issues">
<t>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 results in addressing or naming space overlaps. They occur, for example, when:
<vspace blankLines="1" />
<list style="numbers">
<t>one interface is on the Internet and one is on a corporate private network. The latter may be through VPN.</t>
<t>one interface is on one access network (i.e. wifi) and the other one is on another access network (3G) with specific services.</t>
</list>
</t>
<section title="DNS resolution issues">
<t>A MIF node (M1) has 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). S1 serves with some private 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:
<vspace blankLines="1" />
<list style="numbers">
<t>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.</t>
<t>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.private.example.com to S2. S2 responds with an error for an non-existent domain (NXDOMAIN). The name is not resolved. This issue also arises when performing reverse DNS lookup. In the same situation, the reverse DNS query fails.</t>
<t>M1 keeps only one set of DNS server addresses from the received configuration objects and kept S2 address. M1 sends the DNS query for a.private.example.com to S2. S2 asks its upstream DNS and gets an IP address for a.private.example.com. However, the IP address is not the same one S1 would have given. Therefore, the application tries to connect to the wrong destination node, or to the wrong interface of the latter, which may imply security issues or result in lack of service.</t>
<t>S1 or S2 has been used to resolve "a.private.example.com" to an <xref target="RFC1918"/> address. Both N1 and N2 are <xref target="RFC1918"/> addressed networks. 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.</t>
<t>M1 has resolved an FQDN to locally valid IP address when connected to N1. If the node looses 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.</t>
<t>M1 requests AAAA record from a DNS server on a network that uses protocol translators and DNS64 <xref target="I-D.ietf-behave-dns64"/>. If the M1 receives synthesized AAAA record, it is guaranteed to be valid only on the network it was learned from. If the M1 uses synthesized AAAA on any other network interface, traffic may be lost, dropped or forwarded to the wrong network.</t>
</list>
</t>
</section>
<section title="Routing">
<t> A MIF node (M1) has 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:
<vspace blankLines="1" />
<list style='numbers'>
<t>For IP1, M1 has one default route (R1) via network (N1). To reach IP1, 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.</t>
<t>For the IP1 address family, M1 has one default route (R1, R2) per network (N1, N2). IP1 is reachable by both networks, but N2 path has better characteristics, such as better round-trip time, least cost, better bandwidth, etc.... These preferences could be defined by user, provisioned by the network operator, or else. M1 stack uses R1 and tries to send through I1. IP1 is reached but the service would be better by I2.
</t>
<t>For the IP1 address family, M1 has a default route (R1), a specific X.0.0.0/8 route R1B (eg. 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, M1 stack sends through I2 and never reach the target.</t>
</list>
</t>
<t>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 decision regarding which interface to use. For instance, a user on such multihomed node might want a local policy to influence which interface will be used based on various conditions. Some SDOs have defined policy-based selection mechanisms, for instance the Access Network Discovery and Selection Function (ANDSF) <xref target="TS23.402"/> allows to provide selection policies to terminals with both a 3GPP and non-3GPP interfaces. However, as pointed out in <xref target="CM"/>, the selection may be a tricky problem requiring sophisticated mechanisms (e.g. connection manager), due to lot of criteria to consider. Moreover, information required to make a decision may be not available. For instance, interfaces to lower layer may not provide all required hints to the selection (e.g. information on interface quality).
</t>
<t> Another problem is that a node usually has a node-scoped routing table. Therefore, when a MIF node is connected to multiple provisioning domains, different actors may want to influence the routing table of the node, then conflicts might arise from the multiple routing information being pushed to the node. </t>
<t> 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 sent packets might be filtered in the path if source address filtering is in place (<xref target="RFC2827"/>,<xref target="RFC3704"/>) and reply packets might never come back to the source. </t>
</section>
<section title="Address Selection Policy">
<t> Even if not yet specified, the distribution of address selection policy is sometimes evoked. If deployed, such a mechanism could bring specific issue in a multiple provisioning domain context. Lets 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). When the user or the application is trying to reach an IP address (IP1), the following situations may occur:
<list style='empty'>
<t>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 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. </t>
</list>
</t>
<t>Merging address selection policies may have important impacts on routing.</t>
</section>
<section title="Single Interface on Multiple Provisioning Domains">
<t> When a node using a single interface is connected to multiple networks, i.e. different default routers, similar issues as described above happen. Even with a single interface, a node may wish to connect to more than one configuration 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 domain, so 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. </t>
</section>
</section>
<section title="Underlying problems and causes">
<t> This section lists the underlying problems, and their causes, which 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) connection management and API. They are shown as below:
<vspace blankLines="1" />
<list style='numbers'>
<t> Configuration. In a MIF context, configuration information specific to a provisioning domain may be ignored because:
<list style='numbers'>
<t>Configuration objects (e.g. DNS servers, NTP servers, ...) are node-scoped. So the IP stack is not able to maintain the mapping between information and corresponding provisioning domain.</t>
<t>Same configuration objects (e.g. DNS server addresses, NTP server addresses, ..) received from multiple provisioning domains may be overwritten.</t>
<t>Host implementations usually do not keep separate network configuration (such as DNS server addresses) per provisioning domain.</t>
</list>
</t>
<t>DNS resolution
<list style='numbers'>
<t>Some FQDN can be resolvable only by sending queries to the right server (e.g. intranet services). However, DNS query could be sent to the wrong interface because DNS server addresses may be node-scoped.</t>
<t>A DNS answer can be valid only on a specific provisioning domain but applications may be not aware of that mapping because DNS answers may be not kept with the provisioning from which the answer comes from.</t>
</list>
</t>
<t>Routing
<list style='numbers'>
<t>In the MIF context, routing information could be specific to each interface. This could lead to routing issue because, in current node implementations, routing tables are node-scoped.</t>
<t>Interfaces and provisioning domains of a MIF node can provide different characteristics (e.g. round-trip time, least cost, better bandwidth, etc....). So, user, applications or network provider may wish to influence routing (i.e. first-hop router selection) to take benefit of this heterogeneity. The first-hop selection could be based on policy taking into account various criteria such as path characteristics and application requirements. However, with current node implementations, neither the Type-of-Service nor path characteristics can be taken into account in the routing table. Such a requirement, would thus lead the interface and provisioning domain selection to leverage on dedicated mechanisms (e.g. high-level function, such as connection manager). However, selection may be tricky due to lot of different situations and selection criteria: some applications are domain-scoped, or may have a preferred provisioning domain (e.g. according to available QoS); each actor (user, operator, service provider, etc.) may also have their preferred provisioning domains (e.g. single out lower cost domain), possibly per type of application. </t>
<t>a node attached to multiple provisioning domain could be provided with disparate selection policies. If the different actors (e.g. user and network operator) are allowed to provide their own policies, there is a risk for the node to receive contradictory selection policies. It may lead the node to make wrong selection. </t>
<t>The problem of first hop selection could not be solved via configuration (<xref target="INTF-SEL"/>), and may leverage on sophisticated and specific mechanisms (<xref target="CM"/>). </t>
</list>
</t>
<t> Address selection
<list style='numbers'>
<t>Default Address Selection policies may be specific to their corresponding provisioning domain. However, a MIF node may not be able to manage per-provisioning domain address selection policies because default Address Selection policy is node-scoped.</t>
<t> 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.</t>
<t>Source address or address selection policies could be specified by applications. However, there is no advanced APIs to allow applications realizing such operations. </t>
</list>
</t>
<t> Connection management and API
<list style='numbers'>
<t>Some implementations, specially in the mobile world, have higher-level API and/or connection manager to address MIF issues. These mechanisms are not standardized and do not necessarily behave the same way across different OS, and/or platforms, in the presence of the MIF problems. This lack of consistency is an issue for user and operator who could experience different connection manager behaviors depending on the terminal.</t>
<t>Connection managers usually leverage on interface to link layer to gather information and/or for control purpose. However, such link layer interface may not provide all required services (e.g. may not provide all information allowing to make a proper interface selection). </t>
<t>A MIF node can support different connection managers, which may have contradictory ways to solve the MIF issues. For instance, because of different selection algorithms, two different connection managers could select different domains in a same context. Or, when dealing with different domain selection policies, a connection manager may give precedence to user policy while another could favor mobile operator policy.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>The problems discussed in this document have security implications, such as when the 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 bring 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.</t>
<t> 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.</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Authors">
<t> This document is a joint effort with authors of the MIF requirements draft <xref target="I-D.yang-mif-req"/>. The authors of this document, in alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick Seite, Carl Williams and Peny Yang. </t>
</section>
<section title="Acknowledgements">
<t> The initial Internet-Drafts prior to the MIF working group and the discussions during the MIF BOF meeting and on the mailing list around the MIF charter scope on the mailing list brought very good input to the problem statement. This draft steals a lot of text from these discussions and initial drafts (e.g. <xref target="I-D.yang-mif-req"/>, <xref target="I-D.hui-ip-multiple-connections-ps"/>, <xref target="I-D.savolainen-mif-dns-server-selection"/>). Therefore, the editor would like to acknowledge the following people (in no specific order), from which some text has been taken from: 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, Rémi Denis-Courmont, Alexandru Petrescu, Zhen Cao.
Sorry if some contributors have not been named.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.1136" ?>
<?rfc include="reference.RFC.1661" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3484" ?>
<?rfc include="reference.RFC.3542" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.4294" ?>
<?rfc include="reference.RFC.4477" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5014" ?>
<?rfc include="reference.RFC.5220" ?>
<?rfc include="reference.RFC.5221" ?>
<?rfc include="reference.RFC.5113" ?>
<?rfc include="reference.RFC.5206" ?>
<?rfc include="reference.RFC.5245" ?>
<?rfc include="reference.RFC.5533" ?>
<?rfc include="reference.RFC.5648" ?>
<?rfc include="reference.I-D.savolainen-mif-dns-server-selection" ?>
<?rfc include="reference.I-D.hui-ip-multiple-connections-ps" ?>
<?rfc include="reference.I-D.ietf-mif-current-practices" ?>
<?rfc include="reference.I-D.ietf-6man-addr-select-sol" ?>
<?rfc include="reference.I-D.yang-mif-req" ?>
<?rfc include="reference.I-D.ietf-behave-dns64" ?>
<?rfc include="reference.I-D.carpenter-behave-referral-object" ?>
<?rfc include="reference.I-D.ietf-shim6-multihome-shim-api" ?>
<?rfc include="reference.I-D.ietf-shim6-app-refer" ?>
<?rfc include="reference.I-D.ietf-mptcp-architecture" ?>
<reference anchor="802.21">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks
- Part 21: Media Independent Handover Services, IEEE
LAN/MAN Std 802.21-2008, January 2009.
</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="TS23.234">
<front>
<title>3GPP system to Wireless Local Area Network (WLAN) interworking; TS 23.234
</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="TS23.402">
<front>
<title>Architecture enhancements for non-
3GPP accesses; TS 23.402
</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:20 |