Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 6724 Microsoft
Obsoletes: 3484 R. Draves
Category: Standards Track Microsoft Research
ISSN: 2070-1721 A. Matsumoto
NTT
T. Chown
University of Southampton
September 2012
Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 6724 Microsoft
Obsoletes: 3484 R. Draves
Category: Standards Track Microsoft Research
ISSN: 2070-1721 A. Matsumoto
NTT
T. Chown
University of Southampton
September 2012
Default Address Selection for Internet Protocol Version 6 (IPv6)
Internet协议版本6（IPv6）的默认地址选择
Abstract
摘要
This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.
本文档描述了两种算法，一种用于源地址选择，另一种用于目标地址选择。这些算法为所有Internet协议版本6（IPv6）实现指定默认行为。它们不会覆盖应用程序或上层协议所做的选择，也不会阻止开发更高级的地址选择机制。这两种算法共享一个公共上下文，包括一个可选机制，允许管理员提供可以覆盖默认行为的策略。在双栈实现中，目的地址选择算法可以考虑IPv4和IPv6地址——根据可用的源地址，该算法可能更喜欢IPv4地址而不是IPv4地址，反之亦然。
Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484.
本规范中定义的默认地址选择适用于所有IPv6节点，包括主机和路由器。本文件淘汰了RFC 3484。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6724.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6724.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
1.1. Conventions Used in This Document ..........................4
2. Context in Which the Algorithms Operate .........................4
2.1. Policy Table ...............................................6
2.2. Common Prefix Length .......................................7
3. Address Properties ..............................................7
3.1. Scope Comparisons ..........................................8
3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9
3.4. IPv6 Loopback Address and Other Format Prefixes ............9
3.5. Mobility Addresses .........................................9
4. Candidate Source Addresses .....................................10
5. Source Address Selection .......................................11
6. Destination Address Selection ..................................14
7. Interactions with Routing ......................................16
8. Implementation Considerations ..................................16
9. Security Considerations ........................................17
10. Examples ......................................................18
10.1. Default Source Address Selection .........................18
10.2. Default Destination Address Selection ....................19
10.3. Configuring Preference for IPv6 or IPv4 ..................20
10.3.1. Handling Broken IPv6 ..............................21
10.4. Configuring Preference for Link-Local Addresses ..........21
10.5. Configuring a Multi-Homed Site ...........................22
10.6. Configuring ULA Preference ...............................24
10.7. Configuring 6to4 Preference ..............................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Appendix A. Acknowledgements .....................................29
Appendix B. Changes since RFC 3484 ...............................29
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Context in Which the Algorithms Operate .........................4
2.1. Policy Table ...............................................6
2.2. Common Prefix Length .......................................7
3. Address Properties ..............................................7
3.1. Scope Comparisons ..........................................8
3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9
3.4. IPv6 Loopback Address and Other Format Prefixes ............9
3.5. Mobility Addresses .........................................9
4. Candidate Source Addresses .....................................10
5. Source Address Selection .......................................11
6. Destination Address Selection ..................................14
7. Interactions with Routing ......................................16
8. Implementation Considerations ..................................16
9. Security Considerations ........................................17
10. Examples ......................................................18
10.1. Default Source Address Selection .........................18
10.2. Default Destination Address Selection ....................19
10.3. Configuring Preference for IPv6 or IPv4 ..................20
10.3.1. Handling Broken IPv6 ..............................21
10.4. Configuring Preference for Link-Local Addresses ..........21
10.5. Configuring a Multi-Homed Site ...........................22
10.6. Configuring ULA Preference ...............................24
10.7. Configuring 6to4 Preference ..............................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Appendix A. Acknowledgements .....................................29
Appendix B. Changes since RFC 3484 ...............................29
The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. These addresses might have different reachability scopes (link-local, site-local, or global). These addresses might also be "preferred" or "deprecated" [RFC4862]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [RFC4941]. The mobility architecture introduces "home addresses" and "care-of addresses" [RFC6275]. In addition, multi-homing situations will result in more addresses per node. For example, a node might have multiple interfaces, some of them tunnels or virtual interfaces, or a site might have multiple ISP attachments with a global prefix per ISP.
IPv6寻址体系结构[RFC4291]允许向接口分配多个单播地址。这些地址可能具有不同的可达范围（链接本地、站点本地或全局）。这些地址也可能是“首选”或“不推荐”[RFC4862]。隐私考虑引入了“公共地址”和“临时地址”的概念[RFC4941]。移动性架构引入了“家庭地址”和“转交地址”[RFC6275]。此外，多归属情况将导致每个节点有更多的地址。例如，一个节点可能有多个接口，其中一些接口是隧道或虚拟接口，或者一个站点可能有多个ISP附件，每个ISP都有一个全局前缀。
The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems.
最终的结果是，IPv6实现在启动通信时通常会面临多个可能的源地址和目标地址。最好有默认算法，在所有实现中通用，用于选择源地址和目标地址，以便开发人员和管理员可以对其系统的行为进行推理和预测。
Furthermore, dual- or hybrid-stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication, for example, when DNS name resolution yields both IPv6 and IPv4 addresses and the network protocol stack has available both IPv6 and IPv4 source addresses. In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior. As one example, suppose a DNS name resolves to a global IPv6 address and a global IPv4 address. If the node has assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 address [RFC3927], then IPv6 is the best choice for communication. But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses.
此外，支持IPv6和IPv4的双栈或混合栈实现在启动通信时通常需要在IPv6和IPv4之间进行选择，例如，当DNS名称解析同时产生IPv6和IPv4地址，并且网络协议栈同时具有IPv6和IPv4源地址时。在这种情况下，始终首选IPv6或始终首选IPv4的简单策略可能会产生不良行为。例如，假设DNS名称解析为全局IPv6地址和全局IPv4地址。如果节点已分配全局IPv6地址和169.254/16自动配置的IPv4地址[RFC3927]，则IPv6是通信的最佳选择。但是，如果节点仅分配了链路本地IPv6地址和全局IPv4地址，则IPv4是通信的最佳选择。目标地址选择算法通过在IPv6和IPv4地址之间进行选择的统一过程解决了这一问题。
The algorithms in this document are specified as a set of rules that define a partial ordering on the set of addresses that are available for use. In the case of source address selection, a node typically has multiple addresses assigned to its interfaces, and the source address ordering rules in Section 5 define which address is the "best" one to use. In the case of destination address selection, the DNS might return a set of addresses for a given name, and an application needs to decide which one to use first and in what order to try others if the first one is not reachable. The destination address ordering rules in Section 6, when applied to the set of addresses returned by the DNS, provide such a recommended ordering.
本文档中的算法指定为一组规则，这些规则定义了可供使用的地址集的偏序。在源地址选择的情况下，一个节点通常有多个地址分配给其接口，第5节中的源地址排序规则定义了哪个地址是“最佳”地址。在选择目标地址的情况下，DNS可能会返回给定名称的一组地址，应用程序需要决定首先使用哪个地址，如果无法访问第一个地址，则以什么顺序尝试其他地址。第6节中的目标地址排序规则在应用于DNS返回的地址集时，提供了这样一种推荐的排序。
This document specifies source address selection and destination address selection separately but uses a common context so that together the two algorithms yield useful results. The algorithms attempt to choose source and destination addresses of appropriate scope and configuration status ("preferred" or "deprecated" in the RFC 4862 sense). Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information.
本文档分别指定了源地址选择和目标地址选择，但使用了一个公共上下文，以便将这两种算法结合在一起产生有用的结果。算法尝试选择适当范围和配置状态的源地址和目标地址（“RFC 4862意义上的首选”或“不推荐”）。此外，本文件建议了一种首选方法，即最长匹配前缀，用于在缺乏更好信息的情况下从其他等效地址中进行选择。
This document also specifies policy hooks to allow administrative override of the default behavior. For example, using these hooks, an administrator can specify a preferred source prefix for use with a destination prefix or prefer destination addresses with one prefix over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea.
本文档还指定了允许对默认行为进行管理覆盖的策略挂钩。例如，使用这些钩子，管理员可以指定一个首选源前缀与目标前缀一起使用，或者指定一个前缀的目标地址优于另一个前缀的地址。这些钩子为管理员提供了处理一些多宿主和转换场景的灵活性，但它们肯定不是万灵药。
The selection rules specified in this document MUST NOT be construed to override an application or upper layer's explicit choice of a legal destination or source address.
不得将本文档中指定的选择规则解释为覆盖应用程序或上层对合法目的地或源地址的明确选择。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Our context for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, we have two separate algorithms for these tasks. The algorithms are designed to work well together, and they share a mechanism for administrative policy override.
我们的地址选择上下文源自最常见的实现架构，它将目标地址的选择与源地址的选择分开。因此，对于这些任务，我们有两种不同的算法。这些算法设计为协同工作，它们共享一种管理策略覆盖机制。
In this implementation architecture, applications use APIs such as getaddrinfo() [RFC3493] that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes represented as IPv4-mapped addresses). The application then passes a destination address to the network stack with connect() or sendto(). The application would then typically try the first address in the list, looping over the list of addresses until it finds a working address. In any case, the network layer is never in a situation where it needs to choose a destination address from several alternatives. The application might also specify a source
在此实现体系结构中，应用程序使用诸如getaddrinfo（）[RFC3493]之类的API，这些API将地址列表返回给应用程序。此列表可能同时包含IPv6和IPv4地址（有时表示为IPv4映射地址）。然后，应用程序使用connect（）或sendto（）将目标地址传递给网络堆栈。然后，应用程序通常会尝试列表中的第一个地址，在地址列表上循环，直到找到一个工作地址。在任何情况下，网络层都不需要从多个备选方案中选择目标地址。应用程序还可以指定一个源
address with bind(), but often the source address is left unspecified. Therefore, the network layer does often choose a source address from several alternatives.
带有bind（）的地址，但通常未指定源地址。因此，网络层通常会从几个备选方案中选择源地址。
As a consequence, we intend that implementations of APIs such as getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. Separately, the IPv6 network layer will use the source address selection algorithm when an application or upper layer has not specified a source address. Application of this specification to source address selection in an IPv4 network layer might be possible, but this is not explored further here.
因此，我们希望诸如getaddrinfo（）之类的API实现将使用此处指定的目标地址选择算法对它们返回的IPv6和IPv4地址列表进行排序。另外，当应用程序或上层未指定源地址时，IPv6网络层将使用源地址选择算法。将此规范应用于IPv4网络层中的源地址选择可能是可行的，但此处不作进一步探讨。
Well-behaved applications SHOULD NOT simply use the first address returned from an API such as getaddrinfo() and then give up if it fails. For many applications, it is appropriate to iterate through the list of addresses returned from getaddrinfo() until a working address is found. For other applications, it might be appropriate to try multiple addresses in parallel (e.g., with some small delay in between) and use the first one to succeed.
行为良好的应用程序不应该简单地使用从API（如getaddrinfo（）返回的第一个地址，然后在失败时放弃。对于许多应用程序，迭代从getaddrinfo（）返回的地址列表直到找到工作地址是合适的。对于其他应用程序，可能适合并行尝试多个地址（例如，在两个地址之间有一些小延迟），并使用第一个地址成功。
Although source and destination address selection is most typically done when initiating communication, a responder also must deal with address selection. In many cases, this is trivially dealt with by an application using the source address of a received packet as the response destination and the destination address of the received packet as the response source. Other cases, however, are handled like an initiator, such as when the request is multicast and hence source address selection must still occur when generating a response or when the request includes a list of the initiator's addresses from which to choose a destination. Finally, a third application scenario is that of a listening application choosing on what local addresses to listen. This third scenario is out of the scope of this document.
虽然源地址和目标地址选择通常在启动通信时完成，但响应者也必须处理地址选择。在许多情况下，应用程序使用接收到的数据包的源地址作为响应目的地，使用接收到的数据包的目的地地址作为响应源来处理这一问题。然而，其他情况与启动器一样处理，例如当请求是多播的，因此在生成响应时仍必须进行源地址选择，或者当请求包括启动器地址列表以从中选择目的地时。最后，第三个应用程序场景是侦听应用程序选择要侦听的本地地址。第三种情况超出了本文档的范围。
The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non-deprecated source addresses, avoid the use of transitional addresses when native addresses are available, and all else being equal, prefer address pairs having the longest possible common prefix. For source address selection, temporary addresses [RFC4941] are preferred over public addresses. In mobile situations [RFC6275], home addresses are preferred over care-of addresses. If an address is simultaneously a home address and a care-of address (indicating the mobile node is "at home" for that address), then the home/care-of address is preferred over addresses that are solely a home address or solely a care-of address.
算法在做出决策时使用了几个标准。综合效果是，对于两个地址的作用域或类型相同的目的地/源地址对，目的地地址的作用域较小，而不是较大，首选未弃用的源地址，避免在本机地址可用时使用过渡地址，并且所有其他都相同，首选具有最长公共前缀的地址对。对于源地址选择，临时地址[RFC4941]优先于公共地址。在移动情况下[RFC6275]，家庭地址优先于转交地址。如果地址同时是家庭地址和照管地址（指示移动节点对于该地址“在家”），则家庭/照管地址优先于仅为家庭地址或仅为照管地址的地址。
This specification optionally allows for the possibility of administrative configuration of policy (e.g., via manual configuration or a DHCP option such as that proposed in [ADDR-SEL-OPT]) that can override the default behavior of the algorithms. The policy override consists of the following set of state, which SHOULD be configurable:
本规范可选地允许对策略进行管理配置（例如，通过手动配置或DHCP选项，如[ADDR-SEL-OPT]中提出的），以覆盖算法的默认行为。策略覆盖由以下一组状态组成，这些状态应是可配置的：
o Policy Table (Section 2.1): a table that specifies precedence values and preferred source prefixes for destination prefixes.
o 策略表（第2.1节）：为目标前缀指定优先级值和首选源前缀的表。
o Automatic Row Additions flag (Section 2.1): a flag that specifies whether the implementation is permitted to automatically add site-specific rows for certain types of addresses.
o 自动行添加标志（第2.1节）：指定是否允许实现为特定类型的地址自动添加站点特定行的标志。
o Privacy Preference flag (Section 5): a flag that specifies whether temporary source addresses or stable source addresses are preferred by default when both types exist.
o 隐私首选标志（第5节）：一个标志，指定当临时源地址和稳定源地址都存在时，默认情况下是首选临时源地址还是稳定源地址。
The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces two values: a precedence value denoted Precedence(A) and a classification or label denoted Label(A).
策略表是最长的匹配前缀查找表，很像路由表。给定地址A，策略表中的查找将生成两个值：表示优先级（A）的优先级值和表示标签（A）的分类或标签。
The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A has higher precedence than address B, meaning that our algorithm will prefer to sort destination address A before destination address B.
优先级值priority（A）用于对目标地址进行排序。如果优先级（A）>优先级（B），我们说地址A的优先级高于地址B，这意味着我们的算法将更倾向于在目标地址B之前对目标地址A进行排序。
The label value Label(A) allows for policies that prefer a particular source address prefix for use with a destination address prefix. The algorithms prefer to use a source address S with a destination address D if Label(S) = Label(D).
标签值标签（A）允许策略选择特定的源地址前缀与目标地址前缀一起使用。如果Label（S）=Label（D），算法更喜欢使用源地址S和目标地址D。
IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. It is important that implementations provide a way to change the default policies as more experience is gained. Sections 10.3 through 10.7 provide examples of the kind of changes that might be needed.
IPv6实现应通过一种至少与此处定义的策略表一样强大的机制支持可配置的地址选择。随着经验的积累，实现提供了一种更改默认策略的方法，这一点很重要。第10.3节至第10.7节提供了可能需要的变更类型示例。
If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table:
如果实现不可配置或尚未配置，则应根据此处指定的算法以及以下默认策略表进行操作：
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
An implementation MAY automatically add additional site-specific rows to the default table based on its configured addresses, such as for Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses, for instance (see Sections 10.6 and 10.7 for examples). Any such rows automatically added by the implementation as a result of address acquisition MUST NOT override a row for the same prefix configured via other means. That is, rows can be added but never updated automatically. An implementation SHOULD provide a means (the Automatic Row Additions flag) for an administrator to disable automatic row additions.
实现可以基于其配置的地址自动向默认表中添加额外的站点特定行，例如，对于唯一本地地址（ULA）[RFC4193]和6to4[RFC3056]地址（示例请参见第10.6节和第10.7节）。由于地址获取而由实现自动添加的任何此类行不得覆盖通过其他方式配置的相同前缀的行。也就是说，可以添加行，但不会自动更新。实现应该为管理员提供禁用自动行添加的方法（自动行添加标志）。
As will become apparent later, one effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 source addresses with 6to4 destination addresses, etc. Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available.
如下文所述，默认策略表的一个效果是更喜欢使用本机源地址和本机目标地址，6to4源地址和6to4目标地址等。默认策略表的另一个效果是更喜欢使用IPv6地址进行通信，而不是使用IPv4地址进行通信，如果匹配的源地址可用。
Policy table entries for address prefixes that are not of global scope MAY be qualified with an optional zone index. If so, a prefix table entry only matches against an address during a lookup if the zone index also matches the address's zone index.
不属于全局范围的地址前缀的策略表项可以使用可选区域索引限定。如果是这样，如果区域索引也与地址的区域索引匹配，则前缀表项仅在查找期间与地址匹配。
We define the common prefix length CommonPrefixLen(S, D) of a source address S and a destination address D as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common, up to the length of S's prefix (i.e., the portion of the address not including the interface ID). For example, CommonPrefixLen(fe80::1, fe80::2) is 64.
我们将源地址S和目标地址D的公共前缀长度CommonPrefixLen（S，D）定义为两个地址共有的最长前缀（查看最重要或最左边的位）的长度，直到S的前缀的长度（即地址中不包括接口ID的部分）。例如，CommonPrefixLen（fe80:：1，fe80:：2）是64。
In the rules given in later sections, addresses of different types (e.g., IPv4, IPv6, multicast, and unicast) are compared against each other. Some of these address types have properties that aren't
在后面部分给出的规则中，不同类型的地址（例如IPv4、IPv6、多播和单播）会相互比较。其中一些地址类型的属性不是
directly comparable to each other. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 addresses have no such notion. To compare such addresses using the ordering rules (e.g., to use "preferred" addresses in preference to "deprecated" addresses), the following mappings are defined.
彼此直接可比。例如，IPv6单播地址可以是“首选”或“不推荐”[RFC4862]，而IPv4地址没有这样的概念。为了使用排序规则比较这些地址（例如，优先使用“首选”地址而不是“不推荐”地址），定义了以下映射。
Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for interface-local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes (Section 2.7 of [RFC4291]).
多播目标地址有一个4位作用域字段，用于控制多播数据包的传播。IPv6寻址体系结构定义接口本地（0x1）、链路本地（0x2）、管理本地（0x4）、站点本地（0x5）、组织本地（0x8）和全局（0xE）作用域的作用域字段值[RFC4291]的第2.7节）。
Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope. We map unicast link-local to multicast link-local, unicast site-local to multicast site-local, and unicast global scope to multicast global scope. For example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global. (Note that IPv6 site-local unicast addresses are deprecated [RFC4291]. However, some existing implementations and deployments may still use these addresses; they are therefore included in the procedures in this specification. Also, note that ULAs are considered as global, not site-local, scope but are handled via the prefix policy table as discussed in Section 10.6.)
在存在多播目标地址的情况下使用源地址选择算法需要比较单播地址范围和多播地址范围。我们将单播链路本地映射到多播链路本地，单播站点本地映射到多播站点本地，单播全局范围映射到多播全局范围。例如，单播站点本地等于多播站点本地，它小于多播组织本地，它小于单播全局，它等于多播全局。（请注意，IPv6站点本地单播地址已弃用[RFC4291]。但是，一些现有的实现和部署可能仍然使用这些地址；因此，它们包含在本规范的过程中。此外，请注意，ULA被视为全局范围，而不是站点本地范围，但通过前缀策略表进行处理，如第10.6节所述。）
We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B).
我们将作用域（A）写为地址A的作用域。例如，如果A是链路本地单播地址，B是站点本地多播地址，则作用域（A）<作用域（B）。
This mapping implicitly conflates unicast site boundaries and multicast site boundaries [RFC4007].
此映射隐式地合并了单播站点边界和多播站点边界[RFC4007]。
The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses MUST be represented as IPv4-mapped addresses [RFC4291]. For example, to look up the precedence or other attributes of an IPv4 address in the policy table, look up the corresponding IPv4-mapped IPv6 address.
目标地址选择算法在IPv6和IPv4地址上运行。为此，IPv4地址必须表示为IPv4映射地址[RFC4291]。例如，要在策略表中查找IPv4地址的优先级或其他属性，请查找对应的IPv4映射IPv6地址。
IPv4 addresses are assigned scopes as follows. IPv4 auto-configuration addresses [RFC3927], which have the prefix 169.254/16, are assigned link-local scope. IPv4 loopback addresses (Section
IPv4地址分配的作用域如下。IPv4自动配置地址[RFC3927]前缀为169.254/16，分配给链路本地作用域。IPv4环回地址（第节）
4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address (Section 4 of [RFC4007])). Other IPv4 addresses (including IPv4 private addresses [RFC1918] and Shared Address Space addresses [RFC6598]) are assigned global scope.
4.2.2.11 前缀为127/8的[RFC1812]）中的一个被分配了链路本地作用域（类似于IPv6环回地址的处理方法[RFC4007]的第4节）。其他IPv4地址（包括IPv4专用地址[RFC1918]和共享地址空间地址[RFC6598]）被分配为全局作用域。
IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 sense) configuration status.
IPv4地址必须被视为具有“首选”（在RFC 4862意义上）配置状态。
IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses [RFC3056] contain an embedded IPv4 address. For the purposes of this document, these addresses MUST be treated as having global scope.
IPv4兼容地址[RFC4291]、IPv4映射地址[RFC4291]、IPv4转换地址[RFC6145]、IPv4可翻译地址[RFC6145]和6to4地址[RFC3056]包含嵌入式IPv4地址。就本文件而言，这些地址必须视为具有全局范围。
IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be treated as having "preferred" (in the RFC 4862 sense) configuration status.
IPv4兼容、IPv4映射和IPv4转换的地址必须视为具有“首选”（在RFC 4862意义上）配置状态。
The loopback address MUST be treated as having link-local scope (Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense) configuration status.
环回地址必须被视为具有链路本地作用域（RFC4007第4节）和“首选”（在RFC 4862意义下）配置状态。
NSAP addresses and other addresses with as-yet-undefined format prefixes MUST be treated as having global scope and "preferred" (in the RFC 4862) configuration status. Later standards might supersede this treatment.
NSAP地址和其他格式前缀尚未定义的地址必须视为具有全局作用域和“首选”（在RFC 4862中）配置状态。以后的标准可能会取代这种处理方法。
Some nodes might support mobility using the concepts of home address and care-of address (for example, see [RFC6275]). Conceptually, a home address is an IP address assigned to a mobile node and used as the permanent address of the mobile node. A care-of address is an IP address associated with a mobile node while visiting a foreign link. When a mobile node is on its home link, it might have an address that is simultaneously a home address and a care-of address.
一些节点可能使用家庭地址和转交地址的概念来支持移动（例如，请参见[RFC6275]）。从概念上讲，归属地址是分配给移动节点并用作移动节点的永久地址的IP地址。转交地址是在访问外部链路时与移动节点关联的IP地址。当移动节点位于其主链路上时，其地址可能同时是主地址和转交地址。
For the purposes of this document, it is sufficient to know whether one's own addresses are designated as home addresses or care-of addresses. Whether an address ought to be designated a home address or care-of address is outside the scope of this document.
就本文件而言，了解自己的地址是否被指定为家庭地址或护理地址就足够了。是否应将地址指定为家庭地址或护理地址不在本文件范围内。
The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address. The candidate set is the set of all addresses that could be used as a source address; the source address selection algorithm will pick an address out of that set. We write CandidateSource(A) to denote the candidate set for the address A.
源地址选择算法使用给定目标地址的潜在源地址的“候选集”概念。候选集是可以用作源地址的所有地址的集合；源地址选择算法将从该集合中选择一个地址。我们写CandidateSource（A）来表示地址A的候选集。
It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the "outgoing" interface). On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. Implementations that wish to support the use of global source addresses assigned to a loopback interface MUST behave as if the loopback interface originates and forwards the packet.
建议候选源地址是分配给将用于发送到目的地的接口（“传出”接口）的单播地址集。在路由器上，候选集可以包括分配给转发分组的任何接口的单播地址，服从下面描述的限制。希望支持使用分配给环回接口的全局源地址的实现必须表现为环回接口发起并转发数据包。
Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] requires that routers verify that the source address of a packet identifies a neighbor before generating a Redirect, so it is advantageous for hosts to choose source addresses assigned to the outgoing interface.
讨论：邻居发现重定向机制[RFC4861]要求路由器在生成重定向之前验证数据包的源地址是否标识邻居，因此主机选择分配给传出接口的源地址是有利的。
In some cases, the destination address might be qualified with a zone index or other information that will constrain the candidate set.
在某些情况下，可能会使用区域索引或其他约束候选集的信息限定目标地址。
For all multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface.
对于所有多播和链路本地目标地址，候选源地址集必须仅包括分配给与传出接口属于同一链路的接口的地址。
Discussion: The restriction for multicast destination addresses is necessary because currently deployed multicast forwarding algorithms use Reverse Path Forwarding (RPF) checks.
讨论：对多播目标地址的限制是必要的，因为当前部署的多播转发算法使用反向路径转发（RPF）检查。
For site-local unicast destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface.
对于站点本地单播目标地址，候选源地址集必须仅包括分配给与传出接口属于同一站点的接口的地址。
In any case, multicast addresses and the unspecified address MUST NOT be included in a candidate set.
在任何情况下，多播地址和未指定的地址都不能包含在候选集中。
On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) [RFC6145], if the destination address is an IPv4-converted address, then the candidate set MUST contain only IPv4-translatable addresses.
在支持无状态IP/ICMP转换（SIIT）[RFC6145]的仅IPv6节点上，如果目标地址是IPv4转换的地址，则候选集必须仅包含IPv4可转换地址。
If an application or upper layer specifies a source address, it may affect the choice of outgoing interface. Regardless, if the application or upper layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error. If the application or upper layer specifies a source address that is in the candidate set for the destination, then the network layer MUST respect that choice. If the application or upper layer does not specify a source address, then the network layer uses the source address selection algorithm specified in the next section.
如果应用程序或上层指定了源地址，则可能会影响传出接口的选择。无论如何，如果应用程序或上层指定的源地址不在目标的候选集中，则网络层必须将其视为错误。如果应用程序或上层指定目标候选集中的源地址，则网络层必须尊重该选择。如果应用程序或上层未指定源地址，则网络层使用下一节中指定的源地址选择算法。
The source address selection algorithm produces as output a single source address for use with a given destination address. This algorithm only applies to IPv6 destination addresses, not IPv4 addresses.
源地址选择算法生成单个源地址作为输出，用于给定的目标地址。此算法仅适用于IPv6目标地址，而不适用于IPv4地址。
The algorithm is specified here in terms of a list of pair-wise comparison rules that (for a given destination address D) imposes a "greater than" ordering on the addresses in the candidate set CandidateSource(D). The address at the front of the list after the algorithm completes is the one the algorithm selects.
这里根据成对比较规则列表指定算法，该规则（对于给定的目的地地址D）对候选集CandidateSource（D）中的地址施加“大于”排序。算法完成后列表前面的地址是算法选择的地址。
Note that conceptually, a sort of the candidate set is being performed, where a set of rules define the ordering among addresses. But because the output of the algorithm is a single source address, an implementation need not actually sort the set; it need only identify the "maximum" value that ends up at the front of the sorted list.
请注意，从概念上讲，正在执行一种候选集，其中一组规则定义了地址之间的顺序。但由于算法的输出是单个源地址，因此实现不需要对集合进行实际排序；它只需要标识最终位于排序列表前面的“最大”值。
The ordering of the addresses in the candidate set is defined by a list of eight pair-wise comparison rules, with each rule placing a "greater than", "less than", or "equal to" ordering on two source addresses with respect to each other (and that rule). In the case that a given rule produces a tie, i.e., provides an "equal to" result for the two addresses, the remaining rules MUST be applied (in order) to just those addresses that are tied to break the tie. Note that if a rule produces a single clear "winner" (or set of "winners" in the case of ties), those addresses not in the winning set can be discarded from further consideration, with subsequent rules applied only to the remaining addresses. If the eight rules fail to choose a single address, the tiebreaker is implementation-specific.
候选集中地址的顺序由八个成对比较规则的列表定义，每个规则对两个源地址（以及该规则）进行“大于”、“小于”或“等于”排序。如果给定规则产生一个平局，即为两个地址提供一个“等于”结果，则必须（按顺序）将其余规则仅应用于那些平局以打破平局的地址。请注意，如果一个规则产生一个明确的“赢家”（或在平局的情况下产生一组“赢家”），则不在赢家集中的那些地址可以被丢弃，不再进一步考虑，后续规则仅应用于其余地址。如果八条规则未能选择一个地址，则分层器是特定于实现的。
When comparing two addresses SA and SB from the candidate set, we say "prefer SA" to mean that SA is "greater than" SB, and similarly, we say "prefer SB" to mean that SA is "less than" SB. If neither is stated to be preferred, this means that SA is "equal to" SB, and the remaining rules apply as noted above.
当比较候选集中的两个地址SA和SB时，我们说“偏好SA”表示SA“大于”SB，同样，我们说“偏好SB”表示SA“小于”SB。如果两者都不是首选，这意味着SA“等于”SB，其余规则如上所述适用。
Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
规则1：选择相同的地址。如果SA=D，则选择SA。同样，如果SB=D，则更喜欢SB。
Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
规则2：选择合适的范围。如果范围（SA）<范围（SB）：如果范围（SA）<范围（D），则选择SB，否则选择SA。类似地，如果作用域（SB）<作用域（SA）：如果作用域（SB）<作用域（D），则更喜欢SA，否则更喜欢SB。
Discussion: This rule must be given high priority because it can affect interoperability.
讨论：此规则必须具有较高的优先级，因为它会影响互操作性。
Rule 3: Avoid deprecated addresses. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 4862 sense), then prefer the one that is "preferred".
规则3：避免使用不推荐的地址。如果两个源地址中的一个是“首选”的，而其中一个是“不推荐的”（在RFC 4862的意义上），则选择“首选”的源地址。
Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB.
规则4：选择家庭住址。如果SA同时是家庭住址和照顾住址，而SB不是，则首选SA。同样，如果SB同时是家庭住址和照顾住址，而SA不是，则更喜欢SB。如果SA只是一个家庭地址，而SB只是一个照顾地址，那么选择SA。同样，如果SB只是一个家庭地址，SA只是一个照顾地址，那么更喜欢SB。
Implementations supporting home addresses MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions such as [RFC5014]). Use of the mechanism MUST only affect the selection rules for the invoking application.
支持家庭地址的实现必须提供一种机制，允许应用程序逆转这种偏好，并优先于家庭地址（例如，通过适当的API扩展，如[RFC5014]）。使用该机制只能影响调用应用程序的选择规则。
Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB.
规则5：更喜欢传出接口。如果SA分配给将用于发送给D的接口，而SB分配给不同的接口，则首选SA。类似地，如果将SB分配给将用于发送到D的接口，并且将SA分配给不同的接口，则首选SB。
Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB.
规则5.5：首选由下一跳播发的前缀中的地址。如果SA或SA的前缀由将用于发送到D的选定下一个跃点分配，并且SB或SB的前缀由不同的下一个跃点分配，则首选SA。类似地，如果SB或SB的前缀由将用于发送到D的下一跳指定，而SA或SA的前缀由不同的下一跳指定，则首选SB。
Discussion: An IPv6 implementation is not required to remember which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Hence, Rule 5.5 is only applicable to implementations that track this information.
讨论：IPv6实现不需要记住哪些下一个跃点和哪些前缀。[RFC4861]第5节和[RFC4191]第3节中的IPv6主机概念模型没有此类要求。因此，规则5.5仅适用于跟踪此信息的实现。
Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB.
规则6：选择匹配的标签。如果标签（SA）=标签（D）和标签（SB）<>标签（D），则首选SA。类似地，如果标签（SB）=标签（D）和标签（SA）<>标签（D），则首选SB。
Rule 7: Prefer temporary addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public address, then prefer SB.
规则7：选择临时地址。如果SA是临时地址，SB是公共地址，则首选SA。同样，如果SB是临时地址，SA是公共地址，则更喜欢SB。
Implementations MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer public addresses over temporary addresses (e.g., via appropriate API extensions such as [RFC5014]). Use of the mechanism MUST only affect the selection rules for the invoking application. This default is intended to address privacy concerns as discussed in [RFC4941] but introduces a risk of applications potentially failing due to the relatively short lifetime of temporary addresses or due to the possibility of the reverse lookup of a temporary address either failing or returning a randomized name. Implementations for which application compatibility considerations outweigh these privacy concerns MAY reverse the sense of this rule and by default prefer public addresses over temporary addresses. There SHOULD be an administrative option (the Privacy Preference flag) to change this preference, if the implementation supports temporary addresses. If there is no such option, there MUST be an administrative option to disable temporary addresses.
实现必须提供一种机制，允许应用程序逆转这种偏好，并偏好公共地址而非临时地址（例如，通过适当的API扩展，如[RFC5014]）。使用该机制只能影响调用应用程序的选择规则。此默认设置旨在解决[RFC4941]中讨论的隐私问题，但由于临时地址的生存期相对较短，或者由于临时地址的反向查找可能失败或返回随机名称，因此会引入应用程序可能失败的风险。应用程序兼容性考虑超过这些隐私考虑的实现可能会改变此规则的含义，并且默认情况下更喜欢公共地址而不是临时地址。如果实现支持临时地址，则应该有一个管理选项（隐私首选项标志）来更改此首选项。如果没有这样的选项，则必须有一个管理选项来禁用临时地址。
Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB.
规则8：使用最长匹配前缀。如果CommonPrefixLen（SA，D）>CommonPrefixLen（SB，D），则首选SA。类似地，如果CommonPrefixLen（SB，D）>CommonPrefixLen（SA，D），则更喜欢SB。
Rule 8 MAY be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance.
如果实现具有在源地址中进行选择的其他方式，则规则8可能被取代。例如，如果实现不知何故知道哪个源地址将导致“最佳”通信性能。
The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list.
目标地址选择算法获取目标地址列表，并对地址进行排序以生成新列表。这里根据地址DA和DB的成对比较来指定，其中DA在原始列表中出现在DB之前。
The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address MUST be represented as an IPv4-mapped address.
该算法对IPv6和IPv4地址进行排序。要在策略表中查找IPv4地址的属性，IPv4地址必须表示为IPv4映射地址。
We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document.
我们写入源（D）以指示目标D的选定源地址。对于IPv6地址，上一节指定了源地址选择算法。本文档中未指定IPv4地址的源地址选择。
We say that Source(D) is undefined if there is no source address available for destination D. For IPv6 addresses, this is only the case if CandidateSource(D) is the empty set.
如果目标D没有可用的源地址，我们就说源（D）是未定义的。对于IPv6地址，只有候选源（D）是空集时才是这种情况。
The pair-wise comparison of destination addresses consists of ten rules, which MUST be applied in order. If a rule determines a result, then the remaining rules are not relevant and MUST be ignored. Subsequent rules act as tiebreakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tiebreaker rules can be used to sort a list.
目标地址的成对比较由十条规则组成，必须按顺序应用这些规则。如果某个规则确定了结果，则其余规则不相关，必须忽略。后续规则充当早期规则的分闸规则。请参阅上一节，了解如何使用成对比较分断规则对列表进行排序的更详细说明。
Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB.
规则1：避免无法使用的目的地。如果已知数据库不可访问或源（DB）未定义，则首选DA。类似地，如果已知DA不可访问，或者如果源（DA）未定义，则首选DB。
Discussion: An implementation might know that a particular destination is unreachable in several ways. For example, the destination might be reached through a network interface that is currently unplugged. For example, the implementation might retain information from Neighbor Unreachability Detection [RFC4861] for some period of time. In any case, the determination of unreachability for the purposes of this rule is implementation-dependent.
讨论：一个实现可能知道特定的目的地在几种方式下是无法到达的。例如，可以通过当前未拔出的网络接口到达目的地。例如，该实现可能会将来自邻居不可达性检测[RFC4861]的信息保留一段时间。在任何情况下，就本规则而言，不可达性的确定取决于实现。
Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then prefer DB.
规则2：首选匹配范围。如果Scope（DA）=Scope（Source（DA））和Scope（DB）<>Scope（Source（DB）），则首选DA。类似地，如果Scope（DA）<>Scope（Source（DA））和Scope（DB）=Scope（Source（DB）），则首选DB。
Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then prefer DB. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then prefer DA.
规则3：避免使用不推荐的地址。如果源（DA）已弃用，而源（DB）未弃用，则首选DB。类似地，如果源（DA）未弃用，而源（DB）已弃用，则首选DA。
Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is simultaneously a home address and care-of address and Source(DA) is not, then prefer DB.
规则4：选择家庭住址。如果源（DA）同时是家庭地址和转交地址，而源（DB）不是，则首选DA。类似地，如果源（DB）同时是家庭地址和转交地址，而源（DA）不是，则首选DB。
If Source(DA) is just a home address and Source(DB) is just a care-of address, then prefer DA. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then prefer DB.
如果源（DA）只是一个家庭地址，而源（DB）只是一个转交地址，则首选DA。类似地，如果源（DA）只是一个转交地址，而源（DB）只是一个家庭地址，则首选DB。
Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB.
规则5：选择匹配的标签。如果标签（源（DA））=标签（DA）和标签（源（DB））<>标签（DB），则首选DA。类似地，如果Label（Source（DA））<>Label（DA）和Label（Source（DB））=Label（DB），则首选DB。
Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB.
规则6：优先选择更高的优先级。如果优先级（DA）>优先级（DB），则首选DA。同样，如果优先级（DA）<优先级（DB），则首选DB。
Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA.
规则7：选择本机传输。如果DA是通过封装转换机制（例如IPv4中的IPv6）到达的，而DB不是，则首选DB。类似地，如果DB是通过封装实现的，而DA不是，则首选DA。
Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and configured tunnels [RFC4213] are examples of encapsulating transition mechanisms for which the destination address does not have a specific prefix and hence can not be assigned a lower precedence in the policy table. An implementation MAY generalize this rule by using a concept of interface preference and giving virtual interfaces (like the IPv6- in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces).
讨论：IPv4基础设施上的IPv6快速部署（6rd）协议[RFC5969]、站点内自动隧道寻址协议（ISATAP）[RFC5214]和配置隧道[RFC4213]是封装转换机制的示例，目标地址没有特定前缀，因此无法在策略表中分配较低的优先级。一个实现可以通过使用接口首选项的概念来概括此规则，并给予虚拟接口（如IPv6-in-IPv4封装接口）比本机接口（如以太网接口）更低的首选项。
Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB.
规则8：选择较小的范围。如果作用域（DA）<作用域（DB），则首选DA。类似地，如果Scope（DA）>Scope（DB），则首选DB。
Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(Source(DA), DA) > CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), then prefer DB.
规则9：使用最长匹配前缀。当DA和DB属于同一地址系列（都是IPv6或都是IPv4）时：如果CommonPrefixLen（源（DA），DA）>CommonPrefixLen（源（DB），DB），则首选DA。类似地，如果CommonPrefixLen（Source（DA），DA）<CommonPrefixLen（Source（DB），DB），则首选DB。
Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise, prefer DB.
规则10：否则，保持订单不变。如果DA在原始列表中位于DB之前，则首选DA。否则，请选择DB。
Rules 9 and 10 MAY be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance.
如果实现有其他排序目的地址的方法，则规则9和10可能被取代。例如，如果实现不知何故知道哪些目标地址将导致“最佳”通信性能。
This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection. However, implementations MAY use source address considerations as a tiebreaker when choosing among otherwise equivalent routes.
此源地址选择规范假定路由（更准确地说，在具有多个接口的节点上选择传出接口）在源地址选择之前完成。然而，当在其他等效路由中进行选择时，实现可能会将源地址考虑因素用作断开连接的因素。
For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred (in the RFC 4862 sense) global addresses. When sending to a global destination address, if there's no routing reason to prefer one interface over the other, then an implementation MAY preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination.
例如，假设一个节点在两个不同的链路上有接口，两个链路都有一个工作的默认路由器。这两个接口都有首选（在RFC 4862意义上）全局地址。当发送到全局目标地址时，如果没有路由理由选择一个接口而不是另一个接口，那么实现可能会优先选择传出接口，该接口将允许它使用与目标共享更长公共前缀的源地址。
Implementations that support Rule 5.5 of source address selection (Section 5) also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then, when sending via the first router, the host might prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.
支持源地址选择规则5.5（第5节）的实现也使用路由器的选择来影响源地址的选择。例如，假设一台主机位于与两台路由器的链路上。一个路由器播发全局前缀a，另一个路由器播发全局前缀B。然后，当通过第一个路由器发送时，主机可能更喜欢前缀为a的源地址，当通过第二个路由器发送时，主机可能更喜欢前缀为B的源地址。
The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is for getaddrinfo() to call down to the network layer with a list of destination addresses, sort the list in the network layer with full
目标地址选择算法需要有关潜在源地址的信息。一种可能的实现策略是getaddrinfo（）使用目标地址列表向下调用网络层，在网络层中使用full对列表进行排序
current knowledge of available source addresses, and return the sorted list to getaddrinfo(). This is simple and gives the best results, but it introduces the overhead of another system call. One way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to re-sort the list.
当前了解可用源地址，并将排序后的列表返回给getaddrinfo（）。这很简单，可以得到最好的结果，但会增加另一个系统调用的开销。减少此开销的一种方法是在解析器中缓存已排序的地址列表，以便后续对相同名称的调用不需要重新排序列表。
Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getaddrinfo(). To reduce overhead in this approach, the source address information can be cached, amortizing the overhead of retrieving it across multiple calls to getaddrinfo(). In this approach, the implementation might not have knowledge of the outgoing interface for each destination, so it MAY use a looser definition of the candidate set during destination address ordering.
另一种实现策略是调用网络层来检索源地址信息，然后直接在getaddrinfo（）的上下文中对地址列表进行排序。为了减少这种方法的开销，可以缓存源地址信息，从而在多次调用getaddrinfo（）时分摊检索它的开销。在这种方法中，实现可能不知道每个目的地的传出接口，因此它可能在目的地地址排序期间使用更宽松的候选集定义。
In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection or if the ordering of a cached list of destination addresses is possibly stale, then it MUST ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries, source address assignments, or prefix policy table entries that might affect these algorithms have changed. Another strategy is to use an invalidation counter that is incremented whenever any underlying state is changed. By caching the current invalidation counter value with derived state and then later comparing against the current value, the implementation could detect if the derived state is potentially stale.
在任何情况下，如果实现在其目标地址选择的实现中使用缓存且可能过时的信息，或者如果缓存的目标地址列表的顺序可能过时，则必须确保返回到应用程序的目标地址顺序过期不超过1秒。例如，实现可能会进行系统调用，以检查可能影响这些算法的任何路由表条目、源地址分配或前缀策略表条目是否已更改。另一种策略是使用失效计数器，每当任何基础状态发生更改时，该计数器都会递增。通过使用派生状态缓存当前失效计数器值，然后稍后与当前值进行比较，实现可以检测派生状态是否可能过时。
This document has no direct impact on Internet infrastructure security.
本文件对互联网基础设施安全没有直接影响。
Note that most source address selection algorithms, including the one specified in this document, expose a potential privacy concern. An unfriendly node can infer correlations among a target node's addresses by probing the target node with request packets that force the target host to choose its source address for the reply packets (perhaps because the request packets are sent to an anycast or multicast address or perhaps because the upper-layer protocol chosen for the attack does not specify a particular source address for its reply packets). By using different addresses for itself, the unfriendly node can cause the target node to expose the target's own addresses. The source address selection default preference for temporary addresses helps mitigate this concern.
请注意，大多数源地址选择算法，包括本文档中指定的算法，都暴露了潜在的隐私问题。不友好节点可以通过使用请求包探测目标节点来推断目标节点地址之间的相关性，请求包迫使目标主机为应答包选择其源地址（可能是因为请求数据包被发送到选播或多播地址，或者可能是因为为攻击选择的上层协议没有为其应答数据包指定特定的源地址）。通过为自己使用不同的地址，不友好节点可能会导致目标节点公开目标自己的地址。临时地址的源地址选择默认首选项有助于缓解此问题。
Similarly, most source and destination address selection algorithms, including the one specified in this document, influence the choice of network path taken (as do routing algorithms that are orthogonal to, but used together with, such algorithms) and hence whether data might be sent over a path or network that might be more or less trusted than other paths or networks. Administrators should consider the security impact of the rows they configure in the prefix policy table, just as they should consider the security impact of the interface metrics used in the routing algorithms.
类似地，大多数源地址和目标地址选择算法，包括本文档中指定的算法，都会影响所采用网络路径的选择（与此类算法正交但与此类算法一起使用的路由算法也是如此）因此，数据是否可以通过比其他路径或网络更可信或更不可信的路径或网络发送。管理员应该考虑它们在前缀策略表中配置的行的安全性影响，就像它们应该考虑路由算法中使用的接口度量的安全影响一样。
In addition, some address selection rules might be administratively configurable. Care must be taken to make sure that all administrative options are secured against illicit modification, or else an attacker could redirect and/or block traffic.
此外，某些地址选择规则可能是可配置的。必须小心确保所有管理选项都受到保护，防止非法修改，否则攻击者可能会重定向和/或阻止通信。
This section contains a number of examples, first showing default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they are not to be construed as normative.
本节包含许多示例，首先显示默认行为，然后演示策略表配置的实用程序。提供这些示例是为了说明目的；不得将其解释为规范性文件。
The source address selection rules, in conjunction with the default policy table, produce the following behavior:
源地址选择规则与默认策略表一起产生以下行为：
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8::1 (prefer appropriate scope)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8::1 (prefer appropriate scope)
Destination: ff05::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8:3::1 (prefer appropriate scope)
Destination: ff05::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8:3::1 (prefer appropriate scope)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::1 (deprecated) or
2001:db8:2::1
Result: 2001:db8:1::1 (prefer same address)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::1 (deprecated) or
2001:db8:2::1
Result: 2001:db8:1::1 (prefer same address)
Destination: fe80::1
Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1
Result: fe80::2 (prefer appropriate scope)
Destination: fe80::1
Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1
Result: fe80::2 (prefer appropriate scope)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
Result: 2001:db8:1:::2 (longest matching prefix)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
Result: 2001:db8:1:::2 (longest matching prefix)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
db8:3::2 (home address)
Result: 2001:db8:3::2 (prefer home address)
Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
db8:3::2 (home address)
Result: 2001:db8:3::2 (prefer home address)
Destination: 2002:c633:6401::1
Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8
(temporary) or 2001:db8:1::2
Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2002:c633:6401::1
Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8
(temporary) or 2001:db8:1::2
Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2001:db8:1::d5e3:0:0:1
Candidate Source Addresses: 2001:db8:1::2 (public) or
2001:db8:1::d5e3:7953:13eb:22e8 (temporary)
Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address)
Destination: 2001:db8:1::d5e3:0:0:1
Candidate Source Addresses: 2001:db8:1::2 (public) or
2001:db8:1::d5e3:7953:13eb:22e8 (temporary)
Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address)
The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior:
目标地址选择规则与默认策略表和源地址选择规则一起产生以下行为：
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src
fe80::1) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src
fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001:db8:1::1 or 10.1.2.3
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src
10.1.2.4) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001:db8:1::1 or 10.1.2.3
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src
10.1.2.4) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::2 or fe80::2
Destination Address List: 2001:db8:1::1 or fe80::1
Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2)
(prefer smaller scope)
Candidate Source Addresses: 2001:db8:1::2 or fe80::2
Destination Address List: 2001:db8:1::1 or fe80::1
Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2)
(prefer smaller scope)
Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
db8:3::1 (home address) or fe80::2 (care-of address)
Destination Address List: 2001:db8:1::1 or fe80::1
Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2)
(prefer home address)
Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
db8:3::1 (home address) or fe80::2 (care-of address)
Destination Address List: 2001:db8:1::1 or fe80::1
Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2)
(prefer home address)
Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated)
Destination Address List: 2001:db8:1::1 or fe80::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2)
(avoid deprecated addresses)
Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated)
Destination Address List: 2001:db8:1::1 or fe80::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2)
(avoid deprecated addresses)
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or
fe80::2
Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src
2001:db8:3f44::2) (longest matching prefix)
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or
fe80::2
Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src
2001:db8:3f44::2) (longest matching prefix)
Candidate Source Addresses: 2002:c633:6401::2 or fe80::2
Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1
(src 2002:c633:6401::2) (prefer matching label)
Candidate Source Addresses: 2002:c633:6401::2 or fe80::2
Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1
(src 2002:c633:6401::2) (prefer matching label)
Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or
fe80::2
Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src
2002:c633:6401::2) (prefer higher precedence)
Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or
fe80::2
Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src
2002:c633:6401::2) (prefer higher precedence)
The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable. An administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
默认策略表为IPv6地址提供了高于IPv4地址的优先级。这意味着，当两者同样适用时，应用程序将优先使用IPv6而不是IPv4。管理员可以通过为：：ffff:0.0.0.0/96前缀提供更高的优先级，将策略表更改为首选IPv4地址：
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 100 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 100 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This change to the default policy table produces the following behavior:
对默认策略表的此更改会产生以下行为：
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121
(src 169.254.13.78) (prefer matching scope)
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121
(src 169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 198.51.100.121 (src 198.51.100.117) then
2001:db8::1 (src fe80::1) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 198.51.100.121 (src 198.51.100.117) then
2001:db8::1 (src fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001:db8::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src
2001:db8::2) (prefer higher precedence)
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001:db8::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src
2001:db8::2) (prefer higher precedence)
One problem in practice that has been recently observed occurs when a host has IPv4 connectivity to the Internet but has "broken" IPv6 connectivity to the Internet in that it has a global IPv6 address but is disconnected from the IPv6 Internet. Since the default policy table prefers IPv6, this can result in unwanted timeouts.
最近观察到的一个实际问题是，当主机具有到Internet的IPv4连接，但由于具有全局IPv6地址但与IPv6 Internet断开连接而“断开”到Internet的IPv6连接时。由于默认策略表首选IPv6，这可能会导致不必要的超时。
This can be solved by configuring the table to prefer IPv4 as shown above. An implementation that has some means to detect that it is not connected to the IPv6 Internet MAY do this automatically. An implementation could instead treat it as part of its implementation of Rule 1 (avoid unusable destinations).
这可以通过如上所示将表配置为首选IPv4来解决。如果一个实现有某种方法可以检测到它没有连接到IPv6 Internet，那么它可能会自动执行此操作。实现可以将其视为规则1实现的一部分（避免无法使用的目的地）。
The destination address selection rules give preference to destinations of smaller scope. For example, a link-local destination will be sorted before a global scope destination when the two are otherwise equally suitable. An administrator can change the policy table to reverse this preference and sort global destinations before link-local destinations:
目标地址选择规则优先选择范围较小的目标。例如，当链路本地目的地和全局范围目的地在其他方面同样合适时，它们将被排序在全局范围目的地之前。管理员可以更改策略表以反转此首选项，并在链接本地目标之前对全局目标进行排序：
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
fe80::/10 33 1
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
fe80::/10 33 1
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This change to the default policy table produces the following behavior:
对默认策略表的此更改会产生以下行为：
Candidate Source Addresses: 2001:db8::2 or fe80::2
Destination Address List: 2001:db8::1 or fe80::1
New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2)
(prefer higher precedence)
Candidate Source Addresses: 2001:db8::2 or fe80::2
Destination Address List: 2001:db8::1 or fe80::1
New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2)
(prefer higher precedence)
Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2
Destination Address List: 2001:db8::1 or fe80::1
Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001:
db8::2) (avoid deprecated addresses)
Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2
Destination Address List: 2001:db8::1 or fe80::1
Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001:
db8::2) (avoid deprecated addresses)
Consider a site A that has a business-critical relationship with another site B. To support their business needs, the two sites have contracted for service with a special high-performance ISP. This is in addition to the normal Internet connection that both sites have with different ISPs. The high-performance ISP is expensive, and the two sites wish to use it only for their business-critical traffic with each other.
考虑一个与另一个站点有业务关系的站点A。为了支持他们的业务需求，这两个站点已经签约使用一个特殊的高性能ISP服务。这是两个网站与不同ISP之间正常互联网连接的补充。高性能ISP价格昂贵，两个站点只希望将其用于彼此的业务关键流量。
Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48 from the high-performance ISP and prefix 2001:db8:70aa::/48 from its normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high-performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS.
每个站点都有两个全局前缀，一个来自高性能ISP，另一个来自普通ISP。站点A具有来自高性能ISP的前缀2001:db8:1aaa:：/48，以及来自其正常ISP的前缀2001:db8:70aa:：/48。站点B具有来自高性能ISP的前缀2001:db8:1bbb:：/48，以及来自其正常ISP的前缀2001:db8:70bb:：/48。两个站点中的所有主机都在DNS中注册两个地址。
The routing within both sites directs most traffic to the egress to the normal ISP, but the routing directs traffic sent to the other site's 2001 prefix to the egress to the high-performance ISP. To prevent unintended use of their high-performance ISP connection, the two sites implement ingress filtering to discard traffic entering from the high-performance ISP that is not from the other site.
两个站点内的路由将大部分流量定向到正常ISP的出口，但路由将发送到另一站点的2001前缀的流量定向到高性能ISP的出口。为防止意外使用其高性能ISP连接，这两个站点实施入口过滤，以丢弃从高性能ISP（而非其他站点）进入的流量。
The default policy table and address selection rules produce the following behavior:
默认策略表和地址选择规则产生以下行为：
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b
(src 2001:db8:1aaa::a) (longest matching prefix)
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b
(src 2001:db8:1aaa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior.
换句话说，当站点a中的主机启动与站点B中的主机的连接时，通信量不会利用它们与高性能ISP的连接。这不是他们想要的行为。
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c
(src 2001:db8:70aa::a) (longest matching prefix)
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c
(src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic might come back through the high-performance ISP. Again, this is not their desired behavior.
换句话说，当站点a中的主机启动与其他站点C中的主机的连接时，反向流量可能会通过高性能ISP返回。同样，这不是他们想要的行为。
This predicament demonstrates the limitations of the longest-matching-prefix heuristic in multi-homed situations.
这种困境证明了在多宿情况下最长匹配前缀启发式算法的局限性。
However, the administrators of sites A and B can achieve their desired behavior via policy table configuration. For example, they can use the following policy table:
但是，站点A和站点B的管理员可以通过策略表配置实现他们想要的行为。例如，他们可以使用以下策略表：
Prefix Precedence Label
::1/128 50 0
2001:db8:1aaa::/48 43 6
2001:db8:1bbb::/48 43 6
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
2001:db8:1aaa::/48 43 6
2001:db8:1bbb::/48 43 6
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This policy table produces the following behavior:
此策略表产生以下行为：
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8:
70bb::b (src 2001:db8:70aa::a) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8:
70bb::b (src 2001:db8:70aa::a) (prefer higher precedence)
In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired.
换句话说，当站点a中的主机启动与站点B中的主机的连接时，流量会根据需要使用高性能ISP。
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired.
换句话说，当站点a中的主机启动与某个其他站点C中的主机的连接时，流量会根据需要使用正常ISP。
Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe address selection problems related to Unique Local Addresses (ULAs) [RFC4193]. By default, global IPv6 destinations are preferred over ULA destinations, since an arbitrary ULA is not necessarily reachable:
RFC 5220[RFC5220]第2.1.4、2.2.2和2.2.3节描述了与唯一本地地址（ULA）[RFC4193]相关的地址选择问题。默认情况下，全局IPv6目标优先于ULA目标，因为任意ULA不一定可以访问：
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2
(src fd11:1111:1111:1::1) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2
(src fd11:1111:1111:1::1) (prefer higher precedence)
However, a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses as follows.
但是，特定于站点的策略条目可用于使站点内的ULA优先于全局地址，如下所示。
Prefix Precedence Label
::1/128 50 0
fd11:1111:1111::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
fd11:1111:1111::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Such a configuration would have the following effect:
这种配置将产生以下效果：
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:
2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:
2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2
New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001:
db8:2::2 (src 2001:db8:1::1) (prefer higher precedence)
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2
New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001:
db8:2::2 (src 2001:db8:1::1) (prefer higher precedence)
Since ULAs are defined to have a /48 site prefix, an implementation might choose to add such a row automatically on a machine with a ULA.
由于ULA被定义为具有/48站点前缀，因此实现可能会选择在具有ULA的计算机上自动添加此类行。
It is also worth noting that ULAs are assigned global scope. As such, the existence of one or more rows in the prefix policy table is important so that source address selection does not choose a ULA purely based on longest match:
还值得注意的是，ULA被分配为全局范围。因此，前缀策略表中一行或多行的存在非常重要，这样源地址选择就不会纯粹基于最长匹配来选择ULA：
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: ff00:1
Result: 2001:db8:1::1 (prefer matching label)
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: ff00:1
Result: 2001:db8:1::1 (prefer matching label)
By default, NATed IPv4 is preferred over 6to4-relayed connectivity:
默认情况下，IPv4优先于6to4中继连接：
Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3
Destination Address List: 2001:db8:1::1 or 203.0.113.1
Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633:
6401::2) (prefer matching label)
Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3
Destination Address List: 2001:db8:1::1 or 203.0.113.1
Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633:
6401::2) (prefer matching label)
However, NATed IPv4 is now also preferred over 6to4-to-6to4 connectivity by default. Since a 6to4 prefix might be used natively within an organization, a site-specific policy entry can be used to cause native IPv6 communication (using a 6to4 prefix) to be preferred over NATed IPv4 as follows.
但是，默认情况下，IPv4也优于6to4到6to4连接。由于6to4前缀可能在组织内以本机方式使用，因此可以使用特定于站点的策略条目使本机IPv6通信（使用6to4前缀）优于IPv4，如下所示。
Prefix Precedence Label
::1/128 50 0
2002:c633:6401::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Prefix Precedence Label
::1/128 50 0
2002:c633:6401::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Such a configuration would have the following effect:
这种配置将产生以下效果：
Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3
Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1
New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then
203.0.113.1 (sec 10.1.2.3) (prefer higher precedence)
Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3
Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1
New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then
203.0.113.1 (sec 10.1.2.3) (prefer higher precedence)
Since 6to4 addresses are defined to have a /48 site prefix, an implementation might choose to add such a row automatically on a machine with a native IPv6 address with a 6to4 prefix.
由于6to4地址定义为具有/48站点前缀，因此实现可能会选择在具有6to4前缀的本机IPv6地址的计算机上自动添加这样一行。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[ADDR-SEL-OPT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, August 2012.
[ADDR-SEL-OPT]Matsumoto，A.，Fujisaki，T.，Kato，J.，和T.Chown，“使用DHCPv6分发地址选择策略”，正在进行的工作，2012年8月。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[RFC1794]Brisco，T.，“DNS对负载平衡的支持”，RFC17941995年4月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[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月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004.
[RFC3701]Fink，R.和R.Hinden，“6bone（IPv6测试地址分配）逐步淘汰”，RFC 37012004年3月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014]Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题”，RFC 52202008年7月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
RFC 3484 [RFC3484] acknowledged the contributions of the IPng Working Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the anonymous IESG reviewers had many great comments and suggestions for clarification.
RFC 3484[RFC3484]感谢IPng工作组的贡献，特别是马克·布兰切特、布赖恩·卡彭特、马特·克劳福德、阿兰·杜兰德、史蒂夫·迪林、罗伯特·埃尔兹、伊藤俊一郎·哈吉诺、托尼·海恩、M.T.霍林格、金美·塔图亚、托马斯·纳滕、埃里克·诺德马克、肯·鲍威尔、马克库·萨维拉、佩卡·萨沃拉、赫萨姆·索利曼、戴夫·泰勒、，毛罗·托尔托内西、奥勒·特罗安和斯蒂格·维纳斯。此外，IESG的匿名评论员提出了许多很好的意见和建议，以供澄清。
This revision was heavily influenced by the work by Arifumi Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working document that made proposals for this revision to adopt, with input from Pekka Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes George also provided valuable feedback on this revision.
本次修订受到松本明文、加藤俊彦和藤崎智宏在一份工作文件中的工作的重大影响，该工作文件提出了本次修订的建议，并由佩卡·萨沃拉、雷米·丹尼斯·库尔蒙、弗朗索瓦·泽维尔·勒贝尔和6人工作组提供了意见。德米特里·阿尼普科、马克·安德鲁斯、雷·亨特和韦斯·乔治也对此次修订提供了宝贵的反馈。
Some changes were made to the default policy table that were deemed to be universally useful and cause no harm in every reasonable network environment. In doing so, care was taken to use the same preference and label values as in RFC 3484 whenever possible and for new rows to use label values less likely to collide with values that might already be in use in additional rows on some hosts. These changes are:
对默认策略表进行了一些更改，这些更改被认为是普遍有用的，并且在每个合理的网络环境中都不会造成损害。在这样做的过程中，尽可能使用与RFC 3484中相同的首选项和标签值，并且新行使用的标签值不太可能与某些主机上其他行中可能已经使用的值发生冲突。这些变化是：
1. Added the Teredo [RFC4380] prefix (2001::/32), with the preference and label values already widely used in popular implementations.
1. 添加了Teredo[RFC4380]前缀（2001:：/32），其中首选项和标签值已经在流行的实现中广泛使用。
2. Added a row for ULAs (fc00::/7) below native IPv6 since they are not globally reachable, as discussed in Section 10.6.
2. 如第10.6节所述，在本机IPv6下方添加了一行ULA（fc00:：/7），因为它们无法全局访问。
3. Added a row for site-local addresses (fec0::/10) in order to depreference them, for consistency with the example in Section 10.3, since they are deprecated [RFC3879].
3. 为站点本地地址（fec0:：/10）添加了一行，以便不推荐使用它们，以与第10.3节中的示例保持一致，因为它们已不推荐使用[RFC3879]。
4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 connectivity is less reliable today (and is expected to be phased out over time, rather than becoming more reliable). It remains above Teredo since 6to4 is more efficient in terms of connection establishment time, bandwidth, and server load.
4. 由于目前6to4连接的可靠性较低（预计将随着时间的推移逐步淘汰，而不是变得更可靠），因此在本机IPv4下取消了6to4（2002:：/32）。它仍然高于Teredo，因为6to4在连接建立时间、带宽和服务器负载方面更高效。
5. Depreferenced IPv4-Compatible addresses (::/96) since they are now deprecated [RFC4291] and not in common use.
5. 已弃用的IPv4兼容地址（：：/96），因为它们现在已弃用[RFC4291]，并且不常用。
6. Added a row for 6bone testing addresses (3ffe::/16) in order to depreference them as they have also been phased out [RFC3701].
6. 为6bone测试地址（3ffe:：/16）添加了一行，以取消对它们的引用，因为它们也已被淘汰[RFC3701]。
7. Added optional ability for an implementation to add automatic rows to the table for site-specific ULA prefixes and site-specific native 6to4 prefixes.
7. 增加了实现的可选功能，可以为站点特定的ULA前缀和站点特定的本机6to4前缀向表中自动添加行。
Similarly, some changes were made to the rules, as follows:
同样，对规则作了如下修改：
1. Changed the definition of CommonPrefixLen() to only compare bits up to the source address's prefix length. The previous definition used the entire source address, rather than only its prefix. As a result, when a source and destination addresses had the same prefix, common bits in the interface ID would previously result in overriding DNS load balancing [RFC1794] by forcing the destination address with the most bits in common to be always chosen. The updated definition allows DNS load balancing to continue to be used as a tie breaker.
1. 更改了CommonPrefixLen（）的定义，使其仅比较到源地址前缀长度的位。前面的定义使用了整个源地址，而不仅仅是其前缀。因此，当源地址和目标地址具有相同的前缀时，接口ID中的公共位先前会通过强制始终选择具有最多公共位的目标地址来覆盖DNS负载平衡[RFC1794]。更新后的定义允许DNS负载平衡继续用作断开连接的工具。
2. Added Rule 5.5 to allow choosing a source address from a prefix advertised by the chosen next-hop for a given destination. This allows better connectivity in the presence of BCP 38 [RFC2827] ingress filtering and egress filtering. Previously, RFC 3484 had issues with multiple egress networks reached via the same interface, as discussed in [RFC5220].
2. 添加了规则5.5，允许从为给定目的地选择的下一跳播发的前缀中选择源地址。这允许在存在BCP 38[RFC2827]入口过滤和出口过滤的情况下实现更好的连接。之前，RFC 3484在通过同一接口到达多个出口网络时存在问题，如[RFC5220]中所述。
3. Removed restriction against anycast addresses in the candidate set of source addresses, since the restriction against using IPv6 anycast addresses as source addresses was removed in Section 2.6 of RFC 4291 [RFC4291].
3. 删除了对候选源地址集中选播地址的限制，因为RFC 4291[RFC4291]第2.6节删除了对将IPv6选播地址用作源地址的限制。
4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope in Section 3.2. Previously, they were mapped to site-local scope. However, experience has resulted in current implementations already using global scope instead. When they were mapped to site-local, Destination Address Selection Rule 2 (Prefer matching scope) would cause IPv6 to be preferred in scenarios such as that described in Section 10.7. The change to global scope allows configurability via the prefix policy table.
4. 第3.2节中更改了RFC 1918[RFC1918]地址到全局范围的映射。以前，它们被映射到站点本地范围。然而，根据经验，当前的实现已经改用了全局范围。当它们被映射到站点本地时，目标地址选择规则2（首选匹配范围）将导致在第10.7节所述的场景中首选IPv6。对全局范围的更改允许通过前缀策略表进行配置。
5. Changed the default recommendation for Source Address Selection Rule 7 to prefer temporary addresses rather than public addresses, while providing an administrative override (in addition to the application-specific override that was already specified). This change was made because of the increasing importance of privacy considerations, as well as the fact that widely deployed implementations have preferred temporary addresses for many years without major application issues.
5. 将源地址选择规则7的默认建议更改为首选临时地址而不是公共地址，同时提供管理覆盖（除了已指定的特定于应用程序的覆盖之外）。做出这一改变是因为隐私考虑的重要性越来越高，以及广泛部署的实现多年来一直首选临时地址，而没有重大的应用程序问题。
Finally, some editorial changes were made, including:
最后，进行了一些编辑性修改，包括：
1. Changed global IP addresses in examples to use ranges reserved for documentation.
1. 将示例中的全局IP地址更改为使用为文档保留的范围。
2. Added additional examples in Sections 10.6 and 10.7.
2. 在第10.6节和第10.7节中添加了其他示例。
3. Added Section 10.3.1 on "broken" IPv6.
3. 增加了第10.3.1节关于“损坏的”IPv6。
4. Updated references.
4. 更新参考资料。
Authors' Addresses
作者地址
Dave Thaler (editor) Microsoft One Microsoft Way Redmond, WA 98052 USA
Dave Thaler（编辑）微软一路微软雷德蒙，华盛顿州98052美国
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Richard在美国华盛顿州雷德蒙德市微软研究中心一号绘图，邮编：98052
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Arifumi Matsumoto NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
松本明文NTT实验室Midori Cho 3-9-11武藏野市，日本东京180-8585
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Tim Chown University of Southampt on Southampton, Hampshire SO17 1BJ United Kingdom
南安普顿提姆大学，汉普郡，英国
EMail: tjc@ecs.soton.ac.uk
EMail: tjc@ecs.soton.ac.uk