[要約] RFC 6957は、重複アドレス検出プロキシに関する仕様を提供しています。その目的は、ネットワーク上での重複したIPv6アドレスの検出を効率的に行うことです。
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.
このドキュメントでは、主にデジタル加入者線（DSL）とファイバーに展開された「スプリットホライズン」転送スキームを使用したポイントツーマルチポイントアーキテクチャでIPv6ノードによる重複アドレス検出（DAD）の使用を可能にするプロキシベースのメカニズムについて説明しますアクセスアーキテクチャ。ファーストホップルーターは、DADシグナリングに基づいて、ポイントツーマルチポイントドメイン（VLANなど）で使用されるすべての既知のIPv6アドレスをバインディングテーブルに格納します。ノードが別のノードですでに使用されているアドレスに対してDADを実行する場合、ファーストホップルーターは、アドレスを使用するデバイスではなく、アドレスを防御します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
このドキュメントでは、Duplicate Address Detection（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]が、「スプリットホライズン」転送スキームを使用するポイントツーマルチポイントアーキテクチャで使用できない理由についても説明します（IPv6 over PPP [RFC5072]は影響を受けません）。主な理由の1つは、この転送スキームのため、同じポイントツーマルチポイントドメイン上の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).
このドキュメントでは、ポイントツーマルチポイントドメインのリンク層アドレスはファーストホップルーターの観点から一意であると想定しています（たとえば、信頼できないイーサネットアーキテクチャでは、メディアなどのメカニズムによってこの想定を保証できます） IPv6ノードとファーストホップルーター間で集約デバイスによって実行されるアクセス制御（MAC）アドレス変換）。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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:
このドキュメントの用語は、「Neighbor Discovery for IP version 6（IPv6）」[RFC4861]および「IPv6 Stateless Address Autoconfiguration」[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.
ブロードバンドネットワークゲートウェイ（BNG）CPEから見たファーストホップルーター。
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
+-----+
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はすべての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.
重複アドレス検出（DAD）[RFC4862]は、IPv6ノードが仮のIPv6アドレスの一意性を検証するときに実行されます。このノードは、IP宛先が仮アドレスの送信請求ノードマルチキャストアドレスに設定されたNeighbor Solicitation（NS）メッセージを送信します。
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メッセージは、同じリンク上の他のノードにマルチキャストされます。仮のアドレスがリンク上で別のノードによってすでに使用されている場合、この最後のアドレスはNeighbor Advertisement（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に転送してはならないため、NDプロキシをBNGに実装することはできません。
[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）を使用して、そのアドレスを1つ以上のデフォルトルーターに登録します。このアドレスがすでに別のノードによって所有されている場合、ルーターはこのアドレスを構成できないことを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メッセージの送信者のみが受信することを要求します。ただし、[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.
セキュリティまたはパフォーマンス上の理由から、バインディングテーブルは、それが使用される展開に十分な大きさである必要があります。バインディングテーブルがネイバーキャッシュと異なる場合、少なくとも最後のサイズと同じサイズである必要があります。実装は、サポートするバインディングテーブルの固定サイズを示すか、サイズを構成可能にする必要があります。後者の場合、実装は、サポートする最大のバインディングテーブルサイズを指定する必要があります。さらに、実装では、オペレーターがバインディングテーブルの現在の占有レベルを照会して、満杯になるかどうかを判断できるようにする必要があります（SHOULD）。完全なバインディングテーブルに遭遇する実装は、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.
[RFC4862]で指定されているように、CPEが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 NSメッセージの仮アドレスに設定されたIPv6アドレスフィールド。
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メッセージを転送したりしてはなりません（MUST NOT）。
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 performing DAD for this address. The BNG MUST NOT reply to the CPE or forward the NS message.
これらの条件が満たされ、NSメッセージのリンク層ヘッダーのソースアドレスがエントリのリンク層アドレスフィールドのアドレスと等しい場合、CPEがこのアドレスに対してDADを実行していることを意味します。 BNGはCPEに応答したり、NSメッセージを転送してはなりません（MUST NOT）。
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をリンク層アドレスと呼びます。 Link-layer-CPE1とは異なるDADを実行しているCPE。
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に関連付けられている場合、IPv6-CPE1の到達可能性は、セクション4.2.3で説明されているように確認する必要があります。
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を実行しなかった。上記の仮定の1つは、ポイントツーマルチポイントドメインのすべてのノード（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
* リンク層アドレス：Link-layer-CPE1
* State: STALE
* 状態：STALE
The reachability of IPv6-CPE1 MUST be confirmed as soon as possible following the procedure explained in Section 4.2.3.
IPv6-CPE1の到達可能性は、セクション4.2.3で説明されている手順に従って、できるだけ早く確認する必要があります。
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がネイバーキャッシュのエントリにある場合、IPv6-CPE1の到達可能性は、[RFC4861]のセクション7.3.1で説明されているネイバー到達不能検出（NUD）メカニズムを使用してチェックされます。このメカニズムは、パケットをIPv6-CPE1に送信する必要があるかのようにトリガーする必要があります。場合によっては、このメカニズムは何もしないことに注意してください。たとえば、エントリの状態がREACHABLEであり、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.
バインディングテーブル（Link-layer-CPE1）の競合するエントリが削除され、同じIPv6アドレスを持つ新しいエントリに置き換えられますが、CPEのリンク層アドレスはDAD（Link-layer-CPE2）を実行しています。セクション4.2.1で説明されています。
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の状態がREACHABLEである場合）、それは潜在的な競合が現実であることを意味します。
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は、DADを実行しているCPE（図1のCPE2）に、次の形式のNAメッセージで応答する必要があります。
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によって受信されたNSメッセージのレイヤー2ヘッダーの送信元アドレス（つまり、Link-layer-CPE2）。
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)
| | |
(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.
BNG SHOULDは、DADプロキシ機能によってIPv6アドレスの重複が検出されるたびに、ログに記録してアラームを発行するメカニズムをサポートする必要があります（SHOULD）。さらに、BNG SHOULDは、オペレーターがログにアクセスし、バインディングテーブルの現在のエントリを表示できるようにする関数を実装する必要があります（SHOULD）。この情報を取得するためのアクセス権の管理は、このドキュメントの範囲外です。
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].
このドキュメントで説明されているメカニズムは、SEcureネイバー探索（SEND）[RFC3971]と相互運用しません。これは、プロキシされたNDメッセージ[RFC5909]に正しく署名するために必要な暗号生成アドレス（CGA）[RFC3972]に関連付けられた秘密鍵をBNGが所有していないためです。
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.
SENDのセキュアプロキシNDサポート[RFC6496]は、この制限に対処するために指定されており、BNGおよびCPEで実装および使用する必要があります（SHOULD）。
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 Chatzithomaoglouに感謝します。著者はまた、IETF 6man WGメンバーと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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年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 Stateless Address Autoconfiguration」、RFC 4862、2007年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、「Ethernet on IPv6 Multicast Packets on Ethernet」、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、「SEcure Neighbor Discovery（SEND）」、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年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、「Neighbor Discovery Proxies（ND Proxy）」、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。、編、Haskins、D。、およびE. Allen、「IPバージョン6 over PPP」、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、「Securing Neighbor Discovery Proxy：Problem Statement」、RFC 5909、2010年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 6275、2011年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]クリシュナンS.、ラガニアJ.、ボノーラM.、およびA.ガルシアマルティネス、「SECure Neighbor Discovery（SEND）のセキュアプロキシNDサポート」、RFC 6496、2012年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：First-Come、First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses」、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、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）のネイバー探索最適化」、RFC 6775、2012年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-Abegnoli、編、「SAVI for Mixed Address Assignment Methods Scenario」、Work in Progress、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、「SENDベースのソースアドレス検証の実装」、作業中、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]ブロードバンドフォーラム、「Migration to Ethernet-Based DSL Aggregation」、Issue 2、Technical Report 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.
この付録は参考情報であり、DADベースのNS（DAD-NS）メッセージを受信したときにBNGによって実行されるアクションの概要（表1を参照）が含まれています。このメッセージの暫定アドレスはIPv6-CPE1であり、関連するリンク層アドレスはLink-layer-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. | |
| 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 rue des Archives 75141 Paris Cedex 03フランス
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（編集者）France Telecom Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9フランス
EMail: jeanmichel.combes@orange.com
Xavier Pougnard France Telecom Orange 2 avenue Pierre Marzin 22300 Lannion France
Xavier Pougnard France Telecom Orange 2 avenue Pierre Marzin 22300ラニオンフランス
EMail: xavier.pougnard@orange.com
Hongyu Li Huawei Technologies Huawei Industrial Base Shenzhen China
hongとL IH UAは技術であり、hu Aは産業基盤であり、真の中国です
EMail: lihy@huawei.com