[要約] RFC 7527は、IPv6ネットワークでの重複アドレス検出（DAD）の改善に関するものであり、DADの効率と信頼性を向上させるための手法を提案しています。目的は、ネットワークでのアドレスの重複を効果的に検出し、通信の品質とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 7527 H. Singh
Updates: 4429, 4861, 4862 W. Beebee
Category: Standards Track C. Pignataro
ISSN: 2070-1721 Cisco Systems, Inc.
E. Dart
Lawrence Berkeley National Laboratory
W. George
Time Warner Cable
April 2015
Enhanced Duplicate Address Detection
強化された重複アドレス検出
Abstract
概要
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.
IPv6ループバック抑制と重複アドレス検出（DAD）については、RFC 4862の付録Aで説明されています。この仕様では、ループバックDADメッセージを検出するためのハードウェア支援メカニズムについて説明しています。ハードウェアがループバックDADメッセージを抑制できない場合は、ソフトウェアソリューションが必要です。いくつかのサービスプロバイダーコミュニティは、DADで使用されるループバックされた近隣探索（ND）メッセージの自動検出の必要性を表明しています。このドキュメントには、軽減技術が含まれ、DADで使用されるループバックIPv6 NDメッセージの検出を自動化する拡張DADアルゴリズムの概要が示されています。ネットワークループバックテストの場合、拡張DADアルゴリズムにより、ループバックが配置されて削除された後、IPv6が自己修復できます。さらに、特定のアクセスネットワークでは、このドキュメントは特定の重複アドレスの競合の解決を自動化します。このドキュメントは、RFC 4429、4861、および4862を更新します。
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.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc7527.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7527で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Operational Mitigation Options . . . . . . . . . . . . . . . 4
3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 4
3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5
3.3. Operational Considerations . . . . . . . . . . . . . . . 5
4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6
4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6
4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7
4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7
5. Action to Perform on Detecting a Genuine Duplicate . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of [RFC4862]. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. One specific DAD message is the Neighbor Solicitation (NS), specified in [RFC4861]. The NS is issued by the network interface of an IPv6 node for DAD. Another message involved in DAD is the Neighbor Advertisement (NA). The Enhanced DAD algorithm specified in this document focuses on detecting an NS looped back to the transmitting interface during the DAD operation. Detecting a looped back NA does not solve the looped back DAD problem. Detection of any other looped back ND messages during the DAD operation is outside the scope of this document. This document also includes a section on mitigation that discusses means already available to mitigate the DAD loopback problem. This document updates RFCs 4429, 4861, and 4862. It updates RFCs 4429 and 4862 to use the Enhanced DAD algorithm to detect looped back DAD probes, and it updates RFC 4861 as described in Section 4.3 below.
IPv6ループバック抑制と重複アドレス検出（DAD）については、[RFC4862]の付録Aで説明されています。その仕様は、ループバックされたDADメッセージを検出するためのハードウェア支援メカニズムについて述べています。ハードウェアがループバックDADメッセージを抑制できない場合は、ソフトウェアソリューションが必要です。特定のDADメッセージの1つは、[RFC4861]で指定されている近隣要請（NS）です。 NSは、DADのIPv6ノードのネットワークインターフェイスによって発行されます。 DADに関係する別のメッセージは、ネイバーアドバタイズメント（NA）です。このドキュメントで指定されている拡張DADアルゴリズムは、DAD操作中に送信インターフェイスにループバックされたNSの検出に重点を置いています。ループバックNAを検出しても、ループバックDAD問題は解決されません。 DAD操作中に他のループバックNDメッセージを検出することは、このドキュメントの範囲外です。このドキュメントには、DADループバックの問題を緩和するためにすでに利用可能な手段を説明する緩和に関するセクションも含まれています。このドキュメントは、RFC 4429、4861、および4862を更新します。RFC4429および4862を更新して、拡張DADアルゴリズムを使用してループバックDADプローブを検出し、以下のセクション4.3で説明するようにRFC 4861を更新します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
o DAD-failed state - Duplication Address Detection failure as specified in [RFC4862]. Note even Optimistic DAD as specified in [RFC4429] can fail due to a looped back DAD probe. This document covers looped back detection for Optimistic DAD as well.
o DAD失敗状態-[RFC4862]で指定されている重複アドレス検出の失敗。 [RFC4429]で指定されているオプティミスティックDADでも、ループバックDADプローブが原因で失敗する可能性があることに注意してください。このドキュメントでは、Optimistic DADのループバック検出についても説明します。
o Looped back message - also referred to as a reflected message. The message sent by the sender is received by the sender due to the network or an upper-layer protocol on the sender looping the message back.
o ループバックメッセージ-反射メッセージとも呼ばれます。送信者が送信したメッセージは、ネットワークまたは送信者の上位層プロトコルがメッセージをループバックするため、送信者が受信します。
o Loopback - A function in which the router's Layer 3 interface (or the circuit to which the router's interface is connected) is looped back or connected to itself. Loopback causes packets sent by the interface to be received by the interface and results in interface unavailability for regular data traffic forwarding. See more details in Section 9.1 of [RFC2328]. The Loopback function is commonly used in an interface context to gain information on the quality of the interface, by employing mechanisms such as ICMPv6 pings and bit-error tests. In a circuit context, this function is used in wide-area environments including optical Dense Wavelength Division Multiplexing (DWDM) and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) for fault isolation (e.g., by placing a loopback at different geographic locations along the path of a wide-area circuit to help locate a circuit fault). The Loopback function may be employed locally or remotely.
o ループバック-ルーターのレイヤー3インターフェース（またはルーターのインターフェースが接続されている回線）がループバックされるか、それ自体に接続される機能。ループバックにより、インターフェイスによって送信されたパケットがインターフェイスによって受信され、通常のデータトラフィック転送ではインターフェイスを使用できなくなります。詳細については、[RFC2328]のセクション9.1をご覧ください。ループバック機能は、ICMPv6 pingやビットエラーテストなどのメカニズムを使用して、インターフェイスの品質に関する情報を取得するために、インターフェイスコンテキストで一般的に使用されます。回路のコンテキストでは、この機能は、光高密度波長分割多重（DWDM）や同期光ネットワーク/同期デジタル階層（SONET / SDH）などの広域環境で使用され、障害の分離（たとえば、ループバックをさまざまな地理的な場所に配置することにより）広域回路の経路に沿って、回路障害の特定に役立ちます）。ループバック機能は、ローカルまたはリモートで使用できます。
o NS(DAD) - shorthand notation to denote a Neighbor Solicitation (NS) (as specified in [RFC4861]) that has an unspecified IPv6 source address and was issued during DAD.
o NS（DAD）-未指定のIPv6送信元アドレスがあり、DAD中に発行された（[RFC4861]で指定された）近隣要請（NS）を示す省略表記。
Service providers have reported a problem with DAD that arises in a few scenarios. In the first scenario, loopback testing for troubleshooting purposes is underway on a circuit connected to an IPv6-enabled interface on a router. The interface issues an NS for the IPv6 link-local address DAD. The NS is reflected back to the router interface due to the loopback condition of the circuit, and the router interface enters a DAD-failed state. After the loopback condition is removed, IPv4 will return to operation without further manual intervention. However, IPv6 will remain in DAD-failed state until manual intervention on the router restores IPv6 to operation.
サービスプロバイダーは、いくつかのシナリオで発生するDADの問題を報告しています。最初のシナリオでは、トラブルシューティングを目的としたループバックテストが、ルーターのIPv6対応インターフェイスに接続された回線で進行中です。インターフェイスはIPv6リンクローカルアドレスDADのNSを発行します。回線のループバック状態により、NSはルータインターフェイスに反映され、ルータインターフェイスはDAD障害状態になります。ループバック状態が解消されると、IPv4は手動による介入なしに動作に戻ります。ただし、IPv6は、ルーターへの手動の介入によってIPv6が稼働状態に戻るまで、DAD障害状態のままになります。
In the second scenario, two broadband modems are served by the same service provider and terminate to the same Layer 3 interface on an IPv6-enabled access concentrator. In this case, the two modems' Ethernet interfaces are also connected to a common local network (collision domain). The access concentrator serving the modems is the first-hop IPv6 router for the modems and issues a NS(DAD) message for the IPv6 link-local address of its Layer 3 interface. The NS message reaches one modem first, and this modem sends the message to the local network, where the second modem receives the message and then forwards it back to the access concentrator. The looped back NS message causes the network interface on the access concentrator to be in a DAD-failed state. Such a network interface typically serves thousands of broadband modems, and all would have their IPv6 connectivity affected until the DAD-failed state is cleared. Additionally, it may be difficult for the user of the access concentrator to determine the source of the looped back DAD message. Thus, in order to avoid IPv6 outages that can potentially affect multiple users, there is a need for automated detection of looped back NS messages during DAD operations by a node.
2番目のシナリオでは、2つのブロードバンドモデムが同じサービスプロバイダーによって提供され、IPv6対応のアクセスコンセントレーター上の同じレイヤー3インターフェイスで終端します。この場合、2つのモデムのイーサネットインターフェイスも共通のローカルネットワーク（衝突ドメイン）に接続されています。モデムにサービスを提供するアクセスコンセントレータは、モデムの最初のホップのIPv6ルーターであり、レイヤー3インターフェイスのIPv6リンクローカルアドレスに対してNS（DAD）メッセージを発行します。 NSメッセージは最初に1つのモデムに到達し、このモデムはローカルネットワークにメッセージを送信します。2番目のモデムはメッセージを受信し、それをアクセスコンセントレータに転送します。ループバックされたNSメッセージにより、アクセスコンセントレータのネットワークインターフェイスがDADに失敗した状態になります。このようなネットワークインターフェイスは通常、数千のブロードバンドモデムに対応し、DAD障害状態が解消されるまで、すべてのIPv6接続に影響を与えます。さらに、アクセスコンセントレータのユーザーが、ループバックされたDADメッセージのソースを特定するのが難しい場合があります。したがって、複数のユーザーに影響を与える可能性のあるIPv6の停止を回避するために、ノードによるDAD操作中にループバックされたNSメッセージを自動検出する必要があります。
Note: In both examples above, the IPv6 link-local address DAD operation fails due to a looped back DAD probe. However, the problem of a looped back DAD probe exists for any IPv6 address type including global addresses.
注：上記の両方の例で、ループバックDADプローブが原因で、IPv6リンクローカルアドレスDAD操作は失敗します。ただし、ループバックDADプローブの問題は、グローバルアドレスを含むすべてのIPv6アドレスタイプに存在します。
Two mitigation options are described below that do not require any change to existing implementations.
既存の実装への変更を必要としない2つの緩和オプションを以下に説明します。
One can disable DAD on an interface so that there are no NS(DAD) messages issued. While this mitigation may be the simplest, the mitigation has three drawbacks: 1) care is needed when making such configuration changes on point-to-point interfaces, 2) this is a one-time manual configuration on each interface, and 3) genuine duplicates on the link will not be detected.
NS（DAD）メッセージが発行されないように、インターフェイスでDADを無効にすることができます。この軽減策は最も単純な場合がありますが、軽減策には3つの欠点があります。1）ポイントツーポイントインターフェイスでこのような構成を変更する場合は注意が必要です。2）これは各インターフェイスで1回限りの手動設定であり、3）正規リンクの重複は検出されません。
A service provider router, such as an access concentrator, or network core router, SHOULD support the DAD deactivation per interface.
アクセスコンセントレーターやネットワークコアルーターなどのサービスプロバイダールーターは、インターフェイスごとにDADの非アクティブ化をサポートする必要があります（SHOULD）。
Some Layer 2 protocols include provisions to detect the existence of a loopback on an interface circuit, usually by comparing protocol data sent and received. For example, the Point-to-Point Protocol (PPP) uses a magic number (Section 6.4 of [RFC1661]) to detect a loopback on an interface.
一部のレイヤ2プロトコルには、通常送受信されるプロトコルデータを比較することにより、インターフェイス回線上のループバックの存在を検出するためのプロビジョニングが含まれています。たとえば、ポイントツーポイントプロトコル（PPP）はマジックナンバー（[RFC1661]のセクション6.4）を使用して、インターフェース上のループバックを検出します。
When a Layer 2 protocol detects that a loopback is present on an interface circuit, the device MUST temporarily disable DAD on the interface. When the protocol detects that a loopback is no longer present (or the interface state has changed), the device MUST (re-)enable DAD on that interface.
レイヤ2プロトコルがループバックがインターフェイス回路に存在することを検出すると、デバイスは一時的にインターフェイスのDADを無効にする必要があります。プロトコルがループバックが存在しないことを検出した場合（またはインターフェースの状態が変化した場合）、デバイスはそのインターフェースでDADを（再）有効にする必要があります。
This mitigation has several benefits. It leverages the Layer 2 protocol's built-in hardware loopback detection capability, if available. Being a hardware solution, it scales better than the software solution proposed in this document. This mitigation also scales better since it relies on an event-driven model that requires no additional state or timer. This may be significant on devices with hundreds or thousands of interfaces that may be in loopback for long periods of time (e.g., awaiting turn-up).
この緩和策にはいくつかの利点があります。レイヤー2プロトコルの組み込みハードウェアループバック検出機能を利用します（可能な場合）。ハードウェアソリューションであるため、このドキュメントで提案されているソフトウェアソリューションよりも拡張性に優れています。この緩和策は、追加の状態やタイマーを必要としないイベント駆動型モデルに依存しているため、拡張性にも優れています。これは、長期間ループバック状態にある可能性がある（たとえば、ターンアップを待機している）数百または数千のインターフェースを備えたデバイスでは重要な場合があります。
Detecting looped back DAD messages using a Layer 2 protocol SHOULD be enabled by default, and it MUST be a configurable option if the Layer 2 technology provides means for detecting loopback messages on an interface circuit.
レイヤー2プロトコルを使用したループバックDADメッセージの検出はデフォルトで有効にする必要があり（SHOULD）、レイヤー2テクノロジーがインターフェース回路でループバックメッセージを検出する手段を提供する場合、これは構成可能なオプションでなければなりません。
The mitigation options discussed above do not require the devices on both ends of the circuit to support the mitigation functionality simultaneously and do not propose any capability negotiation. They are effective for unidirectional circuit or interface loopback (i.e. the loopback is placed in one direction on the circuit, rendering the other direction nonoperational), but they may not be effective for a bidirectional loopback (i.e., the loopback is placed in both directions of the circuit interface, so as to identify the faulty segment). This is because, unless both ends followed a mitigation option specified in this document, the noncompliant device would follow current behavior and disable IPv6 on that interface due to DAD until manual intervention restores it.
上記の緩和オプションでは、回路の両端のデバイスが緩和機能を同時にサポートする必要がなく、機能のネゴシエーションを提案しません。これらは単方向回線またはインターフェイスループバックには効果的です（つまり、ループバックは回線上の1つの方向に配置され、他の方向は動作しなくなります）が、双方向ループバックには効果的でない場合があります（つまり、ループバックは障害のあるセグメントを特定するための回路インターフェース）これは、両端がこのドキュメントで指定されている軽減オプションに従っていない場合、非対応デバイスは現在の動作に従い、手動の介入によって復元されるまで、DADによりそのインターフェイスでIPv6を無効にするためです。
The Enhanced DAD algorithm covers detection of a looped back NS(DAD) message. This document proposes use of a random number in the Nonce Option specified in SEcure Neighbor Discovery (SEND) [RFC3971]. Note [RFC3971] does not provide a recommendation for pseudorandom functions. Pseudorandom functions are covered in [RFC4086]. Since a nonce is used only once, the NS(DAD) for each IPv6 address of an interface uses a different nonce. Additional details of the algorithm are included in Section 4.1.
拡張DADアルゴリズムは、ループバックされたNS（DAD）メッセージの検出をカバーします。このドキュメントは、SEcure Neighbor Discovery（SEND）[RFC3971]で指定されているナンスオプションでの乱数の使用を提案しています。注[RFC3971]は、疑似ランダム関数の推奨を提供していません。擬似ランダム関数は[RFC4086]でカバーされています。 nonceは1回しか使用されないため、インターフェースの各IPv6アドレスのNS（DAD）は異なるnonceを使用します。アルゴリズムの詳細については、セクション4.1を参照してください。
If there is a collision because two nodes used the same Target Address in their NS(DAD) and generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD) when a genuine address collision has occurred. Since each looped back NS(DAD) event is logged to system management, the administrator of the network will have access to the information necessary to intervene manually. Also, because the nodes will have detected what appear to be looped back NS(DAD) messages, they will continue to probe, and it is unlikely that they will choose the same nonce the second time (assuming quality random number generators).
2つのノードがNS（DAD）で同じターゲットアドレスを使用し、同じランダムナンスを生成したために衝突が発生した場合、本物のアドレス衝突が発生すると、アルゴリズムはループバックされたNS（DAD）を誤って検出します。ループバックされたNS（DAD）イベントはそれぞれシステム管理に記録されるため、ネットワークの管理者は手動で介入するために必要な情報にアクセスできます。また、ノードはループバックされたNS（DAD）メッセージのように見えるものを検出するため、プローブを続行し、2回目に同じノンスを選択することはほとんどありません（高品質の乱数ジェネレーターを想定）。
The algorithm is capable of detecting any ND solicitation (NS and Router Solicitation) or advertisement (NA and Router Advertisement) that is looped back. However, there may be increased implementation complexity and memory usage for the sender node to store a nonce and nonce-related state for all ND messages. Therefore, this document does not recommend using the algorithm outside of the DAD operation by an interface on a node.
このアルゴリズムは、ループバックされるND要請（NSおよびルーター要請）または通知（NAおよびルーター通知）を検出できます。ただし、送信側ノードがすべてのNDメッセージのnonceおよびnonce関連の状態を格納するために、実装の複雑さとメモリ使用量が増加する可能性があります。したがって、このドキュメントでは、ノード上のインターフェースによるDAD操作の外部でアルゴリズムを使用することを推奨していません。
If a node has been configured to use the Enhanced DAD algorithm, when sending an NS(DAD) for a tentative or optimistic interface address, the sender MUST generate a random nonce associated with the interface address, MUST store the nonce internally, and MUST include the nonce in the Nonce option included in the NS(DAD). If the interface does not receive any DAD failure indications within RetransTimer milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits Neighbor Solicitations, the interface moves the Target Address to the assigned state.
ノードが拡張DADアルゴリズムを使用するように構成されている場合、暫定的または楽観的なインターフェースアドレスのNS（DAD）を送信するときに、送信者はインターフェースアドレスに関連付けられたランダムナンスを生成しなければならず、ナンスを内部に保存しなければならず（MUST） NS（DAD）に含まれるノンスオプションのノンス。 DupAddrDetectTransmits Neighbor Solicitationsを送信した後、インターフェイスがRetransTimerミリ秒（[RFC4861]を参照）以内にDAD障害指示を受信しない場合、インターフェイスはターゲットアドレスを割り当てられた状態に移行します。
If any probe is looped back within RetransTimer milliseconds after having sent DupAddrDetectTransmits NS(DAD) messages, the interface continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) messages transmitted RetransTimer milliseconds apart. Section 2 of [RFC3971] defines a single-use nonce, so each Enhanced DAD probe uses a different nonce. If no probe is looped back within RetransTimer milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops. The probing MAY be stopped via manual intervention. When probing is stopped, the interface moves the Target Address to the assigned state.
DupAddrDetectTransmits NS（DAD）メッセージを送信した後、RetransTimerミリ秒以内にプローブがループバックした場合、インターフェースは、RetransTimerミリ秒間隔で送信された別のMAX_MULTICAST_SOLICIT数のNS（DAD）メッセージで続行します。 [RFC3971]のセクション2は使い捨てのナンスを定義しているため、各Enhanced DADプローブは異なるナンスを使用します。 MAX_MULTICAST_SOLICIT NS（DAD）メッセージが送信されてからRetransTimerミリ秒以内にプローブがループバックされない場合、プローブは停止します。プローブは手動の介入によって停止される場合があります。プローブが停止すると、インターフェイスはターゲットアドレスを割り当てられた状態に移行します。
If the node has been configured to use the Enhanced DAD algorithm and an interface on the node receives any NS(DAD) message where the Target Address matches the interface address (in tentative or optimistic state), the receiver compares the nonce included in the message, with any stored nonce on the receiving interface. If a match is found, the node SHOULD log a system management message, SHOULD update any statistics counter, and MUST drop the received message. If the received NS(DAD) message includes a nonce and no match is found with any stored nonce, the node SHOULD log a system management message for a DAD-failed state and SHOULD update any statistics counter.
ノードが拡張DADアルゴリズムを使用するように構成されていて、ノードのインターフェースがターゲットアドレスがインターフェースアドレスと一致するNS（DAD）メッセージを受信している場合（仮の状態または楽観的な状態）、レシーバーはメッセージに含まれるナンスを比較します、受信インターフェースに格納されたナンスがあります。一致が見つかった場合、ノードはシステム管理メッセージをログに記録し（SHOULD）、統計カウンターを更新し（SHOULD）、受信したメッセージをドロップする必要があります（SHOULD）。受信したNS（DAD）メッセージにナンスが含まれ、格納されているナンスとの一致が見つからない場合、ノードはDAD失敗状態のシステム管理メッセージをログに記録し（SHOULD）、統計カウンターを更新する必要があります（SHOULD）。
The following text is appended to the Source Address definition in Section 4.3 of [RFC4861]:
[RFC4861]のセクション4.3の送信元アドレス定義に次のテキストが追加されます。
If a node has been configured to use the Enhanced DAD algorithm, an NS with an unspecified source address adds the Nonce option to the message and implements the state machine of the Enhanced DAD algorithm.
ノードが拡張DADアルゴリズムを使用するように構成されている場合、ソースアドレスが指定されていないNSは、メッセージにナンスオプションを追加し、拡張DADアルゴリズムのステートマシンを実装します。
The following text is appended to the RetransTimer variable description in Section 6.3.2 of [RFC4861]:
[RFC4861]のセクション6.3.2のRetransTimer変数の説明に次のテキストが追加されます。
The RetransTimer MAY be overridden by a link-specific document if a node supports the Enhanced DAD algorithm.
ノードが拡張DADアルゴリズムをサポートしている場合、RetransTimerはリンク固有のドキュメントによってオーバーライドされる場合があります。
As described in the paragraphs above, the nonce can also serve to detect genuine duplicates even when the network has potential for looping back ND messages. When a genuine duplicate is detected, the node follows the manual intervention specified in Section 5.4.5 of [RFC4862]. However, in certain cases, if the genuine duplicate matches the tentative or optimistic IPv6 address of a network interface of the access concentrator, additional automated action is recommended.
上記の段落で説明したように、ネットワークがNDメッセージをループバックする可能性がある場合でも、ナンスは真の重複を検出するのに役立ちます。真の重複が検出されると、ノードは[RFC4862]のセクション5.4.5で指定されている手動の介入に従います。ただし、場合によっては、真の複製がアクセスコンセントレータのネットワークインターフェイスの仮のまたは楽観的なIPv6アドレスと一致する場合は、追加の自動アクションが推奨されます。
Some networks follow a trust model where a trusted router serves untrusted IPv6 host nodes. Operators of such networks have a desire to take automated action if a network interface of the trusted router has a tentative or optimistic address duplicated by a host. One example of a type of access network is cable broadband deployment where the access concentrator is the first-hop IPv6 router to multiple broadband modems and supports proxying of DAD messages. The network interface on the access concentrator initiates DAD for an IPv6 address and detects a genuine duplicate due to receiving an NS(DAD) or an NA message. On detecting such a duplicate, the access concentrator SHOULD log a system management message, drop the received ND message, and block the modem on whose Layer 2 service identifier the duplicate NS(DAD) or NA message was received. Any other network that follows the same trust model MAY use the automated action proposed in this section.
一部のネットワークは、信頼できるルーターが信頼できないIPv6ホストノードにサービスを提供するという信頼モデルに従っています。このようなネットワークの運営者は、信頼できるルーターのネットワークインターフェースにホストによって複製された一時的または楽観的なアドレスがある場合、自動化されたアクションを実行したいという要望があります。アクセスネットワークのタイプの1つの例は、ケーブルブロードバンドの導入です。アクセスコンセントレータは、複数のブロードバンドモデムへの最初のホップIPv6ルーターであり、DADメッセージのプロキシをサポートしています。アクセスコンセントレータのネットワークインターフェイスは、IPv6アドレスのDADを開始し、NS（DAD）またはNAメッセージの受信が原因で真の重複を検出します。そのような重複を検出すると、アクセスコンセントレータは、システム管理メッセージをログに記録し、受信したNDメッセージをドロップし、重複するNS（DAD）またはNAメッセージを受信したレイヤ2サービスIDを持つモデムをブロックする必要があります（SHOULD）。同じ信頼モデルに従う他のすべてのネットワークは、このセクションで提案されている自動化されたアクションを使用する場合があります。
This document does not improve or reduce the security posture of [RFC4862]. The nonce can be exploited by a rogue deliberately changing the nonce to fail the looped back detection specified by the Enhanced DAD algorithm. SEND is recommended to circumvent this exploit. Additionally, the nonce does not protect against the DoS caused by a rogue node replying by a fake NA to all DAD probes. SEND is recommended to circumvent this exploit also. Disabling DAD has an obvious security issue before a remote node on the link can issue reflected NS(DAD) messages. Again, SEND is recommended for this exploit. Source Address Validation Improvement (SAVI) [RFC6620] also protects against various attacks by on-link rogues.
このドキュメントは、[RFC4862]のセキュリティ体制を改善または低減しません。ナンスは、拡張DADアルゴリズムで指定されたループバック検出に失敗するようにナンスを意図的に変更する不正により悪用される可能性があります。この悪用を回避するには、SENDをお勧めします。さらに、ナンスは、偽のNAによってすべてのDADプローブに応答する不正なノードによって引き起こされるDoSから保護しません。 SENDは、このエクスプロイトも回避することをお勧めします。リンク上のリモートノードが反映されたNS（DAD）メッセージを発行する前に、DADを無効にすると明らかなセキュリティ問題が発生します。繰り返しますが、この悪用にはSENDが推奨されます。送信元アドレス検証改善（SAVI）[RFC6620]は、リンク上の不正によるさまざまな攻撃からも保護します。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994, <http://www.rfc-editor.org/info/rfc1661>.
[RFC1661] Simpson、W.、Ed。、 "The Point-to-Point Protocol（PPP）"、STD 51、RFC 1661、July 1994、<http://www.rfc-editor.org/info/rfc1661> 。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005、<http：//www.rfc- editor.org/info/rfc3971>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005、<http://www.rfc-editor.org/info/ rfc4086>。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>.
[RFC4429] Moore、N。、「IPv6の楽観的重複アドレス検出（DAD）」、RFC 4429、2006年4月、<http://www.rfc-editor.org/info/rfc4429>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：//www.rfc- editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月、<http://www.rfc-editor.org/info/rfc4862>。
[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, <http://www.rfc-editor.org/info/rfc6620>.
[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月、<http ：//www.rfc-editor.org/info/rfc6620>。
Acknowledgements
謝辞
Thanks (in alphabetical order by first name) to Adrian Farrel, Benoit Claise, Bernie Volz, Brian Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Hilarie Orman, Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray Hunter, Suresh Krishnan, Tassos Chatzithomaoglou, and Tim Chown for their guidance and review of the document. Thanks to Thomas Narten for encouraging this work. Thanks to Steinar Haug and Scott Beuker for describing some of the use cases.
Adrian Farrel、Benoit Claise、Bernie Volz、Brian Haberman、Dmitry Anipko、Eric Levy-Abegnoli、Eric Vyncke、Erik Nordmark、Fred Templin、Hilarie Orman、Jouni Korhonen、Michael Sinatra、Ole Troanに（名前のアルファベット順で）感謝します、Pascal Thubert、Ray Hunter、Suresh Krishnan、Tassos Chatzithomaoglou、およびTim Chownによるガイダンスとドキュメントのレビュー。この作業を奨励してくれたThomas Nartenに感謝します。使用例のいくつかを説明してくれたSteinar HaugとScott Beukerに感謝します。
Authors' Addresses
著者のアドレス
Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek road Research Triangle Park, NC 27709-4987 United States
Rajiv Asati Cisco Systems、Inc. 7025 Kit Creek road Research Triangle Park、NC 27709-4987 United States
EMail: rajiva@cisco.com
URI: http://www.cisco.com/
Hemant Singh Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 United States
Hemant Singh Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719 United States
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 United States
Wes Beebee Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719 United States
Phone: +1 978 936 2030
EMail: wbeebee@cisco.com
URI: http://www.cisco.com/
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Carlos Pignataro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
EMail: cpignata@cisco.com
URI: http://www.cisco.com/
Eli Dart Lawrence Berkeley National Laboratory 1 Cyclotron Road, Berkeley, CA 94720 United States
Eli Dart Lawrence Berkeley National Laboratory 1 Cyclotron Road、Berkeley、CA 94720 United States
EMail: dart@es.net
URI: http://www.es.net/
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171アメリカ合衆国
EMail: wesley.george@twcable.com