Internet Engineering Task Force (IETF) M. Blanchet
Request for Comments: 6418 Viagenie
Category: Informational P. Seite
ISSN: 2070-1721 France Telecom - Orange
November 2011
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6418.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
多宿节点可能有多个供应域（通过物理和/或虚拟接口）。例如，节点可以同时连接到有线以太网LAN、802.11 LAN、3G蜂窝网络、一个或多个VPN连接、或一个或多个隧道（自动或手动）。当前的笔记本电脑和智能手机通常具有多址网络接口，因此，它们通常连接到不同的供应域。
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".
多宿节点通过各种机制（如DHCPv4[RFC2131]、DHCPv6[RFC3315]、PPP[RFC1661]和IPv6路由器公告[RFC4861]）从其每个连接的网络接收配置信息。一些收到的配置对象特定于接口，例如IP地址和链接前缀。其他的通常被实现认为是节点的全局的，例如路由信息（例如，默认网关）、DNS服务器IP地址和地址选择策略，这里称为“节点范围”。
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.
当接收到的节点范围的配置对象具有来自每个配置域的不同值（例如不同的DNS服务器IP地址、不同的默认网关或不同的地址选择策略）时，节点必须决定使用哪一个或如何合并它们。
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.
以下各节定义了多接口（MIF）节点和本工作的范围，描述了相关工作，列出了问题，然后总结了潜在问题。
A companion document, [RFC6419], discusses some current practices of various implementations dealing with MIF.
附带文档[RFC6419]讨论了处理MIF的各种实现的一些当前实践。
Administrative domain
行政领域
A group of hosts, routers, and networks operated and managed by a single organization [RFC1136].
由单个组织操作和管理的一组主机、路由器和网络[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.
一组一致的配置信息（例如，默认路由器、网络前缀、DNS）和相应的接口。一个管理域可能有多个设置域。成功连接到供应域意味着终端使用适当的配置信息连接到相应的接口。
Reference to IP version
参考IP版本
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.
如果本文档中使用了IP、PPP或DHCP等协议关键字，而未提及特定的IP版本，则表示IPv4和IPv6。特定的IP版本关键字（如DHCPv4或DHCPv6）意味着特定于该IP版本。
This section describes existing related work and defines the scope of the problem.
本节描述了现有的相关工作，并定义了问题的范围。
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.
某些类型的接口具有链路层特性，可用于确定如何处理多个供应域问题。例如，链路层可能具有身份验证和加密特性，可以用作接口选择的标准。但是，[RFC5113]定义的下层网络发现和选择不在本文件范围内。此外，与低层机制（如IEEE 802.21中定义的服务）的互操作性（旨在促进异构网络之间的切换[MIH]）也超出了范围。
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.
一些机制（例如，基于虚拟IP接口）允许通过多个接口将单个IP地址共享到具有不同访问技术的网络。从节点上的IP堆栈视图中，只有一个接口和一个IP地址。因此，这种情况超出了问题陈述的范围。此外，在IP下进行的链路聚合（其中向IP堆栈显示单个接口）也超出了范围。
A MIF node has the following characteristics:
MIF节点具有以下特征：
o A MIF node is an [RFC1122] IPv4- and/or [RFC4294] IPv6-compliant node.
o MIF节点是[RFC1122]IPv4和/或[RFC4294]IPv6兼容节点。
o A MIF node is configured with more than one IP address (excluding loopback and link-local).
o MIF节点配置有多个IP地址（不包括环回和本地链路）。
o A MIF node can attach to more than one provisioning domain, as presented to the IP stack.
o MIF节点可以连接到多个供应域，如IP堆栈所示。
o The interfaces may be virtual or physical.
o 接口可以是虚拟的，也可以是物理的。
o Configuration objects come from one or more administrative domains.
o 配置对象来自一个或多个管理域。
o The IP addresses may be from the same or different address families, such as IPv4 and IPv6.
o IP地址可以来自相同或不同的地址系列，例如IPv4和IPv6。
o Communications using these IP addresses may happen simultaneously and independently.
o 使用这些IP地址的通信可以同时独立进行。
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 一些使用这些IP地址的通信在所有配置域上都是可能的，而一些仅在一组较小的配置域上是可能的。
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.
o 虽然MIF节点可以在其接口之间转发数据包，但在本定义中不考虑数据包的转发，不在本文档的范围之内。
"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.
“互联网主机的要求——通信层”[RFC1122]将多宿节点描述为具有多个IP地址，这些IP地址可能与连接到相同或不同网络的一个或多个物理接口相关联。
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.
[RFC1122]第3.3.1.3节指出，节点维护一个路由缓存表，其中每个条目包含本地IP地址、目的地IP地址、服务类型（被差异化服务代码点[RFC2474]取代）和下一跳网关IP地址。路由缓存条目将包含有关路径属性的数据，例如由传输协议测量的平均往返延迟。现在，实现并没有缓存这些信息。
[RFC1122] defines two host models:
[RFC1122]定义了两种主机型号：
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 “强”主机模型将多宿主主机定义为同一物理主机内的一组逻辑主机。在此模型中，数据包必须在与该数据包的源地址相对应的接口上发送。
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.
o “弱”主机模型描述具有某些嵌入式网关功能的主机。在弱主机模型中，主机可以在任何接口上发送和接收数据包。
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.
多宿节点根据不同的模型，以不同的方式计算传出数据报的路由。在强模型下，根据源IP地址、目标IP地址和区分服务代码点计算路由。在弱模型下，不使用源IP地址；仅使用目标IP地址和区分服务代码点。
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].
本文档的范围仅涉及对IPv4实现[RFC1122]和对IPv6实现[RFC4294]的节点，而不涉及传输层、移动性、多归属或标识符定位器拆分机制的附加功能或特殊用途支持。使用此类机制处理多个接口是相关的，但被视为一个单独的问题，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.
当应用程序使用一个接口，而另一个具有更好特性的接口可用时，正在进行的应用程序会话可以转移到新启用的接口。但是，在某些情况下，正在进行的会话应保持在当前接口上，同时在新接口上启动新会话。接口选择问题在MIF范围内，可能利用特定节点功能（第3.8节）。但是，如果需要传输IP会话，则应使用IP移动机制，如[RFC6275]。
"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].
“Internet协议版本6（IPv6）的默认地址选择”[RFC3484]定义源和目标IP地址选择的算法。[RFC3484]中定义的默认地址选择必须在IPv6节点中实现，这也意味着双堆栈节点。定义了由IP堆栈管理的节点范围策略表。更新策略表的机制在[ADDR-SELECT-SOL]中定义。
Issues on using default address selection were found in [RFC5220] and [RFC5221] in the context of multiple prefixes on the same link.
[RFC5220]和[RFC5221]在同一链接上的多个前缀上下文中发现了使用默认地址选择的问题。
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.
交互式连接建立（ICE）[RFC5245]是一种NAT穿越技术，用于提供/应答模型建立的基于UDP（和基于TCP）的媒体流。会话描述协议（SDP）提供的IP地址、端口和传输机制的多样性通过对等连接检查进行连接测试。结果是候选IP地址和端口，用于与其他对等方建立连接。但是，当在不同接口上接收到不兼容的配置对象时，ICE无法解决问题。
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].
一些应用程序协议会引用IP地址、端口号和传输，以便进一步交换。例如，应用程序可以向自己或第三方提供可达性信息。转介的一般问题与多接口问题有关，因为在这种情况下，转介必须根据使用的配置域提供一致的信息。推荐在[REFERRAL-PS]和[SHIM6-APP-REFER]中讨论。
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.
在MIF上下文中，节点可以同时处理具有不同特征的多个域，尤其是在支持多址技术时。如果应用程序仅限于一个特定的配置域，则选择很简单：应用程序必须在默认配置域（如果可用）上启动；否则，应用程序不会启动。但是，如果应用程序可以在多个供应域上运行，那么选择问题可能会很困难。
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):
没有选择供应域的标准方法，但在将范围限制为接口选择问题时，存在一些建议。例如，[TS23.234]提出了一种默认的界面选择机制。此方法使用以下信息（非详尽列表）：
o preferences provided by the user
o 用户提供的首选项
o policies provided by the network operator
o 网络运营商提供的政策
o quality of the radio link
o 无线电链路的质量
o network resource considerations (e.g., available Quality of Service (QoS), IP connectivity check)
o 网络资源注意事项（例如，可用服务质量（QoS）、IP连接检查）
o the application QoS requirements in order to map applications to the best interface
o 应用程序QoS要求，以便将应用程序映射到最佳接口
However, [TS23.234] is designed for a specific multiple-interfaces use case. A generic way to handle these characteristics is yet to be defined.
然而，[TS23.234]是为特定的多接口用例而设计的。处理这些特征的通用方法尚未确定。
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.
一些实现，特别是在移动世界中，依赖更高级别的会话管理器（也称为连接管理器）来处理同时连接到多个供应域所带来的问题。通常，会话管理器可以代表应用程序处理接口和/或供应域的选择，或者处理复杂问题，例如如何解决冲突策略（第4.3节）。如第3.7节所述，会话管理器可能会因为多种不同的标准而遇到困难。
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.
会话管理器通常利用链路层接口收集信息（例如，较低层身份验证和加密方法；参见第3.1节）和/或用于控制目的。这样的链路层接口可能不会提供做出正确决策所需的所有服务（例如，接口选择）。一些操作系统或终端已经实现了会话管理器[RFC6419]，供应商特定的平台有时提供了会话管理器可以使用的特定套接字API（第3.9节）。但是，会话管理器及其相关API的通用体系结构目前尚未标准化，因此会话管理器的行为在操作系统和平台之间可能有所不同。
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.
多个接口的管理有时依赖于虚拟接口。例如，虚拟接口允许在代理移动IPv6网络中支持多归属、技术间切换和IP流移动性[逻辑IF支持]。该虚拟接口允许多接口节点在多个物理接口上共享一组IP地址，并且还可以为多接入场景（例如第三代合作伙伴关系项目（3GPP）多接入分组数据网络（PDN）连接）增加好处[TS23.402]。在大多数情况下，虚拟接口将映射多个物理网络接口，会话管理器应控制这些虚拟接口和物理接口中每个接口的配置，以及虚拟接口和子接口之间的映射。
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.
在涉及多个接口的情况下，活动应用程序会话应能在路径故障后生存。这里，会话管理器可以发挥作用，但仅依赖现有机制来管理多路径TCP（MPTCP）[RFC6182]或故障转移（移动IPv6（MIP6）[RFC6275]，Shim6[RFC5533]）。对这些机制和会话管理器之间的交互的描述超出了本文档的范围。
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.
应用程序编程接口（API）可以公开用户应用程序或会话管理器用于处理多个接口的对象。例如，[RFC3542]定义了使用高级套接字API的应用程序如何通过简单的bind（）操作或IPV6_PKTINFO套接字选项指定接口或源IP地址。
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.
已经定义了其他API来解决类似于MIF的问题。例如，[RFC5014]定义了一个API，通过指定它喜欢的源地址的属性来影响默认地址选择机制。[RFC6316]给出了另一个例子，在多主环境中，通过定义套接字API，实现应用程序和多主垫片层之间的交互，以实现高级定位器管理，并访问有关故障检测和路径探索的信息。
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:
本节介绍使用已从其各个供应域接收配置对象的MIF节点时，或使用多个接口并导致错误的域选择、寻址或命名空间重叠时的各种问题。例如，当出现以下情况时，会发生：
1. one interface is on the Internet and one is on a corporate private network. The latter may be through VPN.
1. 一个接口在Internet上，另一个接口在公司专用网络上。后者可以通过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.
2. 一个接口位于一个接入网络（即WiFi）上，另一个接口位于另一个具有特定服务的接入网络（3G）上。
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
MIF节点（M1）具有连接到网络（N1）的活动接口（I1），该网络（N1）具有其DNS服务器（S1作为主DNS服务器）和连接到网络（N2）的另一活动接口（I2），该网络（N2）具有其DNS服务器（S2作为主DNS服务器）。S1提供一些私人服务
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:
名称空间，“private.example.com”。用户或应用程序使用名称“a.private.example.com”，该名称位于S1的私有名称空间内，并且只能由S1解析。可能出现以下任何情况：
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.
1. M1堆栈基于其路由表，使用I2到达S1以解析“a.private.example.com”。M1永远不会到达S1。名称未解析。
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.
2. M1只保留来自接收的配置对象的一组DNS服务器地址。假设M1将S2的地址作为主DNS服务器。M1向S2发送a.private.example.com的前向DNS查询。S2对不存在的域（NXDOMAIN）响应错误。名称未解析。执行反向DNS查找时也会出现此问题。在相同的情况下，反向DNS查询失败。
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.
3. M1只保留来自接收的配置对象的一组DNS服务器地址。假设M1保留S2的地址。M1向S2发送a.private.example.com的DNS查询。S2查询其上游DNS并获取a.private.example.com的IP地址。但是，IP地址与S1给出的地址不同。因此，应用程序试图连接到错误的目标节点或错误的接口，这可能意味着安全问题或导致缺少服务。
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.
4. S1或S2已用于将“a.private.example.com”解析为[RFC1918]地址。N1和N2都是[RFC1918]寻址网络。如果地址重叠，则可能使用错误的接口发送通信量。此问题与接收多个配置对象无关，而是与接口或连接网络之间的地址重叠有关。
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.
5. 连接到N1时，M1已将完全限定域名（FQDN）解析为本地有效IP地址。如果节点失去与N1的连接，则节点可能会尝试通过N2连接到与先前相同的IP地址，但由于该地址仅在本地有效，因此连接设置失败。类似地，当连接到N1时，M1可能已收到FQDN的NXDOMAIN。从N1分离后，节点不应假定FQDN继续在N2上不存在。
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.
6. M1从使用协议转换器和DNS64的网络上的DNS服务器请求AAAA记录[RFC6147]。如果M1接收到合成的AAAA记录，则保证该记录仅在从中学习该记录的网络上有效。如果M1在任何其他网络接口上使用合成AAAA，流量可能会丢失、丢弃或转发到错误的网络。
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:
有些网络要求用户在提供Internet连接之前在一个固定的web门户上进行身份验证。如果通过修改DNS回复来实现此重定向，则可能会出现特定问题。考虑具有连接到网络（N1）的活动接口（I1）的MIF节点（M1），该网络具有其DNS服务器（S1），以及连接到网络（N2）的另一活动接口（I2），其具有DNS服务器（S2）。在用户未进行身份验证之前，S1被配置为使用捕获门户的IP地址响应任何A或AAAA记录查询，以便将web浏览器重定向到访问控制门户网页。只能通过I1访问此捕获门户。当用户已对捕获门户进行身份验证时，M1可以在连接到N1时解析FQDN。然而，如果地址仅在N1上本地有效，则可能发生上述任何问题。当用户未进行身份验证时，可能会出现以下任何情况：
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.
1. M1仅保留来自接收的配置对象的一组DNS服务器地址，并保留S2地址。M1向S2发送a.example.com的前向DNS查询。S2以正确答案R1作出响应。M1试图通过I1联系R1。连接失败。或者，连接成功，绕过N1上的安全策略，可能使M1的所有者面临起诉。
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).
2. M1只保留来自接收的配置对象的一组DNS服务器地址，并保留S1地址。M1向S1发送a.example.com的DNS查询。S1提供其捕获门户的地址。M1尝试使用I1联系此IP地址。应用程序无法连接，导致缺少服务。或者，应用程序成功连接，但连接到捕获门户而不是预期目的地，从而导致缺少服务（即，IP连接检查问题，如第4.4节所述）。
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:
考虑具有连接到网络（N1）的活动接口（I1）和连接到网络（N2）的另一活动接口（I2）的MIF节点（M1）。用户或应用程序正在尝试访问IP地址（IP1）。可能出现以下任何情况：
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.
1. 对于IP1，M1有一条通过网络（N1）的默认路由（R1）。为了达到IP1，M1堆栈使用R1并通过I1发送。如果IP1仅可由N2达到，则IP1从未达到或不是正确的目标。
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.
2. 对于IP1地址系列，M1每个网络（N1，N2）有一个默认路由（R1，R2）。IP1可由两个网络访问，但N2路径具有更好的特性，如更好的往返时间、最低成本、更好的带宽等。这些首选项可由用户定义、由网络运营商提供或以其他方式适当配置。M1堆栈使用R1并尝试通过I1发送。已达到IP1，但通过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.
3. 对于IP1地址系列，M1具有到N1的默认路由（R1）、特定X.0.0.0/8路由R1B（例如，但不限于[RFC1918]前缀）和到N2的默认路由（R2）。IP1仅可由N2访问，但前缀（X.0.0.0/8）在两个网络中都使用。由于最特定的路由R1B，M1堆栈通过I2发送数据包，而这些数据包永远不会到达目标。
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).
MIF节点可能有多条到目的地的路由。但是，默认情况下，它没有任何关于哪个接口最适合用于该目的地的提示。第一跳选择可以利用本地路由策略，允许一些参与者（例如，网络运营商或服务提供商）影响路由表，即，决定使用哪个接口。例如，这种多宿主节点上的用户可能希望本地策略根据各种条件影响将使用的接口。一些标准开发组织（SDO）定义了基于策略的路由选择机制。例如，接入网络发现和选择功能（ANDSF）[TS23.402]向具有3GPP接口和非3GPP接口的终端提供系统间路由策略。然而，由于第3.8节中讨论的不相交标准，路由选择可能仍然很困难。此外，可能无法获得作出正确决定所需的信息。例如，与较低层的接口可能不会提供有关选择的所有必需提示（例如，关于接口质量的信息）。
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.
节点通常有一个节点范围的路由表。但是，MIF节点连接到多个供应域；如果这些域中的每一个都将路由策略推送到节点，那么策略之间可能会发生冲突，节点无法轻松地合并或协调它们。
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.
在MIF节点上，如果在某些接口上使用，则某些源地址无效。例如，[RFC1918]源地址可能适用于VPN接口，但不适用于MIF节点的公共接口。如果未正确选择源地址，则如果源地址过滤到位（[RFC2827]，[RFC3704]），则可能会在路径中过滤数据包，并且应答数据包可能永远不会返回到源。
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:
正在讨论将配置策略（例如，地址选择、路由、DNS选择）分发到终端节点（例如，[TS23.402]、[DHCPv6路由选项]中的ANDSF）。如果在多个供应域中实施，这些机制可能会冲突，并为多宿节点造成问题。考虑到具有连接到网络（N1）的活动接口（I1）和连接到网络（N2）的另一活动接口（I2）的MIF节点（M1），可能会发生以下冲突：
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.
1. M1从两个网络（N1和N2）接收其默认地址选择策略的更新。但是，这些策略是特定于每个网络的。这些策略由M1堆栈合并。根据合并策略，选择的源地址来自N1，但数据包被发送到N2。无法从N2访问源地址；因此，返回数据包丢失。合并地址选择策略可能会对路由产生重要影响。
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.
2. 节点通常有一个节点范围的路由表。然而，每个连接的供应域（N1和N2）可以将路由策略推送到节点；策略之间可能会发生冲突，节点无法轻松地合并或协调策略。
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.
3. M1例如通过3GPP/ANDSF[TS23.402]从其中一个网络接收其接入选择策略的更新。但是，该策略与本地策略（例如，用户定义或默认操作系统策略）冲突。假设网络提供过载接入网络的列表，如果忽略网络发送的策略，则分组可能被发送到通信质量较差的接入网络。
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:
考虑节点已经选择了一个接口并设法配置它（即，节点从网络获得了有效的IP地址）。但是，Internet连接不可用。问题可能是由以下原因造成的：
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.
1. 网络需要基于web的身份验证（例如，接入网络是WiFi热点）。在这种情况下，用户只能访问捕获门户。例如，网络可以执行HTTP重定向或修改DNS行为（第4.1节），直到用户未通过身份验证。
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.
2. IP接口配置为活动，但第2层非常差（例如，恶劣的无线电条件），因此第3层通信无法成功。
In this situation, the session manager should be able to perform IP connectivity checks before selecting an interface.
在这种情况下，会话管理器应该能够在选择接口之前执行IP连接检查。
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.
当节点发现新的供应域时，也可能出现会话问题。考虑具有连接到网络（N1）的活动接口（I1）的MIF节点（M1），其中应用程序正在运行TCP会话。新网络（N2）可用。如果选择了N2（例如，由于通信质量更好），M1将获得到N2的IP连接，并更新路由表优先级。因此，如果没有到对应节点的特定路由，并且该节点实现弱主机模型[RFC1122]，则TCP连接会随着下一跳的改变而中断。为了继续与对应节点通信，M1应尝试通过N2重新连接到服务器。在某些情况下，最好在N1上保持当前会话，而在N2上启动新会话。
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.
当使用单个接口的节点连接到多个网络（例如不同的默认路由器）时，将发生与上述类似的问题。即使使用单个接口，节点也可能希望连接到多个供应域：该节点可能使用多个IP源地址，并且可能有多个默认路由器。节点可能希望访问只能使用其中一个供应域访问的服务。在这种情况下，它需要使用正确的传出源地址和默认网关来访问该服务。在这种情况下，该节点可能还需要使用不同的DNS服务器来获取这些不同供应域中的域名。
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）配置，2）DNS解析，3）路由，4）地址选择，以及5）会话管理和API。它们如下所示：
1. Configuration. In a MIF context, configuration information specific to a provisioning domain may be ignored because:
1. 配置在MIF上下文中，特定于配置域的配置信息可能会被忽略，因为：
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.
A.配置对象（例如DNS服务器、NTP服务器）是节点范围的。因此，IP堆栈无法维护配置信息与相应配置域之间的映射。
B. The same configuration objects (e.g., DNS server addresses, NTP server addresses) received from multiple provisioning domains may be overwritten.
B.从多个供应域接收的相同配置对象（例如，DNS服务器地址、NTP服务器地址）可能会被覆盖。
C. Host implementations usually do not keep separate network configurations (such as DNS server addresses) per provisioning domain.
C.主机实现通常不会为每个配置域保留单独的网络配置（如DNS服务器地址）。
2. DNS resolution
2. DNS解析
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.
A.某些FQDN只能通过将查询发送到正确的服务器（例如，内部网服务）来解析。但是，DNS查询可能发送到错误的接口，因为DNS服务器地址可能是节点范围的。
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.
B.DNS应答可能仅在特定的配置域上有效，但应用程序可能不知道该映射，因为DNS应答可能不会与应答来源的配置一起保存。
3. Routing
3. 路由
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.
A.在MIF上下文中，路由信息可能特定于每个接口。这可能会导致路由问题，因为在当前的节点实现中，路由表是节点范围的。
B. Current node implementations do not take into account the Differentiated Services Code Point or path characteristics in the routing table.
B.当前节点实现未考虑路由表中的差异化服务代码点或路径特征。
C. Even if implementations take into account path characteristics, the node has no way to properly merge or reconcile the provisioning domain preferences.
C.即使实现考虑了路径特征，节点也无法正确合并或协调供应域首选项。
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.
D.可以为连接到多个供应域的节点提供不兼容的选择策略。如果允许不同的参与者（例如，用户和网络运营商）提供自己的策略，则节点无法正确合并或协调多个选择策略。
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).
E.第一跳选择问题无法通过配置解决（第3.7节），可能利用复杂和特定的机制（第3.8节）。
4. Address selection
4. 地址选择
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.
A.默认地址选择策略可能特定于其相应的配置域。但是，MIF节点可能无法管理每个配置域的地址选择策略，因为默认地址选择策略是节点范围的。
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.
B.在MIF节点上，如果在某些接口上，甚至在同一接口上的某些默认路由器上使用，则某些源地址无效。在这种情况下，路由表中应该考虑源地址，但是当前的节点实现不支持这样的功能。
C. Source address or address selection policies could be specified by applications. However, there are no advanced APIs that support such applications.
C.源地址或地址选择策略可以由应用程序指定。但是，没有支持此类应用程序的高级API。
5. Session management and APIs
5. 会话管理和API
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.
A.一些实现，特别是在移动世界中，具有更高级别的API和/或会话管理器（也称为连接管理器）来解决MIF问题。这些机制没有标准化，在存在MIF问题的情况下，在不同的操作系统和/或平台上的行为不一定相同。这种不一致性对于用户和操作员来说是一个问题，他们可能会体验到不同的会话管理器行为，具体取决于终端。
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).
B.会话管理器通常利用到链路层的接口来收集信息（例如，较低层的身份验证和加密方法）和/或用于控制目的。然而，这样的链路层接口可能不会提供所有必需的服务（例如，可能不会提供允许正确接口选择的所有信息）。
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.
C.MIF节点可以支持不同的会话管理器，这些会话管理器在解决MIF问题时可能有相互矛盾的方法。例如，由于选择算法不同，两个不同的会话管理器可以在同一上下文中选择不同的域。或者，在处理不同的域选择策略时，一个会话管理器可能会优先考虑用户策略，而另一个会话管理器可能会优先考虑移动运营商策略。
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.
D.当更新主机路由并且支持弱主机模型时，如果这些会话的路由发生变化，正在进行的TCP会话可能会中断。当TCP会话应绑定到接口时，应使用强主机模型。
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).
E.当由不同的参与者（例如，用户、网络、默认操作系统）提供时，策略可能会发生冲突，因此需要在主机级别进行协调。策略冲突解决可能会影响其他功能（例如命名、路由）。
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.
F.即使节点已成功配置接口，Internet连接也可能不可用。这可能是由于访问控制功能在第3层以上发挥作用，或者是由于第2层条件较差。在选择接口之前，应执行IP连接检查。
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.
本文档中讨论的问题具有安全含义，例如在错误接口上发送的数据包可能会泄漏一些机密信息。来自一个配置域的配置参数可能会导致另一个配置域上的拒绝服务（例如，DNS问题）。此外，多宿环境中IP堆栈的不确定行为带来了额外的威胁，其中多宿节点上的接口可能被用于对其他接口连接的网络进行攻击。损坏的配置域选择策略可能会导致节点做出决策，从而导致某些流量转发给攻击者。
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.
未来可能的机制会给节点提供额外的信息，从而使其能够就本文档中讨论的问题做出更明智的决策，从而引发更多的安全问题。这种未来机制本身可能很脆弱，在一般情况下可能不容易保护。
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.
本文件与MIF需求文件[MIF-REQ]的作者共同努力。这包括按字母顺序排列的：贾斯尼·秦、卡尔·威廉姆斯和彭阳。
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.
MIF工作组成立之前编写的文件，以及MIF“羽毛鸟”（BOF）会议期间的讨论以及邮件列表中关于MIF章程范围的讨论，为问题陈述提供了非常好的信息。本文档从这些讨论和初始文档（例如，[MIF-REQ]、[IP-MULTIPLE-CONN]、[MIF-DNS-SERVER-SELECT]）中窃取了大量文本。因此，作者要感谢以下人（没有具体顺序），他们的一些文本是从他们那里获得的：雅里·阿尔科、基思·摩尔、萨姆·哈特曼、乔治·齐尔茨、斯科特·布里姆、特德·莱蒙、伯尼·沃兹、吉扬·森、加布里埃尔·黑山、朱利安·拉加尼尔、蒂姆·萨沃莱宁、克里斯蒂安·福格特、拉尔斯·艾格特、玛格丽特·瓦瑟曼、惠登、，拉尔夫·德罗姆斯、特德·哈迪、克里斯蒂安·惠特马、雷米·丹尼斯·库尔蒙、亚历山大·彼得雷斯库、曹真、盖坦·菲格、特莱梅科·梅利亚和胡安·卡洛斯·祖尼加。向无意中未透露姓名的任何贡献者致歉。
[ADDR-SELECT-SOL] Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution approaches for address-selection problems", Work in Progress, March 2010.
[ADDR-SELECT-SOL]Matsumoto，A.，Fujisaki，T.，和R.Hiromi，“地址选择问题的解决方法”，正在进行的工作，2010年3月。
[DHCPv6-ROUTE-OPTIONS] Dec, W., Ed., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Route Options", Work in Progress, September 2011.
[DHCPv6路线选择]Dec，W.，Ed.，Mrugalski，T.，Sun，T.，和B.Sarikaya，“DHCPv6路线选择”，正在进行的工作，2011年9月。
[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.
[IP-MULTIPLE-CONN]Hui，M.和H.Deng，“主机简单IP多宿的问题陈述和要求”，正在进行的工作，2009年3月。
[LOGICAL-IF-SUPPORT] Melia, T., Ed., and S. Gundavelli, Ed., "Logical Interface Support for multi-mode IP Hosts", Work in Progress, October 2011.
[LOGICAL-IF-SUPPORT]Melia，T.，Ed.，和S.Gundavelli，Ed.，“多模式IP主机的逻辑接口支持”，正在进行的工作，2011年10月。
[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-DNS-SERVER-SELECT]Savolainen，T.，Kato，J.，和T.Lemon，“多接口节点的改进DNS服务器选择”，正在进行中，2011年10月。
[MIF-REQ] Yang, P., Seite, P., Williams, C., and J. Qin, "Requirements on multiple Interface (MIF) of simple IP", Work in Progress, February 2009.
[MIF-REQ]Yang，P.，Seite，P.，Williams，C.，和J.Qin，“简单IP的多接口（MIF）要求”，正在进行的工作，2009年2月。
[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.
[MIH]IEEE，“IEEE局域网和城域网标准-第21部分：媒体独立切换服务”，IEEE LAN/MAN标准802.21-2008，2009年1月。
[REFERRAL-PS] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011.
[REFERRAL-PS]Carpenter，B.，Jiang，S.，和Z.Cao，“转诊问题陈述”，在建工程，2011年2月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, December 1989.
[RFC1136]Hares，S.和D.Katz，“管理域和路由域：互联网路由模型”，RFC 11361989年12月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[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.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[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.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，编辑，“IPv6节点要求”，RFC 42942006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014]Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月。
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008.
[RFC5113]Arkko，J.，Aboba，B.，Korhonen，J.，Ed.，和F.Bari，“网络发现和选择问题”，RFC 5113，2008年1月。
[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.
[RFC5206]Nikander，P.，Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多址”，RFC 52062008年4月。
[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.
[RFC5220]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题”，RFC 52202008年7月。
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Requirements for Address Selection Mechanisms", RFC 5221, July 2008.
[RFC5221]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“地址选择机制的要求”，RFC 52212008年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648]Wakikawa，R.，Ed.，Devarapalli，V.，Tsirtsis，G.，Ernst，T.，和K.Nagami，“多重托管地址注册”，RFC 5648，2009年10月。
[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.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[RFC6182]福特，A.，雷丘，C.，汉德利，M.，巴尔，S.，和J.艾扬格，“多路径TCP开发的架构指南”，RFC6182，2011年3月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316]Komu，M.，Bagnulo，M.，Slavov，K.，和S.Sugimoto，Ed.，“多归宿垫片的套接字应用程序接口（API）”，RFC 63162011年7月。
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6419]Wasserman，M.和P.Seite，“多接口主机的当前实践”，RFC 6419，2011年11月。
[SHIM6-APP-REFER] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005.
[SHIM6-APP-REFER]Nordmark，E.，“SHIM6应用程序转介问题”，正在进行的工作，2005年7月。
[TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking", TS 23.234, December 2009.
[TS23.234]3GPP，“3GPP系统到无线局域网（WLAN）的互通”，TS 23.234，2009年12月。
[TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", TS 23.402, December 2010.
[TS23.402]3GPP，“非3GPP接入的架构增强”，TS 23.402，2010年12月。
Authors' Addresses
作者地址
Marc Blanchet Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
Marc Blanchet Viagenie 2875 boul。Laurier，加拿大魁北克QC G1V 2M2 D2-630套房
EMail: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca
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
法国电信公司Pierrick Seite-Orange 4，英国石油公司，邮编91226，法国塞森塞维尼35512
EMail: pierrick.seite@orange.com
EMail: pierrick.seite@orange.com