Internet Engineering Task Force (IETF) H. Singh
Request for Comments: 5942 W. Beebee
Updates: 4861 Cisco Systems, Inc.
Category: Standards Track E. Nordmark
ISSN: 2070-1721 Oracle, Inc.
July 2010
Internet Engineering Task Force (IETF) H. Singh
Request for Comments: 5942 W. Beebee
Updates: 4861 Cisco Systems, Inc.
Category: Standards Track E. Nordmark
ISSN: 2070-1721 Oracle, Inc.
July 2010
IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
IPv6子网模型：链路和子网前缀之间的关系
Abstract
摘要
IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861.
IPv6指定与IPv4子网模型不同的子网模型。这些差异的微妙之处导致了不可互操作的错误实现。本文档阐述了最重要的区别：IPv6地址不会自动与IPv6 on link前缀关联。本文档还更新了RFC 4861中“链接上”定义的一部分（部分原因是由于不正确的实现引起的安全问题）。
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/rfc5942.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5942.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Host Behavior ...................................................4
4. Host Rules ......................................................7
5. Observed Incorrect Implementation Behavior ......................8
6. Updates to RFC 4861 .............................................9
7. Conclusion ......................................................9
8. Security Considerations .........................................9
9. Contributors ....................................................9
10. Acknowledgements ...............................................9
11. References ....................................................10
11.1. Normative References .....................................10
11.2. Informative References ...................................10
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Host Behavior ...................................................4
4. Host Rules ......................................................7
5. Observed Incorrect Implementation Behavior ......................8
6. Updates to RFC 4861 .............................................9
7. Conclusion ......................................................9
8. Security Considerations .........................................9
9. Contributors ....................................................9
10. Acknowledgements ...............................................9
11. References ....................................................10
11.1. Normative References .....................................10
11.2. Informative References ...................................10
IPv4 implementations typically associate a netmask with an address when an IPv4 address is assigned to an interface. That netmask together with the IPv4 address designates an on-link prefix. Nodes consider addresses covered by an on-link prefix to be directly attached to the same link as the sending node, i.e., they send traffic for such addresses directly rather than to a router. See Section 3.3.1 of [RFC1122]. Prior to the development of subnetting [RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC4632], an address's netmask could be derived directly from the address simply by determining whether it was a Class A, B, or C address. Today, assigning an address to an interface also requires specifying a netmask to use. In the absence of specifying a specific netmask when assigning an address, some implementations would fall back to deriving the netmask from the class of the address.
当IPv4地址分配给接口时，IPv4实现通常将网络掩码与地址相关联。该网络掩码与IPv4地址一起指定一个链路前缀。节点考虑由链路上前缀所覆盖的地址直接连接到与发送节点相同的链路，即，它们直接发送这些地址的流量而不是路由器。见[RFC1122]第3.3.1节。在开发子网[RFC0950]和无类域间路由（CIDR）[RFC4632]之前，只需确定地址是a类、B类还是C类地址，即可直接从地址派生出地址的网络掩码。如今，为接口分配地址还需要指定要使用的网络掩码。在分配地址时，如果没有指定特定的网络掩码，某些实现将退回到从地址类派生网络掩码。
The behavior of IPv6 as specified in Neighbor Discovery (ND) [RFC4861] is quite different. The on-link determination is separate from the address assignment. A host can have IPv6 addresses without
邻居发现（ND）[RFC4861]中指定的IPv6行为完全不同。链路上的确定与地址分配是分开的。主机可以具有IPv6地址，而无需
any related on-link prefixes or can have on-link prefixes that are not related to any IPv6 addresses that are assigned to the host. Any assigned address on an interface should initially be considered as having no internal structure as shown in [RFC4291].
任何相关的链路上前缀或可以具有与分配给主机的任何IPv6地址不相关的链路上前缀。接口上的任何分配地址最初应视为没有[RFC4291]中所示的内部结构。
In IPv6, by default, a host treats only the link-local prefix as on-link.
在IPv6中，默认情况下，主机仅将链路本地前缀视为on-link。
The reception of a Prefix Information Option (PIO) with the L-bit set [RFC4861] and a non-zero valid lifetime creates (or updates) an entry in the Prefix List. All prefixes on a host's Prefix List (i.e., those prefixes that have not yet timed out) are considered to be on-link by that host.
接收带有L位集合[RFC4861]和非零有效生存期的前缀信息选项（PIO）会在前缀列表中创建（或更新）一个条目。主机前缀列表上的所有前缀（即尚未超时的前缀）都被该主机视为处于链接上。
The on-link definition in the Terminology section of [RFC4861], as modified by this document, defines the complete list of cases in which a host considers an address to be on-link. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism.
[RFC4861]术语部分中的链接定义（经本文件修改）定义了主机将地址视为链接地址的完整情况列表。单个地址条目可以通过邻居不可访问性检测机制过期。
IPv6 packets sent using the Conceptual Sending Algorithm as described in [RFC4861] only trigger address resolution for IPv6 addresses that the sender considers to be on-link. Packets to any other address are sent to a default router. If there is no default router, then the node should send an ICMPv6 Destination Unreachable indication as specified in [RFC4861] -- more details are provided in the "Host Behavior" and "Host Rules" sections of this document. (Note that [RFC4861] changed the behavior when the Default Router List is empty.
使用[RFC4861]中描述的概念发送算法发送的IPv6数据包仅触发发送方认为在链路上的IPv6地址的地址解析。发送到任何其他地址的数据包都会发送到默认路由器。如果没有默认路由器，则节点应发送[RFC4861]中指定的ICMPv6目的地不可到达指示——本文档的“主机行为”和“主机规则”部分提供了更多详细信息。（注意，[RFC4861]更改了默认路由器列表为空时的行为。
In the old version of Neighbor Discovery [RFC2461], if the Default Router List is empty, rather than sending the ICMPv6 Destination Unreachable indication, the [RFC2461] node assumed that the destination was on-link.) Note that ND is scoped to a single link. All Neighbor Solicitation (NS) responses are assumed to be sent out the same interface on which the corresponding query was received without using the Conceptual Sending Algorithm.
在旧版本的邻居发现[RFC2461]中，如果默认路由器列表为空，而不是发送ICMPv6目的地不可到达指示，[RFC2461]节点假定目的地在链路上。）请注意，ND的作用域为单个链路。假设所有邻居请求（NS）响应都在接收相应查询的同一接口上发送，而不使用概念发送算法。
Failure of host implementations to correctly implement the IPv6 subnet model can result in lack of IPv6 connectivity. See the "Observed Incorrect Implementation Behavior" section for details.
主机实现未能正确实现IPv6子网模型可能会导致IPv6连接不足。有关详细信息，请参阅“观察到的错误实现行为”部分。
This document deprecates the last two bullets from the definition of "on-link" in [RFC4861] to address security concerns arising from particular ND implementations.
本文档不推荐[RFC4861]中“链接上”定义的最后两个项目符号，以解决特定ND实现引起的安全问题。
Host behavior is clarified in the "Host Behavior" and "Host Rules" sections.
主机行为在“主机行为”和“主机规则”部分中进行了说明。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
1. The original Neighbor Discovery (ND) specification [RFC4861] was unclear in its usage of the term "on-link" in a few places. In IPv6, an address is on-link (with respect to a specific link), if the address has been assigned to an interface attached to that link. Any node attached to the link can send a datagram directly to an on-link address without forwarding the datagram through a router. However, in order for a node to know that a destination is on-link, it must obtain configuration information to that effect. In IPv6, there are two main ways of maintaining information about on-link destinations. First, a host maintains a Prefix List that identifies ranges of addresses that are to be considered on-link. Second, Redirects can identify individual destinations that are on-link; such Redirects update the Destination Cache.
1. 最初的邻居发现（ND）规范[RFC4861]在一些地方对术语“链路上”的用法不清楚。在IPv6中，如果地址已分配给连接到该链路的接口，则该地址位于该链路上（相对于特定链路）。连接到链路的任何节点都可以直接向链路地址发送数据报，而无需通过路由器转发数据报。然而，为了让节点知道目的地在链路上，它必须获得相应的配置信息。在IPv6中，有两种主要的方式来维护链路上目的地的信息。首先，主机维护一个前缀列表，该列表标识链路上要考虑的地址范围。第二，重定向可以识别链路上的各个目的地；这样的重定向会更新目标缓存。
The Prefix List is populated via the following means:
前缀列表通过以下方式填充：
* Receipt of a valid Router Advertisement (RA) that specifies a prefix with the L-bit set. Such a prefix is considered on-link for a period specified in the Valid Lifetime and is added to the Prefix List. (The link-local prefix is effectively considered a permanent entry on the Prefix List.)
* 接收有效的路由器播发（RA），该播发指定带有L位集的前缀。在有效生存期中指定的一段时间内，在链路上考虑这样一个前缀，并将其添加到前缀列表中。（链接本地前缀实际上被视为前缀列表中的永久条目。）
* Indication of an on-link prefix (which may be a /128) via manual configuration, or some other yet-to-be-specified configuration mechanism.
* 通过手动配置或其他一些尚未指定的配置机制指示链路前缀（可能是a/128）。
A Redirect can also signal whether an address is on-link. If a host originates a packet, but the first-hop router routes the received packet back out onto the same link, the router also sends the host a Redirect. If the Target and Destination Address of the Redirect are the same, the Target Address is to be treated as on-link as specified in Section 8 of [RFC4861]. That is, the host updates its Destination Cache (but not its Prefix List -- though the impact is similar).
重定向还可以指示地址是否在链接上。如果主机发起一个数据包，但第一跳路由器将收到的数据包路由回同一链路，路由器也会向主机发送重定向。如果重定向的目标地址和目的地址相同，则按照[RFC4861]第8节的规定，将目标地址视为链路上的地址。也就是说，主机更新其目标缓存（但不更新其前缀列表——尽管影响类似）。
2. It should be noted that ND does not have a way to indicate a destination is "off-link". Rather, a destination is assumed to be off-link, unless there is explicit information indicating that it is on-link. Such information may later expire or be changed,
2. 应该注意的是，ND没有一种方式来指示目的地是“断开链接”。相反，除非有明确的信息表明目的地在链路上，否则假定目的地是非链路的。此类信息可能会在以后过期或更改，
in which case a destination may revert back to being considered off-link, but that is different than there being an explicit mechanism for signaling that a destination is off-link. Redirect messages do not contain sufficient information to signal that an address is off-link. Instead, Redirect messages indicate a preferred next hop that is a more appropriate choice to use than the originator of the Redirect.
在这种情况下，目的地可以恢复为被认为是断开链路的，但这不同于存在用于发送目的地断开链路的明确机制。重定向消息不包含足够的信息，无法发出地址断开链接的信号。相反，重定向消息表示首选的下一跳，该跳比重定向的发起人更适合使用。
3. IPv6 also defines the term "neighbor" to refer to nodes attached to the same link and that can send packets directly to each other. Received ND packets that pass the required validation tests can only come from a neighbor attached to the link on which the ND packet was received. Unfortunately, [RFC4861] is imprecise in its definition of "on-link" and states that a node considers an address to be on-link if:
3. IPv6还将术语“邻居”定义为指连接到同一链路并可直接向彼此发送数据包的节点。通过所需验证测试的接收的ND数据包只能来自连接到接收ND数据包的链路的邻居。不幸的是，[RFC4861]对“在链路上”的定义不准确，并且指出节点认为地址在链路上，如果：
* a Neighbor Advertisement (NA) message is received for the (target) address, or
* 接收到（目标）地址的邻居播发（NA）消息，或
* any Neighbor Discovery message is received from the address.
* 从该地址接收任何邻居发现消息。
Neither of these tests are acceptable definitions for an address to be considered as on-link as defined above, and this document deprecates and removes both of them from the formal definition of "on-link". Neither of these tests should be used as justification for modifying the Prefix List or Destination Cache for an address.
这两种测试都不是可接受的地址定义，如上文所述，地址被视为链接上的地址，本文档反对并从“链接上”的正式定义中删除这两种测试。这两种测试都不应用作修改地址的前缀列表或目标缓存的理由。
The conceptual sending algorithm of [RFC4861] defines a Prefix List, Destination Cache, and Default Router List. The combination of Prefix List, Destination Cache, and Default Router List form what many implementations consider to be the IP data forwarding table for a host. Note that the Neighbor Cache is a separate data structure referenced by the Destination Cache, but entries in the Neighbor Cache are not necessarily in the Destination Cache. It is quite possible (and intentional) that entries be added to the Neighbor Cache for addresses that would not be considered on-link as defined above. For example, upon receipt of a valid NS, Section 7.2.3 of [RFC4861] states:
[RFC4861]的概念发送算法定义了前缀列表、目标缓存和默认路由器列表。前缀列表、目的缓存和默认路由器列表的组合形式，许多实现被认为是主机的IP数据转发表。请注意，邻居缓存是目标缓存引用的单独数据结构，但邻居缓存中的条目不一定在目标缓存中。对于上面定义的链路上不考虑的地址，很有可能（并且有意）将条目添加到邻居缓存中。例如，[RFC4861]第7.2.3节在收到有效的NS后规定：
If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address, and the entry's reachability state MUST be set to STALE.
如果条目不存在，节点应创建一个新条目，并按照第7.3.3节的规定将其可达性状态设置为STALE。如果条目已存在，并且缓存的链接层地址与接收的源链接层选项中的地址不同，则缓存的地址应替换为接收的地址，并且条目的可访问性状态必须设置为STALE。
The intention of the above feature is to add an address to the Neighbor Cache, even though it might not be considered on-link per the Prefix List. The benefit of such a step is to have the receiver populate the Neighbor Cache with an address it will almost certainly be sending packets to shortly, thus avoiding the need for an additional round of ND to perform address resolution. But because there is no validation of the address being added to the Neighbor Cache, an intruder could spoof the address and cause a receiver to add an address for a remote site to its Neighbor Cache. This vulnerability is a specific instance of the broad set of attacks that are possible by an on-link neighbor [RFC3756]. This causes no problems in practice, so long as the entry only exists in the Neighbor Cache and the address is not considered to be on-link by the IP forwarding code (i.e., the address is not added to the Prefix List and is not marked as on-link in the Destination Cache).
上述功能的目的是将地址添加到邻居缓存中，即使在每个前缀列表的链接上可能不考虑地址。这样一个步骤的好处是让接收器用它几乎肯定会很快发送数据包的地址填充邻居缓存，从而避免需要额外一轮ND来执行地址解析。但是，由于没有对添加到邻居缓存中的地址进行验证，入侵者可能会伪造该地址，并导致接收方将远程站点的地址添加到其邻居缓存中。此漏洞是链路上邻居[RFC3756]可能发起的一系列攻击的具体实例。这在实践中不会导致任何问题，只要条目仅存在于邻居缓存中，并且IP转发代码不认为地址在链路上（即，地址未添加到前缀列表，且未在目标缓存中标记为链路上）。
4. After the update to the on-link definition in [RFC4861], certain text from Section 7.2.3 of [RFC4861] may appear, upon a cursory examination, to be inconsistent with the updated definition of "on-link" because the text does not ensure that the source address is already deemed on-link through other methods:
4. 更新[RFC4861]中的链路上定义后，[RFC4861]第7.2.3节中的某些文本在粗略检查后可能与更新后的“链路上”定义不一致，因为该文本无法确保源地址已通过其他方法被视为链路上的地址：
If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation.
如果源地址不是未指定的地址，并且在具有地址的链路层上，请求包括源链路层地址选项，则收件人应为请求的IP源地址创建或更新邻居缓存条目。
Similarly, the following text from Section 6.2.6 of [RFC4861] may also seem inconsistent:
类似地，[RFC4861]第6.2.6节中的以下文本也可能不一致：
If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link-layer address and sets its reachability state to STALE as specified in Section 7.3.3.
如果请求的发送方没有现有的邻居缓存条目，路由器将创建一个，安装链路层地址，并按照第7.3.3节的规定将其可达性状态设置为STALE。
However, the text in the aforementioned sections of [RFC4861], upon closer inspection, is actually consistent with the deprecation of the last two bullets of the on-link definition because there are two different ways in which on-link determination can affect the state of ND: through updating the Prefix List or updating the Destination Cache. Through deprecating the last two bullets of the on-link definition, the Prefix List is explicitly not to be changed when a node receives an NS, NA, or Router Solicitation (RS). The Neighbor Cache can still be updated through receipt of an NS, NA, or RS.
然而，经仔细检查，[RFC4861]上述章节中的文本实际上与链路上定义的最后两个项目符号的弃用一致，因为链路上的确定有两种不同的方式可以影响ND的状态：通过更新前缀列表或更新目标缓存。通过弃用on-link定义的最后两个项目符号，当节点接收到NS、NA或路由器请求（RS）时，前缀列表将明确不被更改。仍然可以通过接收NS、NA或RS来更新邻居缓存。
5. [RFC4861] is written from the perspective of a host with a single interface on which Neighbor Discovery is run. All ND traffic (whether sent or received) traverses the single interface. On hosts with multiple interfaces, care must be taken to ensure that the scope of ND processing from one link stays local to that link. That is, when responding to an NS, the NA would be sent out on the same link on which it was received. Likewise, a host would not respond to a received NS for an address only assigned to an interface on a different link. Although implementations may choose to implement Neighbor Discovery using a single data structure that merges the Neighbor Caches of all interfaces, an implementation's behavior must be consistent with the above model.
5. [RFC4861]是从主机的角度编写的，主机上有一个运行邻居发现的接口。所有ND通信（无论是发送的还是接收的）都会通过单个接口。在具有多个接口的主机上，必须注意确保从一个链路到该链路的ND处理范围保持本地。也就是说，当响应NS时，NA将在接收到它的同一链路上发送出去。同样，对于仅分配给不同链路上接口的地址，主机不会响应接收到的NS。尽管实现可以选择使用合并所有接口的邻居缓存的单个数据结构来实现邻居发现，但实现的行为必须与上述模型一致。
A correctly implemented IPv6 host MUST adhere to the following rules:
正确实施的IPv6主机必须遵守以下规则：
1. The assignment of an IPv6 address -- whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration -- MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List. A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] (as modified by this document) or via manual configuration. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861].
1. IPv6地址的分配——无论是通过IPv6无状态地址自动配置[RFC4862]、DHCPv6[RFC3315]还是手动配置——不得隐式导致从该地址派生的前缀被视为在链路上并添加到前缀列表。主机仅通过显式方式将前缀视为链路上前缀，如[RFC4861]（经本文件修改）术语部分中的链路上定义中指定的方式，或通过手动配置。注意，[RFC4861]中没有明确提到手动配置地址的要求。
2. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link (L) bit set and later the Valid Lifetime expires, the host MUST then consider addresses of the prefix to be off-link, as specified by the PIO paragraph of Section 6.3.4 of [RFC4861].
2. 在没有其他链接信息源的情况下，包括重定向，如果RA用ON链路（L）位设置广告前缀，并且随后有效寿命到期，则主机必须考虑前缀的地址为非链接，如[RCFC661]第6节第3.3.4节的PIO段落所指定的。
3. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link (L) bit set and later the Valid Lifetime expires, the host MUST then update its Prefix List with respect to the entry. In most cases, this will result in the addresses covered by the prefix defaulting back to being considered off-link, as specified by the PIO paragraph of Section 6.3.4 of [RFC4861]. However, there are cases where an address could be covered by multiple entries in the Prefix List, where expiration of one prefix would result in destinations then being covered by a different entry.
3. 在缺少其他链路上信息源（包括重定向）的情况下，如果RA播发设置了链路上（L）位的前缀，并且随后有效生存期到期，则主机必须更新其关于该条目的前缀列表。在大多数情况下，这将导致前缀覆盖的地址默认返回被视为断开链接，如[RFC4861]第6.3.4节的PIO段落所规定。然而，在某些情况下，一个地址可能被前缀列表中的多个条目覆盖，其中一个前缀的过期将导致目的地随后被另一个条目覆盖。
4. Implementations compliant with [RFC4861] MUST adhere to the following rules. If the Default Router List is empty and there is no other source of on-link information about any address or prefix:
4. 符合[RFC4861]的实施必须遵守以下规则。如果默认路由器列表为空，并且没有关于任何地址或前缀的其他链接信息源：
a. The host MUST NOT assume that all destinations are on-link.
a. 主机不能假定所有目的地都在链路上。
b. The host MUST NOT perform address resolution for non-link-local addresses.
b. 主机不得对非链接本地地址执行地址解析。
c. Since the host cannot assume the destination is on-link, and off-link traffic cannot be sent to a default router (since the Default Router List is empty), address resolution cannot be performed. This case is specified in the last paragraph of Section 4 of [RFC4943]: when there is no route to the destination, the host should send an ICMPv6 Destination Unreachable indication (for example, a locally delivered error message) as specified in the Terminology section of [RFC4861].
c. 由于主机不能假定目的地在链路上，且断开链路的通信量不能发送到默认路由器（因为默认路由器列表为空），因此无法执行地址解析。这种情况在[RFC4943]第4节的最后一段中有规定：当没有到目的地的路由时，主机应发送[RFC4861]术语部分中规定的ICMPv6目的地不可到达指示（例如，本地传递的错误消息）。
On-link information concerning particular addresses and prefixes can make those specific addresses and prefixes on-link, but does not change the default behavior mentioned above for addresses and prefixes not specified. [RFC4943] provides justification for these rules.
关于特定地址和前缀的链接上信息可以使这些特定地址和前缀在链接上，但不会更改上述未指定地址和前缀的默认行为。[RFC4943]为这些规则提供了理由。
One incorrect implementation behavior illustrates the severe consequences when the IPv6 subnet model is not understood by the implementers of several popular host operating systems. In an access concentrator network ([RFC4388]), a host receives a Router Advertisement message with no on-link prefix advertised. An address could be acquired through the DHCPv6 identity association for non-temporary addresses (IA_NA) option from [RFC3315] (which does not include a prefix length), or through manual configuration (if no prefix length is specified). The host incorrectly assumes an invented prefix is on-link. This invented prefix typically is a /64 that was written by the developer of the operating system network module API to any IPv6 application as a "default" prefix length when a length isn't specified. This may cause the API to seem to work in the case of a network interface initiating stateless address autoconfiguration (SLAAC); however, it can cause connectivity problems in Non-Broadcast Multi-Access (NBMA) networks. Having incorrectly assumed an invented prefix, the host performs address resolution when the host should send all non-link-local traffic to a
一个不正确的实现行为说明了当几种流行主机操作系统的实现者不理解IPv6子网模型时的严重后果。在接入集中器网络（[RFC4388]）中，主机接收到没有在链路上播发前缀的路由器播发消息。可以通过[RFC3315]（不包括前缀长度）的DHCPv6非临时地址标识关联（IA_NA）选项或通过手动配置（如果未指定前缀长度）获取地址。主机错误地假定虚构的前缀位于链接上。这种发明的前缀通常是操作系统网络模块API的开发人员在未指定长度时将其作为“默认”前缀长度写入任何IPv6应用程序的a/64。这可能导致API在网络接口启动无状态地址自动配置（SLAAC）的情况下工作；然而，在非广播多址（NBMA）网络中，它会导致连接问题。由于错误地假定了一个虚构的前缀，当主机应将所有非链路本地通信发送到主机时，主机将执行地址解析
default router. Neither the router nor any other host will respond to the address resolution, preventing this host from sending IPv6 traffic.
默认路由器。路由器或任何其他主机都不会响应地址解析，从而阻止此主机发送IPv6流量。
This document deprecates the following two bullets from the on-link definition in Section 2.1 of [RFC4861]:
本文件不推荐[RFC4861]第2.1节中链接定义中的以下两个项目符号：
o a Neighbor Advertisement message is received for the (target) address, or
o 接收到（目标）地址的邻居播发消息，或
o any Neighbor Discovery message is received from the address.
o 从该地址接收任何邻居发现消息。
This document clarifies and summarizes the relationship between links and subnet prefixes described in [RFC4861]. Configuration of an IPv6 address does not imply the existence of corresponding on-link prefixes. One should also look at API considerations for prefix length as described in the last paragraph of Section 4.2 of [RFC4903]. This document also updates the definition of "on-link" from [RFC4861] by deprecating the last two bullets.
本文档澄清并总结了[RFC4861]中描述的链路和子网前缀之间的关系。IPv6地址的配置并不意味着存在相应的链路前缀。还应参考[RFC4903]第4.2节最后一段中描述的前缀长度的API注意事项。本文档还更新了[RFC4861]中“链接”的定义，取消了最后两个项目符号。
This document addresses a security concern present in [RFC4861]. As a result, the last two bullets of the on-link definition in [RFC4861] have been deprecated. US-CERT Vulnerability Note VU#472363 lists the implementations affected.
本文件解决了[RFC4861]中存在的安全问题。因此，[RFC4861]中链接定义的最后两个项目符号已被弃用。US-CERT漏洞说明VU#472363列出了受影响的实施。
Thomas Narten contributed significant text and provided substantial guidance to the production of this document.
Thomas Narten提供了重要的文本，并为本文件的编制提供了实质性指导。
Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh Krishnan, Josh Littlefield, Bert Manfredi, David Miles, Madhu Sudan, Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their consistent input, ideas, and review during the production of this document. The security problem related to an NS message that provides one reason for invalidating a part of the on-link definition was found by David Miles. Jinmei Tatuya found the security problem to also exist with an RS message.
感谢（按字母顺序排列）阿德尔·艾哈迈德、贾里·阿尔科、拉尔夫·德罗姆斯、阿伦·埃文斯、戴夫·福斯特、普拉善·克里希纳穆尔西、苏雷什·克里希南、乔什·利特菲尔德、伯特·曼弗雷迪、大卫·迈尔斯、苏丹马杜、金美·塔图亚、戴夫·泰勒、伯尼·沃尔兹和弗拉德·亚舍维奇在本文件制作过程中始终如一的投入、想法和评论。David Miles发现了与NS消息相关的安全问题，该消息提供了使部分链路定义无效的一个原因。Jinmei Tatuya发现RS消息也存在安全问题。
[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月。
[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月。
[RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC0950]Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[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月。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4388]Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，2006年2月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[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月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 49032007年6月。
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.
[RFC4943]Roy，S.，Durand，A.，和J.Paugh，“基于链路假设的IPv6邻居发现被认为是有害的”，RFC 49432007年9月。
Authors' Addresses
作者地址
Hemant Singh Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Hemant Singh Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: +1 978 936 1622
EMail: shemant@cisco.com
URI: http://www.cisco.com/
Phone: +1 978 936 1622
EMail: shemant@cisco.com
URI: http://www.cisco.com/
Wes Beebee Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Wes Beebee Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: +1 978 936 2030
EMail: wbeebee@cisco.com
URI: http://www.cisco.com/
Phone: +1 978 936 2030
EMail: wbeebee@cisco.com
URI: http://www.cisco.com/
Erik Nordmark Oracle, Inc. 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Oracle，Inc.美国加利福尼亚州门罗公园17号Network Circle Menlo Park 94025
Phone: +1 650 786 2921
EMail: erik.nordmark@oracle.com
Phone: +1 650 786 2921
EMail: erik.nordmark@oracle.com