Internet Engineering Task Force (IETF) F. Costa
Request for Comments: 6957 J-M. Combes, Ed.
Category: Standards Track X. Pougnard
ISSN: 2070-1721 France Telecom Orange
H. Li
Huawei Technologies
June 2013
Internet Engineering Task Force (IETF) F. Costa
Request for Comments: 6957 J-M. Combes, Ed.
Category: Standards Track X. Pougnard
ISSN: 2070-1721 France Telecom Orange
H. Li
Huawei Technologies
June 2013
Duplicate Address Detection Proxy
重复地址检测代理
Abstract
摘要
The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.
本文档描述了一种基于代理的机制，允许IPv6节点在具有“分割地平线”转发方案的点对多点体系结构中使用重复地址检测（DAD），主要用于数字用户线（DSL）和光纤接入体系结构。基于DAD信令，第一跳路由器在绑定表中存储点对多点域（例如VLAN）上使用的所有已知IPv6地址。当一个节点对另一个节点已经使用的地址执行DAD时，第一跳路由器保护该地址，而不是使用该地址的设备。
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/rfc6957.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6957.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why Existing IETF Solutions Are Not Sufficient . . . . . . . 4
3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 4
3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . 5
3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . 5
3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 6
4.1. DAD-Proxy Data Structure . . . . . . . . . . . . . . . . 6
4.2. DAD-Proxy Mechanism . . . . . . . . . . . . . . . . . . . 7
4.2.1. No Entry Exists for the Tentative Address . . . . . . 7
4.2.2. An Entry Already Exists for the Tentative Address . . 7
4.2.3. Confirmation of Reachability to Check the Validity of
the Conflict . . . . . . . . . . . . . . . . . . . . 9
5. Manageability Considerations . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11
6.2. Protection against IP Source Address Spoofing . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why Existing IETF Solutions Are Not Sufficient . . . . . . . 4
3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 4
3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . 5
3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . 5
3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 6
4.1. DAD-Proxy Data Structure . . . . . . . . . . . . . . . . 6
4.2. DAD-Proxy Mechanism . . . . . . . . . . . . . . . . . . . 7
4.2.1. No Entry Exists for the Tentative Address . . . . . . 7
4.2.2. An Entry Already Exists for the Tentative Address . . 7
4.2.3. Confirmation of Reachability to Check the Validity of
the Conflict . . . . . . . . . . . . . . . . . . . . 9
5. Manageability Considerations . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11
6.2. Protection against IP Source Address Spoofing . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 14
This document specifies a function called Duplicate Address Detection (DAD) proxy allowing the use of DAD by the nodes on the same point-to-multipoint domain with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures [TR-101]. It only impacts the first-hop router and it doesn't need modifications on the other IPv6 nodes. This mechanism is fully effective if all the nodes of a point-to-multipoint domain (except the DAD proxy itself) perform DAD.
本文件规定了一种称为重复地址检测（DAD）代理的功能，允许同一点对多点域上的节点使用DAD，该功能采用“分割地平线”转发方案，主要用于数字用户线（DSL）和光纤接入架构[TR-101]。它只影响第一跳路由器，不需要对其他IPv6节点进行修改。如果点对多点域的所有节点（DAD代理本身除外）都执行DAD，则此机制完全有效。
This document explains also why the DAD mechanism [RFC4862] without a proxy cannot be used in a point-to-multipoint architecture with a "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not affected). One of the main reasons is that, because of this forwarding scheme, IPv6 nodes on the same point-to-multipoint domain cannot have direct communication: any communication between them must go through the first-hop router of the same domain.
本文档还解释了为什么没有代理的DAD机制[RFC4862]不能用于具有“拆分地平线”转发方案的点对多点体系结构（PPP上的IPv6[RFC5072]不受影响）。其中一个主要原因是，由于这种转发方案，同一点对多点域上的IPv6节点无法进行直接通信：它们之间的任何通信都必须通过同一域的第一跳路由器。
It is assumed in this document that link-layer addresses on a point-to-multipoint domain are unique from the first-hop router's point of view (e.g., in an untrusted Ethernet architecture, this assumption can be guaranteed thanks to mechanisms such as Media Access Control (MAC) address translation performed by an aggregation device between IPv6 nodes and the first-hop router).
在本文档中，假设点对多点域上的链路层地址从第一跳路由器的角度来看是唯一的（例如，在不受信任的以太网体系结构中，由于媒体访问控制（MAC）等机制，可以保证此假设由聚合设备在IPv6节点和第一跳路由器之间执行的地址转换）。
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]中所述进行解释。
Terminology in this document follows that in "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862]. In addition, this section defines additional terms related to DSL and Fiber access architectures, which are an important case where the solution described in this document can be used:
本文档中的术语遵循“IP版本6（IPv6）的邻居发现”[RFC4861]和“IPv6无状态地址自动配置”[RFC4862]中的术语。此外，本节还定义了与DSL和光纤接入架构相关的其他术语，这是可以使用本文档中描述的解决方案的重要情况：
Customer Premises Equipment (CPE) The first IPv6 node in a customer's network.
客户场所设备（CPE）客户网络中的第一个IPv6节点。
Access Node (AN) The first aggregation point in the public access network. It is considered as an L2 bridge in this document.
接入节点（AN）公共接入网络中的第一个聚合点。在本文档中，它被视为L2桥。
Broadband Network Gateway (BNG) The first-hop router from the CPE's point of view.
从CPE的角度来看，宽带网络网关（BNG）是第一跳路由器。
VLAN N:1 architecture A point-to-multipoint architecture where many CPEs are connected to the same VLAN. The CPEs may be connected on the same or different Access Nodes.
VLAN N:1体系结构一种点对多点体系结构，其中许多CPE连接到同一VLAN。cpe可以连接在相同或不同的接入节点上。
split-horizon model A forwarding scheme where CPEs cannot have direct layer 2 communications between them (i.e., IP flows must be forwarded through the BNG via routing).
拆分地平线模型一种转发方案，其中CPE之间不能有直接的第2层通信（即IP流必须通过路由通过BNG转发）。
The following figure shows where the different entities are, as defined above.
下图显示了不同实体的位置，如上所述。
+------+ +----+
| CPE3 |---------| AN |
+------+ +----+
|
|
+------+ +----+
| CPE2 |---------| AN |---+
+------+ +----+ |
+------+ | |
| CPE1 |------------+ |
+------+ +-----+
| BNG |--- Internet
+-----+
+------+ +----+
| CPE3 |---------| AN |
+------+ +----+
|
|
+------+ +----+
| CPE2 |---------| AN |---+
+------+ +----+ |
+------+ | |
| CPE1 |------------+ |
+------+ +-----+
| BNG |--- Internet
+-----+
Figure 1: DSL and Fiber Access Architecture
图1:DSL和光纤接入架构
In a DSL or Fiber access architecture depicted in Figure 1, CPE1, CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge providing connectivity between the BNG and each CPE. The AN enforces a split-horizon model so that CPEs can only send and receive frames (e.g., Ethernet frames) to and from the BNG but not to each other. That said, the BNG is on the same link with all CPEs, but a given CPE is not on the same link with any other CPE.
在图1所示的DSL或光纤接入架构中，CPE1、CPE2、CPE3和BNG是IPv6节点，而AN是提供BNG和每个CPE之间连接的L2网桥。AN实施分割地平线模型，以便CPE只能向BNG发送和从BNG接收帧（例如以太网帧），而不能相互发送和接收帧。也就是说，BNG与所有CPE在同一链路上，但是给定CPE与任何其他CPE不在同一链路上。
Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6 node verifies the uniqueness of a tentative IPv6 address. This node sends a Neighbor Solicitation (NS) message with the IP destination set to the solicited-node multicast address of the tentative address.
当IPv6节点验证暂定IPv6地址的唯一性时，执行重复地址检测（DAD）[RFC4862]。此节点发送邻居请求（NS）消息，IP目的地设置为暂定地址的请求节点多播地址。
This NS message is multicasted to other nodes on the same link. When the tentative address is already used on the link by another node, this last one replies with a Neighbor Advertisement (NA) message to inform the first node. So, when performing DAD, a node expects the NS messages to be received by any node currently using the tentative address.
此NS消息被多播到同一链路上的其他节点。当另一个节点已经在链路上使用了暂定地址时，最后一个节点会回复邻居公告（NA）消息以通知第一个节点。因此，在执行DAD时，节点期望当前使用暂定地址的任何节点都能接收NS消息。
However, in a point-to-multipoint network with a split-horizon forwarding scheme implemented in the AN, the CPEs are prevented from talking to each other directly. All packets sent out from a CPE are forwarded by the AN only to the BNG but not to any other CPE. NS messages sent by a certain CPE will be received only by the BNG and will not reach other CPEs. So, other CPEs have no idea that a certain IPv6 address is used by another CPE. That means, in a network with split-horizon, DAD, as defined in [RFC4862], can't work properly without additional help.
然而，在AN中实施了分裂地平线转发方案的点对多点网络中，cpe被阻止直接彼此交谈。从CPE发送的所有分组仅由AN转发到BNG，而不转发到任何其他CPE。某个CPE发送的NS消息将仅由BNG接收，不会到达其他CPE。因此，其他CPE不知道某个IPv6地址被另一个CPE使用。这意味着，在具有拆分地平线的网络中，[RFC4862]中定义的DAD无法在没有额外帮助的情况下正常工作。
Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND messages between different IP links where the subnet prefix is the same. An ND Proxy function on a bridge ensures that packets between nodes on different segments can be received by this function and have the correct link-layer address type on each segment. When the ND Proxy receives a multicast ND message, it forwards it to all other interfaces on a same link.
邻居发现（ND）代理[RFC4389]设计用于在子网前缀相同的不同IP链路之间转发ND消息。网桥上的ND代理功能确保不同网段上的节点之间的数据包可以通过该功能接收，并且在每个网段上具有正确的链路层地址类型。当ND代理收到多播ND消息时，它将其转发到同一链路上的所有其他接口。
In DSL or Fiber networks, when the AN, acting as an ND Proxy, receives an ND message from a CPE, it will forward it to the BNG but none of the other CPEs, as only the BNG is on the same link with the CPE. Hence, implementing ND Proxy on the AN would not help a CPE acknowledge link-local addresses used by other CPEs.
在DSL或光纤网络中，当充当ND代理的AN从CPE接收到ND消息时，它将转发给BNG，但不会转发给其他CPE，因为只有BNG与CPE处于同一链路上。因此，在AN上实现ND代理将不会帮助CPE确认其他CPE使用的链路本地地址。
As the BNG must not forward link-local scoped messages sent from a CPE to other CPEs, ND Proxy cannot be implemented in the BNG.
由于BNG不得将从CPE发送的链路本地作用域消息转发给其他CPE，因此无法在BNG中实现ND代理。
[RFC6775] defines an optional modification of DAD for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN). When a 6LoWPAN node wants to configure an IPv6 address, it registers that address with one or more of its default routers using the Address Registration Option (ARO). If this address is already owned by another node, the router informs the 6LoWPAN node that this address cannot be configured.
[RFC6775]定义了低功耗无线个人区域网络（6LoWPAN）上IPv6的DAD的可选修改。当6LoWPAN节点想要配置IPv6地址时，它会使用地址注册选项（ARO）向一个或多个默认路由器注册该地址。如果此地址已由另一个节点拥有，路由器将通知6LoWPAN节点无法配置此地址。
This mechanism requires modifications in all hosts in order to support the ARO.
此机制需要在所有主机中进行修改，以支持ARO。
According to [RFC6275], a home agent acts as a proxy for mobile nodes when they are away from the home network: the home agent defends a mobile node's home address by replying to NS messages with NA messages.
根据[RFC6275]，当移动节点远离家庭网络时，家庭代理充当移动节点的代理：家庭代理通过使用NA消息回复NS消息来保护移动节点的家庭地址。
There is a problem for this mechanism if it is applied in a DSL or Fiber public access network. Operators of such networks require that an NA message is only received by the sender of the corresponding NS message, for security and scalability reasons. However, the home agent per [RFC6275] multicasts NA messages on the home link and all nodes on this link will receive these NA messages. This shortcoming prevents this mechanism from being deployed in DSL or Fiber access networks directly.
如果将此机制应用于DSL或光纤公共接入网络，则会出现问题。出于安全性和可伸缩性原因，此类网络的运营商要求NA消息仅由相应NS消息的发送方接收。然而，归属代理per[RFC6275]在归属链路上多播NA消息，并且该链路上的所有节点将接收这些NA消息。这一缺点使得该机制无法直接部署在DSL或光纤接入网络中。
First, it is important to note that, as this mechanism is strongly based on DAD [RFC4862], it is not completely reliable, and the goal of this document is not to fix DAD.
首先，需要注意的是，由于该机制强烈基于DAD[RFC4862]，因此并不完全可靠，本文档的目标不是修复DAD。
A BNG needs to store in a Binding Table information related to the IPv6 addresses generated by any CPE. This Binding Table can be distinct from the Neighbor Cache. This must be done per point-to-multipoint domain (e.g., per Ethernet VLAN). Each entry in this Binding Table MUST contain the following fields:
BNG需要在绑定表中存储与任何CPE生成的IPv6地址相关的信息。此绑定表可以与邻居缓存不同。这必须在每个点对多点域（例如，每个以太网VLAN）进行。此绑定表中的每个条目必须包含以下字段：
o IPv6 Address
o IPv6地址
o Link-layer Address
o 链路层地址
For security or performances reasons, it must be possible to limit the number of IPv6 addresses per link-layer address (possibly, but not necessarily, to 1).
出于安全或性能原因，必须能够限制每个链路层地址的IPv6地址数（可能，但不一定，为1）。
On the reception of an unsolicited NA (e.g., when a CPE wishes to inform its neighbors of a new link-layer address) for an IPv6 address already recorded in the Binding Table, each entry associated to this IPv6 address MUST be updated consequently: the current link-layer address is replaced by the one included in the unsolicited NA message.
在接收到已记录在绑定表中的IPv6地址的未经请求的NA时（例如，当CPE希望通知其邻居新的链路层地址时），与此IPv6地址相关联的每个条目都必须随之更新：当前链路层地址被未经请求的NA消息中包含的地址替换。
For security or performances reasons, the Binding Table MUST be large enough for the deployment in which it is used: if the Binding Table is distinct from the Neighbor Cache, it MUST be at least the same
出于安全或性能方面的原因，绑定表必须足够大，以适合使用它的部署：如果绑定表不同于邻居缓存，则它必须至少相同
size as this last one. Implementations MUST either state the fixed size of the Binding Table that they support or make the size configurable. In the latter case, implementations MUST state the largest Binding Table size that they support. Additionally, implementations SHOULD allow an operator to inquire about the current occupancy level of the Binding Table to determine if it is about to become full. Implementations encountering a full Binding Table will likely handle it in a way similar to NS message loss.
大小和最后一个一样。实现必须声明它们支持的绑定表的固定大小，或者使大小可配置。在后一种情况下，实现必须声明它们支持的最大绑定表大小。此外，实现应该允许操作员查询绑定表的当前占用级别，以确定它是否即将满。遇到完整绑定表的实现可能会以类似于NS消息丢失的方式处理它。
It is recommended to apply technical solutions to minimize the risk that the Binding Table becomes full. These solutions are out of the scope of this document.
建议应用技术解决方案，将绑定表变满的风险降至最低。这些解决方案不在本文档的范围内。
When a CPE performs DAD, as specified in [RFC4862], it sends a Neighbor Solicitation (NS) message, with the unspecified address as the source address, in order to check if a tentative address is already in use on the link. The BNG receives this message and MUST perform actions specified in the following sections based on the information in the Binding Table.
当CPE按照[RFC4862]中的规定执行DAD时，它发送一条邻居请求（NS）消息，其中未指定的地址作为源地址，以检查链路上是否已经在使用一个临时地址。BNG收到此消息，必须根据绑定表中的信息执行以下部分中指定的操作。
When there is no entry for the tentative address, the BNG MUST create one with the following information:
当没有暂定地址条目时，BNG必须创建一个包含以下信息的条目：
o IPv6 Address field set to the tentative address in the NS message.
o IPv6地址字段设置为NS消息中的暂定地址。
o Link-layer Address field set to the link-layer source address in the link-layer header of the NS message.
o 链路层地址字段设置为NS消息链路层标头中的链路层源地址。
The BNG MUST NOT reply to the CPE or forward the NS message.
BNG不得回复CPE或转发NS消息。
When there is an entry for the tentative address, the BNG MUST check the following conditions:
当有暂定地址条目时，BNG必须检查以下条件：
o The address in the Target Address field in the NS message is equal to the address in the IPv6 Address field in the entry.
o NS消息中目标地址字段中的地址等于条目中IPv6地址字段中的地址。
o The source address of the IPv6 Header in the NS message is equal to the unspecified address.
o NS消息中IPv6标头的源地址等于未指定的地址。
When these conditions are met and the source address of the link-layer header in the NS message is equal to the address in the Link-layer Address field in the entry, that means the CPE is still
当满足这些条件，并且NS消息中链路层报头的源地址等于条目中链路层地址字段中的地址时，这意味着CPE仍然有效
performing DAD for this address. The BNG MUST NOT reply to the CPE or forward the NS message.
正在为这个地址执行任务。BNG不得回复CPE或转发NS消息。
When these conditions are met and the source address of the link-layer header in the NS message is not equal to the address in the Link-layer Address field in the entry, that means possibly another CPE is performing DAD for an already owned address. The BNG then has to verify whether there is a real conflict by checking if the CPE whose IPv6 address is in the entry is still connected. In the following text, we will call IPv6-CPE1 the IPv6 address of the existing entry in the Binding Table, Link-layer-CPE1 the link-layer address of that entry, and Link-layer-CPE2 the link-layer address of the CPE that is performing DAD, which is different from Link-layer-CPE1.
当满足这些条件并且NS消息中链路层报头的源地址不等于条目中链路层地址字段中的地址时，这意味着另一个CPE可能正在对已经拥有的地址执行DAD。然后，BNG必须通过检查条目中IPv6地址所在的CPE是否仍然连接来验证是否存在真正的冲突。在下面的文本中，我们将IPv6-CPE1称为绑定表中现有条目的IPv6地址，Link-layer-CPE1称为该条目的链路层地址，Link-layer-CPE2称为执行DAD的CPE的链路层地址，这与Link-layer-CPE1不同。
The BNG MUST check if the potential address conflict is real. In particular:
BNG必须检查潜在的地址冲突是否真实。特别地：
o If IPv6-CPE1 is in the Neighbor Cache and it is associated with Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed as explained in Section 4.2.3.
o 如果IPv6-CPE1位于邻居缓存中，并且与链路层CPE1关联，则必须按照第4.2.3节的说明确认IPv6-CPE1的可达性。
o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is associated with a link-layer address other than Link-layer-CPE1, that means that there is possibly a conflict with another CPE, but that CPE did not perform DAD. This situation is out of the scope of this document, since one assumption made above is that all the nodes of a point-to-multipoint domain (except the DAD proxy itself) perform DAD.
o 如果IPv6-CPE1在邻居缓存中，但在该缓存中它与链路层地址（而不是链路层CPE1）相关联，这意味着可能与另一个CPE存在冲突，但该CPE没有执行DAD。这种情况超出了本文的范围，因为上面的一个假设是点对多点域的所有节点（DAD代理本身除外）都执行DAD。
o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST create a new entry based on the information of the entry in the Binding Table. This step is necessary in order to trigger the reachability check as explained in Section 4.2.3. The entry in the Neighbor Cache MUST be created based on the algorithm defined in Section 7.3.3 of [RFC4861], in particular by treating this case as though a packet other than a solicited Neighbor Advertisement were received from IPv6-CPE1. Thus, the new entry of the Neighbor Cache MUST contain the following information:
o 如果IPv6-CPE1不在邻居缓存中，则BNG必须基于绑定表中的条目信息创建一个新条目。如第4.2.3节所述，该步骤是触发可达性检查所必需的。邻居缓存中的条目必须根据[RFC4861]第7.3.3节中定义的算法创建，尤其是将这种情况视为从IPv6-CPE1接收到请求的邻居播发以外的数据包。因此，邻居缓存的新条目必须包含以下信息：
* IPv6 address: IPv6-CPE1
* IPv6地址：IPv6-CPE1
* Link-layer address: Link-layer-CPE1
* 链路层地址：链路层CPE1
* State: STALE
* 状态：陈旧
The reachability of IPv6-CPE1 MUST be confirmed as soon as possible following the procedure explained in Section 4.2.3.
必须按照第4.2.3节中说明的程序尽快确认IPv6-CPE1的可达性。
4.2.3. Confirmation of Reachability to Check the Validity of the Conflict
4.2.3. 确认可达性以检查冲突的有效性
Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the reachability of IPv6-CPE1 is checked by using the Neighbor Unreachability Detection (NUD) mechanism described in Section 7.3.1 of [RFC4861]. This mechanism MUST be triggered as though a packet had to be sent to IPv6-CPE1. Note that in some cases this mechanism does not do anything. For instance, if the state of the entry is REACHABLE and a positive confirmation was received recently that the forward path to the IPv6-CPE1 was functioning properly (see RFC 4861 for more details), this mechanism does not do anything.
假设IPv6-CPE1位于邻居缓存的条目中，则使用[RFC4861]第7.3.1节中描述的邻居不可达性检测（NUD）机制检查IPv6-CPE1的可达性。必须触发此机制，就像必须将数据包发送到IPv6-CPE1一样。请注意，在某些情况下，此机制不起任何作用。例如，如果条目的状态是可访问的，并且最近收到了到IPv6-CPE1的转发路径正常运行的肯定确认（有关更多详细信息，请参阅RFC 4861），则此机制不会起任何作用。
Next, the behavior of the BNG depends on the result of the NUD process, as explained in the following sections.
接下来，BNG的行为取决于NUD过程的结果，如下部分所述。
If the result of the NUD process is negative (i.e., if this process removes IPv6-CPE1 from the Neighbor Cache), that means that the potential conflict is not real.
如果NUD进程的结果为负（即，如果此进程从邻居缓存中删除IPv6-CPE1），则意味着潜在冲突不是真实的。
The conflicting entry in the Binding Table (Link-layer-CPE1) is deleted and it is replaced by a new entry with the same IPv6 address, but the link-layer address of the CPE is performing DAD (Link-layer-CPE2), as explained in Section 4.2.1.
将删除绑定表（链路层-CPE1）中的冲突条目，并将其替换为具有相同IPv6地址的新条目，但如第4.2.1节所述，CPE的链路层地址正在执行DAD（链路层-CPE2）。
If the result of the NUD process is positive (i.e., if after this process the state of IPv6-CPE1 is REACHABLE), that means that the potential conflict is real.
如果NUD过程的结果是肯定的（即，如果在此过程之后IPv6-CPE1的状态是可访问的），则意味着潜在冲突是真实的。
As shown in Figure 2, the BNG MUST reply to the CPE that is performing DAD (CPE2 in Figure 1) with an NA message that has the following format:
如图2所示，BNG必须使用具有以下格式的NA消息回复正在执行DAD的CPE（图1中的CPE2）：
Layer 2 Header Fields:
第2层标题字段：
Source Address The link-layer address of the interface on which the BNG received the NS message.
源地址BNG接收NS消息的接口的链路层地址。
Destination Address The source address in the Layer 2 Header of the NS message received by the BNG (i.e., Link-layer-CPE2).
目的地地址BNG（即链路层CPE2）接收的NS消息的第2层报头中的源地址。
IPv6 Header Fields:
IPv6标头字段：
Source Address An address assigned to the interface from which the advertisement is sent.
源地址分配给发送播发的接口的地址。
Destination Address The all-nodes multicast address.
目标地址所有节点的多播地址。
ICMPv6 Fields:
ICMPv6字段：
Target Address The tentative address already used (i.e., IPv6-CPE1).
目标地址已使用的暂定地址（即IPv6-CPE1）。
Target Link-layer Address The link-layer address of the interface on which the BNG received the NS message.
目标链路层地址BNG接收NS消息的接口的链路层地址。
CPE1 CPE2 BNG
| | |
(a)| | |
| | |
(b)|===================>|
| | |(c)
| | |
| (d)| |
| | |
| (e)|=========>|
| | |
| |<=========|(f)
| | |
CPE1 CPE2 BNG
| | |
(a)| | |
| | |
(b)|===================>|
| | |(c)
| | |
| (d)| |
| | |
| (e)|=========>|
| | |
| |<=========|(f)
| | |
(a) CPE1 generates a tentative address (b) CPE1 performs DAD for this one (c) BNG updates its Binding Table (d) CPE2 generates a same tentative address (e) CPE2 performs DAD for this one (f) BNG informs CPE2 that DAD fails
(a) CPE1生成一个暂定地址（b）CPE1对此地址执行DAD（c）BNG更新其绑定表（d）CPE2生成一个相同的暂定地址（e）CPE2对此地址执行DAD（f）BNG通知CPE2 DAD失败
Figure 2: DAD Failure
图2:DAD故障
The BNG and the CPE MUST support the unicast transmission on the link layer of IPv6 multicast messages [RFC6085], to be able, respectively, to generate and to process such a packet format.
BNG和CPE必须支持IPv6多播消息[RFC6085]链路层上的单播传输，以便能够分别生成和处理这样的数据包格式。
The BNG SHOULD support a mechanism to log and emit alarms whenever a duplication of IPv6 addresses is detected by the DAD-Proxy function. Moreover, the BNG SHOULD implement a function to allow an operator to access logs and to see the current entries in the Binding Table. The management of access rights to get this information is out of the scope of this document.
当DAD代理功能检测到IPv6地址重复时，BNG应支持记录和发出警报的机制。此外，BNG应该实现一个函数，允许操作员访问日志并查看绑定表中的当前条目。获取此信息的访问权限管理不在本文档范围内。
The mechanism described in this document will not interoperate with SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG not owning the private key associated with the Cryptographically Generated Address (CGA) [RFC3972] needed to correctly sign the proxied ND messages [RFC5909].
本文档中描述的机制将不会与安全邻居发现（SEND）[RFC3971]进行互操作。这是因为BNG不拥有与加密生成地址（CGA）[RFC3972]相关联的私钥，该地址是正确签署代理ND消息[RFC5909]所需的。
Secure Proxy ND Support for SEND [RFC6496] has been specified to address this limitation, and it SHOULD be implemented and used on the BNG and the CPEs.
已指定对发送[RFC6496]的安全代理ND支持来解决此限制，应在BNG和CPE上实现和使用。
To ensure protection against IP source address spoofing in data packets, this proposal can be used in combination with Source Address Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND] [SAVI-MIX].
为确保防止数据包中的IP源地址欺骗，此方案可与源地址验证改进（SAVI）机制[RFC6620][SAVI-SEND][SAVI-MIX]结合使用。
If SAVI mechanisms are used, the SAVI device is the BNG, and the Binding Anchor for a CPE is its MAC address, which is assumed to be unique in this document (cf. Section 1).
如果使用SAVI机制，SAVI设备是BNG，CPE的绑定锚是其MAC地址，在本文档中它被认为是唯一的（参见第1节）。
The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh Krishnan, and Tassos Chatzithomaoglou for their comments. The authors would like also to thank the IETF 6man WG members and the BBF community for their support.
作者要感谢Alan Kavanagh、Wojciech Dec、Suresh Krishnan和Tassos Chatzithomaglou的评论。作者还要感谢IETF 6man工作组成员和BBF社区的支持。
[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月。
[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月。
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, January 2011.
[RFC6085]Gundavelli，S.，Townsley，M.，Troan，O.，和W.Dec，“以太网上IPv6多播数据包的地址映射”，RFC 6085，2011年1月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，2006年4月。
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]Varada，S.，Ed.，Haskins，D.，和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing Neighbor Discovery Proxy: Problem Statement", RFC 5909, July 2010.
[RFC5909]Combes，J-M.，Krishnan，S.和G.Daley，“保护邻居发现代理：问题声明”，RFC 59092010年7月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-Martinez, "Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)", RFC 6496, February 2012.
[RFC6496]Krishnan，S.，Laganier，J.，Bonola，M.，和A.Garcia Martinez，“安全代理和支持安全邻居发现（SEND）”，RFC 64962012年2月。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012.
[RFC6620]Nordmark，E.，Bagnulo，M.和E.Levy Abegnoli，“FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进”，RFC 6620，2012年5月。
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012.
[RFC6775]Shelby，Z.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年11月。
[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed., "SAVI for Mixed Address Assignment Methods Scenario", Work in Progress, May 2013.
[SAVI-MIX]Bi，J.，Yao，G.，Halpern，J.，和E.Levy Abegoni，Ed.，“混合地址分配方法方案的SAVI”，正在进行的工作，2013年5月。
[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-Address Validation Implementation", Work in Progress, April 2013.
[SAVI-SEND]Bagnulo，M.和A.Garcia Martinez，“基于发送的源地址验证实施”，正在进行的工作，2013年4月。
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", Issue 2, Technical Report TR-101, July 2011, <http://www.broadband-forum.org/technical/download/ TR-101_Issue-2.pdf>.
[TR-101]宽带论坛，“迁移到基于以太网的DSL聚合”，第2期，技术报告TR-101，2011年7月<http://www.broadband-forum.org/technical/download/ TR-101_Issue-2.pdf>。
This appendix, which is informative, contains a summary (cf. Table 1) of the actions done by the BNG when it receives a DAD-based NS (DAD-NS) message. The tentative address in this message is IPv6-CPE1 and the associated link-layer address is Link-layer-CPE2. The actions are precisely specified in Section 4.2.
本附录为资料性附录，包含BNG在收到基于DAD的NS（DAD-NS）消息时所采取行动的摘要（参见表1）。此消息中的暂定地址为IPv6-CPE1，关联的链路层地址为链路层CPE2。第4.2节明确规定了这些措施。
+------------+--------------------+--------------------+------------+
| Event | Check | Action | New event |
+------------+--------------------+--------------------+------------+
| DAD-NS | * No entry for | Create an entry | - |
| message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| reception. | Binding Table. | bound to Link- | |
| | | layer-CPE2 in the | |
| | | Binding Table. | |
| | * Entry for | - | Existing |
| | IPv6-CPE1 in the | | entry. |
| | Binding Table. | | |
| | | | |
| Existing | * Link-layer-CPE2 | - | - |
| entry. | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | * Another link- | - | Conflict? |
| | layer address, | | |
| | Link-layer-CPE1, | | |
| | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | | | |
| Conflict? | * IPv6-CPE1 | - | Reachable? |
| | associated to | | |
| | Link-layer-CPE1 in | | |
| | the Neighbor | | |
| | Cache. | | |
| | * IPv6-CPE1 | Out of scope. | - |
| | associated to | | |
| | another link-layer | | |
| | address than Link- | | |
| | layer-CPE1 in the | | |
| | Neighbor Cache. | | |
| | * IPv6-CPE1 is not | Create an entry | Reachable? |
| | in the Neighbor | for IPv6-CPE1 | |
| | Cache. | associated to | |
| | | Link-layer-CPE1 in | |
| | | the Neighbor | |
| | | Cache. | |
+------------+--------------------+--------------------+------------+
| Event | Check | Action | New event |
+------------+--------------------+--------------------+------------+
| DAD-NS | * No entry for | Create an entry | - |
| message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| reception. | Binding Table. | bound to Link- | |
| | | layer-CPE2 in the | |
| | | Binding Table. | |
| | * Entry for | - | Existing |
| | IPv6-CPE1 in the | | entry. |
| | Binding Table. | | |
| | | | |
| Existing | * Link-layer-CPE2 | - | - |
| entry. | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | * Another link- | - | Conflict? |
| | layer address, | | |
| | Link-layer-CPE1, | | |
| | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | | | |
| Conflict? | * IPv6-CPE1 | - | Reachable? |
| | associated to | | |
| | Link-layer-CPE1 in | | |
| | the Neighbor | | |
| | Cache. | | |
| | * IPv6-CPE1 | Out of scope. | - |
| | associated to | | |
| | another link-layer | | |
| | address than Link- | | |
| | layer-CPE1 in the | | |
| | Neighbor Cache. | | |
| | * IPv6-CPE1 is not | Create an entry | Reachable? |
| | in the Neighbor | for IPv6-CPE1 | |
| | Cache. | associated to | |
| | | Link-layer-CPE1 in | |
| | | the Neighbor | |
| | | Cache. | |
| Reachable? | * NUD process is | IPv6-CPE2 is bound | - |
| | negative. | to Link-layer- | |
| | | CPE2, instead to | |
| | | Link-layer-CPE1, | |
| | | in the Binding | |
| | | Table. | |
| | * NUD process is | A NA message is | - |
| | positive. | sent. | |
+------------+--------------------+--------------------+------------+
| Reachable? | * NUD process is | IPv6-CPE2 is bound | - |
| | negative. | to Link-layer- | |
| | | CPE2, instead to | |
| | | Link-layer-CPE1, | |
| | | in the Binding | |
| | | Table. | |
| | * NUD process is | A NA message is | - |
| | positive. | sent. | |
+------------+--------------------+--------------------+------------+
Table 1: DAD-Proxy State Machine
表1:DAD代理状态机
Authors' Addresses
作者地址
Fabio Costa France Telecom Orange 61 rue des Archives 75141 Paris Cedex 03 France
法比奥·科斯塔法国电信橙色61路档案馆75141巴黎Cedex 03法国
EMail: fabio.costa@orange.com
EMail: fabio.costa@orange.com
Jean-Michel Combes (editor) France Telecom Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France
Jean-Michel Combes（编辑）法国电信Orange 38 rue du General Leclerc 92794 Issy les Moulineaux Cedex 9 France
EMail: jeanmichel.combes@orange.com
EMail: jeanmichel.combes@orange.com
Xavier Pougnard France Telecom Orange 2 avenue Pierre Marzin 22300 Lannion France
Xavier Pougnard法国电信橙色2大道Pierre Marzin法国拉尼翁22300
EMail: xavier.pougnard@orange.com
EMail: xavier.pougnard@orange.com
Hongyu Li Huawei Technologies Huawei Industrial Base Shenzhen China
李宏宇华为技术华为工业基地中国深圳
EMail: lihy@huawei.com
EMail: lihy@huawei.com