[要約] RFC 4429は、IPv6における楽観的な重複アドレス検出（DAD）の方法を提案しています。その目的は、ネットワーク上で重複したアドレスが使用されないようにすることです。
Network Working Group N. Moore
Request for Comments: 4429 Monash University CTIE
Category: Standards Track April 2006
Optimistic Duplicate Address Detection (DAD) for IPv6
IPv6の楽観的な複製アドレス検出（DAD）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers.
楽観的な複製アドレスの検出は、既存のIPv6隣接発見（RFC 2461）およびStateless Address Autoconfiguration（RFC 2462）プロセスの相互運用可能な変更です。意図は、成功したケースでのアドレス構成の遅延を最小限に抑え、障害の場合に可能な限り破壊を減らし、変更されていないホストとルーターと相互運用可能なままにすることです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Definitions ................................................4
1.3. Address Types ..............................................4
1.4. Abbreviations ..............................................5
2. Optimistic DAD Behaviors ........................................6
2.1. Optimistic Addresses .......................................6
2.2. Avoiding Disruption ........................................6
2.3. Router Redirection .........................................7
2.4. Contacting the Router ......................................7
3. Modifications to RFC-Mandated Behavior ..........................8
3.1. General ....................................................8
3.2. Modifications to RFC 2461 Neighbor Discovery ...............8
3.3. Modifications to RFC 2462 Stateless Address
Autoconfiguration ..........................................9
4. Protocol Operation .............................................10
4.1. Simple Case ...............................................10
4.2. Collision Case ............................................10
4.3. Interoperation Cases ......................................11
4.4. Pathological Cases ........................................11
5. Security Considerations ........................................12
Appendix A. Probability of Collision ..............................13
A.1. The Birthday Paradox ......................................13
A.2. Individual Moving Nodes ...................................14
Normative References ..............................................15
Informative References ............................................15
Acknowledgements ..................................................16
Optimistic Duplicate Address Detection (DAD) is a modification of the existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462] processes. The intention is to minimize address configuration delays in the successful case, and to reduce disruption as far as possible in the failure case.
楽観的な複製アドレス検出（DAD）は、既存のIPv6隣接発見（ND）[RFC2461]およびStateless Address Autoconfiguration（SLAAC）[RFC2462]プロセスの変更です。意図は、成功したケースでのアドレス構成の遅延を最小限に抑え、障害の場合の混乱を可能な限り減らすことです。
Optimistic DAD is a useful optimization because in most cases DAD is far more likely to succeed than fail. This is discussed further in Appendix A. Disruption is minimized by limiting nodes' participation in Neighbor Discovery while their addresses are still Optimistic.
楽観的なお父さんは、ほとんどの場合、父親は失敗するよりもはるかに成功する可能性が高いため、有用な最適化です。これについては、付録Aでさらに説明します。ノードの近隣発見への参加を制限することにより、混乱は最小限に抑えられます。
It is not the intention of this memo to improve the security, reliability, or robustness of DAD beyond that of existing standards, but merely to provide a method to make it faster.
既存の標準のセキュリティ、信頼性、または堅牢性を改善することは、このメモの意図ではなく、単にそれをより速くする方法を提供するためだけです。
The existing IPv6 address configuration mechanisms provide adequate collision detection mechanisms for the fixed hosts they were designed for. However, a growing population of nodes need to maintain continuous network access despite frequently changing their network attachment. Optimizations to the DAD process are required to provide these nodes with sufficiently fast address configuration.
既存のIPv6アドレス構成メカニズムは、設計された固定ホストに適切な衝突検出メカニズムを提供します。ただし、ノードの集団の増加は、ネットワークの添付ファイルを頻繁に変更するにもかかわらず、継続的なネットワークアクセスを維持する必要があります。これらのノードを十分に高速なアドレス構成で提供するには、DADプロセスの最適化が必要です。
An optimized DAD method needs to:
最適化されたDADメソッドが必要です。
* provide interoperability with nodes using the current standards.
* 現在の標準を使用して、ノードで相互運用性を提供します。
* remove the RetransTimer delay during address configuration.
* アドレス構成中にretranstimerの遅延を削除します。
* ensure that the probability of address collision is not increased.
* アドレス衝突の確率が増加しないことを確認してください。
* improve the resolution mechanisms for address collisions.
* アドレス衝突の解像度メカニズムを改善します。
* minimize disruption in the case of a collision.
* 衝突の場合の混乱を最小限に抑えます。
It is not sufficient to merely reduce RetransTimer in order to reduce the handover delay, as values of RetransTimer long enough to guarantee detection of a collision are too long to avoid disruption of time-critical services.
衝突の検出を保証するのに十分な長さのレトランスティマーの値は、時間批判的なサービスの混乱を避けるために長すぎるため、ハンドオーバー遅延を減らすために単にレトランスティマーを減らすだけでは十分ではありません。
Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current Practice, RFC 2119 [RFC2119]
要件の定義キーワード（「必須」、「必要はない」、「may」、「sufe」、 'must'）は、IETFの最良の現在のプラクティス、RFC 2119 [RFC2119]に準拠しています。
Address Resolution - Process defined by [RFC2461], section 7.2.
アドレス解像度 - [RFC2461]で定義されたプロセス、セクション7.2。
Neighbor Unreachability Detection (NUD) - Process defined by [RFC2461], section 7.3.
近隣の到達不能（NUD） - [RFC2461]で定義されたプロセス、セクション7.3。
Standard Node - A Standard Node is one that is compliant with [RFC2461] and [RFC2462].
標準ノード - 標準ノードは、[RFC2461]および[RFC2462]に準拠したノードです。
Optimistic Node (ON) - An Optimistic Node is one that is compliant with the rules specified in this memo.
楽観的なノード（オン） - 楽観的なノードは、このメモで指定されたルールに準拠したノードです。
Link - A communication facility or medium over which nodes can communicate at the link layer.
リンク - ノードがリンクレイヤーで通信できる通信施設または媒体。
Neighbors - Nodes on the same link, which may therefore be competing for the same IP addresses.
Neighbors -同じリンク上のノード。したがって、同じIPアドレスを競合する可能性があります。
Tentative address (as per [RFC2462]) - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A Tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a Tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the Tentative address.
暫定アドレス（[RFC2462]による） - インターフェイスへの割り当ての前に、リンク上の一意性が検証されているアドレス。暫定的なアドレスは、通常の意味でインターフェイスに割り当てられているとは見なされません。インターフェイスは、暫定的なアドレスに宛てられたパケットを受け取ったパケットを破棄しますが、暫定アドレスの複製アドレス検出に関連する近隣発見パケットを受け入れます。
Optimistic address - an address that is assigned to an interface and available for use, subject to restrictions, while its uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions.
楽観的なアドレス - リンク上の独自性が検証されている間、制限の対象となるインターフェイスに割り当てられ、使用可能なアドレスです。このメモは、楽観的な状態を紹介し、その行動と制限を定義します。
Preferred address (as per [RFC2462]) - an address assigned to an interface whose use by upper-layer protocols is unrestricted. Preferred addresses may be used as the source (or destination) address of packets sent from (or to) the interface.
優先アドレス（[RFC2462]による） - 上層層プロトコルによる使用が無制限のインターフェイスに割り当てられたアドレス。優先アドレスは、インターフェイスから送信されたパケットのソース（または宛先）アドレスとして使用できます。
Deprecated address (as per [RFC2462]) - An address assigned to an interface whose use is discouraged, but not forbidden. A Deprecated address should no longer be used as a source address in new communications, but packets sent from or to Deprecated addresses are delivered as expected. A Deprecated address may continue to be used as a source address in communications where switching to a Preferred address causes hardship to a specific upper-layer activity (e.g., an existing TCP connection).
非推奨アドレス（[RFC2462]による） - 使用が阻止されているが禁止されていないインターフェイスに割り当てられたアドレス。非推奨のアドレスは、新しい通信のソースアドレスとして使用されなくなりますが、予想通りに送信されるパケットが送信されます。非推奨アドレスは、優先アドレスに切り替えると特定の上層活動（既存のTCP接続など）に困難を引き起こす通信のソースアドレスとして引き続き使用される場合があります。
DAD - Duplicate Address Detection. Technique used for SLAAC. See [RFC2462], section 5.4.
お父さん - 住所検出を重複しています。SLAACに使用される手法。[RFC2462]、セクション5.4を参照してください。
ICMP Redirect - See [RFC2461], section 4.5.
ICMPリダイレクト - [RFC2461]、セクション4.5を参照してください。
NA - Neighbor Advertisement. See [RFC2461], sections 4.4 and 7.
NA-隣人広告。[RFC2461]、セクション4.4および7を参照してください。
NC - Neighbor Cache. See [RFC2461], sections 5.1 and 7.3.
NC-ネイバーキャッシュ。[RFC2461]、セクション5.1および7.3を参照してください。
ND - Neighbor Discovery. The process described in [RFC2461].
ND-隣人の発見。[RFC2461]で説明されているプロセス。
NS - Neighbor Solicitation. See [RFC2461], sections 4.3 and 7.
ns-隣人の勧誘。[RFC2461]、セクション4.3および7を参照してください。
RA - Router Advertisement. See [RFC2462], sections 4.2 and 6.
RA-ルーター広告。[RFC2462]、セクション4.2および6を参照してください。
RS - Router Solicitation. See [RFC2461], sections 4.1 and 6.
RS-ルーターの勧誘。[RFC2461]、セクション4.1および6を参照してください。
SLAAC - StateLess Address AutoConfiguration. The process described in [RFC2462].
SLAAC-ステートレスアドレスAutoconfiguration。[RFC2462]で説明されているプロセス。
SLLAO - Source Link-Layer Address Option - an option to NS, RA, and RS messages, which gives the link-layer address of the source of the message. See [RFC2461], section 4.6.1.
Sllao-ソースリンク層アドレスオプション - NS、RA、およびRSメッセージへのオプション。これにより、メッセージのソースのリンクレイヤーアドレスが表示されます。[RFC2461]、セクション4.6.1を参照してください。
TLLAO - Target Link-Layer Address Option - an option to ICMP Redirect messages and Neighbor Advertisements. See [RFC2461], sections 4.4, 4.5, and 4.6.1.
Tllao-ターゲットリンク層アドレスオプション - ICMPのリダイレクトメッセージと近隣広告のオプション。[RFC2461]、セクション4.4、4.5、および4.6.1を参照してください。
This non-normative section discusses Optimistic DAD behaviors.
この非規範的なセクションでは、楽観的なパパの行動について説明します。
[RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated (in 5.5.4) addresses. Addresses that are neither are said to be Preferred. Tentative addresses may not be used for communication, and Deprecated addresses should not be used for new communications. These address states may also be used by other standards documents, for example, Default Address Selection [RFC3484].
[RFC2462]は、暫定（5.4）および非推奨（5.5.4）のアドレスの概念を導入します。どちらも好まないと言われているアドレス。暫定的なアドレスは通信に使用されない場合があり、新しい通信には非推奨アドレスを使用しないでください。これらのアドレス状態は、デフォルトのアドレス選択[RFC3484]など、他の標準ドキュメントでも使用できます。
This memo introduces a new address state, 'Optimistic', that is used to mark an address that is available for use but that has not completed DAD.
このメモは、使用可能な住所をマークするために使用されるが、パパを完成させていない新しいアドレス状態「楽観的」を紹介します。
Unless noted otherwise, components of the IPv6 protocol stack should treat addresses in the Optimistic state equivalently to those in the Deprecated state, indicating that the address is available for use but should not be used if another suitable address is available. For example, Default Address Selection [RFC3484] uses the address state to decide which source address to use for an outgoing packet. Implementations should treat an address in state Optimistic as if it were in state Deprecated. If address states are recorded as individual flags, this can easily be achieved by also setting 'Deprecated' when 'Optimistic' is set.
特に明記しない限り、IPv6プロトコルスタックのコンポーネントは、非推奨状態の住所と同等のアドレスのアドレスを扱う必要があります。たとえば、デフォルトのアドレス選択[RFC3484]は、アドレス状態を使用して、発信パケットに使用するソースアドレスを決定します。実装では、州の住所を楽観的に扱う必要があります。アドレス状態が個々のフラグとして記録されている場合、これは「楽観的」が設定されたときに「非推奨」を設定することで簡単に実現できます。
It is important to note that the address lifetime rules of [RFC2462] still apply, and so an address may be Deprecated as well as Optimistic. When DAD completes without incident, the address becomes either a Preferred or a Deprecated address, as per [RFC2462].
[RFC2462]の住所の生涯規則がまだ適用されていることに注意することが重要です。したがって、住所は楽観的であると同時に非難される可能性があります。お父さんが無事に完了すると、住所は[RFC2462]に従って、優先または非推奨の住所になります。
In order to avoid interference, it is important that an Optimistic Node does not send any messages from an Optimistic Address that will override its neighbors' Neighbor Cache (NC) entries for the address it is trying to configure: doing so would disrupt the rightful owner of the address in the case of a collision.
干渉を回避するために、楽観的なノードが、構成しようとしているアドレスのNeighbors Neighbor Cache（NC）エントリをオーバーライドする楽観的なアドレスからメッセージを送信しないことが重要です。衝突の場合のアドレスの。
This is achieved by:
これは、次のように達成されます。
* Clearing the 'Override' flag in Neighbor Advertisements for Optimistic Addresses, which prevents neighbors from overriding their existing NC entries. The 'Override' flag is already defined [RFC2461] and used for Proxy Neighbor Advertisement.
* 隣のアドレスのために隣の広告で「オーバーライド」フラグをクリアするため、隣人が既存のNCエントリを無効にすることができなくなります。「オーバーライド」フラグは既に定義されており[RFC2461]、プロキシネイバー広告に使用されています。
* Never sending Neighbor Solicitations from an Optimistic Address. NSes include a Source Link-Layer Address Option (SLLAO), which may cause Neighbor Cache disruption. NSes sent as part of DAD are sent from the unspecified address, without a SLLAO.
* 楽観的な住所から隣人の勧誘を決して送らないでください。NSEには、ソースリンク層アドレスオプション（SLLAO）が含まれており、隣接キャッシュの破壊を引き起こす可能性があります。お父さんの一部として送信されたNSEは、Sllaoなしで、不特定の住所から送信されます。
* Never using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified address, may be used, or the RS may be sent without a SLLAO.
* Sllaoを使用したルーター勧誘のソースアドレスとして楽観的なアドレスを使用しないでください。別のアドレス、または不特定のアドレスを使用することも、RSをSLLAOなしで送信することもできます。
An address collision with a router may cause a neighboring router's IsRouter flags for that address to be cleared. However, routers do not appear to use the IsRouter flag for anything, and the NA sent in response to the collision will reassert the IsRouter flag.
ルーターとのアドレス衝突により、そのアドレスがクリアされるために、隣接するルーターのiSrouterフラグが原因になる場合があります。ただし、ルーターはISRouterフラグを何でも使用していないようであり、衝突に応じて送信されたNAはISRouterフラグを再確認します。
Neighbor Solicitations cannot be sent from Optimistic Addresses, and so an ON cannot directly contact a neighbor that is not already in its Neighbor Cache. Instead, the ON forwards packets via its default router, relying on the router to forward the packets to their destination. In accordance with RFC 2461, the router should then provide the ON with an ICMP Redirect, which may include a Target Link-Layer Address Option (TLLAO). If it does, this will update the ON's NC, and direct communication can begin. If it does not, packets continue to be forwarded via the router until the ON has a non-Optimistic address from which to send an NS.
隣人の勧誘は楽観的なアドレスから送信することはできないため、隣のキャッシュにまだ含まれていない隣人に直接連絡することはできません。代わりに、オンフォワードパケットはデフォルトのルーターを介してパケットを介して、ルーターに依存してパケットを宛先に転送します。RFC 2461に従って、ルーターはターゲットリンク層アドレスオプション（TLLAO）を含むICMPリダイレクトをオンに提供する必要があります。もしそうなら、これによりONのNCが更新され、直接通信が開始されます。そうでない場合、パケットは、NSを送信するための最適でないアドレスがオンになるまで、ルーターを介して転送され続けます。
Generally, an RA will include a SLLAO, however this "MAY be omitted to facilitate in-bound load balancing over replicated interfaces" [RFC2461]. A node with only Optimistic Addresses is unable to determine the router's Link-Layer Address as it can neither send an RS to request a unicast RA, nor send an NS to request an NA. In this case, the ON will be unable to communicate with the router until at least one of its addresses is no longer Optimistic.
一般に、RAにはSllaoが含まれますが、これは「複製されたインターフェイス上の内部負荷分散を促進するために省略される可能性があります」[RFC2461]。楽観的なアドレスのみを備えたノードは、ルーターのリンク層アドレスを決定することができません。これは、ユニキャストRAを要求するためにRSを送信することも、NSを要求するNSを送信することもできないためです。この場合、ONは、そのアドレスの少なくとも1つがもはや楽観的ではなくなるまで、ルーターと通信することができません。
All normative text in this memo is contained in this section.
このメモのすべての規範的なテキストは、このセクションに含まれています。
* Optimistic DAD SHOULD only be used when the implementation is aware that the address is based on a most likely unique interface identifier (such as in [RFC2464]), generated randomly [RFC3041], or by a well-distributed hash function [RFC3972] or assigned by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Optimistic DAD SHOULD NOT be used for manually entered addresses.
* 楽観的なお父さんは、アドレスがランダムに生成された[RFC2464]などの最も可能性の高いユニークなインターフェイス識別子（[RFC2464]など）に基づいていることを実装している場合にのみ使用する必要があります。IPv6（DHCPV6）[RFC3315]の動的ホスト構成プロトコルによって割り当てられます。楽観的なお父さんは、手動で入力されたアドレスに使用されるべきではありません。
* (modifies section 6.3.7) A node MUST NOT send a Router Solicitation with a SLLAO from an Optimistic Address. Router Solicitations SHOULD be sent from a non-Optimistic or the Unspecified Address; however, they MAY be sent from an Optimistic Address as long as the SLLAO is not included.
* （セクション6.3.7を変更します）ノードは、楽観的なアドレスからSllaoを使用してルーターの勧誘を送信してはなりません。ルーターの勧誘は、非光学的または不特定のアドレスから送信する必要があります。ただし、Sllaoが含まれていない限り、楽観的な住所から送信される場合があります。
* (modifies section 7.2.2) A node MUST NOT use an Optimistic Address as the source address of a Neighbor Solicitation.
* （セクション7.2.2を変更します）ノードは、隣接勧誘のソースアドレスとして楽観的なアドレスを使用してはなりません。
* If the ON isn't told the SLLAO of the router in an RA, and it cannot determine this information without breaching the rules above, it MUST leave the address Tentative until DAD completes despite being unable to send any packets to the router.
* オンがRAでルーターのSllaoに言われておらず、上記のルールに違反することなくこの情報を決定できない場合、パケットをルーターに送ることができないにもかかわらず、パパが完了するまで住所を暫定的にしておく必要があります。
* (modifies section 7.2.2) When a node has a unicast packet to send from an Optimistic Address to a neighbor, but does not know the neighbor's link-layer address, it MUST NOT perform Address Resolution. It SHOULD forward the packet to a default router on the link in the hope that the packet will be redirected. Otherwise, it SHOULD buffer the packet until DAD is complete.
* （セクション7.2.2を変更します）ノードには、楽観的な住所から隣人に送信するユニキャストパケットがあるが、隣人のリンク層アドレスがわからない場合、アドレス解像度を実行してはなりません。パケットがリダイレクトされることを期待して、リンクのデフォルトのルーターにパケットを転送する必要があります。それ以外の場合は、お父さんが完了するまでパケットをバッファリングする必要があります。
* (modifies section 5.5) A host MAY choose to configure a new address as an Optimistic Address. A host that does not know the SLLAO of its router SHOULD NOT configure a new address as Optimistic. A router SHOULD NOT configure an Optimistic Address.
* （セクション5.5を変更します）ホストは、新しいアドレスを楽観的なアドレスとして構成することを選択できます。ルーターのsllaoを知らないホストは、新しいアドレスを楽観的として構成すべきではありません。ルーターは、楽観的なアドレスを構成しないでください。
* (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages.
* （セクション5.4.2を変更します）ホストは、暫定アドレスのAll-Nodesマルチキャストアドレスと勧誘されたノードマルチキャストアドレスに参加する必要があります。ホストは、近隣の勧誘メッセージを送信する前に遅延しないでください。
* (modifies section 5.4) The Optimistic Address is configured and available for use on the interface immediately. The address MUST be flagged as 'Optimistic'.
* （セクション5.4を変更します）楽観的なアドレスは構成され、すぐにインターフェイスで使用できます。アドレスは「楽観的」としてフラグを立てる必要があります。
* When DAD completes for an Optimistic Address, the address is no longer Optimistic and it becomes Preferred or Deprecated according to the rules of RFC 2462.
* お父さんが楽観的なアドレスを完了すると、住所はもはや楽観的ではなく、RFC 2462のルールに従って好まれるか、非推奨になります。
* (modifies section 5.4.3) The node MUST NOT reply to a Neighbor Solicitation for an Optimistic Address from the unspecified address. Receipt of such an NS indicates that the address is a duplicate, and it MUST be deconfigured as per the behaviour specified in RFC 2462 for Tentative addresses.
* （セクション5.4.3を変更します）ノードは、不特定のアドレスから楽観的なアドレスの近隣勧誘に返信してはなりません。このようなNSの受領は、アドレスが重複していることを示し、暫定アドレスについてRFC 2462で指定された動作に従ってデコン設定する必要があります。
* (modifies section 5.4.3) The node MUST reply to a Neighbor Solicitation for an Optimistic Address from a unicast address, but the reply MUST have the Override flag cleared (O=0).
* （セクション5.4.3を変更します）ノードは、ユニキャストアドレスから楽観的なアドレスの近隣勧誘に応答する必要がありますが、返信にはオーバーライドフラグがクリアされている必要があります（O = 0）。
This non-normative section provides clarification of the interactions between Optimistic Nodes, and between Optimistic Nodes and Standard Nodes.
この非規範的なセクションは、楽観的なノード間の相互作用、および楽観的なノードと標準ノード間の相互作用の明確化を提供します。
The following cases all consider an Optimistic Node (ON) receiving a Router Advertisement containing a new prefix and deciding to autoconfigure a new Optimistic Address on that prefix.
以下のケースはすべて、新しいプレフィックスを含むルーター広告を受信し、そのプレフィックスの新しい楽観的アドレスを自動構成することを決定するという楽観的なノード（オン）を検討します。
The ON will immediately send out a Neighbor Solicitation to determine if its new Optimistic Address is already in use.
オンはすぐに隣人の勧誘を送信して、その新しい楽観的アドレスがすでに使用されているかどうかを判断します。
In the non-collision case, the Optimistic Address being configured by the new node is unused and not present in the Neighbor Caches of any of its neighbors.
非衝突の場合、新しいノードによって構成されている楽観的なアドレスは未使用であり、隣人の隣人のキャッシュには存在しません。
There will be no response to its NS (sent from ::), and this NS will not modify the state of neighbors' Neighbor Caches.
そのNS（:)から送信されたNSへの応答はありません。このNSは、隣人の隣人のキャッシュの状態を変更しません。
The ON already has the link-layer address of the router (from the RA), and the router can determine the link-layer address of the ON through standard Address Resolution. Communications can begin as soon as the router and the ON have each other's link-layer addresses.
オンには、ルーターのリンク層アドレス（RAから）があり、ルーターは標準アドレス解像度を介してONのリンク層アドレスを決定できます。通信は、ルーターとオンに互いのリンク層アドレスを持っているとすぐに開始できます。
After the appropriate DAD delay has completed, the address is no longer Optimistic, and becomes either Preferred or Deprecated as per RFC 2462.
適切な父親の遅延が完了した後、住所はもはや楽観的ではなく、RFC 2462に従って好まれるか、非推奨になります。
In the collision case, the Optimistic Address being configured by the new node is already in use by another node, and present in the Neighbor Caches (NCs) of neighbors that are communicating with this node.
衝突の場合、新しいノードによって構成されている楽観的なアドレスは、別のノードですでに使用されており、このノードと通信している近隣のキャッシュ（NC）に存在しています。
The NS sent by the ON has the unspecified source address, ::, and no SLLAO. This NS will not cause changes to the NC entries of neighboring hosts.
オンによって送信されたNSには、不特定のソースアドレス::、およびSllaoなしがあります。このNSは、近隣ホストのNCエントリに変更を引き起こしません。
The ON will hopefully already know all it needs to about the router from the initial RA. However, if it needs to it can still send an RS to ask for more information, but it may not include a SLLAO. This forces an all-nodes multicast response from the router, but will not disrupt other nodes' NCs.
オンは、最初のRAからのルーターについて必要なすべてを既に知っていることを願っています。ただし、必要な場合は、さらに情報を要求するためにRSを送信できますが、Sllaoは含まれない場合があります。これにより、ルーターからのオールノードマルチキャスト応答が強制されますが、他のノードのNCを破壊しません。
In the course of establishing connections, the ON might have sent NAs in response to received NSes. Since NAs sent from Optimistic Addresses have O=0, they will not have overridden existing NC entries, although they may have resulted in a colliding entry being changed to state STALE. This change is recoverable through standard NUD.
接続を確立する過程で、オンNSEに応じてNASを送信した可能性があります。楽観的な住所から送信されたNASにはO = 0のため、既存のNCエントリをオーバーライドすることはできませんが、衝突するエントリが状態の古いものに変更された可能性があります。この変更は、標準のnudを通じて回復可能です。
When an NA is received from the collidee defending the address, the ON immediately stops using the address and deconfigures it.
住所を防御する衝突からNAが受信されると、アドレスの使用をすぐに停止し、それをデコン表示します。
Of course, in the meantime the ON may have sent packets that identify it as the owner of its new Optimistic Address (for example, Binding Updates in Mobile IPv6 [RFC3775]). This may incur some penalty to the ON, in the form of broken connections, and some penalty to the rightful owner of the address, since it will receive (and potentially reply to) the misdirected packets. It is for this reason that Optimistic DAD should be used only where the probability of collision is very low.
もちろん、その間に、ONはそれを新しい楽観的アドレスの所有者として識別するパケットを送信した可能性があります（たとえば、モバイルIPv6 [RFC3775]のバインディングアップデート）。これにより、接続の破損の形で、オンにペナルティが発生し、住所の正当な所有者にペナルティが発生する可能性があります。このため、楽観的なお父さんは、衝突の確率が非常に低い場合にのみ使用する必要があります。
Once the Optimistic Address has completed DAD, it acts exactly like a normal address, and so interoperation cases only arise while the address is Optimistic.
楽観的な住所がDADを完成させると、それは通常の住所とまったく同じように機能するため、操作のケースは住所が楽観的である間にのみ発生します。
If an ON attempts to configure an address currently Tentatively assigned to a Standard Node, the Standard Node will see the Neighbor Solicitation and deconfigure the address.
現在標準ノードに暫定的に割り当てられているアドレスを構成しようとする場合、標準ノードは近隣の勧誘とアドレスをデコンフィギングします。
If a node attempts to configure an ON's Optimistic Address, the ON will see the NS and deconfigure the address.
ノードがONの楽観的なアドレスを構成しようとする場合、ONはNSとDECONFIGUREを表示します。
Optimistic DAD suffers from similar problems to Standard DAD; for example, duplicates are not guaranteed to be detected if packets are lost.
楽観的なお父さんは、標準的なパパと同様の問題に苦しんでいます。たとえば、パケットが失われた場合、複製は検出されることは保証されていません。
These problems exist, and are not gracefully recoverable, in Standard DAD. Their probability in both Optimistic and Standard DAD can be reduced by increasing the RFC 2462 DupAddrDetectTransmits variable to greater than 1.
これらの問題は存在し、標準的なパパでは優雅に回復できません。楽観的と標準的なパパの両方での確率は、RFC 2462 dupaddrdeTecttransmits変数を1より大きくすることで減らすことができます。
This version of Optimistic DAD is dependent on the details of the router behavior, e.g., that the router includes SLLAOs in RAs and that the router is willing to redirect traffic for the ON. Where the router does not behave in this way, the behavior of Optimistic DAD inherently reverts to that of Standard DAD.
このバージョンの楽観的なお父さんは、ルーターの動作の詳細に依存しています。たとえば、ルーターにはRASにSllaosが含まれており、ルーターがオンのトラフィックをリダイレクトすることをいとわないことです。このようにルーターが動作しない場合、楽観的なパパの行動は本質的に標準的なパパの行動に戻ります。
There are existing security concerns with Neighbor Discovery and Stateless Address Autoconfiguration, and this memo does not purport to fix them. However, this memo does not significantly increase security concerns either.
近隣の発見とステートレスアドレスのオートコンフィギュレーションに関する既存のセキュリティの懸念があり、このメモはそれらを修正することを目的としていません。ただし、このメモは、セキュリティの懸念を大幅に高めることもありません。
Secure Neighbor Discovery (SEND) [RFC3971] provides protection against the threats to Neighbor Discovery described in [RFC3756]. Optimistic Duplicate Address Detection does not introduce any additional threats to Neighbor Discovery if SEND is used.
Secure Neighbor Discovery（SEND）[RFC3971]は、[RFC3756]に記載されている近隣発見に対する脅威に対する保護を提供します。楽観的な複製アドレス検出では、送信が使用された場合、近隣発見に追加の脅威は導入されません。
Optimistic DAD takes steps to ensure that if another node is already using an address, the proper link-layer address in existing Neighbor Cache entries is not replaced with the link-layer address of the Optimistic Node. However, there are still scenarios where incorrect entries may be created, if only temporarily. For example, if a router (while forwarding a packet) sends out a Neighbor Solicitation for an address, the Optimistic Node may respond first, and if the router has no pre-existing link-layer address for that IP address, it will accept the response and (incorrectly) forward any queued packets to the Optimistic Node. The Optimistic Node may then respond in an incorrect manner (e.g., sending a TCP RST in response to an unknown TCP connection). Such transient conditions should be short-lived, in most cases.
楽観的なお父さんは、別のノードがすでにアドレスを使用している場合、既存の近隣キャッシュエントリの適切なリンク層アドレスが楽観的なノードのリンク層アドレスに置き換えられないことを保証するための措置を講じます。ただし、一時的にのみ作成される場合、誤ったエントリが作成される場合があるシナリオがまだあります。たとえば、ルーター（パケットの転送中）がアドレスの近隣勧誘を送信すると、楽観的なノードが最初に応答する場合があり、ルーターにそのIPアドレスの既存のリンク層アドレスがない場合、応答と（誤って）キューに囲まれたパケットを楽観的なノードに転送します。楽観的なノードは、誤った方法で応答する場合があります（たとえば、未知のTCP接続に応じてTCP Rを送信します）。このような一時的な条件は、ほとんどの場合、短命でなければなりません。
Likewise, an Optimistic Node can still inject IP packets into the Internet that will in effect be "spoofed" packets appearing to come from the legitimate node. In some cases, those packets may lead to errors or other operational problems, though one would expect that upper-layer protocols would generally treat such packets robustly, in the same way they must treat old and other duplicate packets.
同様に、楽観的なノードは、正当なノードから来るように見える「スプーフィングされた」パケットであるインターネットにIPパケットをインターネットに挿入できます。場合によっては、これらのパケットがエラーやその他の運用上の問題につながる可能性がありますが、上層層プロトコルは一般に、古いパケットや他の複製パケットを扱わなければならないのと同じように、そのようなパケットを堅牢に扱うことが予想されます。
In assessing the usefulness of Duplicate Address Detection, the probability of collision must be considered. Various mechanisms such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee the uniqueness of the address. The uniqueness of SLAAC depends on the reliability of the manufacturing process (so that duplicate L2 addresses are not assigned) and human factors if L2 addresses can be manually assigned. The uniqueness of DHCPv6-assigned addresses relies on the correctness of implementation to ensure that no two nodes can be given the same address.
重複するアドレス検出の有用性を評価する際には、衝突の確率を考慮する必要があります。SLAAC [RFC2462]やDHCPV6 [RFC3315]などのさまざまなメカニズムは、アドレスの一意性を保証しようとします。SLAACの一意性は、製造プロセスの信頼性（重複L2アドレスが割り当てられないように）と、L2アドレスを手動で割り当てることができる場合のヒューマンファクターに依存します。DHCPV6に割り当てられたアドレスの一意性は、実装の正確性に依存して、2つのノードに同じアドレスを与えられないようにします。
"Privacy Extensions to SLAAC" [RFC3041] avoids these potential error cases by picking an Interface Identifier (IID) at random from 2^62 possible 64-bit IIDs (allowing for the reserved U and G bits). No attempt is made to guarantee uniqueness, but the probability can be easily estimated, and as the following discussion shows, probability of collision is exceedingly small.
「SLAACへのプライバシー拡張」[RFC3041]は、2^62の可能な64ビットIID（予約されたUおよびGビットを可能にする）からランダムにインターフェイス識別子（IID）を選択することにより、これらの潜在的なエラーケースを回避します。一意性を保証する試みは行われませんが、確率を簡単に推定することができ、次の議論が示すように、衝突の確率は非常に少ないです。
When considering collision probability, the Birthday Paradox is generally mentioned. When randomly selecting k values from n possibilities, the probability of two values being the same is:
衝突確率を考慮すると、誕生日のパラドックスが一般的に言及されています。nの可能性からk値をランダムに選択する場合、2つの値が同じである確率は次のとおりです。
Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )
Calculating the probability of collision with this method is difficult, however, as one of the terms is n!, and (2^62)! is an unwieldy number. We can, however, calculate an upper bound for the probability of collision:
ただし、この方法の衝突の確率を計算することは困難です。用語の1つはn！、および（2^62）です。扱いにくい数字です。ただし、衝突の確率のために上限を計算できます。
Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )
which lets us calculate that even for large networks the probability of any two nodes colliding is very small indeed:
これにより、大規模なネットワークであっても、任意の2つのノードが衝突する確率は非常に小さいことを計算できます。
Pb(2^62, 500) <= 5.4e-14
Pb(2^62, 5000) <= 5.4e-12
Pb(2^62, 50000) <= 5.4e-10
Pb(2^62, 500000) <= 5.4e-08
The upper-bound formula used above was taken from "Random Generation of Interface Identifiers", by M. Bagnulo, I. Soto, A. Garcia-Martinez, and A. Azcorra, and is used with the kind permission of the authors.
上記で使用された上部の式は、「ランダム生成の界面識別子」から取られ、M。bagnulo、I。Soto、A。Garcia-Martinez、およびA. Azcorraから取得され、著者の親切な許可を得て使用されています。
When considering the effect of collisions on an individual node, we do not need to consider the Birthday Paradox. When a node moves into a network with K existing nodes, the probability that it will not collide with any of the distinct addresses in use is simply 1-K/N. If it moves to such networks M times, the probability that it will not cause a collision on any of those moves is (1-K/N)^M; thus, the probability of it causing at least one collision is:
個々のノードでの衝突の効果を考慮する場合、誕生日のパラドックスを考慮する必要はありません。ノードが既存のノードを使用してネットワークに移動すると、使用中の異なるアドレスのいずれかと衝突しない確率は1-k/nです。そのようなネットワークに移動する場合、それらの動きのいずれにも衝突を引き起こさない確率は（1-k/n）^mです。したがって、少なくとも1つの衝突を引き起こす確率は次のとおりです。
Pc(n,k,m) = 1-[(1-k/n)^m]
Even considering a very large number of moves (m = 600000, slightly more than one move per minute for one year) and rather crowded networks (k=50000 nodes per network), the odds of collision for a given node are vanishingly small:
非常に多数の動き（M = 600000、1年間に1分あたり1分以上の移動）とむしろ混雑したネットワーク（ネットワークごとに50000ノード）を考慮しても、特定のノードの衝突の可能性はほとんど小さくなります。
Pc(2^62, 5000, 600000) = 6.66e-10
Pc(2^62, 50000, 600000) = 6.53e-09
Each such collision affects two nodes, so the probability of being affected by a collision is twice this. Even if the node moves into networks of 50000 nodes once per minute for 100 years, the probability of it causing or suffering a collision at any point are a little over 1 in a million.
このような衝突それぞれは2つのノードに影響するため、衝突の影響を受ける可能性は2倍です。ノードが100年にわたって1分あたり1回50000ノードのネットワークに移動したとしても、いつでも衝突を引き起こす可能性があるか、100万人に1人を超える可能性があります。
Pc(2^62, 50000, 60000000) * 2 = 1.3e-06
Normative References
引用文献
[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月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
Informative References
参考引用
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Ed。、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、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]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
Acknowledgements
謝辞
There is some precedent for this work in expired Internet-Drafts and in discussions in the MobileIP WG mailing list and at IETF-54. A similar concept occurs in the 'Optimistic' bit used by R. Koodli and C. Perkins in the now expired, "Fast Handovers in Mobile IPv6".
期限切れのインターネットドラフトとMobileIP WGメーリングリストとIETF-54での議論では、この作業にはいくつかの先例があります。同様の概念は、R。KoodliとC. Perkinsが現在期限切れにした「モバイルIPv6の高速ハンドオーバー」で使用されている「楽観的」なビットで発生します。
Thanks to Greg Daley, Richard Nelson, Brett Pentland and Ahmet Sekercioglu at Monash University CTIE for their feedback and encouragement. More information is available at:
グレッグ・デイリー、リチャード・ネルソン、ブレット・ペントランド、モナッシュ大学Ctieのアフメット・セケルコグルに感謝します。詳細については、以下をご覧ください。
<http://www.ctie.monash.edu.au/ipv6/fastho/>
Thanks to all the MobileIP and IPng/IPv6 WG members who have contributed to the debate, especially and alphabetically: Jari Arkko, Marcelo Bagnulo, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, Pekka Nikander, Erik Nordmark, Soohong 'Daniel' Park, Mohan Parthasarathy, Ed Remmel, Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei Tatuya, Dave Thaler, Pascal Thubert, Christian Vogt, Vladislav Yasevich, and Alper Yegin.
特に、そしてアルファベット順に議論に貢献したすべてのMobileIPおよびIPNG/IPv6 WGメンバーに感謝します：Jari Arkko、Marcelo Bagnulo、Jinhyeock Choi、Youn-Hee Han、James Kempf、Thomas Narten、Pekka Nikander、Erik Nordmark、Sohong '' Nordmarkダニエル・パーク、モハン・パルタサラシー、エド・レンメル、ペッカ・サヴォラ、ヘシャム・ソリマン、無知なスーヴァッツィス、ジンメイ・タトゥヤ、デイブ・タラー、パスカル・ツバート、クリスチャン・フォグト、ヴラディスラヴ・ヤセビッチ、およびアルパー・イギン。
This work has been supported by the Australian Telecommunications Cooperative Research Centre (ATcrc):
この作業は、オーストラリアの通信協同組合研究センター（ATCRC）によってサポートされています。
<http://www.telecommunications.crc.org.au/>
Author's Address
著者の連絡先
Nick 'Sharkey' Moore Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia
ニック「シャーキー」ムーアセンターのためのテレコミュニケーションおよび情報工学モナッシュ大学3800ビクトリア、オーストラリア
Comments should be sent to <sharkey@zoic.org> and/or the IPv6 Working Group mailing list. Please include 'RFC4429' in the Subject line.
コメントは、<sharkey@zoic.org>および/またはIPv6ワーキンググループメーリングリストに送信する必要があります。件名に「RFC4429」を含めてください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。