Internet Engineering Task Force (IETF) D. Anipko, Ed.
Request for Comments: 7556 Unaffiliated
Category: Informational June 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Anipko, Ed.
Request for Comments: 7556 Unaffiliated
Category: Informational June 2015
ISSN: 2070-1721
Multiple Provisioning Domain Architecture
多供应域体系结构
Abstract
摘要
This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.
本文档是多接口体系结构设计团队的工作成果。它概述了可同时连接到多个网络的节点遇到的一些问题的解决方案框架。该框架定义了供应域（PvD）的概念，它是一组一致的网络配置信息。PvD感知节点从其连接到的网络和/或其他来源学习PvD特定信息。PVD用于在存在多个并发连接时实现分离和配置一致性。
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/rfc7556.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7556.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 5
2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 6
2.3. Relationship between PvDs and Interfaces . . . . . . . . 7
2.4. PvD Identity/Naming . . . . . . . . . . . . . . . . . . . 8
2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 8
3. Conveying PvD Information . . . . . . . . . . . . . . . . . . 9
3.1. Separate Messages or One Message? . . . . . . . . . . . . 9
3.2. Securing PvD Information . . . . . . . . . . . . . . . . 10
3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
3.4. Retracting/Updating PvD Information . . . . . . . . . . . 10
3.5. Conveying Configuration Information Using IKEv2 . . . . . 10
4. Example Network Configurations . . . . . . . . . . . . . . . 11
4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 11
4.2. A Node with a VPN Connection . . . . . . . . . . . . . . 12
4.3. A Home Network and a Network Operator with Multiple PvDs 12
5. Reference Model for the PvD-Aware Node . . . . . . . . . . . 13
5.1. Constructions and Maintenance of Separate PvDs . . . . . 13
5.2. Consistent Use of PvDs for Network Connections . . . . . 14
5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 14
5.2.2. Next-Hop and Source Address Selection . . . . . . . . 15
5.2.3. Listening Applications . . . . . . . . . . . . . . . 16
5.2.3.1. Processing of Incoming Traffic . . . . . . . . . 16
5.2.4. Enforcement of Security Policies . . . . . . . . . . 17
5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . 18
5.4. Relationship to Interface Management and Connection
Managers . . . . . . . . . . . . . . . . . . . . . . . . 18
6. PvD Support in APIs . . . . . . . . . . . . . . . . . . . . . 19
6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . 20
7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . 20
7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . 20
7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . 21
7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 5
2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 6
2.3. Relationship between PvDs and Interfaces . . . . . . . . 7
2.4. PvD Identity/Naming . . . . . . . . . . . . . . . . . . . 8
2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 8
3. Conveying PvD Information . . . . . . . . . . . . . . . . . . 9
3.1. Separate Messages or One Message? . . . . . . . . . . . . 9
3.2. Securing PvD Information . . . . . . . . . . . . . . . . 10
3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
3.4. Retracting/Updating PvD Information . . . . . . . . . . . 10
3.5. Conveying Configuration Information Using IKEv2 . . . . . 10
4. Example Network Configurations . . . . . . . . . . . . . . . 11
4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 11
4.2. A Node with a VPN Connection . . . . . . . . . . . . . . 12
4.3. A Home Network and a Network Operator with Multiple PvDs 12
5. Reference Model for the PvD-Aware Node . . . . . . . . . . . 13
5.1. Constructions and Maintenance of Separate PvDs . . . . . 13
5.2. Consistent Use of PvDs for Network Connections . . . . . 14
5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 14
5.2.2. Next-Hop and Source Address Selection . . . . . . . . 15
5.2.3. Listening Applications . . . . . . . . . . . . . . . 16
5.2.3.1. Processing of Incoming Traffic . . . . . . . . . 16
5.2.4. Enforcement of Security Policies . . . . . . . . . . 17
5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . 18
5.4. Relationship to Interface Management and Connection
Managers . . . . . . . . . . . . . . . . . . . . . . . . 18
6. PvD Support in APIs . . . . . . . . . . . . . . . . . . . . . 19
6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . 20
7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . 20
7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . 20
7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . 21
7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
Nodes attached to multiple networks may encounter problems from conflicting configuration between the networks or attempts to simultaneously use more than one network. While various techniques are currently used to tackle these problems [RFC6419], in many cases issues may still appear. The Multiple Interfaces Problem Statement document [RFC6418] describes the general landscape and discusses many of the specific issues and scenario details.
连接到多个网络的节点可能会遇到网络之间配置冲突或试图同时使用多个网络的问题。虽然目前使用各种技术来解决这些问题[RFC6419]，但在许多情况下，问题仍然会出现。多接口问题陈述文档[RFC6418]描述了总体情况，并讨论了许多具体问题和场景细节。
Problems, enumerated in [RFC6418], can be grouped into 3 categories:
[RFC6418]中列举的问题可分为3类：
1. Lack of consistent and distinctive management of configuration elements associated with different networks.
1. 对与不同网络相关的配置元素缺乏一致和独特的管理。
2. Inappropriate mixed use of configuration elements associated with different networks during a particular network activity or connection.
2. 在特定网络活动或连接期间，与不同网络关联的配置元素的不当混合使用。
3. Use of a particular network that is not consistent with the intended use of the network, or the intent of the communicating parties, leading to connectivity failure and/or other undesired consequences.
3. 使用与网络的预期用途或通信方的意图不一致的特定网络，导致连接故障和/或其他不期望的后果。
An example of (1) is a single, node-scoped list of DNS server IP addresses learned from different networks leading to failures or delays in resolution of names from particular namespaces; an example of (2) is an attempt to resolve the name of an HTTP proxy server learned from network A using a DNS server learned from network B; and an example of (3) is the use of an employer-provided VPN connection for peer-to-peer connectivity unrelated to employment activities.
（1）的一个示例是从不同网络中获取的DNS服务器IP地址的单个节点范围列表，该列表导致在解析特定名称空间中的名称时出现故障或延迟；（2）的示例是尝试使用从网络B学习的DNS服务器解析从网络A学习的HTTP代理服务器的名称；（3）的一个例子是使用雇主提供的VPN连接进行与就业活动无关的点对点连接。
This architecture provides solutions to these categories of problems, respectively, by:
该体系结构分别通过以下方式为这些类别的问题提供解决方案：
1. Introducing the formal notion of PvDs, including identity for PvDs, and describing mechanisms for nodes to learn the intended associations between acquired network configuration information elements.
1. 介绍PVD的形式化概念，包括PVD的标识，并描述节点学习获取的网络配置信息元素之间预期关联的机制。
2. Introducing a reference model for PvD-aware nodes that prevents the inadvertent mixed use of configuration information that may belong to different PvDs.
2. 引入PvD感知节点的参考模型，以防止无意中混合使用可能属于不同PvD的配置信息。
3. Providing recommendations on PvD selection based on PvD identity and connectivity tests for common scenarios.
3. 根据常见场景的PvD身份和连通性测试，提供关于PvD选择的建议。
Provisioning Domain: A consistent set of network configuration information. Classically, all of the configuration information available on a single interface is provided by a single source (such as a network administrator) and can therefore be treated as a single provisioning domain. In modern IPv6 networks, multihoming can result in more than one provisioning domain being present on a single link. In some scenarios, it is also possible for elements of the same PvD to be present on multiple links.
配置域：一组一致的网络配置信息。通常，单个接口上可用的所有配置信息都由单个源（如网络管理员）提供，因此可以将其视为单个配置域。在现代IPv6网络中，多归属可能导致单个链路上存在多个供应域。在某些情况下，相同PvD的元件也可能出现在多个链路上。
Typical examples of information in a provisioning domain learned from the network are:
从网络中获取的供应域中的信息的典型示例有：
* Source address prefixes for use by connections within the provisioning domain
* 供配置域内的连接使用的源地址前缀
* IP address(es) of the DNS server(s)
* DNS服务器的IP地址
* Name of the HTTP proxy server (if available)
* HTTP代理服务器的名称（如果可用）
* DNS suffixes associated with the network
* 与网络关联的DNS后缀
* Default gateway address
* 默认网关地址
PvD-aware node: A node that supports the association of network configuration information into PvDs and the use of these PvDs to serve requests for network connections in ways consistent with the recommendations of this architecture.
支持PvD的节点：支持将网络配置信息关联到PvD中，并使用这些PvD以符合此体系结构建议的方式服务网络连接请求的节点。
PvD-aware application: An application that contains code and/or application-specific configuration information explicitly aware of the notion of PvD and/or specific types of PvD elements or properties.
支持PvD的应用程序：包含明确了解PvD概念和/或特定类型的PvD元素或属性的代码和/或特定于应用程序的配置信息的应用程序。
A node may receive explicit information from the network and/or other sources conveying the presence of PvDs and the association of particular network information with a particular PvD. PvDs that are constructed based on such information are referred to as "explicit" in this document.
节点可以从网络和/或其他源接收明确信息，传达PvD的存在以及特定网络信息与特定PvD的关联。基于此类信息构建的PVD在本文件中称为“明确”。
Protocol changes or extensions will likely be required to support explicit PvDs through IETF-defined mechanisms. As an example, one could think of one or more DHCP options carrying PvD identity and/or its elements.
协议变更或扩展可能需要通过IETF定义的机制支持显式PVD。例如，可以想到一个或多个带有PvD标识和/或其元素的DHCP选项。
A different approach could be the introduction of a DHCP option that only carries the identity of a PvD. Here, the associations between network information elements with the identity is implemented by the respective protocols, for example, with a Router Discovery [RFC4861] option associating an address range with a PvD. Additional discussion can be found in Section 3.
另一种方法可能是引入仅携带PvD标识的DHCP选项。这里，网络信息元素与标识之间的关联由相应的协议实现，例如，通过将地址范围与PvD关联的路由器发现[RFC4861]选项。更多讨论见第3节。
Other examples of a delivery mechanism for PvDs are key exchange or tunneling protocols, such as the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] that allows the transport of host configuration information.
pvd的传递机制的其他示例是密钥交换或隧道协议，例如允许传输主机配置信息的因特网密钥交换协议版本2（IKEv2）[RFC7296]。
Specific, existing, or new features of networking protocols that enable the delivery of PvD identity and association with various network information elements will be defined in companion design documents.
网络协议的特定、现有或新功能将在配套设计文件中定义，这些功能可实现PvD身份的交付以及与各种网络信息元素的关联。
Link-specific and/or vendor-proprietary mechanisms for the discovery of PvD information (differing from IETF-defined mechanisms) can be used by nodes either separate from or in conjunction with IETF-defined mechanisms, providing they allow the discovery of the necessary elements of the PvD(s).
用于发现PvD信息的链路特定和/或供应商专有机制（不同于IETF定义的机制）可由独立于IETF定义的机制或与IETF定义的机制结合使用，前提是它们允许发现PvD的必要元素。
In all cases, nodes must by default ensure that the lifetime of all dynamically discovered PvD configuration is appropriately limited by relevant events. For example, if an interface media state change is indicated, previously discovered information relevant to that interface may no longer be valid and thus needs to be confirmed or re-discovered.
在所有情况下，默认情况下，节点必须确保所有动态发现的PvD配置的生存期受到相关事件的适当限制。例如，如果指示接口介质状态更改，则先前发现的与该接口相关的信息可能不再有效，因此需要确认或重新发现。
It is expected that the way a node makes use of PvD information is generally independent of the specific mechanism/protocol that the information was received by.
预计节点使用PvD信息的方式通常独立于接收信息的特定机制/协议。
In some network topologies, network infrastructure elements may need to advertise multiple PvDs. Generally, the details of how this is performed will be defined in companion design documents.
在某些网络拓扑中，网络基础设施元件可能需要宣传多个PVD。通常，如何执行的细节将在配套设计文件中定义。
For the foreseeable future, there will be networks that do not advertise explicit PvD information, because deployment of new features in networking protocols is a relatively slow process.
在可预见的未来，将有一些网络不宣传明确的PvD信息，因为在网络协议中部署新功能是一个相对缓慢的过程。
When connected to networks that don't advertise explicit PvD information, a PvD-aware node shall automatically create separate PvDs for received configuration. Such PvDs are referred to in this document as "implicit".
当连接到不公布明确PvD信息的网络时，PvD感知节点应自动为接收到的配置创建单独的PvD。此类PVD在本文件中称为“隐式”。
Through the use of implicit PvDs, PvD-aware nodes may still provide benefits to their users (when compared to non-PvD-aware nodes) by following the best practices described in Section 5.
通过使用隐式PvD，PvD感知节点仍然可以通过遵循第5节中描述的最佳实践为其用户提供好处（与非PvD感知节点相比）。
PvD-aware nodes shall treat network information from different interfaces, which is not identified as belonging explicitly to some PvD, as belonging to separate PvDs, one per interface.
感知PvD的节点应将来自不同接口的网络信息视为属于单独的PvD，每个接口一个。
Implicit PvDs can also occur in a mixed mode, i.e., where of multiple networks that are available on an attached link, only some advertise PvD information. In this case, the PvD-aware node shall create explicit PvDs from information explicitly labeled as belonging to PvDs. It shall associate configuration information not labeled with an explicit PvD with an implicit PvD(s) created for that interface.
隐式PvD也可以在混合模式下发生，即，在连接链路上可用的多个网络中，只有一些公布PvD信息。在这种情况下，PvD感知节点应根据明确标记为属于PvD的信息创建明确的PvD。其应将未标记有显式PvD的配置信息与为该接口创建的隐式PvD相关联。
By default, implicit PvDs are limited to the network configuration information received on a single interface, and by default, one such PvD is formed for each interface. If additional information is available to the host (through mechanisms out of scope of this document), the host may form implicit PvDs with different granularity. For example, PvDs spanning multiple interfaces such as a home network with a router that has multiple internal interfaces or multiple PvDs on a single interface such as a network that has multiple uplink connections.
默认情况下，隐式PvD仅限于在单个接口上接收的网络配置信息，并且默认情况下，为每个接口形成一个这样的PvD。如果主机可以获得其他信息（通过本文档范围之外的机制），主机可能会形成具有不同粒度的隐式PVD。例如，跨越多个接口的PVD，例如具有具有多个内部接口的路由器的家庭网络，或在单个接口上的多个PVD，例如具有多个上行链路连接的网络。
In the simplest case, explicit PvDs will be scoped for configuration related only to a specific interface. However, there is no requirement in this architecture for such a limitation. Explicit PvDs may include information related to more than one interface if the node learns the presence of the same PvD on those interfaces and the authentication of the PvD ID meets the level required by the node policy (authentication of a PvD ID may be also required in scenarios involving only one connected interface and/or PvD; for additional discussion of PvD Trust, see Section 7).
在最简单的情况下，显式PVD的范围仅限于与特定接口相关的配置。然而，在这种体系结构中没有对这种限制的要求。如果节点获悉在这些接口上存在相同的PvD并且PvD ID的认证满足节点策略所要求的级别，则显式PvD可以包括与多个接口相关的信息（在仅涉及一个连接接口和/或PvD的情况下，也可能需要验证PvD ID；有关PvD信任的更多讨论，请参阅第7节）。
This architecture supports such scenarios. Hence, no hierarchical relationship exists between interfaces and PvDs: it is possible for multiple PvDs to be simultaneously accessible over one interface, as well as a single PvD to be simultaneously accessible over multiple interfaces.
此体系结构支持此类场景。因此，接口和PvD之间不存在分层关系：多个PvD可以通过一个接口同时访问，而单个PvD可以通过多个接口同时访问。
For explicit PvDs, the PvD ID is a value that is or has a high probability of being globally unique and is received as part of PvD information. It shall be possible to generate a human-readable form of the PvD ID to present to the end user, either based on the PvD ID itself or using metadata associated with the ID. For implicit PvDs, the node assigns a locally generated ID with a high probability of being globally unique to each implicit PvD.
对于显式PvD，PvD ID是一个具有全局唯一性或高概率的值，并作为PvD信息的一部分接收。基于PvD ID本身或使用与ID相关联的元数据，可以生成人类可读的PvD ID形式，以呈现给最终用户。对于隐式PvD，节点分配一个本地生成的ID，该ID很可能对每个隐式PvD全局唯一。
We say that a PvD ID should be, or should have a high probability of being, globally unique. The purpose of this is to make it unlikely that any individual node will ever accidentally see the same PvD name twice if it is not actually referring to the same PvD. Protection against deliberate attacks involving name clashes requires that the name be authenticated (see Section 7.2.1).
我们说一个PvD ID应该是，或者应该有很高的概率是，全球唯一的。这样做的目的是，如果某个节点实际上不是指同一个PvD，则该节点不太可能意外地看到同一个PvD名称两次。为防止涉及姓名冲突的蓄意攻击，需要对姓名进行身份验证（见第7.2.1节）。
A PvD-aware node may use these IDs to select a PvD with a matching ID for special-purpose connection requests in accordance with node policy, as chosen by advanced applications, or to present a human-readable representation of the IDs to the end user for selection of PvDs.
感知PvD的节点可以使用这些ID来根据节点策略（如高级应用程序所选择的）为特殊目的连接请求选择具有匹配ID的PvD，或者向最终用户呈现ID的人类可读表示以供选择PvD。
A single network provider may operate multiple networks, including networks at different locations. In such cases, the provider may chose whether to advertise single or multiple PvD identities at all or some of those networks as it suits their business needs. This architecture does not impose any specific requirements in this regard.
单个网络提供商可以操作多个网络，包括位于不同位置的网络。在这种情况下，提供商可以选择是否在所有或部分网络上宣传单个或多个PvD身份，因为这符合其业务需求。该体系结构在这方面没有强加任何特定要求。
When multiple nodes are connected to the same link with one or more explicit PvDs available, this architecture assumes that the information about all available PvDs is made available by the networks to all the connected nodes. At the same time, connected nodes may have different heuristics, policies, and/or other settings, including their configured sets of trusted PvDs. This may lead to different PvDs actually being used by different nodes for their connections.
当多个节点通过一个或多个可用的显式PVD连接到同一链路时，该体系结构假定网络向所有连接的节点提供关于所有可用PVD的信息。同时，连接的节点可能具有不同的启发式、策略和/或其他设置，包括其配置的可信PVD集。这可能导致不同节点实际使用不同的PVD进行连接。
Possible extensions whereby networks advertise different sets of PvDs to different connected nodes are out of scope of this document.
网络向不同连接节点宣传不同PVD集的可能扩展超出了本文档的范围。
When applied to dual-stack networks, the PvD definition allows for multiple PvDs to be created whereby each PvD contains information relevant to only one address family, or for a single PvD containing information for multiple address families. This architecture
当应用于双栈网络时，PvD定义允许创建多个PvD，其中每个PvD仅包含与一个地址族相关的信息，或者单个PvD包含多个地址族的信息。这个架构
requires that accompanying design documents describing PvD-related protocol changes must support PvDs containing information from multiple address families. PvD-aware nodes must be capable of creating and using both single-family and multi-family PvDs.
要求描述PvD相关协议变更的随附设计文件必须支持包含多个地址族信息的PvD。支持PvD的节点必须能够创建和使用单族和多族PvD。
For explicit PvDs, the choice of either of these approaches is a policy decision for the network administrator and/or the node user/ administrator. Since some of the IP configuration information that can be learned from the network can be applicable to multiple address families (for instance, DHCPv6 Address Selection Policy Option [RFC7078]), it is likely that dual-stack networks will deploy single PvDs for both address families.
对于显式PVD，这些方法的选择是网络管理员和/或节点用户/管理员的策略决定。由于可以从网络中了解到的一些IP配置信息可适用于多个地址族（例如，DHCPv6地址选择策略选项[RFC7078]），因此双栈网络可能会为两个地址族部署单个PVD。
By default for implicit PvDs, PvD-aware nodes shall include multiple IP families into a single implicit PvD created for an interface. At the time of writing, in dual-stack networks it appears to be common practice for the configuration of both address families to be provided by a single source.
默认情况下，对于隐式PvD，PvD感知节点应将多个IP族包含到为接口创建的单个隐式PvD中。在撰写本文时，在双栈网络中，两个地址族的配置似乎都是由单个源提供的常见做法。
A PvD-aware node that provides an API to use, enumerate, and inspect PvDs and/or their properties shall provide the ability to filter PvDs and/or their properties by address family.
提供API以使用、枚举和检查PvD和/或其属性的PvD感知节点应提供按地址系列过滤PvD和/或其属性的能力。
DHCPv6 and Router Advertisements (RAs) are the two most common methods of configuring hosts. To support the architecture described in this document, these protocols would need to be extended to convey explicit PvD information. The following sections describe topics that must be considered before finalizing a mechanism to augment DHCPv6 and RAs with PvD information.
DHCPv6和路由器播发（RAs）是配置主机的两种最常见的方法。为了支持本文档中描述的体系结构，需要扩展这些协议以传递明确的PvD信息。以下各节描述了在最终确定使用PvD信息增强DHCPv6和RAs的机制之前必须考虑的主题。
When information related to several PvDs is available from the same configuration source, there are two possible ways of distributing this information: One way is to send information from each different provisioning domain in separate messages. The second method is combining the information from multiple PvDs into a single message. The latter method has the advantage of being more efficient but could have problems with authentication and authorization, as well as potential issues with accommodating information not tagged with any PvD information.
当来自同一配置源的与多个PVD相关的信息可用时，有两种可能的方法分发此信息：一种方法是在单独的消息中从每个不同的配置域发送信息。第二种方法是将来自多个PVD的信息组合成单个消息。后一种方法的优点是效率更高，但可能在身份验证和授权方面存在问题，以及在容纳未标记任何PvD信息的信息方面存在潜在问题。
DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of authentication to ensure the identity of the source as well as the integrity of the secured message content. While this is useful, determining authenticity does not tell a node whether the configuration source is actually allowed to provide information from a given PvD. To resolve this, there must be a mechanism for the PvD owner to attach some form of authorization token or signature to the configuration information that is delivered.
DHCPv6[RFC3315]和RAs[RFC3971]都提供某种形式的身份验证，以确保源的身份以及安全消息内容的完整性。虽然这是有用的，但确定真实性并不能告诉节点是否允许配置源实际提供来自给定PvD的信息。为了解决这个问题，必须有一种机制，让PvD所有者将某种形式的授权令牌或签名附加到所交付的配置信息上。
The extensions to RAs and DHCPv6 should be defined in such a manner that unmodified hosts (i.e., hosts not aware of PvDs) will continue to function as well as they did prior to PvD information being added. This could imply that some information may need to be duplicated in order to be conveyed to legacy hosts. Similarly, PvD-aware hosts need to be able to correctly utilize legacy configuration sources that do not provide PvD information. There are also several initiatives that are aimed at adding some form of additional information to prefixes [DHCPv6-CLASS-BASED-PREFIX] [IPv6-PREFIX-PROPERTIES], and any new mechanism should try to consider coexistence with such deployed mechanisms.
RAs和DHCPv6的扩展应以这样一种方式定义：未修改的主机（即，不知道PvD的主机）将继续像添加PvD信息之前一样正常工作。这可能意味着某些信息可能需要复制才能传送到遗留主机。类似地，支持PvD的主机需要能够正确利用不提供PvD信息的旧式配置源。也有一些举措旨在将某种形式的附加信息添加到前缀[DHCPv6类前缀] [IPv6前缀属性]，并且任何新的机制应该尝试考虑与这种部署机制的共存。
After PvD information is provisioned to a host, it may become outdated or superseded by updated information before the hosts would normally request updates. To resolve this requires that the mechanism be able to update and/or withdraw all (or some subset) of the information related to a given PvD. For efficiency reasons, there should be a way to specify that all information from the PvD needs to be reconfigured instead of individually updating each item associated with the PvD.
将PvD信息提供给主机后，在主机正常请求更新之前，它可能会过时或被更新的信息取代。要解决这一问题，需要该机制能够更新和/或撤销与给定PvD相关的所有（或某些子集）信息。出于效率原因，应该有一种方法指定需要重新配置来自PvD的所有信息，而不是单独更新与PvD相关的每个项目。
IKEv2 [RFC7296] [RFC5739] is another widely used method of configuring host IP information. For IKEv2, the provisioning domain could be implicitly learned from the Identification - Responder (IDr) payloads that the IKEv2 initiator and responder inject during their IKEv2 exchange. The IP configuration may depend on the named IDr. Another possibility could be adding a specific provisioning domain identifying payload extensions to IKEv2. All of the considerations for DHCPv6 and the RAs listed above potentially apply to IKEv2 as well.
IKEv2[RFC7296][RFC5739]是另一种广泛使用的配置主机IP信息的方法。对于IKEv2，可以从IKEv2启动器和响应程序在其IKEv2交换期间注入的标识-响应程序（IDr）有效负载隐式学习设置域。IP配置可能取决于命名的IDr。另一种可能是向IKEv2添加一个标识有效负载扩展的特定供应域。上面列出的DHCPv6和RAs的所有注意事项也可能适用于IKEv2。
Consider a mobile node with two network interfaces: one to the mobile network, the other to the Wi-Fi network. When the mobile node is only connected to the mobile network, it will typically have one PvD, implicit or explicit. When the mobile node discovers and connects to a Wi-Fi network, it will have zero or more (typically one) additional PvD(s).
考虑一个具有两个网络接口的移动节点：一个是移动网络，另一个是Wi-Fi网络。当移动节点仅连接到移动网络时，它通常具有一个PvD，隐式或显式。当移动节点发现并连接到Wi-Fi网络时，它将具有零个或多个（通常为一个）附加PvD。
Some existing OS implementations only allow one active network connection. In this case, only the PvD(s) associated with the active interface can be used at any given time.
某些现有操作系统实现只允许一个活动网络连接。在这种情况下，在任何给定时间只能使用与有源接口相关的PvD。
As an example, the mobile network can explicitly deliver PvD information through the Packet Data Protocol (PDP) context activation process. Then, the PvD-aware mobile node will treat the mobile network as an explicit PvD. Conversely, the legacy Wi-Fi network may not explicitly communicate PvD information to the mobile node. The PvD-aware mobile node will associate network configuration for the Wi-Fi network with an implicit PvD in this case.
例如，移动网络可以通过分组数据协议（PDP）上下文激活过程显式地传送PvD信息。然后，感知PvD的移动节点将移动网络视为显式PvD。相反，传统Wi-Fi网络可能不会显式地将PvD信息传送给移动节点。在这种情况下，感知PvD的移动节点将Wi-Fi网络的网络配置与隐式PvD相关联。
The following diagram illustrates the use of different PvDs in this scenario:
下图说明了在这种情况下不同PVD的使用：
<----------- Wi-Fi 'Internet' PvD -------->
+---------+
| +-----+ | +-----+ _ __ _ _
| |Wi-Fi| | | | ( ` ) ( ` )_
| |-IF + |----+ |---------------------------( `)
| | | | |Wi-Fi| ( ) ( Internet )
| +-----+ | | AP | ( ) ( )
| | | | ( Service ) ( )
| | +-----+ ( Provider's ) ( )
| | ( Networks - ( )
| +----+ | `_ ) ( )
| |CELL| | ( ) ( )
| |-IF +--|-------------------------------------( )
| | | | (_ __) (_ _)
| +----+ | `- -- `- __ _) -
+---------+
<------- Mobile 'Internet' PvD ----------->
<----------- Wi-Fi 'Internet' PvD -------->
+---------+
| +-----+ | +-----+ _ __ _ _
| |Wi-Fi| | | | ( ` ) ( ` )_
| |-IF + |----+ |---------------------------( `)
| | | | |Wi-Fi| ( ) ( Internet )
| +-----+ | | AP | ( ) ( )
| | | | ( Service ) ( )
| | +-----+ ( Provider's ) ( )
| | ( Networks - ( )
| +----+ | `_ ) ( )
| |CELL| | ( ) ( )
| |-IF +--|-------------------------------------( )
| | | | (_ __) (_ _)
| +----+ | `- -- `- __ _) -
+---------+
<------- Mobile 'Internet' PvD ----------->
Figure 1: An Example of PvD Use with Wi-Fi and Mobile Interfaces
图1：使用Wi-Fi和移动接口的PvD示例
If the node has established a VPN connection, zero or more (typically one) additional PvD(s) will be created. These may be implicit or explicit. The routing to IP addresses reachable within this PvD will be set up via the VPN connection, and the routing of packets to addresses outside the scope of this PvD will remain unaffected. If a node already has N connected PvDs, after the VPN session has been established typically there will be N+1 connected PvDs.
如果节点已建立VPN连接，则将创建零个或多个（通常为一个）附加PvD。这些可能是隐式的，也可能是显式的。将通过VPN连接设置到该PvD内可访问的IP地址的路由，并且将数据包路由到该PvD范围外的地址将不受影响。如果一个节点已经有N个连接的PVD，在VPN会话建立之后，通常会有N+1个连接的PVD。
The following diagram illustrates the use of different PvDs in this scenario:
下图说明了在这种情况下不同PVD的使用：
<----------- 'Internet' PvD ------>
+--------+
| +----+ | +----+ _ __ _ _
| |Phy | | | | ( ` ) ( ` )_
| |-IF +-|----+ |--------------------( `)
| | | | | | ( ) (_ Internet _)
| +----+ | | | ( ) `- __ _) -
| | |Home| ( Service ) ||
| | |Gate| ( Provider's ) ||
| | |-way| ( Network - ||
| +----+ | | | `_ ) +---------+ +------------+
| |VPN | | | | ( ) | VPN | | |
| |-IF +-|----+ |---------------------+ Gateway |--+ Private |
| | | | | | (_ __) | | | Services |
| +----+ | +----+ `- -- +---------+ +------------+
+--------+
<-------------- Explicit 'VPN' PvD ----->
<----------- 'Internet' PvD ------>
+--------+
| +----+ | +----+ _ __ _ _
| |Phy | | | | ( ` ) ( ` )_
| |-IF +-|----+ |--------------------( `)
| | | | | | ( ) (_ Internet _)
| +----+ | | | ( ) `- __ _) -
| | |Home| ( Service ) ||
| | |Gate| ( Provider's ) ||
| | |-way| ( Network - ||
| +----+ | | | `_ ) +---------+ +------------+
| |VPN | | | | ( ) | VPN | | |
| |-IF +-|----+ |---------------------+ Gateway |--+ Private |
| | | | | | (_ __) | | | Services |
| +----+ | +----+ `- -- +---------+ +------------+
+--------+
<-------------- Explicit 'VPN' PvD ----->
Figure 2: An Example of PvD Use with VPN
图2:PvD与VPN一起使用的示例
An operator may use separate PvDs for individual services that they offer to their customers. These may be used so that services can be designed and provisioned to be completely independent of each other, allowing for complete flexibility in combinations of services that are offered to customers.
运营商可以为其向客户提供的个别服务使用单独的PVD。可以使用这些服务，以便能够设计和提供彼此完全独立的服务，从而允许向客户提供的服务组合具有完全的灵活性。
From the perspective of the home network and the node, this model is functionally very similar to being multihomed to multiple upstream operators: Each of the different services offered by the service provider is its own PvD with associated PvD information. In this case, the operator may provide a generic/default PvD (explicit or
从家庭网络和节点的角度来看，该模型在功能上非常类似于对多个上游运营商进行多址：服务提供商提供的每个不同服务都是其自己的PvD，带有相关的PvD信息。在这种情况下，操作员可提供通用/默认PvD（明确或默认）
implicit), which provides Internet access to the customer. Additional services would then be provisioned as explicit PvDs for subscribing customers.
隐式），为客户提供互联网访问。然后，将为订阅客户提供额外的服务作为显式PVD。
The following diagram illustrates this, using video-on-demand as a service-specific PvD:
下图说明了这一点，使用视频点播作为特定于服务的PvD：
<------ Implicit 'Internet' PvD ------>
+----+ +-----+ _ __ _ _
| | | | ( ` ) ( ` )_
| PC +-----+ |-------------------------( `)
| | | | ( ) (_ Internet _)
+----+ | | ( ) `- __ _) -
|Home | ( Service )
|Gate-| ( Provider's )
|way | ( Network -
+-----+ | | `_ ) +-----------+
| Set-| | | ( ) |ISP Video- |
| Top +----+ |--------------------------+on-Demand |
| Box | | | (_ __) | Service |
+-----+ +-----+ `- -- +-----------+
<-- Explicit 'Video-on-Demand' PvD -->
<------ Implicit 'Internet' PvD ------>
+----+ +-----+ _ __ _ _
| | | | ( ` ) ( ` )_
| PC +-----+ |-------------------------( `)
| | | | ( ) (_ Internet _)
+----+ | | ( ) `- __ _) -
|Home | ( Service )
|Gate-| ( Provider's )
|way | ( Network -
+-----+ | | `_ ) +-----------+
| Set-| | | ( ) |ISP Video- |
| Top +----+ |--------------------------+on-Demand |
| Box | | | (_ __) | Service |
+-----+ +-----+ `- -- +-----------+
<-- Explicit 'Video-on-Demand' PvD -->
Figure 3: An Example of PvD Use with Wi-Fi and Mobile Interfaces
图3：使用Wi-Fi和移动接口的PvD示例
In this case, the number of PvDs that a single operator could provision is based on the number of independently provisioned services that they offer. Some examples may include:
在这种情况下，单个运营商可以提供的PVD数量基于其提供的独立供应服务的数量。一些例子可能包括：
o Real-time packet voice
o 实时分组语音
o Streaming video
o 流视频
o Interactive video (n-way video conferencing)
o 交互式视频（n向视频会议）
o Interactive gaming
o 互动游戏
o Best effort / Internet access
o 尽力而为/互联网接入
It is assumed that normally, the configuration information contained in a single PvD shall be sufficient for a node to fulfill a network connection request by an application, and hence there should be no need to attempt to merge information across different PvDs.
通常，假设单个PvD中包含的配置信息足以使节点满足应用程序的网络连接请求，因此不需要尝试在不同PvD之间合并信息。
Nevertheless, even when a PvD lacks some necessary configuration information, merging of information associated with a different PvD(s) shall not be done automatically as this will typically lead to the issues described in [RFC6418].
然而，即使PvD缺少一些必要的配置信息，也不应自动合并与不同PvD相关的信息，因为这通常会导致[RFC6418]中所述的问题。
A node may use other sources, for example: node local policy, user input, or other mechanisms not defined by the IETF for any of the following:
节点可使用其他源，例如：节点本地策略、用户输入或IETF未定义的其他机制，用于以下任何一项：
o Construction of a PvD in its entirety (analogous to statically configuring IP on an interface)
o 整个PvD的构造（类似于静态配置接口上的IP）
o Supplementing some or all learned PvDs with particular configuration elements
o 使用特定配置元素补充部分或所有已学习的PVD
o Merging of information from different PvDs (if this is explicitly allowed by policy)
o 合并来自不同PVD的信息（如果政策明确允许）
As an example, a node administrator could configure the node to use a specific DNS resolver on a particular interface, or for a particular named PvD. In the case of a per-interface DNS resolver, this might override or augment the DNS resolver configuration for PvDs that are discovered on that interface. Such creation/augmentation of a PvD(s) could be static or dynamic. The specific mechanism(s) for implementing this is outside the scope of this document. Such a merging or overriding of DNS resolver configuration might be contrary to the policy that applies to a special-purpose connection, such as, for example, those discussed in Sections 5.2.1 and 5.2.4. In such cases, either the special-purpose connection should not be used or the merging/overriding should not be performed.
例如，节点管理员可以将节点配置为在特定接口上使用特定DNS解析器，或为特定命名PvD使用特定DNS解析器。对于每个接口的DNS解析器，这可能会覆盖或增加该接口上发现的PVD的DNS解析器配置。此类PvD的创建/增强可以是静态的，也可以是动态的。用于实现此目的的具体机制不在本文件的范围内。DNS解析程序配置的这种合并或覆盖可能会违反适用于特殊用途连接的策略，例如，第5.2.1节和第5.2.4节中讨论的策略。在这种情况下，不应使用专用连接或不应执行合并/覆盖。
PvDs enable PvD-aware nodes to consistently use the correct set of configuration elements to serve specific network requests from beginning to end. This section provides examples of such use.
PvD使支持PvD的节点能够始终如一地使用正确的配置元素集来服务于特定的网络请求。本节提供了此类使用的示例。
When a PvD-aware node needs to resolve the name of the destination for use by a connection request, the node could use one or multiple PvDs for a given name lookup.
当PvD感知节点需要解析连接请求使用的目的地名称时，该节点可以使用一个或多个PvD进行给定名称查找。
The node shall choose a single PvD if, for example, the node policy required the use of a particular PvD for a specific purpose (e.g., to download a Multimedia Messaging Service (MMS) message using a specific Access Point Name (APN) over a cellular connection or to direct traffic of enterprise applications to a VPN connection to the
例如，如果节点策略要求为特定目的使用特定PvD（例如，通过蜂窝连接下载使用特定接入点名称（APN）的多媒体消息服务（MMS）消息，或将企业应用程序的流量引导到VPN连接到网络），则节点应选择单个PvD
enterprise network). To make this selection, the node could use a match between the PvD DNS suffix and a Fully Qualified Domain Name (FQDN) that is being resolved or a match of the PvD ID, as determined by the node policy.
企业网络）。要进行此选择，节点可以使用PvD DNS后缀和正在解析的完全限定域名（FQDN）之间的匹配，或者使用由节点策略确定的PvD ID的匹配。
The node may pick multiple PvDs if, for example, the PvDs are for general purpose Internet connectivity, and the node is attempting to maximize the probability of connectivity similar to the Happy Eyeballs [RFC6555] approach. In this case, the node could perform DNS lookups in parallel, or in sequence. Alternatively, the node may use only one PvD for the lookup, based on the PvD connectivity properties, user configuration of preferred Internet PvD, etc.
例如，如果pvd用于通用互联网连接，并且节点试图最大化连接的概率，则节点可以选择多个pvd，类似于快乐眼球[RFC6555]方法。在这种情况下，节点可以并行或顺序执行DNS查找。或者，节点可以基于PvD连接属性、优选因特网PvD的用户配置等，仅使用一个PvD进行查找。
If an application implements an API that provides a way of explicitly specifying the desired interface or PvD, that interface or PvD should be used for name resolution (and the subsequent connection attempt), provided that the host's configuration permits this.
如果应用程序实现的API提供了明确指定所需接口或PvD的方法，则该接口或PvD应用于名称解析（以及随后的连接尝试），前提是主机配置允许。
In either case, by default a node uses information obtained via a name service lookup to establish connections only within the same PvD as the lookup results were obtained.
在这两种情况下，默认情况下，节点使用通过名称服务查找获得的信息仅在获得查找结果的同一PvD内建立连接。
For clarification, when it is written that the name service lookup results were obtained "from a PvD", it should be understood to mean that the name service query was issued against a name service that is configured for use in a particular PvD. In that sense, the results are "from" that particular PvD.
为了澄清，当写入名称服务查找结果是“从PvD”获得时，应理解为是针对配置为在特定PvD中使用的名称服务发出名称服务查询。从这个意义上说，结果是“来自”特定的PvD。
Some nodes may support transports and/or APIs that provide an abstraction of a single connection, aggregating multiple underlying connections. Multipath TCP (MPTCP) [RFC6182] is an example of such a transport protocol. For connections provided by such transports/ APIs, a PvD-aware node may use different PvDs for servicing that logical connection, provided that all operations on the underlying connections are performed consistently within their corresponding PvD(s).
一些节点可能支持传输和/或API，这些传输和/或API提供单个连接的抽象，聚合多个底层连接。多路径TCP（MPTCP）[RFC6182]就是这种传输协议的一个例子。对于这种传输/api提供的连接，PvD感知节点可以使用不同的PvD来服务该逻辑连接，前提是底层连接上的所有操作在其相应的PvD内一致地执行。
For the purpose of this example, let us assume that the preceding name lookup succeeded in a particular PvD. For each obtained destination address, the node shall perform a next-hop lookup among routers associated with that PvD. As an example, the node could determine such associations via matching the source address prefixes / specific routes advertised by the router against known PvDs or by receiving an explicit PvD affiliation advertised through a new Router Discovery [RFC4861] option.
在本例中，假设前面的名称查找在特定的PvD中成功。对于每个获得的目的地地址，节点应在与该PvD相关联的路由器之间执行下一跳查找。例如，节点可以通过将路由器通告的源地址前缀/特定路由与已知PvD相匹配，或者通过接收通过新的路由器发现[RFC4861]选项通告的显式PvD从属关系来确定此类关联。
For each destination, once the best next hop is found, the node selects the best source address according to rules defined in [RFC6724], but with the constraint that the source address must belong to a range associated with the used PvD. If needed, the node would use the prefix policy from the same PvD for selecting the best source address from multiple candidates.
对于每个目的地，一旦找到最佳下一跳，节点将根据[RFC6724]中定义的规则选择最佳源地址，但有一个约束，即源地址必须属于与所用PvD关联的范围。如果需要，节点将使用来自同一PvD的前缀策略从多个候选中选择最佳源地址。
When destination/source pairs are identified, they are sorted using the [RFC6724] destination sorting rules and prefix policy table from the used PvD.
标识目标/源对后，将使用所用PvD中的[RFC6724]目标排序规则和前缀策略表对其进行排序。
Consider a host connected to several PvDs, running an application that opens a listening socket / transport API object. The application is authorized by the host policy to use a subset of connected PvDs that may or may not be equal to the complete set of the connected PvDs. As an example, in the case where there are different PvDs on the Wi-Fi and cellular interfaces, for general Internet traffic the host could use only one, preferred PvD at a time (and accordingly, advertise to remote peers the host name and addresses associated with that PvD), or it could use one PvD as the default for outgoing connections, while still allowing use of the other PvDs simultaneously.
考虑一个连接到多个PVDs的主机，运行一个打开侦听套接字/传输API对象的应用程序。主机策略授权应用程序使用连接的PVD子集，该子集可能等于或不等于连接的PVD的完整集合。例如，在Wi-Fi和蜂窝接口上存在不同PvD的情况下，对于一般互联网流量，主机一次只能使用一个首选PvD（并相应地向远程对等方公布与该PvD相关联的主机名和地址），或者可以使用一个PvD作为传出连接的默认值，同时仍允许同时使用其他PVD。
Another example is a host with an established VPN connection. Here, security policy could be used to permit or deny an application's access to the VPN PvD and other PvDs.
另一个示例是具有已建立VPN连接的主机。这里，安全策略可用于允许或拒绝应用程序访问VPN PvD和其他PvD。
For non-PvD-aware applications, the operating system has policies that determine the authorized set of PvDs and the preferred outgoing PvD. For PvD-aware applications, both the authorized set of PvDs and the default outgoing PvD can be determined as the common subset produced between the OS policies and the set of PvD IDs or characteristics provided by the application.
对于不支持PvD的应用程序，操作系统具有确定PvD授权集和首选传出PvD的策略。对于支持PvD的应用程序，授权的PvD集和默认的传出PvD都可以确定为操作系统策略和应用程序提供的PvD ID或特征集之间产生的公共子集。
Application input could be provided on a per-application, per-transport-API-object, or per-transport-API-call basis. The API for application input may have an option for specifying whether the input should be treated as a preference instead of a requirement.
可以根据每个应用程序、每个传输API对象或每个传输API调用提供应用程序输入。应用程序输入的API可能有一个选项，用于指定是否应将输入视为首选项而不是需求。
Unicast IP packets are received on a specific IP address associated with a PvD. For multicast packets, the host can derive the PvD association from other configuration information, such as an explicit PvD property or local policy.
在与PvD相关联的特定IP地址上接收单播IP分组。对于多播分组，主机可以从其他配置信息（例如显式PvD属性或本地策略）派生PvD关联。
The node OS or middleware may apply more advanced techniques for determining the resultant PvD and/or authorization of the incoming traffic. Those techniques are outside the scope of this document.
节点OS或中间件可以应用更先进的技术来确定所产生的PvD和/或传入流量的授权。这些技术超出了本文件的范围。
If the determined receiving PvD of a packet is not in the allowed subset of PvDs for the particular application/transport API object, the packet should be handled in the same way as if there were no listener.
如果确定的数据包接收PvD不在特定应用程序/传输API对象允许的PvD子集中，则应以与没有侦听器相同的方式处理数据包。
For connection-oriented APIs, when the initial incoming packet is received, the packet PvD is remembered for the established connection and used for the handling of outgoing traffic for that connection. While typically connection-oriented APIs use a connection-oriented transport protocol, such as TCP, it is possible to have a connection-oriented API that uses a generally connectionless transport protocol, such as UDP.
对于面向连接的API，当接收到初始传入数据包时，数据包PvD将被记住用于已建立的连接，并用于处理该连接的传出流量。虽然面向连接的API通常使用面向连接的传输协议（如TCP），但也可以使用面向连接的API，该API使用通常无连接的传输协议（如UDP）。
For APIs/protocols that support multiple IP traffic flows associated with a single transport API connection object (for example, Multipath TCP), the processing rules may be adjusted accordingly.
对于支持与单个传输API连接对象（例如，多路径TCP）相关联的多个IP通信流的API/协议，可以相应地调整处理规则。
For connectionless APIs, the host should provide an API that PvD-aware applications can use to query the PvD associated with the packet. For outgoing traffic on this transport API object, the OS should use the selected outgoing PvDs, determined as described in Sections 5.2.1 and 5.2.2.
对于无连接API，主机应该提供一个API，支持PvD的应用程序可以使用该API查询与数据包关联的PvD。对于此传输API对象上的传出流量，操作系统应使用选定的传出PVD，如第5.2.1节和第5.2.2节所述确定。
By themselves, PvDs do not define, and cannot be used for communication of, security policies. When implemented in a network, this architecture provides the host with information about connected networks. The actual behavior of the host then depends on the host's policies (provisioned through mechanisms out of scope of this document), applied by taking received PvD information into account. In some scenarios, e.g., a VPN, such policies could require the host to use only a particular VPN PvD for some/all of the application's traffic (VPN 'disable split tunneling' also known as 'force tunneling' behavior) or apply such restrictions only to selected applications and allow the simultaneous use of the VPN PvD together with the other connected PvDs by the other or all applications (VPN 'split tunneling' behavior).
PVD本身并不定义安全策略，也不能用于安全策略的通信。在网络中实现时，此体系结构为主机提供有关连接网络的信息。然后，主机的实际行为取决于主机的策略（通过本文档范围外的机制提供），通过考虑接收到的PvD信息应用。在某些场景中，例如VPN，此类策略可能要求主机仅对部分/所有应用程序流量使用特定的VPN PvD（VPN“禁用拆分隧道”也称为“强制隧道”行为）或者仅对选定的应用程序应用此类限制，并允许其他或所有应用程序同时使用VPN PvD和其他连接的PvD（VPN“拆分隧道”行为）。
Although some PvDs may appear as valid candidates for PvD selection (e.g., good link quality, consistent connection parameters, etc.), they may provide limited or no connectivity to the desired network or the Internet. For example, some PvDs provide limited IP connectivity (e.g., scoped to the link or to the access network) but require the node to authenticate through a web portal to get full access to the Internet. This may be more likely to happen for PvDs that are not trusted by a given PvD-aware node.
尽管一些PvD可能作为PvD选择的有效候选（例如，良好的链路质量、一致的连接参数等），但它们可能会提供有限的或没有到所需网络或互联网的连接。例如，一些PVD提供有限的IP连接（例如，范围限于链路或接入网络），但要求节点通过web门户进行身份验证，以获得对Internet的完全访问。对于给定的PvD感知节点不信任的PvD，这种情况更可能发生。
An attempt to use such a PvD may lead to limited network connectivity or application connection failures. To prevent the latter, a PvD-aware node may perform a connectivity test for the PvD before using it to serve application network connection requests. In current implementations, some nodes already implement this, e.g., by trying to reach a dedicated web server (see [RFC6419]).
尝试使用这种PvD可能会导致有限的网络连接或应用程序连接失败。为了防止后者，感知PvD的节点可以在使用PvD服务于应用程序网络连接请求之前执行PvD的连接性测试。在当前的实现中，一些节点已经实现了这一点，例如，通过尝试访问专用的web服务器（请参见[RFC6419]）。
Section 5.2 describes how a PvD-aware node shall maintain and use multiple PvDs separately. The PvD-aware node shall perform a connectivity test and, only after validation of the PvD, consider using it to serve application connections requests. Ongoing connectivity tests are also required, since during the IP session, the end-to-end connectivity could be disrupted for various reasons (e.g., L2 problems and IP QoS issues); hence, a connectivity monitoring function is needed to check the connectivity status and remove the PvD from the set of usable PvDs if necessary.
第5.2节描述了PvD感知节点应如何分别维护和使用多个PvD。PVD感知节点应该执行连通性测试，并且仅在验证PVD之后，考虑使用它来服务应用连接请求。还需要进行持续的连接测试，因为在IP会话期间，端到端连接可能会因各种原因中断（例如，L2问题和IP QoS问题）；因此，需要连接监控功能来检查连接状态，并在必要时从可用PvD集中移除PvD。
There may be cases where a connectivity test for PvD selection may not be appropriate and should be complemented, or replaced, by PvD selection based on other factors. For example, this could be realized by leveraging some 3GPP and IEEE mechanisms, which would allow the exposure of some PvD characteristics to the node (e.g., 3GPP Access Network Discovery and Selection Function (ANDSF) [TS23402], Access Network Query Protocol (ANQP) [IEEE802.11u]).
在某些情况下，PvD选择的连接性测试可能不合适，应根据其他因素进行PvD选择，以补充或替代该测试。例如，这可以通过利用一些3GPP和IEEE机制来实现，这些机制将允许向节点公开一些PvD特性（例如，3GPP接入网络发现和选择功能（ANDSF）[TS23402]，接入网络查询协议（ANQP）[IEEE802.11u]）。
Current devices such as mobile handsets make use of proprietary mechanisms and custom applications to manage connectivity in environments with multiple interfaces and multiple sets of network configuration. These mechanisms or applications are commonly known as connection managers [RFC6419].
当前的设备（如手机）利用专有机制和自定义应用程序来管理具有多个接口和多组网络配置的环境中的连接。这些机制或应用程序通常称为连接管理器[RFC6419]。
Connection managers sometimes rely on policy servers to allow a node that is connected to multiple networks to perform network selection. They can also make use of routing guidance from the network (e.g., 3GPP ANDSF [TS23402]). Although connection managers solve some
连接管理器有时依赖策略服务器来允许连接到多个网络的节点执行网络选择。它们还可以利用来自网络的路由指导（例如，3GPP和sf[TS23402]）。尽管连接管理器解决了一些问题
connectivity problems, they rarely address network selection problems in a comprehensive manner. With proprietary solutions, it is challenging to present coherent behavior to the end user of the device, as different platforms present different behaviors even when connected to the same network, with the same type of interface, and for the same purpose. The architecture described in this document should improve the host's behavior by providing the hosts with tools and guidance to make informed network selection decisions.
连接问题，它们很少以综合方式解决网络选择问题。对于专有解决方案，向设备的最终用户呈现一致的行为是一项挑战，因为即使连接到同一网络，使用相同类型的接口，出于相同的目的，不同的平台也会呈现不同的行为。本文档中描述的体系结构应该通过为主机提供工具和指导来改进主机的行为，从而做出明智的网络选择决策。
For all levels of PvD support in APIs described in this chapter, it is expected that the notifications about changes in the set of available PvDs are exposed as part of the API surface.
对于本章中描述的API中的所有级别的PvD支持，预期关于可用PvD集合中的更改的通知将作为API表面的一部分公开。
Applications are not PvD aware in any manner and only submit connection requests. The node performs PvD selection implicitly, without any application participation, based purely on node-specific administrative policies and/or choices made by the user from a user interface provided by the operating environment, not by the application.
应用程序不以任何方式了解PvD，只提交连接请求。节点仅基于节点特定的管理策略和/或用户从操作环境（而非应用程序）提供的用户界面所做的选择，隐式执行PvD选择，而无需任何应用程序参与。
As an example, PvD selection can be done at the name service lookup step by using the relevant configuration elements, such as those described in [RFC6731]. As another example, PvD selection could be made based on application identity or type (i.e., a node could always use a particular PvD for a Voice over IP (VoIP) application).
例如，可以通过使用相关配置元素（如[RFC6731]中所述）在名称服务查找步骤中进行PvD选择。作为另一个示例，可以基于应用程序标识或类型进行PvD选择（即，节点可以始终将特定PvD用于IP语音（VoIP）应用程序）。
Applications indirectly participate in PvD selection by specifying hard requirements and soft preferences. As an example, a real-time communication application intending to use the connection for the exchange of real-time audio/video data may indicate a preference or a requirement for connection quality, which could affect PvD selection (different PvDs could correspond to Internet connections with different loss rates and latencies).
应用程序通过指定硬需求和软偏好间接参与PvD选择。例如，意图使用连接来交换实时音频/视频数据的实时通信应用程序可指示连接质量的偏好或要求，其可影响PvD选择（不同PvD可对应于具有不同丢失率和延迟的因特网连接）。
Another example is the connection of an infrequently executed background activity, which checks for application updates and performs large downloads when updates are available. For such connections, a cheaper or zero-cost PvD may be preferable, even if such a connection has a higher relative loss rate or lower bandwidth. The node performs PvD selection based on applications' inputs and policies and/or user preferences. Some/all properties of the resultant PvD may be exposed to applications.
另一个例子是连接一个不常执行的后台活动，该活动检查应用程序更新，并在更新可用时执行大量下载。对于这种连接，更便宜或零成本的PvD可能是优选的，即使这种连接具有更高的相对损耗率或更低的带宽。节点根据应用程序的输入、策略和/或用户偏好执行PvD选择。所得PvD的部分/所有特性可能暴露于应用中。
PvDs are directly exposed to applications for enumeration and selection. Node polices and/or user choices may still override the applications' preferences and limit which PvD(s) can be enumerated and/or used by the application, irrespective of any preferences that the application may have specified. Depending on the implementation, such restrictions (imposed by node policy and/or user choice) may or may not be visible to the application.
PVD直接暴露于用于枚举和选择的应用程序中。节点策略和/或用户选择仍然可以覆盖应用程序的首选项，并限制应用程序可以枚举和/或使用哪些PvD，而不考虑应用程序可能已指定的任何首选项。根据实现的不同，这些限制（由节点策略和/或用户选择施加）可能对应用程序可见，也可能不可见。
Implicit and explicit PvDs for which no trust relationship exists are considered untrusted. Only PvDs that meet the requirements in Section 7.2 are trusted; any other PvD is untrusted.
不存在信任关系的隐式和显式PVD被视为不受信任。仅信任满足第7.2节要求的PVD；任何其他PvD都是不可信的。
In order to avoid the various forms of misinformation that could occur when PvDs are untrusted, nodes that implement PvD separation cannot assume that two explicit PvDs with the same identifier are actually the same PvD. A node that makes this assumption will be vulnerable to attacks where, for example, an open Wi-Fi hotspot might assert that it was part of another PvD and thereby attempt to draw traffic intended for that PvD onto its own network.
为了避免PvD不受信任时可能出现的各种形式的错误信息，实现PvD分离的节点不能假定具有相同标识符的两个显式PvD实际上是相同的PvD。做出这种假设的节点将容易受到攻击，例如，开放的Wi-Fi热点可能会断言它是另一个PvD的一部分，从而试图将该PvD的流量吸引到自己的网络上。
Since implicit PvD identifiers are synthesized by the node, this issue cannot arise with implicit PvDs.
由于隐式PvD标识符由节点合成，因此隐式PvD不会出现此问题。
Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide configuration information that asserts special knowledge about the reachability of resources through that PvD. Such assertions cannot be validated unless the node has a trust relationship with the PvD; therefore, assertions of this type must be ignored by nodes that receive them from untrusted PvDs. Failure to ignore such assertions could result in traffic being diverted from legitimate destinations to spoofed destinations.
存在这样的机制（例如，[RFC6731]），其中PvD可以提供配置信息，该配置信息断言关于通过该PvD的资源可达性的特殊知识。除非节点与PvD具有信任关系，否则无法验证此类断言；因此，从不受信任的PVD接收此类断言的节点必须忽略此类断言。如果不忽略这些断言，可能会导致流量从合法目的地转移到欺骗目的地。
Trusted PvDs are PvDs for which two conditions apply: First, a trust relationship must exist between the node that is using the PvD configuration and the source that provided that configuration; this is the authorization portion of the trust relationship. Second, there must be some way to validate the trust relationship. This is the authentication portion of the trust relationship. Two mechanisms for validating the trust relationship are defined.
可信PvD是两个条件适用的PvD：首先，使用PvD配置的节点和提供该配置的源之间必须存在信任关系；这是信任关系的授权部分。其次，必须有某种方法来验证信任关系。这是信任关系的身份验证部分。定义了两种验证信任关系的机制。
It shall be possible to validate the trust relationship for all advertised elements of a trusted PvD, irrespective of whether the PvD elements are communicated as a whole, e.g., in a single DHCP option, or separately, e.g., in supplementary RA options. The feasibility of mechanisms to implement a trust relationship for all PvD elements will be determined in the respective companion design documents.
应能够验证受信任PvD的所有广告元素的信任关系，无论PvD元素是作为一个整体（例如在单个DHCP选项中）通信，还是单独（例如在补充RA选项中）通信。为所有PvD元素实现信任关系的机制的可行性将在相应的配套设计文件中确定。
One way to validate the trust relationship between a node and the source of a PvD is through the combination of cryptographic authentication and an identifier configured on the node.
验证节点和PvD源之间的信任关系的一种方法是通过密码认证和在节点上配置的标识符的组合。
If authentication is done using a public key mechanism such as PKI certificate chain validation or DNS-Based Authentication of Named Entities (DANE), authentication by itself is not enough since theoretically any PvD could be authenticated in this way. In addition to authentication, the node would need configuration to trust the identifier being authenticated. Validating the authenticated PvD name against a list of PvD names configured as trusted on the node would constitute the authorization step in this case.
如果使用公钥机制进行身份验证，如PKI证书链验证或基于DNS的命名实体身份验证（DANE），则仅凭身份验证本身是不够的，因为理论上任何PvD都可以通过这种方式进行身份验证。除了身份验证之外，节点还需要配置以信任正在进行身份验证的标识符。在这种情况下，根据节点上配置为受信任的PvD名称列表验证已验证的PvD名称将构成授权步骤。
In some cases, a trust relationship may be validated by some means other than those described in Section 7.2.1 simply by virtue of the connection through which the PvD was obtained. For instance, a handset connected to a mobile network may know through the mobile network infrastructure that it is connected to a trusted PvD. Whatever mechanism was used to validate that connection constitutes the authentication portion of the PvD trust relationship. Presumably, such a handset would be configured from the factory (or else through mobile operator or user preference settings) to trust the PvD, and this would constitute the authorization portion of this type of trust relationship.
在某些情况下，信任关系可通过第7.2.1节所述以外的其他方式进行验证，仅通过获得PvD的连接进行验证。例如，连接到移动网络的手持设备可以通过移动网络基础设施知道它连接到可信PvD。无论使用何种机制来验证连接构成PvD信任关系的身份验证部分。据推测，这样的手机将从工厂（或通过移动运营商或用户偏好设置）配置为信任PvD，并且这将构成这种信任关系的授权部分。
There are at least three different forms of attacks that can be performed using configuration sources that support multiple provisioning domains.
使用支持多个供应域的配置源至少可以执行三种不同形式的攻击。
Tampering with provided configuration information: An attacker may attempt to modify information provided inside the PvD container option. These attacks can easily be prevented by using message integrity features provided by the underlying protocol used to carry the configuration information. For example, SEcure Neighbor
篡改提供的配置信息：攻击者可能试图修改PvD容器选项中提供的信息。通过使用用于传输配置信息的底层协议提供的消息完整性功能，可以很容易地防止这些攻击。例如，安全邻居
Discovery (SEND) [RFC3971] would detect any form of tampering with the RA contents and the DHCPv6 [RFC3315] AUTH option that would detect any form of tampering with the DHCPv6 message contents. This attack can also be performed by a compromised configuration source by modifying information inside a specific PvD, in which case the mitigations proposed in the next subsection may be helpful.
发现（发送）[RFC3971]将检测任何形式的对RA内容的篡改，DHCPv6[RFC3315]AUTH选项将检测任何形式的对DHCPv6消息内容的篡改。通过修改特定PvD内的信息，受损配置源也可以执行此攻击，在这种情况下，下一小节中提出的缓解措施可能会有所帮助。
Rogue configuration source: A compromised configuration source, such as a router or a DHCPv6 server, may advertise information about PvDs that it is not authorized to advertise. For example, a coffee shop WLAN may advertise configuration information purporting to be from an enterprise and may try to attract enterprise-related traffic. This may also occur accidentally if two sites choose the same identifier (e.g., "linsky").
流氓配置源：受损的配置源（如路由器或DHCPv6服务器）可能会发布未经授权发布的有关PVD的信息。例如，咖啡店WLAN可以宣传声称来自企业的配置信息，并且可以尝试吸引与企业相关的流量。如果两个站点选择相同的标识符（例如，“linsky”），也可能会意外发生这种情况。
In order to detect and prevent this, the client must be able to authenticate the identifier provided by the network. This means that the client must have configuration information that maps the PvD identifier to an identity and must be able to authenticate that identity.
为了检测和防止这种情况，客户端必须能够验证网络提供的标识符。这意味着客户端必须具有将PvD标识符映射到标识的配置信息，并且必须能够验证该标识。
In addition, the network must provide information the client can use to authenticate the identity. This could take the form of a PKI-based or DNSSEC-based trust anchor, or a key remembered from a previous leap-of-faith authentication of the identifier.
此外，网络必须提供客户端可用于身份验证的信息。这可以采取基于PKI或基于DNSSEC的信任锚的形式，也可以是从标识符的前一次信任验证中记住的密钥。
Because the PvD-specific information may come to the network infrastructure with which the client is actually communicating from some upstream provider, it is necessary in this case that the PvD container and its contents be relayed to the client unchanged, leaving the upstream provider's signature intact.
由于PvD特定信息可能会到达网络基础设施，客户机实际上正在与某个上游提供商进行通信，因此在这种情况下，有必要将PvD容器及其内容原封不动地中继到客户机，保持上游提供商的签名完好无损。
Replay attacks: A compromised configuration source or an on-link attacker may try to capture advertised configuration information and replay it on a different link, or at a future point in time. This can be avoided by including a replay protection mechanism such as a timestamp or a nonce inside the PvD container to ensure the validity of the provided information.
重播攻击：受损的配置源或链接上的攻击者可能试图捕获公布的配置信息，并在不同的链接上或在将来的某个时间点重播该信息。这可以通过在PvD容器内包括重放保护机制（例如时间戳或nonce）来避免，以确保所提供信息的有效性。
[DHCPv6-CLASS-BASED-PREFIX] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix", Work in Progress, draft-bhandari-dhc-class-based-prefix-05, July 2013.
[DHCPv6基于类前缀]Systems，C.，Halwasia，G.，Gundavelli，S.，Deng，H.，Thiebaut，L.，Korhonen，J.，和I.Farrer，“基于类前缀的DHCPv6”，在建工程，草稿-bhandari-dhc-CLASS-BASED-PREFIX-052013年7月。
[IEEE802.11u] IEEE, "Local and Metropolitan networks - specific requirements - Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks", IEEE Std 802.11u, <http://standards.ieee.org/findstds/ standard/802.11u-2011.html>.
[IEEE802.11u]IEEE，“局域网和城域网-具体要求-第二部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范：修改件9：与外部网络的互通”，IEEE标准802.11u<http://standards.ieee.org/findstds/ 标准/802.11u-2011.html>。
[IPv6-PREFIX-PROPERTIES] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Mobility Management Properties", Work in Progress, draft-korhonen-dmm-prefix-properties-03, October 2012.
[IPv6前缀属性]Korhonen，J.，Patil，B.，Gundavelli，S.，Seite，P.，和D.Liu，“IPv6前缀移动性管理属性”，正在进行的工作，草稿-Korhonen-dmm-PREFIX-PROPERTIES-032012年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<http://www.rfc-editor.org/info/rfc3971>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010, <http://www.rfc-editor.org/info/rfc5739>.
[RFC5739]Eronen，P.，Laganier，J.，和C.Madson，“互联网密钥交换协议版本2（IKEv2）中的IPv6配置”，RFC 5739，DOI 10.17487/RFC5739，2010年2月<http://www.rfc-editor.org/info/rfc5739>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <http://www.rfc-editor.org/info/rfc6182>.
[RFC6182]福特，A.，雷丘，C.，汉德利，M.，巴尔，S.，和J.艾扬格，“多路径TCP开发的体系结构指南”，RFC 6182，DOI 10.17487/RFC6182，2011年3月<http://www.rfc-editor.org/info/rfc6182>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, DOI 10.17487/RFC6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，DOI 10.17487/RFC6418，2011年11月<http://www.rfc-editor.org/info/rfc6418>.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, November 2011, <http://www.rfc-editor.org/info/rfc6419>.
[RFC6419]Wasserman，M.和P.Seite，“多接口主机的当前实践”，RFC 6419，DOI 10.17487/RFC6419，2011年11月<http://www.rfc-editor.org/info/rfc6419>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, <http://www.rfc-editor.org/info/rfc6731>.
[RFC6731]Savolainen，T.，Kato，J.，和T.Lemon，“多接口节点的改进递归DNS服务器选择”，RFC 6731，DOI 10.17487/RFC6731，2012年12月<http://www.rfc-editor.org/info/rfc6731>.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, <http://www.rfc-editor.org/info/rfc7078>.
[RFC7078]Matsumoto，A.，Fujisaki，T.，和T.Chown，“使用DHCPv6分发地址选择策略”，RFC 7078，DOI 10.17487/RFC7078，2014年1月<http://www.rfc-editor.org/info/rfc7078>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[TS23402] 3GPP, "Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", Release 12, 3GPP TS 23.402, 2014.
[TS23402]3GPP，“技术规范组服务和系统方面；非3GPP接入的架构增强”，第12版，3GPP TS 23.4022014。
Acknowledgments
致谢
The authors would like to thank (in no specific order) Ian Farrer, Markus Stenberg, and Mikael Abrahamsson for their review and comments.
作者要感谢（没有具体顺序）伊恩·法勒、马库斯·斯滕伯格和米凯尔·亚伯拉罕松的评论和评论。
Contributors
贡献者
The following individuals contributed to this document (listed in no specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com), Dmitry Anipko (dmitry.anipko@gmail.com), Hui Deng (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos Pentikousis (k.pentikousis@huawei.com), Marc Blanchet (marc.blanchet@viagenie.ca), Margaret Wasserman (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com), and Tim Chown (tjc@ecs.soton.ac.uk).
以下个人对本文件作出了贡献（未按具体顺序列出）：阿尔珀·耶金（阿尔珀。yegin@yegin.org)，丁一荣(yding@cs.helsinki.fi)，曹珍(caozhenpku@gmail.com)，刘大鹏(liudapeng@chinamobile.com)戴夫·泰勒(dthaler@microsoft.com)，Dmitry Anipko（Dmitry。anipko@gmail.com)，邓晖(denghui@chinamobile.com),Jouni Korhonen（Jouni。nospam@gmail.com)胡安·卡洛斯·祖尼加（胡安·卡洛斯·祖尼加）。Zuniga@InterDigital.com)，Konstantinos Pentikousis（k。pentikousis@huawei.com)，马克·布兰切特（马克。blanchet@viagenie.ca)，玛格丽特·沃瑟曼(margaretw42@gmail.com)，Pierrick Seite（Pierrick。seite@orange.com)，Suresh Krishnan（Suresh。krishnan@ericsson.com)，蒂姆·萨沃莱宁（蒂姆。savolainen@nokia.com)，泰德·莱蒙（泰德·莱蒙）。lemon@nominum.com)，以及周永康(tjc@ecs.soton.ac.uk).
Author's Address
作者地址
Dmitry Anipko (editor) Unaffiliated
Dmitry Anipko（编辑）非附属
Phone: +1 425 442 6356
EMail: dmitry.anipko@gmail.com
Phone: +1 425 442 6356
EMail: dmitry.anipko@gmail.com