Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6419 Painless Security, LLC
Category: Informational P. Seite
ISSN: 2070-1721 France Telecom - Orange
November 2011
Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6419 Painless Security, LLC
Category: Informational P. Seite
ISSN: 2070-1721 France Telecom - Orange
November 2011
Current Practices for Multiple-Interface Hosts
多接口主机的当前实践
Abstract
摘要
An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context.
越来越多的主机在多接口环境中运行。本文档总结了该领域的当前实践，并详细描述了一些常见操作系统如何应对由此带来的挑战。
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/rfc6419.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6419.
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. Summary of Current Approaches . . . . . . . . . . . . . . . . 3
2.1. Centralized Connection Management . . . . . . . . . . . . 3
2.2. Per-Application Connection Settings . . . . . . . . . . . 4
2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4
2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5
2.3.2. First-Hop Selection . . . . . . . . . . . . . . . . . 5
2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5
3. Current Practices in Some Operating Systems . . . . . . . . . 6
3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7
3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Leadcore Technology Arena . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. First-Hop Selection . . . . . . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15
3.2.2. Linux and BSD-Based Operating Systems . . . . . . . . 16
3.2.2.1. First-Hop Selection . . . . . . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3
2.1. Centralized Connection Management . . . . . . . . . . . . 3
2.2. Per-Application Connection Settings . . . . . . . . . . . 4
2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4
2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5
2.3.2. First-Hop Selection . . . . . . . . . . . . . . . . . 5
2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5
3. Current Practices in Some Operating Systems . . . . . . . . . 6
3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7
3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Leadcore Technology Arena . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. First-Hop Selection . . . . . . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15
3.2.2. Linux and BSD-Based Operating Systems . . . . . . . . 16
3.2.2.1. First-Hop Selection . . . . . . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Multiple-interface hosts face several challenges not faced by single-interface hosts, some of which are described in the multiple interfaces (MIF) problem statement [RFC6418]. This document summarizes how current implementations deal with the problems identified in the MIF problem statement.
多接口主机面临多个单一接口主机无法面对的挑战，其中一些挑战在多接口（MIF）问题陈述[RFC6418]中有所描述。本文档总结了当前实施如何处理MIF问题陈述中确定的问题。
Publicly available information about the multiple-interface solutions implemented in some widely used operating systems, including both mobile handset and desktop operating systems, is collected in this document, including Nokia S60 [S60], Microsoft Windows Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], Microsoft Windows, Linux, and BSD-based operating systems.
本文档收集了一些广泛使用的操作系统（包括手机和桌面操作系统）中实施的多界面解决方案的公开信息，包括诺基亚S60[S60]、微软Windows mobile[WINDOWSMOBILE]、黑莓[Blackberry]、谷歌安卓[Android]，基于Microsoft Windows、Linux和BSD的操作系统。
This section summarizes current approaches that are used to resolve the multiple-interface issues described in the MIF problem statement [RFC6418]. These approaches can be broken down into three major categories:
本节总结了用于解决MIF问题陈述[RFC6418]中描述的多个接口问题的当前方法。这些方法可分为三大类：
o Centralized connection management
o 集中式连接管理
o Per-application connection settings
o 每个应用程序的连接设置
o Stack-level solutions to specific problems
o 特定问题的堆栈级解决方案
It is a common practice for mobile handset operating systems to use a centralized connection manager that performs network interface selection based on application or user input. However, connection managers usually restrict the problem to the selection of the interface and do not cope with selection of the provisioning domain, as defined in [RFC6418]. The information used by the connection manager may be programmed into an application or provisioned on a handset-wide basis. When information is not available to make an interface selection, the connection manager will query the user to choose between available choices.
移动手持设备操作系统通常使用集中式连接管理器，该管理器根据应用程序或用户输入执行网络接口选择。然而，连接管理器通常将问题限制在接口的选择上，而不处理[RFC6418]中定义的供应域的选择。连接管理器使用的信息可以编程到应用程序中或在手持设备范围内提供。当信息不可用于进行界面选择时，连接管理器将查询用户以在可用选项之间进行选择。
Routing tables are not typically used for network interface selection when a connection manager is in use, as the criteria for network selection is not strictly IP-based but is also dependent on other properties of the interface (cost, type, etc.). Furthermore, multiple overlapping private IPv4 address spaces are often exposed to a multiple-interface host, making it difficult to make interface selection decisions based on prefix matching.
当使用连接管理器时，路由表通常不用于网络接口选择，因为网络选择的标准并非严格基于IP，而是取决于接口的其他属性（成本、类型等）。此外，多个重叠的专用IPv4地址空间通常会暴露给多接口主机，因此很难根据前缀匹配做出接口选择决策。
In mobile handsets, applications are often involved in choosing what interface and related configuration information should be used. In some cases, the application selects the interface directly, and in other cases, the application provides more abstract information to a connection manager that makes the final interface choice.
在手机中，应用程序通常涉及选择应使用的接口和相关配置信息。在某些情况下，应用程序直接选择接口，而在其他情况下，应用程序向进行最终接口选择的连接管理器提供更多抽象信息。
In most desktop operating systems, multiple-interface problems are dealt with in the stack and related components, based on system-level configuration information, without the benefit of input from applications or users. These solutions tend to map well to the problems listed in the problem statement:
在大多数桌面操作系统中，基于系统级配置信息，在堆栈和相关组件中处理多个接口问题，而不需要应用程序或用户的输入。这些解决方案往往能很好地反映问题陈述中列出的问题：
o DNS resolution issues
o DNS解析问题
o Routing
o 路由
o Address selection policy
o 地址选择策略
The configuration information for desktop systems comes from one of the following sources: DHCP, router advertisements, proprietary configuration systems, or manual configuration. While these systems universally accept IP address assignment on a per-interface basis, they differ in what set of information can be assigned on a per-interface basis and what can be configured only on a per-system basis.
桌面系统的配置信息来自以下来源之一：DHCP、路由器广告、专有配置系统或手动配置。虽然这些系统普遍接受基于每个接口的IP地址分配，但它们在基于每个接口可以分配哪些信息集以及只能基于每个系统配置哪些信息集方面存在差异。
When choosing between multiple sets of information provided, these systems will typically give preference to information received on the "primary" interface. The mechanism for designating the "primary" interface differs by system.
当在提供的多组信息之间进行选择时，这些系统通常会优先考虑在“主要”界面上接收的信息。指定“主要”接口的机制因系统而异。
There is very little commonality in how desktop operating systems handle multiple sets of configuration information, with notable variations between different versions of the same operating system and/or within different software packages built for the same operating system. Although these systems differ widely, it is not clear that any of them provide a completely satisfactory user experience in multiple-interface environments.
桌面操作系统处理多组配置信息的方式几乎没有共同之处，同一操作系统的不同版本之间和/或为同一操作系统构建的不同软件包之间存在显著差异。尽管这些系统差别很大，但尚不清楚它们是否能在多界面环境中提供完全令人满意的用户体验。
The following sections discuss some of the solutions used in each of the areas raised in the MIF problem statement.
以下各节讨论MIF问题陈述中提出的每个领域中使用的一些解决方案。
There is very little commonality in how desktop operating systems handle the DNS server list. Some systems support per-interface DNS server lists, while others only support a single system-wide list.
桌面操作系统处理DNS服务器列表的方式几乎没有什么共同之处。一些系统支持每个接口的DNS服务器列表，而另一些系统仅支持单个系统范围的列表。
On hosts with per-interface DNS server lists, different mechanisms are used to determine which DNS server is contacted for a given query. In most cases, the first DNS server listed on the "primary" interface is queried first, with back off to other servers if an answer is not received.
在具有每个接口DNS服务器列表的主机上，使用不同的机制来确定为给定查询联系哪个DNS服务器。在大多数情况下，首先查询“主”界面上列出的第一个DNS服务器，如果没有收到答复，则返回到其他服务器。
Systems that support a single system-wide list differ in how they select which DNS server to use in cases where they receive more than one DNS server list to configure (e.g., from DHCP on multiple interfaces). Some accept the information received on the "primary" interface, while others use either the first or last set DNS server list configured.
支持单个系统范围列表的系统在接收到多个要配置的DNS服务器列表的情况下（例如，从多个接口上的DHCP）选择使用哪个DNS服务器的方式不同。一些接受在“主”接口上接收的信息，而另一些则使用配置的第一个或最后一个设置的DNS服务器列表。
Routing information is also handled differently on different desktop operating systems. While all systems maintain some sort of routing cache, to handle redirects and/or statically configured routes, most packets are routed based on configured default gateway information.
路由信息在不同的桌面操作系统上的处理方式也不同。虽然所有系统都维护某种路由缓存，以处理重定向和/或静态配置的路由，但大多数数据包都是基于配置的默认网关信息进行路由的。
Some systems do allow the configuration of different default router lists for different interfaces. These systems will always choose the default gateway on the interface with the lowest routing metric, with different behavior when two or more interfaces have the same routing metric.
有些系统允许为不同的接口配置不同的默认路由器列表。这些系统将始终在具有最低路由度量的接口上选择默认网关，当两个或多个接口具有相同的路由度量时，其行为不同。
Most systems do not allow the configuration of more than one default router list, choosing instead to use the first or last default router list configured and/or the router list configured on the "primary" interface.
大多数系统不允许配置多个默认路由器列表，而是选择使用配置的第一个或最后一个默认路由器列表和/或“主”界面上配置的路由器列表。
There is somewhat more commonality in how desktop hosts handle address selection. Applications typically provide the destination address for an outgoing packet, and the IP stack is responsible for picking the source address.
桌面主机处理地址选择的方式有更多的共性。应用程序通常为传出数据包提供目标地址，IP堆栈负责选择源地址。
IPv6 specifies a specific source address selection mechanism in [RFC3484], and several systems implement this mechanism with similar support for IPv4. However, many systems do not provide any mechanism to update this default policy, and there is no standard way to do so.
IPv6在[RFC3484]中指定了一种特定的源地址选择机制，有几个系统实现了这种机制，并对IPv4提供了类似的支持。但是，许多系统不提供任何机制来更新此默认策略，并且没有标准的方法来进行更新。
In some cases, the routing decision (including which interface to use) is made before source address selection is performed, and a source address is chosen from the outbound interface. In other cases, source address selection is performed before, or independently from, outbound interface selection.
在某些情况下，路由决策（包括使用哪个接口）是在执行源地址选择之前做出的，并且从出站接口选择源地址。在其他情况下，源地址选择在出站接口选择之前执行，或独立于出站接口选择执行。
The material presented in this section is derived from contributions from people familiar with the operating systems described (see Section 6 a list of these individuals). The authors and the IETF take no position about the operating systems described and understand that other operating systems also exist. Furthermore, it should be understood that Section 3 describes particular behaviors that were believed to be current at the time this document was written: earlier and later versions of the operating systems described may exhibit different behaviors. Please refer to the References section for pointers to original documentation, including further details.
本节中提供的材料来源于熟悉所述操作系统的人员的贡献（参见第6节这些人员的列表）。作者和IETF对所描述的操作系统不持任何立场，并且理解也存在其他操作系统。此外，应该理解的是，第3节描述了在编写本文档时被认为是最新的特定行为：所描述的操作系统的早期版本和后期版本可能表现出不同的行为。有关原始文档的指针，包括更多详细信息，请参阅参考资料部分。
Cellular devices typically run a variety of applications in parallel, each with different requirements for IP connectivity. A typical scenario is shown in Figure 1, where a cellular device is utilizing Wireless Local Area Network (WLAN) access for web browsing and General Packet Radio Service (GPRS) access for transferring multimedia messages (MMS). Another typical scenario would be a real-time Voice over IP (VoIP) session over one network interface in parallel with best-effort web browsing on another network interface. Yet another typical scenario would be global Internet access through one network interface and local (e.g., corporate VPN) network access through another.
Cellular devices typically run a variety of applications in parallel, each with different requirements for IP connectivity. A typical scenario is shown in Figure 1, where a cellular device is utilizing Wireless Local Area Network (WLAN) access for web browsing and General Packet Radio Service (GPRS) access for transferring multimedia messages (MMS). Another typical scenario would be a real-time Voice over IP (VoIP) session over one network interface in parallel with best-effort web browsing on another network interface. Yet another typical scenario would be global Internet access through one network interface and local (e.g., corporate VPN) network access through another.translate error, please retry
Web server MMS Gateway
| |
-+--Internet---- ----Operator network--+-
| |
+-------+ +-------+
|WLAN AP| | GGSN |
+-------+ +-------+
| +--------+ |
+--------|Cellular|--------+
|device |
+--------+
Web server MMS Gateway
| |
-+--Internet---- ----Operator network--+-
| |
+-------+ +-------+
|WLAN AP| | GGSN |
+-------+ +-------+
| +--------+ |
+--------|Cellular|--------+
|device |
+--------+
A Cellular Device with Two Network Interfaces
具有两个网络接口的蜂窝设备
Figure 1
图1
Different network access technologies require different settings. For example, WLAN requires the Service Set Identifier (SSID), and the GPRS network requires the Access Point Name (APN) of the Gateway GPRS Support Node (GGSN), among other parameters. It is common that different accesses lead to different destination networks (e.g., to Internet, intranet, cellular network services, etc.).
不同的网络接入技术需要不同的设置。例如，WLAN需要服务集标识符（SSID），GPRS网络需要网关GPRS支持节点（GGSN）的接入点名称（APN）以及其他参数。通常，不同的访问会导致不同的目标网络（例如，到Internet、intranet、蜂窝网络服务等）。
S60 is a software platform for mobile devices running on the Symbian operating system (OS). S60 uses the concept of an Internet Access Point (IAP) [S60] that contains all information required for opening a network connection using a specific access technology. A device may have several IAPs configured for different network technologies and settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may also be 'virtual' IAPs that define parameters needed for tunnel establishment (e.g., for VPN).
S60是运行在Symbian操作系统（OS）上的移动设备的软件平台。S60使用因特网接入点（IAP）[S60]的概念，其包含使用特定接入技术打开网络连接所需的所有信息。一个设备可能有多个IAP，配置用于不同的网络技术和设置（多个WLAN SSID、GPRS APN、拨号号码等）。也可能存在“虚拟”IAP，用于定义建立隧道所需的参数（例如VPN）。
For each application, a correct IAP needs to be selected at the point when the application requires network connectivity. This is essential, as the wrong IAP may not be able to support the application or reach the desired destination. For example, an MMS application must use the correct IAP in order to reach the MMS Gateway, which typically is not accessible from the public Internet. As another example, an application might need to use the IAP associated with its corporate VPN in order to reach internal corporate servers. Binding applications to IAPs avoids several problems, such as choosing the correct DNS server in the presence of split DNS (as an application will use the DNS server list from its bound IAP) and overlapping private IPv4 address spaces used for different interfaces (as each application will use the default routes from its bound IAP).
对于每个应用程序，需要在应用程序需要网络连接时选择正确的IAP。这是至关重要的，因为错误的IAP可能无法支持应用程序或到达所需的目的地。例如，MMS应用程序必须使用正确的IAP才能访问MMS网关，该网关通常无法从公共互联网访问。作为另一个示例，应用程序可能需要使用与其公司VPN关联的IAP，以便访问内部公司服务器。将应用程序绑定到IAP可避免几个问题，例如在存在拆分DNS的情况下选择正确的DNS服务器（因为应用程序将使用其绑定IAP中的DNS服务器列表）和用于不同接口的重叠专用IPv4地址空间（因为每个应用程序将使用其绑定IAP中的默认路由）。
If multiple applications utilize the same IAP, the underlying network connection can typically be shared. This is often the case when multiple Internet-using applications are running in parallel.
如果多个应用程序使用相同的IAP，则底层网络连接通常可以共享。当多个使用Internet的应用程序并行运行时，通常会出现这种情况。
The IAP for an application can be selected in multiple ways:
可以通过多种方式选择应用程序的IAP：
o Statically: for example, from a configuration interface, via client provisioning/device management system, or at build-time.
o 静态：例如，从配置界面、通过客户端配置/设备管理系统或在构建时。
o Manually by the user: for example, each time an application starts, the user may be asked to select the IAP to use. This may be needed, for example, if a user sometimes wishes to access his corporate intranet and other times would prefer to access the Internet directly.
o 用户手动：例如，每次启动应用程序时，可能会要求用户选择要使用的IAP。例如，如果用户有时希望访问其公司内部网，而其他时候则希望直接访问Internet，则可能需要这样做。
o Automatically by the system: after the destination network has been selected statically or dynamically.
o 系统自动：静态或动态选择目标网络后。
The static approach is fine for certain applications, like MMS, for which configuration can be provisioned by the network operator and does not change often. Manual selection works but may be seen as troublesome by the user. An automatic selection mechanism needs to have some way of knowing which destination network the user, or an application, is trying access.
静态方法适用于某些应用程序，如MMS，网络运营商可以为其配置，并且不会经常更改。手动选择可以工作，但用户可能会认为这很麻烦。自动选择机制需要知道用户或应用程序正在尝试访问哪个目标网络。
S60 3rd Edition, Feature Pack 2 introduces the concept of Service Network Access Points (SNAPs) that group together IAPs that lead to the same destination. This enables static or manual selection of the destination network for an application and leaves the problem of selecting the best of the available IAPs within a SNAP to the operating system.
S60第3版，功能包2引入了服务网络接入点（Snap）的概念，这些接入点将通向同一目的地的IAP组合在一起。这允许静态或手动选择应用程序的目标网络，并将在快照中选择最佳可用IAP的问题留给操作系统。
When SNAPs are used, the operating system can notify applications when a preferred IAP, leading to the same destination, becomes available (for example, when a user comes within range of his home WLAN access point) or when the currently used IAP is no longer available. If so, applications have to reconnect via another IAP (for example, when a user goes out of range of his home WLAN and must move to the cellular network).
使用快照时，当指向同一目的地的首选IAP可用时（例如，当用户在其家庭WLAN接入点的范围内时），或当当前使用的IAP不再可用时，操作系统可以通知应用程序。如果是这样，应用程序必须通过另一个IAP重新连接（例如，当用户超出其家庭WLAN的范围并且必须移动到蜂窝网络时）。
S60 3.2 does not support RFC 3484 for source address selection mechanisms. Applications are tightly bound to the network interface selected for them or by them. For example, an application may be connected to an IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN connection. The application can change between the connections but uses only one at a time. If the interface happens to be dual-stack, then IPv4 is preferred over IPv6.
S60 3.2不支持源地址选择机制的RFC 3484。应用程序紧密地绑定到为其选择的或由其选择的网络接口。例如，应用程序可以连接到IPv6 3G连接、IPv4 3G连接、WLAN连接或VPN连接。应用程序可以在连接之间更改，但一次只能使用一个连接。如果接口恰好是双堆栈的，则IPv4优先于IPv6。
DNS configuration is per-interface; an application bound to an interface will always use the DNS settings for that interface. Hence, the device itself remembers these pieces of information for each interface separately.
DNS配置为每个接口；绑定到接口的应用程序将始终使用该接口的DNS设置。因此，设备本身会分别记住每个接口的这些信息。
S60 3.2 manages with totally overlapping addresses spaces. Each interface can even have the same IPv4 address configured on it without issues because interfaces are kept totally separate from each other. This implies that interface selection has to be done at the application layer, as from the network-layer point of view, a device is not multihomed in the IP-sense.
S60 3.2使用完全重叠的地址空间进行管理。每个接口甚至可以在其上配置相同的IPv4地址，而不会出现问题，因为接口彼此完全分开。这意味着接口选择必须在应用层进行，从网络层的角度来看，设备在IP意义上不是多址的。
Please see the S60 source documentation for more details and screenshots [S60].
有关更多详细信息和屏幕截图，请参阅S60源代码文档[S60]。
Microsoft Windows Mobile leverages a connection manager [WINDOWSMOBILE] to handle multiple network connections. This architecture centralizes and automates network connection establishment and management and makes it possible to automatically select a connection, to dial-in automatically or by user initiation, and to optimize connection and shared resource usage. The connection manager periodically re-evaluates the validity of the connection selection. The connection manager uses various attributes such as cost, security, bandwidth, error rate, and latency in its decision making.
Microsoft Windows Mobile利用连接管理器[Windows Mobile]处理多个网络连接。此体系结构集中化和自动化了网络连接的建立和管理，使自动选择连接、自动拨号或通过用户发起拨号以及优化连接和共享资源使用成为可能。连接管理器定期重新评估连接选择的有效性。连接管理器在其决策过程中使用各种属性，如成本、安全性、带宽、错误率和延迟。
The connection manager selects the best possible connection for the application based on the destination network the application wishes to reach. The selection is made between available physical and virtual connections (e.g., VPN, GPRS, WLAN, and wired Ethernet) that are known to provide connectivity to the destination network, and the selection is based on the costs associated with each connection. Different applications are bundled to use the same network connection when possible, but in conflict situations when a connection cannot be shared, higher-priority applications take precedence, and the lower-priority applications lose connectivity until the conflict situation clears.
连接管理器根据应用程序希望到达的目标网络为应用程序选择可能的最佳连接。在已知可提供到目标网络的连接的可用物理连接和虚拟连接（例如VPN、GPRS、WLAN和有线以太网）之间进行选择，选择基于与每个连接相关的成本。在可能的情况下，不同的应用程序捆绑使用相同的网络连接，但在冲突情况下，当连接无法共享时，优先级较高的应用程序优先，而优先级较低的应用程序在冲突情况清除之前将失去连接。
During operation, the connection manager opens new connections as needed and also disconnects unused or idle connections.
在操作过程中，连接管理器会根据需要打开新连接，并断开未使用或空闲的连接。
To optimize resource use, such as battery power and bandwidth, the connection manager enables applications to synchronize network connection usage by allowing applications to register their requirements for periodic connectivity. An application is notified when a suitable connection becomes available for its use.
为了优化资源使用（如电池电量和带宽），connection manager允许应用程序注册其定期连接要求，从而使应用程序能够同步网络连接使用情况。当合适的连接可供使用时，会通知应用程序。
In comparison to Windows Mobile connection management, Windows Phone 7 updates the routing functionality in the case where the terminal can be attached simultaneously to several interfaces. Windows Phone 7 selects the first hop corresponding to the interface that has a lower metric. When there are multiple interfaces, the applications system will, by default, choose from an ordered list of available interfaces. The default connection policy will prefer wired over wireless and WLAN over cellular. Hence, if an application wants to use cellular 3G as the active interface when WLAN is available, the application needs to override the default connection mapping policy. An application-specific mapping policy can be set via a Microsoft API or provisioned by the Mobile Operator. The application, in
与Windows Mobile连接管理相比，Windows Phone 7在终端可以同时连接到多个接口的情况下更新了路由功能。Windows Phone 7选择与具有较低度量的接口对应的第一个跃点。当存在多个接口时，默认情况下，应用程序系统将从可用接口的有序列表中进行选择。默认连接策略将首选有线而非无线，WLAN而非蜂窝。因此，如果应用程序希望在WLAN可用时使用蜂窝3G作为活动接口，则应用程序需要覆盖默认连接映射策略。特定于应用程序的映射策略可以通过Microsoft API设置或由移动运营商提供。应用程序，在
compliance with the security model, can request connection type by interface (WLAN, cellular), by minimum interface speed (x kbit/s, y Mbit/s), or by name (Access Point Name).
根据安全模型，可以按接口（WLAN、蜂窝）、最低接口速度（x kbit/s、y Mbit/s）或名称（接入点名称）请求连接类型。
In dual-stack systems, Windows Mobile and Windows Phone 7 implement address selection rules per [WNDS-RFC3484]. An administrator can configure a policy table that can override the default behavior of the selection algorithms. Note that the policy table specifies precedence values and preferred source prefixes for destination prefixes (see [RFC3484], Section 2.1 for details). If the system has not been configured, then the default policy table specified in [RFC3484] is used.
在双栈系统中，Windows Mobile和Windows Phone 7根据[WNDS-RFC3484]实施地址选择规则。管理员可以配置可以覆盖选择算法默认行为的策略表。请注意，策略表为目标前缀指定了优先级值和首选源前缀（有关详细信息，请参阅[RFC3484]，第2.1节）。如果尚未配置系统，则使用[RFC3484]中指定的默认策略表。
Depending on the network configuration, applications in Research In Motion (RIM) BlackBerry devices [BLACKBERRY] can use direct TCP/IP connectivity or different application proxies to establish connections over the wireless network. For instance, some wireless service providers provide an Internet gateway to offer direct TCP/IP connectivity to the Internet while some others can provide a Wireless Application Protocol (WAP) gateway that allows HTTP connections to occur over WAP. It is also possible to use the BlackBerry Enterprise Server [BLACKBERRY] as a network gateway. The BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy service to allow the application to use it as a secure gateway for managing HTTP and TCP/IP connections to the intranet or the Internet. An application connecting to the Internet can use either the BlackBerry Internet Service or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to manage connections. The problem of gateway selection is supposed to be managed independently by each application. For instance, an application can be designed to always use the default Internet gateway, while another application can be designed to use a preferred proxy when available.
根据网络配置，动态研究（RIM）黑莓设备中的应用程序[BlackBerry]可以使用直接TCP/IP连接或不同的应用程序代理通过无线网络建立连接。例如，一些无线服务提供商提供一个Internet网关，以提供到Internet的直接TCP/IP连接，而另一些无线服务提供商可以提供一个允许通过WAP进行HTTP连接的无线应用程序协议（WAP）网关。也可以将BlackBerry企业服务器[BlackBerry]用作网络网关。BlackBerry Enterprise Server提供HTTP和TCP/IP代理服务，允许应用程序将其用作安全网关，用于管理到intranet或Internet的HTTP和TCP/IP连接。连接到Internet的应用程序可以使用BlackBerry Internet服务或无线服务器提供商的Internet网关，也可以通过WLAN直接连接Internet来管理连接。网关选择问题应该由每个应用程序独立管理。例如，一个应用程序可以设计为始终使用默认的Internet网关，而另一个应用程序可以设计为在可用时使用首选代理。
A BlackBerry device [BLACKBERRY] can be attached to multiple networks simultaneously (wireless/wired). In this case, multiple network interfaces can be associated to a single IP stack or multiple IP stacks. The device, or the application, can select the network interface to be used in various ways. For instance, the device can always map the applications to the default network interface (or the default access network). When multiple IP stacks are associated to multiple interfaces, the application can select the source address corresponding to the preferred network interface. Per-interface IP stacks also allow to manage overlapping address spaces. When multiple network interfaces are aggregated into a single IP stack,
黑莓设备[BlackBerry]可以同时连接到多个网络（无线/有线）。在这种情况下，多个网络接口可以关联到单个IP堆栈或多个IP堆栈。设备或应用程序可以选择以各种方式使用的网络接口。例如，设备始终可以将应用程序映射到默认网络接口（或默认访问网络）。当多个IP堆栈与多个接口关联时，应用程序可以选择与首选网络接口对应的源地址。每个接口IP堆栈还允许管理重叠的地址空间。当多个网络接口聚合到单个IP堆栈中时，
the device associates each application to the more appropriate network interface. The selection can be based on cost, type of service (ToS), and/or user preference.
设备将每个应用程序与更合适的网络接口相关联。选择可以基于成本、服务类型（ToS）和/或用户偏好。
The BlackBerry uses per-interface DNS configuration; applications bound to a specific interface will use the DNS settings for that interface.
黑莓使用每个接口的DNS配置；绑定到特定接口的应用程序将使用该接口的DNS设置。
Android is based on a Linux kernel and, in many situations, behaves like a Linux device as described in Section 3.2.2. Per Linux, Android can manage multiple routing tables and relies on policy-based routing associated with packet-filtering capabilities (see Section 3.2.2.1 for details). Such a framework can be used to solve complex routing issue brought by multiple interfaces terminals, e.g., address space overlapping.
Android基于Linux内核，在许多情况下，其行为类似于第3.2.2节所述的Linux设备。根据Linux，Android可以管理多个路由表，并依赖于与包过滤功能相关联的基于策略的路由（有关详细信息，请参阅第3.2.2.1节）。该框架可用于解决多接口终端带来的地址空间重叠等复杂路由问题。
For incoming packets, Android implements the weak host model [RFC1122] on both IPv4 and IPv6. However, Android can also be configured to support the strong host model.
对于传入的数据包，Android在IPv4和IPv6上都实现了弱主机模型[RFC1122]。不过，Android也可以配置为支持强主机模式。
Regarding DNS configuration, Android does not list the DNS servers in the file /etc/resolv.conf, used by Linux. However, per Linux, DNS configuration is node-scoped, even if DNS configuration can rely on the DHCP client. For instance, the udhcp client [UDHCP], which is also available for Linux, can be used on Android. Each time new configuration data is received by the host from a DHCP server, regardless of which interface it is received on, the DHCP client rewrites the global configuration data with the most recent information received.
关于DNS配置，Android没有在Linux使用的/etc/resolv.conf文件中列出DNS服务器。但是，根据Linux，DNS配置是节点范围的，即使DNS配置可以依赖DHCP客户端。例如，udhcp客户端[udhcp]也可用于Linux，可以在Android上使用。每当主机从DHCP服务器接收到新的配置数据时，无论在哪个接口上接收，DHCP客户端都会使用接收到的最新信息重写全局配置数据。
Actually, the main difference between Linux and Android is on the address selection mechanism. Android versions prior to 2.2 simply prefer IPv6 connectivity over IPv4. However, it should be noted that, at the time of this writing, IPv6 is available only on WiFi and virtual interfaces but not on the cellular interface (without IPv6 in IPv4 encapsulation). Android 2.2 has been updated with [ANDROID-RFC3484], which implements some of the address selection rules defined in [RFC3484]. All [RFC3484] rules are supported, except rule 3 (avoid deprecated addresses), rule 4 (prefer home addresses), and rule 7 (prefer native transport). Also, rule 9 (use longest matching prefix) has been modified so it does not sort IPv4 addresses.
实际上，Linux和Android的主要区别在于地址选择机制。2.2之前的Android版本更喜欢IPv6连接而不是IPv4连接。然而，应该注意的是，在撰写本文时，IPv6仅在WiFi和虚拟接口上可用，而在蜂窝接口上不可用（IPv4封装中没有IPv6）。Android 2.2已更新为[Android-RFC3484]，它实现了[RFC3484]中定义的一些地址选择规则。支持所有[RFC3484]规则，但规则3（避免不推荐的地址）、规则4（首选家庭地址）和规则7（首选本机传输）除外。此外，规则9（使用最长匹配前缀）已被修改，因此它不会对IPv4地址进行排序。
The Android reference documentation describes the android.net package [ANDROID] and the ConnectivityManager class that applications can use to request the first hop to a specified destination address via a
Android参考文档描述了Android.net包[Android]和ConnectionManager类，应用程序可以使用该类通过
specified network interface (Third Generation Partnership Project (3GPP) or WLAN). Applications also ask the connection manager for permission to start using a network feature. The connection manager monitors changes in network connectivity and attempts to failover to another network if connectivity to an active network is lost. When there are changes in network connectivity, applications are notified. Applications are also able to ask for information about all network interfaces, including their availability, type, and other information.
指定的网络接口（第三代合作伙伴计划（3GPP）或WLAN）。应用程序还请求连接管理器允许开始使用网络功能。连接管理器监视网络连接的更改，并在与活动网络的连接丢失时尝试故障切换到另一个网络。当网络连接发生变化时，会通知应用程序。应用程序还可以请求有关所有网络接口的信息，包括其可用性、类型和其他信息。
This section describes how multiple-interface support is handled by Advanced Mobile Station Software (AMSS) that comes with Brew OS for all Qualcomm chipsets (e.g., Mobile Station Modem (MSM), Snapdragon, etc.). AMSS is a low-level connectivity platform, on top of which manufacturers can build to provide the necessary connectivity to applications. The interaction model between AMSS, the operating system, and the applications is not unique and depends on the design chosen by the manufacturer. The Mobile OS can let an application invoke the AMSS directly (via API) or provide its own connection manager that will request connectivity to the AMSS based on applications needs. The interaction between the OS connection manager and the applications is OS dependent.
本节介绍Brew操作系统为所有高通芯片组（如移动站调制解调器（MSM）、Snapdragon等）提供的高级移动站软件（AMS）如何处理多接口支持。AMSS是一个低级连接平台，制造商可以在其上构建，以提供必要的应用程序连接。AMS、操作系统和应用程序之间的交互模型不是唯一的，取决于制造商选择的设计。移动操作系统可以让应用程序直接（通过API）调用AMS，或者提供自己的连接管理器，该管理器将根据应用程序的需要请求与AMS的连接。操作系统连接管理器和应用程序之间的交互依赖于操作系统。
AMSS supports a concept of netpolicy that allows each application to specify the type of network connectivity desired. The netpolicy contains parameters such as access technology, IP version type, and network profile. Access technology could be a specific technology type such as CDMA or WLAN or could be a group of technologies, such as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, IPv6, or Default. The network profile identifies a type of network domain or service within a certain network technology, such as 3GPP APN or Mobile IP Home Agent. It also specifies all the mandatory parameters required to connect to the domain such authentication credentials and other optional parameters such as Quality of Service (QoS) attributes. Network profile is technology specific, and the set of parameters contained in the profile could vary for different technologies.
AMS支持netpolicy的概念，允许每个应用程序指定所需的网络连接类型。netpolicy包含访问技术、IP版本类型和网络配置文件等参数。接入技术可以是特定的技术类型，如CDMA或WLAN，也可以是一组技术，如任何无线或蜂窝。IP版本可以是IPv4、IPv6或默认版本之一。网络简档识别特定网络技术（例如3GPP APN或移动IP归属代理）内的网络域或服务的类型。它还指定连接到域所需的所有必需参数，如身份验证凭据和其他可选参数，如服务质量（QoS）属性。网络配置文件是特定于技术的，配置文件中包含的参数集可能因不同技术而异。
Two models of network usage are supported:
支持两种网络使用模式：
o Applications requiring network connectivity specify an appropriate netpolicy in order to select the desired network. The netpolicy may match one or more network interfaces. The AMSS system selection module selects the best interface out of the ones that match the netpolicy based on various criteria such as cost, speed, or other provisioned rules. The application explicitly starts the
o 需要网络连接的应用程序指定适当的netpolicy以选择所需的网络。netpolicy可以匹配一个或多个网络接口。AMSS系统选择模块根据各种标准（如成本、速度或其他配置规则）从与netpolicy匹配的接口中选择最佳接口。应用程序显式启动
selected network interface and, as a result, the application also gets bound to the corresponding network interface. All outbound packets from this application are always routed over this bound interface using the source address of the interface.
选定的网络接口，因此应用程序也会绑定到相应的网络接口。来自此应用程序的所有出站数据包始终使用接口的源地址通过此绑定接口路由。
o Applications may rely on a separate connection manager to control (e.g., start/stop) the network interface. In this model, applications are not necessarily bound to any one interface. All outbound packets from such applications are routed on one of the interfaces that match its netpolicy. The routing decision is made individually for each packet and selects the best interface based on the criteria described above and the destination address. Source address is always assigned to the interface used to transmit the packet.
o 应用程序可能依赖单独的连接管理器来控制（例如，启动/停止）网络接口。在此模型中，应用程序不一定绑定到任何一个接口。来自此类应用程序的所有出站数据包都在与其netpolicy匹配的一个接口上路由。为每个分组分别做出路由决策，并基于上述标准和目的地地址选择最佳接口。源地址始终分配给用于传输数据包的接口。
All of the routing/interface selection decisions are based on the netpolicy and not just on the destination address to avoid the issue of overlapping private IPv4 addresses. This also allows multiple interfaces to be configured with the same IP address, for example, to handle certain tunneling scenarios. Applications that do not specify a netpolicy are routed by AMSS to the best possible interface using the default netpolicy. Default netpolicy could be pre-defined or provisioned by the administrator or operator. Hence, the default interface could vary from device to device and also depends upon the available networks at any given time.
所有路由/接口选择决策都基于netpolicy，而不仅仅是目标地址，以避免私有IPv4地址重叠的问题。这还允许使用相同的IP地址配置多个接口，例如，用于处理某些隧道方案。未指定netpolicy的应用程序由AMS使用默认netpolicy路由到最佳接口。默认netpolicy可以由管理员或操作员预定义或设置。因此，默认接口可能因设备而异，也取决于任何给定时间的可用网络。
AMSS allows each interface to be configured with its own set of DNS configuration parameters (e.g., list of DNS servers, domain names, etc.). The interface selected to make a DNS resolution is the one to which the application making the DNS query is bound. Applications can also specify a different netpolicy as part of the DNS request to select another interface for DNS resolution. Regardless, all the DNS queries are sent only over this selected interface using the DNS configuration from the interface. DNS resolution is first attempted with the primary server configured in the interface. If a response is not received, the queries are sent to all the other servers configured in the interface in a sequential manner using a backoff mechanism.
AMS允许每个接口使用自己的一组DNS配置参数（例如，DNS服务器列表、域名等）进行配置。选择用于进行DNS解析的接口是进行DNS查询的应用程序绑定到的接口。应用程序还可以指定不同的netpolicy作为DNS请求的一部分，以选择另一个接口进行DNS解析。不管怎样，所有DNS查询都仅使用接口中的DNS配置通过此选定接口发送。首先尝试使用接口中配置的主服务器进行DNS解析。如果未收到响应，则使用退避机制以顺序方式将查询发送到接口中配置的所有其他服务器。
Arena, a mobile OS based on Linux, provides a connection manager, which is described in [MIF-ARENA] and [MIF-REQS]. The Arena connection manager provides a means for applications to register their connectivity requirement. The connection manager can then choose an interface that matches the application's needs while
Arena是基于Linux的移动操作系统，提供了连接管理器，如[MIF-Arena]和[MIF-REQS]所述。Arena连接管理器为应用程序提供了一种注册其连接要求的方法。然后，连接管理器可以选择一个与应用程序的需要相匹配的接口
considering other factors such as availability, cost, and stability. Also, the connection manager can handle multiple-interface issues such as connection sharing.
考虑其他因素，如可用性、成本和稳定性。此外，连接管理器还可以处理多个接口问题，例如连接共享。
Multiple-interface issues also occur in desktop environments in those cases where a desktop host has multiple (logical or physical) interfaces connected to networks with different reachability properties, such as one interface connected to the global Internet, while another interface is connected to a corporate VPN.
在桌面主机有多个（逻辑或物理）接口连接到具有不同可达性属性的网络的情况下，桌面环境中也会出现多个接口问题，例如一个接口连接到全球互联网，而另一个接口连接到公司VPN。
The multiple-interface functionality currently implemented in Microsoft Windows operation systems is described in more detail in [MULTIHOMING].
目前在Microsoft Windows操作系统中实现的多接口功能在[MULTIHOMING]中有更详细的描述。
It is possible, although not often desirable, to configure default routers on more than one Windows interface. In this configuration, Windows will use the default route on the interface with the lowest routing metric (i.e., the fastest interface). If multiple interfaces share the same metric, the behavior will differ based on the version of Windows in use. Prior to Windows Vista, the packet would be routed out of the first interface that was bound to the TCP/IP stack, the preferred interface. In Windows Vista, host-to-router load sharing [RFC4311] is used for both IPv4 and IPv6.
在多个Windows界面上配置默认路由器是可能的，尽管通常不可取。在此配置中，Windows将在具有最低路由度量（即，最快接口）的接口上使用默认路由。如果多个接口共享相同的度量，则行为将因使用的Windows版本而异。在Windows Vista之前，数据包将从绑定到TCP/IP堆栈的第一个接口（首选接口）路由出去。在Windows Vista中，主机到路由器负载共享[RFC4311]用于IPv4和IPv6。
If the source address of the outgoing packet has not been determined by the application, Windows will choose from the addresses assigned to its interfaces. Windows implements [RFC3484] for source address selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows Vista, IPv4 simply chose the first address on the outgoing interface.
如果应用程序尚未确定传出数据包的源地址，Windows将从分配给其接口的地址中进行选择。Windows在IPv6中为源地址选择实现[RFC3484]，在Windows Vista中为IPv4实现[RFC3484]。在Windows Vista之前，IPv4只需选择传出接口上的第一个地址。
For incoming packets, Windows will check if the destination address matches one of the addresses assigned to its interfaces. Windows has implemented the weak host model [RFC1122] on IPv4 in Windows 2000, Windows XP, and Windows Server 2003. The strong host model became the default for IPv4 in Windows Vista and Windows Server 2008; however, the weak host model is available via per-interface configuration. IPv6 has always implemented the strong host model.
对于传入的数据包，Windows将检查目标地址是否与分配给其接口的地址之一匹配。Windows在Windows 2000、Windows XP和Windows Server 2003中的IPv4上实现了弱主机模型[RFC1122]。在Windows Vista和Windows Server 2008中，强主机模式成为IPv4的默认模式；但是，弱主机模型可通过每个接口配置使用。IPv6始终实现了强主机模型。
Windows largely relies on suffixes to solve DNS resolution issues. Suffixes are used for four different purposes:
Windows主要依靠后缀来解决DNS解析问题。后缀有四种不同的用途：
1. DNS Suffix Search List (aka domain search list): suffix is added to non-FQDNs (Fully Qualified Domain Names).
1. DNS后缀搜索列表（又名域搜索列表）：将后缀添加到非FQDNs（完全限定的域名）中。
2. Interface-specific suffix list: allows sending different DNS queries to different DNS servers.
2. 接口特定后缀列表：允许向不同的DNS服务器发送不同的DNS查询。
3. Suffix to control Dynamic DNS Updates: determines which DNS server will receive a dynamic update for a name with a certain suffix.
3. 控制动态DNS更新的后缀：确定哪个DNS服务器将接收具有特定后缀的名称的动态更新。
4. Suffix in the Name Resolution Policy Table [NRPT]: aids in identifying a namespace that requires special handling (feature available only after Windows 7 and its server counterpart, Windows Server 2008 R2).
4. 名称解析策略表[NRPT]中的后缀：有助于识别需要特殊处理的命名空间（此功能仅在Windows 7及其服务器对应项Windows server 2008 R2之后可用）。
However, this section focuses on the interface-specific suffix list since it is the only suffix usage in the scope of this document.
但是，本节重点介绍特定于接口的后缀列表，因为它是本文档范围内唯一的后缀用法。
DNS configuration information can be host-wide or interface specific. Host-wide DNS configuration is input via static configuration or, in sites that use Active Directory, Microsoft's Group Policy. Interface-specific DNS configuration can be input via static configuration or via DHCP.
DNS配置信息可以是主机范围的，也可以是特定于接口的。主机范围的DNS配置通过静态配置输入，或者在使用Active Directory的站点中，通过Microsoft的组策略输入。接口特定的DNS配置可以通过静态配置或DHCP输入。
The host-wide configuration consists of a primary DNS suffix to be used for the local host, as well as a list of suffixes that can be appended to names being queried. Before Windows Vista and Windows Server 2008, there was also a host-wide DNS server list that took precedence over per-interface DNS configuration.
主机范围的配置包括用于本地主机的主DNS后缀，以及可附加到所查询名称的后缀列表。在Windows Vista和Windows Server 2008之前，还有一个主机范围的DNS服务器列表优先于每个接口的DNS配置。
The interface-specific DNS configuration comprises an interface-specific suffix list and a list of DNS server IP addresses.
接口特定DNS配置包括接口特定后缀列表和DNS服务器IP地址列表。
Windows uses a host-wide "effective" server list for an actual query, where the effective server list may be different for different names. In the list of DNS server addresses, the first server is considered the "primary" server, with all other servers being secondary.
Windows使用主机范围的“有效”服务器列表进行实际查询，其中有效服务器列表对于不同的名称可能不同。在DNS服务器地址列表中，第一台服务器被视为“主”服务器，而所有其他服务器都是辅助服务器。
When a DNS query is performed in Windows, the query is first sent to the primary DNS server on the preferred interface. If no response is received in one second, the query is sent to the primary DNS servers on all interfaces under consideration. If no response is received for 2 more seconds, the DNS server sends the query to all of the DNS
在Windows中执行DNS查询时，查询首先发送到首选接口上的主DNS服务器。如果在一秒钟内没有收到响应，查询将发送到所有正在考虑的接口上的主DNS服务器。如果在2秒以上没有收到响应，DNS服务器将向所有DNS服务器发送查询
servers on the DNS server lists for all interfaces under consideration. If the host still doesn't receive a response after 4 seconds, it will send to all of the servers again and wait 8 seconds for a response.
DNS服务器上的服务器列出了考虑中的所有接口。如果主机在4秒后仍然没有收到响应，它将再次发送到所有服务器，并等待8秒以获得响应。
In addition to the two commonly used routing tables (the local and main routing tables), the kernel can support up to 252 additional routing tables that can be added in the file /etc/iproute2/rt_tables. A routing table can contain an arbitrary number of routes; the selection of route is classically made according to the destination address of the packet. Linux also provides more flexible routing selection based on the type of service, scope, and output interface. In addition, since kernel version 2.2, Linux supports policy-based routing using the multiple routing tables capability and a routing policy database. This database contains routing rules used by the kernel. Using policy-based routing, the source address, the ToS flags, the interface name, and an "fwmark" (a mark added in the data structure representing the packet) can be used as route selectors.
除了两个常用的路由表（本地路由表和主路由表），内核最多可以支持252个额外的路由表，这些路由表可以添加到文件/etc/iproute2/rt_表中。路由表可以包含任意数量的路由；路由的选择通常是根据数据包的目的地址进行的。Linux还提供了基于服务类型、作用域和输出接口的更灵活的路由选择。此外，由于内核版本2.2，Linux支持使用多路由表功能和路由策略数据库的基于策略的路由。此数据库包含内核使用的路由规则。使用基于策略的路由，源地址、ToS标志、接口名称和“fwmark”（添加在数据结构中表示数据包的标记）可以用作路由选择器。
Policy-based routing can be used in addition to Linux packet-filtering capabilities, e.g., provided by the "iptables" tool. In a multiple-interface context, this tool can be used to mark the packets, i.e., assign a number to fwmark, in order to select the routing rule according to the type of traffic. This mark can be assigned according to parameters like protocol, source and/or destination addresses, port number, and so on.
除了Linux数据包过滤功能之外，还可以使用基于策略的路由，例如，由“iptables”工具提供。在多接口上下文中，此工具可用于标记数据包，即为fwmark分配一个编号，以便根据流量类型选择路由规则。可以根据协议、源和/或目标地址、端口号等参数分配此标记。
Such a routing management framework allows management of complex situations such as address space overlapping. In this situation, the administrator can use packet marking and policy-based routing to select the correct interface.
这种路由管理框架允许管理地址空间重叠等复杂情况。在这种情况下，管理员可以使用包标记和基于策略的路由选择正确的接口。
By default, source address selection follows the following basics rules. The initial source address for an outbound packet can be chosen by the application using the bind() call. Without information from the application, the kernel chooses the first address configured on the interface that belongs to the same subnet as the destination address or the next-hop router.
默认情况下，源地址选择遵循以下基本规则。出站数据包的初始源地址可以由应用程序使用bind（）调用来选择。如果没有来自应用程序的信息，内核将选择接口上配置的第一个地址，该地址与目标地址或下一跳路由器属于同一子网。
Linux also implements [RFC3484] for source address selection for IPv6 and dual-stack configurations. However, the address-sorting rules from [RFC3484] are not always adequate. For this reason, Linux allows the system administrator to dynamically change the sorting. This can be achieved with the /etc/gai.conf file.
Linux还为IPv6和双堆栈配置的源地址选择实现[RFC3484]。但是，[RFC3484]中的地址排序规则并不总是足够的。因此，Linux允许系统管理员动态更改排序。这可以通过/etc/gai.conf文件实现。
For incoming packets, Linux checks if the destination address matches one of the addresses assigned to its interfaces and then processes the packet according the configured host model. By default, Linux implements the weak host model [RFC1122] on both IPv4 and IPv6. However, Linux can also be configured to support the strong host model.
对于传入的数据包，Linux检查目标地址是否与分配给其接口的地址之一匹配，然后根据配置的主机模型处理数据包。默认情况下，Linux在IPv4和IPv6上都实现弱主机模型[RFC1122]。但是，Linux也可以配置为支持强主机模型。
Most BSD and Linux distributions rely on their DHCP client to handle the configuration of interface-specific information (such as an IP address and netmask) and a set of system-wide configuration information (such a DNS server list, an NTP server list, and default routes). Users of these operating systems have the choice of using any DHCP client available for their platform with an operating system default. This section discusses the behavior of several DHCP clients that may be used with Linux and BSD distributions.
大多数BSD和Linux发行版依靠其DHCP客户端来处理特定于接口的信息（如IP地址和网络掩码）和一组系统范围的配置信息（如DNS服务器列表、NTP服务器列表和默认路由）的配置。这些操作系统的用户可以选择在操作系统默认值下使用其平台上可用的任何DHCP客户端。本节讨论几个可用于Linux和BSD发行版的DHCP客户端的行为。
The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with specific instructions for each interface. However, each time new configuration data is received by the host from a DHCP server, regardless of which interface it is received on, the DHCP client rewrites the global configuration data, such as the default routes and the DNS server list (in /etc/resolv.conf) with the most recent information received. Therefore, the last configured interface always become the primary one. The ISC DHCPv6 client behaves similarly. However, OpenBSD provides two mechanisms that prevent the configuration that the user made manually from being overwritten:
Internet Systems Consortium（ISC）DHCP客户端[ISCDHCP]及其OpenBSD的衍生产品[OPENBSDDHCLIENT]可以为每个接口配置特定的指令。但是，每当主机从DHCP服务器接收到新的配置数据时，无论在哪个接口上接收，DHCP客户端都会用接收到的最新信息重写全局配置数据，例如默认路由和DNS服务器列表（在/etc/resolv.conf中）。因此，最后配置的接口始终成为主要接口。ISC DHCPv6客户端的行为类似。但是，OpenBSD提供了两种机制来防止用户手动进行的配置被覆盖：
o OPTION MODIFIERS (default, supersede, prepend, and append): this mechanism allows the user to override the DHCP options. For example, the supersede statement defines, for some options, the values the client should always use rather than any value supplied by the server.
o 选项修饰符（默认、取代、前置和追加）：此机制允许用户覆盖DHCP选项。例如，对于某些选项，“取代”语句定义了客户端应始终使用的值，而不是服务器提供的任何值。
o resolv.conf.tail: this allows the user to append anything to the resolv.conf file created by the DHCP client.
o resolv.conf.tail：这允许用户向DHCP客户端创建的resolv.conf文件追加任何内容。
The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the ISC client. It replaces the DNS server list in /etc/resolv.conf and the default routes each time new DHCP information is received on any
Phystech dhcpcd客户端[PHYSTECHDHCPC]的行为与ISC客户端类似。每次在任何服务器上接收到新的DHCP信息时，它都会替换/etc/resolv.conf中的DNS服务器列表和默认路由
interface. However, the -R flag can be used to instruct the client to not replace the DNS servers in /etc/resolv.conf. However, this flag is a global flag for the DHCP server and is therefore applicable to all interfaces. When dhcpd is called with the -R flag, the DNS servers are never replaced.
界面但是，-R标志可用于指示客户端不要替换/etc/resolv.conf中的DNS服务器。但是，此标志是DHCP服务器的全局标志，因此适用于所有接口。当使用-R标志调用dhcpd时，DNS服务器永远不会被替换。
The pump client [PUMP] also behaves similarly to the ISC client. It replaces the DNS servers in /etc/resolv.conf and the default routes each time new DHCP information is received on any interface. However, the nodns and nogateway options can be specified on a per-interface basis, enabling the user to define which interface should be used to obtain the global configuration information.
泵客户端[泵]的行为也与ISC客户端类似。每次在任何接口上接收到新的DHCP信息时，它都会替换/etc/resolv.conf中的DNS服务器和默认路由。但是，可以在每个接口的基础上指定nodns和nogateway选项，使用户可以定义应该使用哪个接口来获取全局配置信息。
The udhcp client [UDHCP] is often used in embedded platforms based on busybox. The udhcp client behaves similarly to the ISC client. It rewrites default routes and the DNS server list each time new DHCP information is received.
udhcp客户端[udhcp]通常用于基于busybox的嵌入式平台。udhcp客户端的行为与ISC客户端类似。每次收到新的DHCP信息时，它都会重写默认路由和DNS服务器列表。
Red Hat-based distributions, such as Red Hat, Centos, and Fedora have a per-interface configuration option (PEERDNS) that indicates that the DNS server list should not be updated based on configuration received on that interface.
基于Red Hat的发行版（如Red Hat、Centos和Fedora）具有每个接口的配置选项（PEERDS），该选项指示不应根据在该接口上接收的配置更新DNS服务器列表。
Most configurable DHCP clients can be set to define a primary interface; only that interface is used for the global configuration data. However, this is limited, since a mobile host might not always have the same set of interfaces available. Connection managers may help in this situation.
大多数可配置的DHCP客户端可以设置为定义主接口；只有该接口用于全局配置数据。但是，这是有限的，因为移动主机可能并不总是具有相同的可用接口集。连接管理器在这种情况下可能会有所帮助。
Some distributions also have a connection manager. However, most connection managers serve as a GUI to the DHCP client and therefore do not change the functionality described above.
某些发行版还具有连接管理器。但是，大多数连接管理器充当DHCP客户端的GUI，因此不会更改上述功能。
The authors of this document would like to thank following people for their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien Laganier, and Steinar H. Gunderson.
本文件的作者感谢以下人士的投入和反馈：Dan Wing、Hui Deng、Jari Arkko、Julien Laganier和Steinar H.Gunderson。
This document describes current operating system implementations and how they handle the issues raised in the MIF problem statement. While it is possible that the currently implemented mechanisms described in this document may affect the security of the systems described, this document merely reports on current practice. It does not attempt to analyze the security properties (or any other architectural properties) of the currently implemented mechanisms.
本文档描述了当前的操作系统实现以及它们如何处理MIF问题陈述中提出的问题。虽然本文件中描述的当前实施的机制可能会影响所述系统的安全性，但本文件仅报告了当前实践。它不会尝试分析当前实现的机制的安全属性（或任何其他体系结构属性）。
The following people contributed most of the per-operating system information found in this document:
以下人员提供了本文档中每个操作系统的大部分信息：
o Marc Blanchet, Viagenie
o 马克·布兰切特，维亚吉尼
o Hua Chen, Leadcore Technology, Ltd.
o 陈华，领芯科技有限公司。
o Yan Zhang, Leadcore Technology, Ltd.
o 张燕，领芯科技有限公司。
o Shunan Fan, Huawei Technology
o 范树南，华为科技
o Jian Yang, Huawei Technology
o 杨健，华为科技
o Gabriel Montenegro, Microsoft Corporation
o 加布里埃尔·黑山，微软公司
o Shyam Seshadri, Microsoft Corporation
o Shyam Seshadri，微软公司
o Dave Thaler, Microsoft Corporation
o 戴夫·泰勒，微软公司
o Kevin Chin, Microsoft Corporation
o 陈凯文，微软公司
o Teemu Savolainen, Nokia
o 诺基亚Teemu Savolainen
o Tao Sun, China Mobile
o 孙涛，中国移动
o George Tsirtsis, Qualcomm
o George Tsirtsis，高通公司
o David Freyermuth, France Telecom
o David Freyermuth，法国电信
o Aurelien Collet, Altran
o 奥雷林·科莱，奥特兰
o Giyeong Son, RIM
o 林琼森
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，2011年11月。
[ANDROID] Google Inc., "Android developers: package android.net", <http://developer.android.com/reference/android/net/ ConnectivityManager.html>.
[安卓]谷歌公司，“安卓开发者：安卓.net软件包”<http://developer.android.com/reference/android/net/ ConnectivityManager.html>。
[ANDROID-RFC3484] Gunderson, S., "RFC 3484 support for Android", 2010, <http://gitorious.org/0xdroid/bionic/commit/ 9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>.
[ANDROID-RFC3484]Gunderson，S.，“RFC 3484对ANDROID的支持”，2010年<http://gitorious.org/0xdroid/bionic/commit/ 9AB75D4C803E91B7F1B656FFBE2AD32C52A86F9>。
[BLACKBERRY] Research In Motion Limited, "BlackBerry Java Development Environment - Fundamentals Guide: Wireless gateways", <http://na.blackberry.com/eng/ deliverables/5827/Wireless_gateways_447132_11.jsp>.
[BLACKBERRY]Research In Motion Limited，“BLACKBERRY Java开发环境-基础知识指南：无线网关”<http://na.blackberry.com/eng/ 可交付成果/5827/Wireless_gateways_447132_11.jsp>。
[ISCDHCP] Internet Software Consortium, "ISC DHCP", <http://www.isc.org/software/dhcp>.
[ISC DHCP]互联网软件联盟，“ISC DHCP”<http://www.isc.org/software/dhcp>.
[MIF-ARENA] Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network Connection Manager in Arena Platform", Work in Progress, February 2009.
[MIF-ARENA]Zhang，Y.，Sun，T.，和H.Chen，“ARENA平台中的多接口网络连接管理器”，正在进行的工作，2009年2月。
[MIF-REQS] Yang, J., Sun, T., and S. Fan, "Multi-interface Connection Manager Implementation and Requirements", Work in Progress, March 2009.
[MIF-REQS]Yang，J.，Sun，T.，和S.Fan，“多接口连接管理器的实施和要求”，正在进行的工作，2009年3月。
[MULTIHOMING] Montenegro, G., Thaler, D., and S. Seshadri, "Multiple Interfaces on Windows", Work in Progress, March 2009.
[MULTIHOMING]黑山，G.，Thaler，D.，和S.Seshadri，“Windows上的多界面”，正在进行的工作，2009年3月。
[NRPT] Davies, J., "Name Resolution Policy Table", February 2010, <http://technet.microsoft.com/en-us/magazine/ff394369.aspx>.
[NRPT]Davies，J.，“名称解析策略表”，2010年2月<http://technet.microsoft.com/en-us/magazine/ff394369.aspx>.
[OPENBSDDHCLIENT] OpenBSD, "OpenBSD dhclient", <http://www.openbsd.org/>.
[OPENBSDDHCLIENT]OpenBSD，“OpenBSD dhclient”<http://www.openbsd.org/>.
[PHYSTECHDHCPC] Phystech, "dhcpcd", <http://www.phystech.com/download/dhcpcd.html>.
[PHYSTECHDHCPC]Phystech，“dhcpcd”<http://www.phystech.com/download/dhcpcd.html>.
[PUMP] Red Hat, "PUMP", 2009, <http://redhat.com>.
[泵]红帽，“泵”，2009年<http://redhat.com>.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[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月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311]Hinden，R.和D.Thaler，“IPv6主机到路由器负载共享”，RFC 4311，2005年11月。
[S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 2007, <http://www.forum.nokia.com/info/ sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/ S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>.
[S60]诺基亚公司，“S60平台：IP承载管理”，2007年<http://www.forum.nokia.com/info/ sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_平台_IP_承载_管理_v1_0_en.pdf.html>。
[UDHCP] Busybox, "uDHCP", <http://busybox.net/downloads/BusyBox.html>.
[UDHCP]总线箱，“UDHCP”<http://busybox.net/downloads/BusyBox.html>.
[WINDOWSMOBILE] Microsoft Corporation, "SDK Documentation for Windows Mobile-Based Smartphones: Connection Manager", 2005, <http://msdn.microsoft.com/en-us/library/ aa457829.aspx>.
[WINDOWSMOBILE]微软公司，“基于Windows Mobile的智能手机SDK文档：连接管理器”，2005年<http://msdn.microsoft.com/en-us/library/ aa457829.aspx>。
[WNDS-RFC3484] Microsoft Corporation, "SDK Documentation for Windows Mobile-Based Smartphones: Default Address Selection for IPv6", April 2010, <http://msdn.microsoft.com/en-us/ library/aa925716.aspx>.
[WNDS-RFC3484]微软公司，“基于Windows Mobile的智能手机SDK文档：IPv6的默认地址选择”，2010年4月<http://msdn.microsoft.com/en-us/ 库/aa925716.aspx>。
Authors' Addresses
作者地址
Margaret Wasserman Painless Security, LLC 356 Abbott Street North Andover, MA 01845 USA
Margaret Wasserman无痛安全有限责任公司，地址：美国马萨诸塞州安多弗市阿伯特北街356号，邮编：01845
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Pierrick Seite France Telecom - Orange 4, rue du clos courtel BP 91226 Cesson-Sevigne 35512 France
Pierrick Seite法国电信-法国克莱斯科特尔街橙色4号BP 91226塞森塞维涅35512
EMail: pierrick.seite@orange.com
EMail: pierrick.seite@orange.com