Network Working Group R. Draves
Request for Comments: 3484 Microsoft Research
Category: Standards Track February 2003
Network Working Group R. Draves
Request for Comments: 3484 Microsoft Research
Category: Standards Track February 2003
Default Address Selection for Internet Protocol version 6 (IPv6)
Internet协议版本6（IPv6）的默认地址选择
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes two algorithms, for source address selection and 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地址，反之亦然。
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.
所有IPv6节点（包括主机和路由器）都必须实现本规范中定义的默认地址选择。
Table of Contents
目录
1. Introduction................................................2
1.1. Conventions Used in This Document.....................4
2. Context in Which the Algorithms Operate.....................4
2.1. Policy Table..........................................5
2.2. Common Prefix Length..................................6
3. Address Properties..........................................6
3.1. Scope Comparisons.....................................7
3.2. IPv4 Addresses and IPv4-Mapped Addresses..............7
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses.....8
3.4. IPv6 Loopback Address and Other Format Prefixes.......8
3.5. Mobility Addresses....................................8
4. Candidate Source Addresses..................................8
5. Source Address Selection...................................10
6. Destination Address Selection..............................12
7. Interactions with Routing..................................14
8. Implementation Considerations..............................15
9. Security Considerations....................................15
10. Examples...................................................16
10.1. Default Source Address Selection.....................16
10.2. Default Destination Address Selection................17
10.3. Configuring Preference for IPv6 or IPv4..............18
10.4. Configuring Preference for Scoped Addresses..........19
10.5. Configuring a Multi-Homed Site.......................19
Normative References.............................................21
Informative References...........................................22
Acknowledgments..................................................23
Author's Address.................................................23
Full Copyright Statement.........................................24
1. Introduction................................................2
1.1. Conventions Used in This Document.....................4
2. Context in Which the Algorithms Operate.....................4
2.1. Policy Table..........................................5
2.2. Common Prefix Length..................................6
3. Address Properties..........................................6
3.1. Scope Comparisons.....................................7
3.2. IPv4 Addresses and IPv4-Mapped Addresses..............7
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses.....8
3.4. IPv6 Loopback Address and Other Format Prefixes.......8
3.5. Mobility Addresses....................................8
4. Candidate Source Addresses..................................8
5. Source Address Selection...................................10
6. Destination Address Selection..............................12
7. Interactions with Routing..................................14
8. Implementation Considerations..............................15
9. Security Considerations....................................15
10. Examples...................................................16
10.1. Default Source Address Selection.....................16
10.2. Default Destination Address Selection................17
10.3. Configuring Preference for IPv6 or IPv4..............18
10.4. Configuring Preference for Scoped Addresses..........19
10.5. Configuring a Multi-Homed Site.......................19
Normative References.............................................21
Informative References...........................................22
Acknowledgments..................................................23
Author's Address.................................................23
Full Copyright Statement.........................................24
The IPv6 addressing architecture [1] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [2]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [3]. The mobility architecture introduces "home addresses" and "care-of addresses" [8]. In addition, multi-homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP.
IPv6寻址体系结构[1]允许向接口分配多个单播地址。这些地址可能具有不同的可达范围（链接本地、站点本地或全局）。这些地址也可能是“首选”或“不推荐”[2]。隐私考虑引入了“公共地址”和“临时地址”的概念[3]。移动性架构引入了“家庭地址”和“转交地址”[8]。此外，多归属情况将导致每个节点有更多的地址。例如，一个节点可能有多个接口，其中一些接口是隧道或虚拟接口，或者一个站点可能有多个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
最终的结果是，IPv6实现在启动通信时通常会面临多个可能的源地址和目标地址。违约是可取的
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.
在所有实现中通用的算法，用于选择源地址和目标地址，以便开发人员和管理员可以对其系统的行为进行推理和预测。
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 [9], 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地址[9]，则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 may 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 should the first one not be 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 using 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 2462 sense). Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information.
本文档分别指定源地址选择和目标地址选择，但使用公共上下文，以便将这两种算法结合在一起产生有用的结果。算法尝试选择适当范围和配置状态的源地址和目标地址（RFC2462意义上的首选或不推荐）。此外，本文件建议了一种首选方法，即最长匹配前缀，用于在缺乏更好信息的情况下从其他等效地址中进行选择。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[4]中的描述进行解释。
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 [10] like getaddrinfo() 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 address with bind(), but often the source address is left unspecified. Therefore the network layer does often choose a source address from several alternatives.
在这个实现架构中，应用程序使用诸如getaddrinfo（）之类的API[10]，它们将地址列表返回给应用程序。此列表可能同时包含IPv6和IPv4地址（有时表示为IPv4映射地址）。然后，应用程序使用connect（）或sendto（）将目标地址传递给网络堆栈。然后，应用程序通常会尝试列表中的第一个地址，在地址列表上循环，直到找到一个工作地址。在任何情况下，网络层都不需要从多个备选方案中选择目标地址。应用程序还可以使用bind（）指定源地址，但通常未指定源地址。因此，网络层通常会从几个备选方案中选择一个源地址。
As a consequence, we intend that implementations of 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 may be possible but this is not explored further here.
因此，我们希望getaddrinfo（）的实现将使用此处指定的目标地址选择算法对它们返回的IPv6和IPv4地址列表进行排序。另外，当应用程序或上层未指定源地址时，IPv6网络层将使用源地址选择算法。将此规范应用于IPv4网络层中的源地址选择可能是可行的，但此处不作进一步探讨。
Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.
行为良好的应用程序应该遍历从getaddrinfo（）返回的地址列表，直到找到工作地址为止。
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, public addresses [3] are preferred over temporary addresses. In mobile situations [8], 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.
算法在做出决策时使用了几个标准。综合效果是，对于两个地址的作用域或类型相同的目标/源地址对，对于目标地址，更喜欢较小的作用域而不是较大的作用域，更喜欢未弃用的源地址，避免在本机地址可用时使用过渡地址，所有其他条件相同时，优先选择具有尽可能长的公共前缀的地址对。对于源地址选择，公共地址[3]优先于临时地址。在移动情况下[8]，家庭地址优先于转交地址。如果地址同时是家庭地址和照管地址（指示移动节点对于该地址“在家”），则家庭/照管地址优先于仅为家庭地址或仅为照管地址的地址。
This specification optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used.
此规范还允许对策略进行管理配置，以覆盖算法的默认行为。策略覆盖采用可配置表的形式，该表为目标前缀指定优先级值和首选源前缀。如果实现不可配置，或者尚未配置实现，则应使用本文档中指定的默认策略表。
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 Precedence(A) and a classification or label 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. Note that at the time of this writing there is only limited experience with the use of policies that select from a set of possible IPv6 addresses. As more experience is gained, the recommended default policies may change. Consequently it is important that implementations provide a way to change the default
IPv6实现应通过一种至少与此处定义的策略表一样强大的机制支持可配置的地址选择。请注意，在撰写本文时，使用从一组可能的IPv6地址中选择的策略的经验有限。随着经验的积累，推荐的默认策略可能会改变。因此，实现提供一种更改默认值的方法是很重要的
policies as more experience is gained. Sections 10.3 and 10.4 provide examples of the kind of changes that might be needed.
随着经验的积累，政策也会随之改变。第10.3节和第10.4节提供了可能需要的变更类型示例。
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
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 [5] source addresses with 6to4 destination addresses, and v4-compatible [1] source addresses with v4-compatible destination addresses. 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[5]源地址和6to4目标地址，以及v4兼容的[1]源地址和v4兼容的目标地址。默认策略表的另一个效果是，如果匹配的源地址可用，则更喜欢使用IPv6地址进行通信，而不是使用IPv4地址进行通信。
Policy table entries for scoped address prefixes 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(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128.
我们将两个地址A和B的公共前缀长度CommonPrefixLen（A，B）定义为两个地址共同拥有的最长前缀（查看最重要或最左边的位）的长度。范围从0到128。
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 directly comparable to each other. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [2], 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.
在后面章节中给出的规则中，不同类型的地址（例如IPv4、IPv6、多播和单播）相互比较。其中一些地址类型的属性彼此不可直接比较。例如，IPv6单播地址可以是“首选”或“不推荐”[2]，而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), subnet-local (0x3), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes [11].
多播目标地址有一个4位作用域字段，用于控制多播数据包的传播。IPv6寻址体系结构为接口本地（0x1）、链路本地（0x2）、子网本地（0x3）、管理本地（0x4）、站点本地（0x5）、组织本地（0x8）和全局（0xE）作用域定义作用域字段值[11]。
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.
在存在多播目标地址的情况下使用源地址选择算法需要比较单播地址范围和多播地址范围。我们将单播链路本地映射到多播链路本地，单播站点本地映射到多播站点本地，单播全局范围映射到多播全局范围。例如，单播站点本地等于多播站点本地，它小于多播组织本地，它小于单播全局，它等于多播全局。
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 [11].
该映射隐式地合并了单播站点边界和多播站点边界[11]。
The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [1]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address.
目标地址选择算法在IPv6和IPv4地址上运行。为此，IPv4地址应表示为IPv4映射地址[1]。例如，要在策略表中查找IPv4地址的优先级或其他属性，请查找对应的IPv4映射IPv6地址。
IPv4 addresses are assigned scopes as follows. IPv4 auto-configuration addresses [9], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-local scope. IPv4 loopback addresses [12, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address [11, section 4]). Other IPv4 addresses are assigned global scope.
IPv4地址分配的作用域如下。IPv4自动配置地址[9]，前缀为169.254/16，分配给链路本地作用域。IPv4专用地址[12]的前缀为10/8、172.16/12和192.168/16，分配给站点本地范围。IPv4环回地址[12，第4.2.2.11节]前缀为127/8，分配给链路本地作用域（类似于IPv6环回地址[11，第4节]）。其他IPv4地址被分配到全局范围。
IPv4 addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4地址应被视为具有“首选”（在RFC 2462意义上）配置状态。
IPv4-compatible addresses [1], IPv4-mapped [1], IPv4-translatable [6] and 6to4 addresses [5] contain an embedded IPv4 address. For the purposes of this document, these addresses should be treated as having global scope.
IPv4兼容地址[1]、IPv4映射地址[1]、IPv4可翻译地址[6]和6to4地址[5]包含嵌入式IPv4地址。在本文档中，这些地址应被视为具有全局范围。
IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4兼容、IPv4映射和IPv4可翻译地址应视为具有“首选”（在RFC 2462意义上）配置状态。
The loopback address should be treated as having link-local scope [11, section 4] and "preferred" (in the RFC 2462 sense) configuration status.
环回地址应被视为具有链路本地作用域[11，第4节]和“首选”（在RFC 2462意义下）配置状态。
NSAP addresses and other addresses with as-yet-undefined format prefixes should be treated as having global scope and "preferred" (in the RFC 2462) configuration status. Later standards may supersede this treatment.
NSAP地址和其他格式前缀尚未定义的地址应视为具有全局范围和“首选”（在RFC 2462中）配置状态。以后的标准可能会取代这种处理方法。
Some nodes may support mobility using the concepts of a home address and a care-of address (for example see [8]). 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 may have an address that is simultaneously a home address and a care-of address.
一些节点可以使用归属地址和转交地址的概念来支持移动性（例如，参见[8]）。从概念上讲，归属地址是分配给移动节点并用作移动节点的永久地址的IP地址。转交地址是在访问外部链路时与移动节点关联的IP地址。当移动节点在其归属链路上时，它可以具有同时是归属地址和转交地址的地址。
For the purposes of this document, it is sufficient to know whether or not one's own addresses are designated as home addresses or care-of addresses. Whether or not an address should 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.
建议候选源地址是分配给将用于发送到目标的接口的单播地址集。（传出接口。）在路由器上，候选集可包括分配给转发分组的任何接口的单播地址，受以下描述的限制。
Discussion: The Neighbor Discovery Redirect mechanism [14] 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. Implementations that wish to support the use of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet.
讨论：邻居发现重定向机制[14]要求路由器在生成重定向之前验证数据包的源地址是否识别邻居，因此主机选择分配给传出接口的源地址是有利的。希望支持使用分配给环回接口的全局源地址的实现应该表现为环回接口发起并转发数据包。
In some cases the destination address may be qualified with a zone index or other information that will constrain the candidate set.
在某些情况下，目标地址可能会使用区域索引或其他约束候选集的信息进行限定。
For 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 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, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set.
在任何情况下，选播地址、多播地址和未指定的地址都不能包含在候选集中。
If an 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. The specified source address may influence the candidate set, by affecting the choice of outgoing interface. 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.
如果应用程序或上层指定的源地址不在目标的候选集中，则网络层必须将其视为错误。指定的源地址可能通过影响传出接口的选择而影响候选集。如果应用程序或上层指定目标候选集中的源地址，则网络层必须尊重该选择。如果应用程序或上层未指定源地址，则网络层使用下一节中指定的源地址选择算法。
On IPv6-only nodes that support SIIT [6, especially section 5], if the destination address is an IPv4-mapped address then the candidate set MUST contain only IPv4-translatable addresses. If the
在支持SIIT[6，特别是第5节]的仅IPv6节点上，如果目标地址是IPv4映射地址，则候选集必须仅包含IPv4可翻译地址。如果
destination address is not an IPv4-mapped address, then the candidate set MUST NOT contain IPv4-translatable addresses.
目标地址不是IPv4映射地址，则候选集不得包含IPv4可翻译地址。
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 are 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, some unspecified tie-breaker should be used.
候选集中地址的顺序由八个成对比较规则的列表定义，每个规则对两个源地址（以及该规则）进行“大于”、“小于”或“等于”排序。如果给定的规则产生一个tie，即为两个地址提供一个“等于”的结果，则剩余的规则（按顺序）仅应用于那些绑定以打破tie的地址。请注意，如果一个规则产生一个明确的“赢家”（或在平局的情况下产生一组“赢家”），则不在赢家集中的那些地址可以被丢弃，不再进一步考虑，后续规则仅应用于其余地址。如果这八条规则无法选择一个地址，则应使用一些未指定的连接断路器。
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.
当比较候选集中的两个地址SA和SB时，我们说“偏好SA”表示SA“大于”SB，同样地，我们说“偏好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。
Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 2462 sense), then prefer the one that is "preferred."
规则3：避免使用不推荐的地址。地址SA和SB具有相同的作用域。如果两个源地址中的一个是“首选”的，而其中一个是“不推荐的”（在RFC2462的意义上），则选择“首选”的源地址
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 should 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). Use of the mechanism should only affect the selection rules for the invoking application.
实现应该提供一种机制，允许应用程序逆转这种偏好，并更喜欢照顾地址而不是家庭地址（例如，通过适当的API扩展）。使用该机制应该只影响调用应用程序的选择规则。
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 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 public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary 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 temporary addresses over public addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. This rule avoids 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 privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses.
实现必须提供一种机制，允许应用程序逆转这种偏好，并偏好临时地址而不是公共地址（例如，通过适当的API扩展）。使用该机制应该只影响调用应用程序的选择规则。此规则避免了由于临时地址的生存期相对较短或由于临时地址的反向查找可能失败或返回随机名称而导致应用程序可能失败。隐私考虑超过这些应用程序兼容性考虑的实现可能会改变此规则的含义，并且默认情况下更喜欢临时地址而不是公共地址。
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可能被取代。例如，如果实现不知何故知道哪个源地址将导致“最佳”通信性能。
Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability.
必须实施规则2（首选适当的范围）并给予高度优先权，因为它会影响互操作性。
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 should 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 should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tie-breaker 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 may know that a particular destination is unreachable in several ways. For example, the destination may be reached through a network interface that is
讨论：一个实现可能知道特定的目的地在几种方式下是无法到达的。例如，可以通过以下网络接口到达目的地：
currently unplugged. For example, the implementation may retain for some period of time information from Neighbor Unreachability Detection [14]. In any case, the determination of unreachability for the purposes of this rule is implementation-dependent.
目前已拔出。例如，该实现可以将来自邻居不可达性检测的信息保留一段时间[14]。在任何情况下，就本规则而言，不可达性的确定取决于实现。
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: 6-over-4 [15], ISATAP [16], and configured tunnels [17] 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).
讨论：6-over-4[15]、ISATAP[16]和配置的隧道[17]是封装转换机制的示例，对于这些转换机制，目标地址没有特定的前缀，因此不能在策略表中分配较低的优先级。实现可以通过使用接口首选项的概念来概括此规则，并给予虚拟接口（如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(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB.
规则9：使用最长匹配前缀。当DA和DB属于同一地址系列（都是IPv6或都是IPv4）时：如果CommonPrefixLen（DA，Source（DA））>CommonPrefixLen（DB，Source（DB）），则首选DA。类似地，如果CommonPrefixLen（DA，Source（DA））<CommonPrefixLen（DB，Source（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 2462 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 2462意义上）全局地址。当发送到全局目标地址时，如果没有路由理由选择一个接口而不是另一个接口，那么实现可能会优先选择传出接口，该接口将允许它使用与目标共享更长公共前缀的源地址。
Implementations may 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 may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.
实现还可以使用路由器的选择来影响源地址的选择。例如，假设一台主机位于与两台路由器的链路上。一个路由器播发全局前缀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 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 resort the list.
目标地址选择算法需要有关潜在源地址的信息。一种可能的实现策略是getaddrinfo（）使用目标地址列表向下调用网络层，在网络层中使用可用源地址的全部当前知识对列表进行排序，然后将排序后的列表返回给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 may 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 should 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 or source address assignments 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.
在任何情况下，如果实现在其目标地址选择的实现中使用缓存且可能过时的信息，或者如果目标地址的缓存列表的顺序可能过时，则应确保返回到应用程序的目标地址顺序过期不超过一秒。例如，实现可能会进行系统调用，以检查可能影响这些算法的任何路由表条目或源地址分配是否已更改。另一种策略是使用失效计数器，每当任何基础状态发生更改时，该计数器都会递增。通过使用派生状态缓存当前失效计数器值，然后稍后与当前值进行比较，实现可以检测派生状态是否可能过时。
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 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.
多播地址，或者可能是为攻击选择的上层协议没有为其应答数据包指定特定的源地址。）通过为自己使用不同的地址，不友好节点可以导致目标节点公开目标自己的地址。
This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative.
本节包含许多示例，首先是默认行为，然后演示策略表配置的实用程序。提供这些示例是为了说明目的；它们不应被解释为规范性的。
The source address selection rules, in conjunction with the default policy table, produce the following behavior:
源地址选择规则与默认策略表一起产生以下行为：
Destination: 2001::1
Candidate Source Addresses: 3ffe::1 or fe80::1
Result: 3ffe::1 (prefer appropriate scope)
Destination: 2001::1
Candidate Source Addresses: 3ffe::1 or fe80::1
Result: 3ffe::1 (prefer appropriate scope)
Destination: 2001::1
Candidate Source Addresses: fe80::1 or fec0::1
Result: fec0::1 (prefer appropriate scope)
Destination: 2001::1
Candidate Source Addresses: fe80::1 or fec0::1
Result: fec0::1 (prefer appropriate scope)
Destination: fec0::1
Candidate Source Addresses: fe80::1 or 2001::1
Result: 2001::1 (prefer appropriate scope)
Destination: fec0::1
Candidate Source Addresses: fe80::1 or 2001::1
Result: 2001::1 (prefer appropriate scope)
Destination: ff05::1
Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1
Result: fec0::1 (prefer appropriate scope)
Destination: ff05::1
Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1
Result: fec0::1 (prefer appropriate scope)
Destination: 2001::1
Candidate Source Addresses: 2001::1 (deprecated) or 2002::1
Result: 2001::1 (prefer same address)
Destination: 2001::1
Candidate Source Addresses: 2001::1 (deprecated) or 2002::1
Result: 2001::1 (prefer same address)
Destination: fec0::1
Candidate Source Addresses: fec0::2 (deprecated) or 2001::1
Result: fec0::2 (prefer appropriate scope)
Destination: fec0::1
Candidate Source Addresses: fec0::2 (deprecated) or 2001::1
Result: fec0::2 (prefer appropriate scope)
Destination: 2001::1
Candidate Source Addresses: 2001::2 or 3ffe::2
Result: 2001::2 (longest-matching-prefix)
Destination: 2001::1
Candidate Source Addresses: 2001::2 or 3ffe::2
Result: 2001::2 (longest-matching-prefix)
Destination: 2001::1
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2
(home address)
Result: 3ffe::2 (prefer home address)
Destination: 2001::1
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2
(home address)
Result: 3ffe::2 (prefer home address)
Destination: 2002:836b:2179::1
Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8
(temporary) or 2001::2
Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2002:836b:2179::1
Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8
(temporary) or 2001::2
Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2001::d5e3:0:0:1
Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8
(temporary)
Result: 2001::2 (prefer public address)
Destination: 2001::d5e3:0:0:1
Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8
(temporary)
Result: 2001::2 (prefer public 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::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
fe80::1) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
higher precedence)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
higher precedence)
Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
2001::1 (src 2001::2) (prefer smaller scope)
Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
2001::1 (src 2001::2) (prefer smaller scope)
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1
(home address) or fec0::2 (care-of address) or fe80::2 (care-of
address)
Destination Address List: 2001::1 or fec0::1
Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
address)
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1
(home address) or fec0::2 (care-of address) or fe80::2 (care-of
address)
Destination Address List: 2001::1 or fec0::1
Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
address)
Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or
fe80::2
Destination Address List: 2001::1 or fec0::1
Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
deprecated addresses)
Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or
fe80::2
Destination Address List: 2001::1 or fec0::1
Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
deprecated addresses)
Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2
Destination Address List: 2001::1 or 3ffe::1
Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
matching prefix)
Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2
Destination Address List: 2001::1 or 3ffe::1
Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
matching prefix)
Candidate Source Addresses: 2002:836b:4179::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
2002:836b:4179::2) (prefer matching label)
Candidate Source Addresses: 2002:836b:4179::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
2002:836b:4179::2) (prefer matching label)
Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
2002:836b:4179::2) (prefer higher precedence)
Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
2002:836b:4179::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
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 100 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 100 4
This change to the default policy table produces the following behavior:
对默认策略表的此更改会产生以下行为：
Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
(src fe80::1) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
(src fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
(prefer higher precedence)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
(prefer higher precedence)
The destination address selection rules give preference to destinations of smaller scope. For example, a site-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 site-local destinations, and site-local destinations before link-local destinations:
目标地址选择规则优先选择范围较小的目标。例如，如果站点本地目的地与全局范围目的地在其他方面相同，则它们将排序在全局范围目的地之前。管理员可以更改策略表以反转此首选项，并将全局目标排序在站点本地目标之前，将站点本地目标排序在链接本地目标之前：
Prefix Precedence Label
::1/128 50 0
::/0 40 1
fec0::/10 37 1
fe80::/10 33 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
fec0::/10 37 1
fe80::/10 33 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
This change to the default policy table produces the following behavior:
对默认策略表的此更改会产生以下行为：
Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
fe80::1 (src fe80::2) (prefer higher precedence)
Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
fe80::1 (src fe80::2) (prefer higher precedence)
Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or
fe80::2
Destination Address List: 2001::1 or fec0::1
Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2)
(avoid deprecated addresses)
Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or
fe80::2
Destination Address List: 2001::1 or fec0::1
Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::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:aaaa:aaaa::/48 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high-performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS.
每个站点都有两个全局前缀，一个来自高性能ISP，另一个来自普通ISP。站点A具有来自高性能ISP的前缀2001:aaaa:aaaa:：/48，以及来自其正常ISP的前缀2007:0:aaaa:：/48。站点B具有来自高性能ISP的前缀2001:bbbb:bbbbbb:：/48和来自其正常ISP的前缀2007:0:bbbbbb:：/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:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
(src 2001:aaaa:aaaa::a) (longest matching prefix)
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
(src 2001:aaaa:aaaa::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:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
2006:cccc:cccc::c (src 2007:0:aaaa::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 may 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 50 0
2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
Prefix Precedence Label
::1 50 0
2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
This policy table produces the following behavior:
此策略表产生以下行为：
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
2007:0:bbbb::b (src 2007:0:aaaa::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:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
2001:cccc:cccc::c (src 2007:0:aaaa::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。
Normative References
规范性引用文件
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[1] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[2] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462 , December 1998.
[2] Thompson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[3] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[5] Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[6] Nordmark，E.，“无状态IP/ICMP转换算法（SIIT）”，RFC 27652000年2月。
Informative References
资料性引用
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[7] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[8] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[8] Johnson，D.和C.Perkins，“IPv6中的移动支持”，正在进行中。
[9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", Work in Progress.
[9] S.Cheshire，B.Aboba，“IPv4链路本地地址的动态配置”，正在进行中。
[10] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[10] Gilligan，R.，Thomson，S.，Bound，J.和W.Stevens，“IPv6的基本套接字接口扩展”，RFC2553，1999年3月。
[11] S. Deering et. al, "IP Version 6 Scoped Address Architecture", Work in Progress.
[11] S.Deering等人，“IP版本6作用域地址体系结构”，正在进行中。
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[12] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[13] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[13] Baker，F，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[14] Narten, T. and E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998.
[14] Narten，T.和E.Nordmark，W.Simpson，“IP版本6的邻居发现”，RFC 2461，1998年12月。
[15] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[15] Carpenter，B.和C.Jung，“无显式隧道的IPv4域上IPv6传输”，RFC 2529，1999年3月。
[16] F. Templin et. al, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress.
[16] F.Templin等人，“站点内自动隧道寻址协议（ISATAP）”，正在进行中。
[17] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[17] Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，1996年4月。
Acknowledgments
致谢
The author would like to acknowledge 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.
作者要感谢IPng工作组的贡献，特别是马克·布兰切特、布赖恩·卡彭特、马特·克劳福德、阿兰·杜兰德、史蒂夫·迪林、罗伯特·埃尔兹、伊藤俊一郎·哈吉诺、托尼·海恩、M.T.霍林格、金美·塔图亚、托马斯·纳滕、埃里克·诺德马克、肯·鲍威尔、马克库·萨维拉、佩卡·萨沃拉、海瑟姆·索利曼、戴夫·泰勒、，毛罗·托尔托内西、奥勒·特罗安和斯蒂格·维纳斯。此外，IESG的匿名评论员提出了许多很好的意见和建议，以供澄清。
Author's Address
作者地址
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
Richard在华盛顿州雷德蒙市微软研究中心一号撰写微软研究报告，邮编：98052
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。