RFC4429 日本語訳
4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT=33123 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Moore Request for Comments: 4429 Monash University CTIE Category: Standards Track April 2006
コメントを求めるワーキンググループN.ムーア要求をネットワークでつないでください: 4429年のモナッシュ大学CTIEカテゴリ: 標準化過程2006年4月
Optimistic Duplicate Address Detection (DAD) for IPv6
IPv6に、楽観的な写しアドレス検出(おとうさん)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
楽観的なDuplicate Address Detectionは既存のIPv6 Neighborディスカバリー(RFC2461)とStateless Address Autoconfiguration(RFC2462)の過程の共同利用できる変更です。 意志は、うまくいっているケースのアドレス構成遅れを最小にして、失敗事件で分裂をできるだけ抑えて、変更されていないホストとルータで共同利用できたままで残ることになっています。
Moore Standards Track [Page 1] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[1ページ]RFC4429
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
1. 序論…3 1.1. 問題声明…3 1.2. 定義…4 1.3. タイプに演説してください…4 1.4. 略語…5 2. 楽観的なおとうさんの振舞い…6 2.1. 楽観的なアドレス…6 2.2. 分裂を避けます…6 2.3. ルータリダイレクション…7 2.4. ルータに連絡します…7 3. RFCによって強制された振舞いへの変更…8 3.1. 一般…8 3.2. RFC2461隣人発見への変更…8 3.3. RFC2462に国がない変更は自動構成を記述します…9 4. 操作について議定書の中で述べてください…10 4.1. 簡単なケース…10 4.2. 衝突ケース…10 4.3. Interoperationケース…11 4.4. 病理学的なケース…11 5. セキュリティ問題…12 付録A.衝突確率…13 A.1。 誕生日のパラドックス…13 A.2。 個々の感動的なノード…14 標準の参照…15 有益な参照…15の承認…16
Moore Standards Track [Page 2] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[2ページ]RFC4429
1. Introduction
1. 序論
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.
楽観的なDuplicate Address Detection(DAD)は既存のIPv6 Neighborディスカバリー(ノースダコタ)[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.
DADが多くの場合失敗するよりはるかに成功しそうであるので、楽観的なDADは役に立つ最適化です。 Appendix A.で、より詳しくこれについて議論します。Disruptionは、それでも、それらのアドレスがOptimisticである間、Neighborディスカバリーへのノードの参加を制限することによって、最小にされます。
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.
それは、このメモがそれを超えてDADのセキュリティ、信頼性、または丈夫さを向上させるという既存の規格の意志であるのではなくそれをより速くする方法を提供するために単に意志です。
1.1. Problem Statement
1.1. 問題声明
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.
それは引き渡し遅れを減少させるためにRetransTimerを単に減少させるために十分ではありません、衝突の検出を保証できるくらい長いRetransTimerの値が時間批判的にサービスの分裂を避けることができないくらい長いときに。
Moore Standards Track [Page 3] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[3ページ]RFC4429
1.2. Definitions
1.2. 定義
Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT',
'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current
Practice, RFC 2119 [RFC2119]
要件キーワードの定義、('、'、'SHOULD NOT'、'5月'、'SHOULD''MUST') IETF Best Current Practiceによると、ある、RFC2119でなければならない[RFC2119]
Address Resolution - Process defined by [RFC2461], section 7.2.
Resolutionを記述してください--[RFC2461]、セクション7.2によって定義された過程。
Neighbor Unreachability Detection (NUD) - Process defined by
[RFC2461], section 7.3.
隣人Unreachability Detection(NUD)--[RFC2461]、セクション7.3によって定義された過程。
Standard Node - A Standard Node is one that is compliant with
[RFC2461] and [RFC2462].
標準のNode--Standard Nodeは[RFC2461]と[RFC2462]と共に言いなりになっているものです。
Optimistic Node (ON) - An Optimistic Node is one that is compliant
with the rules specified in this memo.
楽観的なNode(ON)--Optimistic Nodeは規則がこのメモで指定されている状態で言いなりになっているものです。
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.
ネイバーズ--同じくらいのノード(したがって、同じIPアドレスを競争しているかもしれない)はリンクします。
1.3. Address Types
1.3. アドレスタイプ
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]に従って)--リンクのユニークさが課題の前にインタフェースに確かめられる予定であるアドレス。 Tentativeアドレスは普通の意味におけるインタフェースに割り当てられると考えられません。 インタフェースは、Tentativeアドレスに記述された容認されたパケットを捨てますが、TentativeアドレスのためにDuplicate Address Detectionに関連するNeighborディスカバリーパケットを受け入れます。
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.
楽観的なアドレス--リンクのユニークさが確かめられている間、インタフェースに割り当てられて、制限を条件として使用に利用可能なアドレス。 このメモは、Optimistic状態を導入して、その振舞いと制限を定義します。
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]に従って)--上側の層のプロトコルによる使用が無制限であるインタフェースに割り当てられたアドレス。 パケットのソース(または、目的地)アドレスが(or to)からインタフェースを送ったので、都合のよいアドレスは使用されるかもしれません。
Moore Standards Track [Page 4] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[4ページ]RFC4429
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]に従って)--使用ががっかりしていますが、禁じられないインタフェースに割り当てられたアドレス。 もうソースアドレスとして新しいコミュニケーションでDeprecatedアドレスを使用するべきではありませんが、予想されるようにアドレスかDeprecatedアドレスに送られたパケットを届けます。 Deprecatedアドレスは、コミュニケーションのソースアドレスがPreferredアドレスに切り替わるところで特定の上側の層の活動(例えば、既存のTCP接続)に苦労を引き起こすので使用され続けるかもしれません。
1.4. Abbreviations
1.4. 略語
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 Redirect--[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].
ノースダコタ--隣人発見。 [RFC2461]で説明された過程。
NS - Neighbor Solicitation. See [RFC2461], sections 4.3 and 7.
ナノ秒--隣人懇願。 [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--国がないアドレス自動構成。 [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--ソースLink-層のAddress Option--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--Link-層のAddress Optionを狙ってください--ICMP RedirectメッセージとNeighbor Advertisementsへのオプション。 [RFC2461]、セクション4.4、4.5、および4.6.1を見てください。
Moore Standards Track [Page 5] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[5ページ]RFC4429
2. Optimistic DAD Behaviors
2. 楽観的なおとうさんの振舞い
This non-normative section discusses Optimistic DAD behaviors.
この非標準のセクションはOptimistic DADの振舞いについて論じます。
2.1. Optimistic Addresses
2.1. 楽観的なアドレス
[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]がTentative(5.4における)とDeprecatedの概念を紹介する、(5.5、.4、)、アドレス。 どちらもでないアドレスはPreferredであると言われています。 コミュニケーションに一時的なアドレスを使用しないかもしれません、そして、新しいコミュニケーションにDeprecatedアドレスを使用するべきではありません。 また、これらのアドレス州は他の規格文書、例えば、Default Address Selection[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.
このメモは使用に利用可能なアドレスにマークするのに使用されますが、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プロトコル・スタックの部品はDeprecated状態でOptimistic状態で同等にそれらにアドレスを扱うはずです、別の適当なアドレスが利用可能であるならアドレスが使用に利用可能ですが、使用されるべきでないのを示して。 例えば、Default Address Selection[RFC3484]は、出発しているパケットにどのソースアドレスを使用したらよいかを決めるのにアドレス状態を使用します。 まるでそれが州のDeprecatedにあるかのように実現は州のOptimisticのアドレスを扱うべきです。 アドレス州が独特の旗として記録されるなら、容易にこれによる'楽観的である'ときに、また、セットすることによって達成されて、'非難されたこと'が設定されるということであることができます。
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]のアドレス生涯規則がまだ適用されているのでアドレスがOptimisticと同様にDeprecatedであるかもしれないことに注意するのは重要です。 DADが完成するいつ、事件がなければ、アドレスは[RFC2462]に従ってPreferredかDeprecatedアドレスのどちらかになるか。
2.2. Avoiding Disruption
2.2. 分裂を避けます。
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.
干渉を避けるために、Optimistic Nodeがそれが構成しようとしているアドレスのための隣人のNeighbor Cache(NC)エントリーをくつがえすOptimistic Addressからどんなメッセージも送らないのは、重要です: そうするのは衝突の場合でアドレスの正当な持ち主を混乱させるでしょう。
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.
* Optimistic AddressesのためにNeighbor Advertisementsの'オーバーライド'旗をきれいにします。(Optimistic Addressesは、隣人が彼らの既存のNCエントリーをくつがえすのを防ぎます)。 'オーバーライド'旗は、既に定義されて[RFC2461]、Proxy Neighbor Advertisementに使用されます。
Moore Standards Track [Page 6] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[6ページ]RFC4429
* 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.
* Optimistic AddressからNeighbor Solicitationsを決して送りません。 NSesはAddress Option(SLLAO)Source Link-層を含んでいます。(それは、Neighbor Cacheに分裂を引き起こすかもしれません)。 不特定のアドレスからSLLAOなしでDADの一部として送られたNSesを送ります。
* 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と共にRouter SolicitationのソースアドレスとしてOptimistic Addressを決して使用しません。 別のアドレス、または不特定のアドレスを使用するかもしれませんか、またはSLLAOなしでRSを送るかもしれません。
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旗を重ねて主張させるでしょう。
2.3. Router Redirection
2.3. ルータリダイレクション
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.
Optimistic Addressesから隣人Solicitationsを送ることができないので、ONは直接Neighbor Cacheに既にいない隣人に連絡できません。 代わりに、それらの目的地にパケットを送るためにルータを当てにして、ONはデフォルトルータでパケットを進めます。 RFC2461によると、そして、ルータはICMP RedirectをONに提供するべきです。(ICMP RedirectはAddress Option(TLLAO)Target Link-層を含むかもしれません)。 そうすると、これはONのNCをアップデートするでしょう、そして、ダイレクトコミュニケーションは始まることができます。 そうしないなら、パケットは、ONにはNSを送る非楽観的なアドレスがあるまでルータで進められ続けています。
2.4. Contacting the Router
2.4. ルータに連絡します。
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]。 Optimistic Addressesだけとのノードは、ユニキャストを要求するためにどちらもRSを送ることができないようなルータのLink-層のAddress RAを決定して、NAを要求するためにNSを送ることができません。 この場合、ONはルータで少なくともアドレスの1つがもうOptimisticにならないまで交信できないでしょう。
Moore Standards Track [Page 7] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[7ページ]RFC4429
3. Modifications to RFC-Mandated Behavior
3. RFCによって強制された振舞いへの変更
All normative text in this memo is contained in this section.
このメモによるすべての標準のテキストがこのセクションに含まれています。
3.1. General
3.1. 一般
* 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]などの)に基づいているのを意識しているときだけ、使用されたか、無作為[RFC3041]、またはよく分散しているハッシュ関数[RFC3972]によって発生されたか、またはIPv6(DHCPv6)[RFC3315]のためにDynamic Host Configuration Protocolによって割り当てられた楽観的なDAD SHOULD。 楽観的なDAD SHOULD NOT、手動で入力されたアドレスには、使用されてください。
3.2. Modifications to RFC 2461 Neighbor Discovery
3.2. RFC2461隣人発見への変更
* (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を変更します) ノードはOptimistic AddressからSLLAOとRouter Solicitationを送ってはいけません。 または、ルータSolicitations SHOULD、aから非楽観的に送ってください、Unspecified Address。 しかしながら、SLLAOが含まれていない限り、Optimistic Addressからそれらを送るかもしれません。
* (modifies section 7.2.2) A node MUST NOT use an Optimistic Address
as the source address of a Neighbor Solicitation.
* (セクション7.2.2を変更します) ノードはNeighbor SolicitationのソースアドレスとしてOptimistic Addressを使用してはいけません。
* 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.
* SLLAOがRAでルータについてONに言われないで、上の規則を破らないでこの情報を決定できないなら、発信できない存在にもかかわらず、DADがどんなパケットもルータに完成するまで、それはアドレスをTentativeに出なければなりません。
* (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を変更します) ノードがOptimistic Addressから隣人に送るユニキャストパケットを持っていますが、隣人のリンクレイヤアドレスを知らないとき、それはAddress Resolutionを実行してはいけません。 それ、SHOULDはリンクの上にパケットが向け直されるという望みでデフォルトルータにパケットを送ります。 そうでなければ、それ、DADが完全になるまで、SHOULDはパケットをバッファリングします。
Moore Standards Track [Page 8] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[8ページ]RFC4429
3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration
RFC2462に国がない3.3の変更が自動構成を記述します。
* (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を変更します) ホストは、Optimistic Addressとして新しいアドレスを構成するのを選ぶかもしれません。 ルータSHOULD NOTについてSLLAOを知らないホストはOptimisticとして新しいアドレスを構成します。 ルータSHOULD NOTはOptimistic Addressを構成します。
* (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を変更します) ホストはオールノードマルチキャストアドレスとTentativeアドレスの請求されたノードマルチキャストアドレスに加わらなければなりません。 メッセージをNeighbor Solicitationに送る前に、ホストSHOULD NOTは延着します。
* (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を変更します) すぐに、インタフェースのにおける使用について、Optimistic Addressが構成されてあります。 '楽観的である'としてアドレスに旗を揚げさせなければなりません。
* 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.
* DADが完成するいつ、Optimistic Addressに関しては、アドレスはもうOptimisticでなく、RFC2462の規則に従って、それはPreferredかDeprecatedになるか。
* (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を変更します) ノードはOptimistic Addressのために不特定のアドレスからNeighbor Solicitationに答えてはいけません。 そのようなNSの領収書はアドレスが写しであり、RFC2462でTentativeアドレスに指定されたふるまいに従ってそれを反構成しなければならないのを示します。
* (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を変更します) ノードはOptimistic AddressのためにユニキャストアドレスからNeighbor Solicitationに答えなければなりませんが、回答で、Override旗をきれいにしなければなりません(O=0)。
Moore Standards Track [Page 9] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[9ページ]RFC4429
4. Protocol Operation
4. プロトコル操作
This non-normative section provides clarification of the interactions between Optimistic Nodes, and between Optimistic Nodes and Standard Nodes.
この非標準のセクションはOptimistic Nodesと、Optimistic Nodesと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.
すべてがその接頭語で新しい接頭語を含んでいて、新しいOptimistic Addressを自動構成すると決めながらRouter Advertisementを受けるOptimistic Node(ON)であると考える以下のケース。
The ON will immediately send out a Neighbor Solicitation to determine if its new Optimistic Address is already in use.
ONは、すぐに、新しいOptimistic Addressが既に使用中であるかどうか決定するためにNeighbor Solicitationを出すでしょう。
4.1. Simple Case
4.1. 簡単なケース
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.
非衝突場合では、新しいノードによって構成されるOptimistic Addressは隣人のどれかのNeighbor Cachesに未使用であって存在していません。
There will be no response to its NS (sent from ::), and this NS will not modify the state of neighbors' Neighbor Caches.
NSへの応答が全くないでしょう、そして、(以下から送られる:)このNSは隣人のNeighbor Cachesの州を変更しないでしょう。
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.
ONには、ルータ(RAからの)のリンクレイヤアドレスが既にあります、そして、ルータは標準のAddress Resolutionを通してONのリンクレイヤアドレスを決定できます。 ルータとONが互いのリンクレイヤ住所を知っているとすぐに、コミュニケーションは始まることができます。
After the appropriate DAD delay has completed, the address is no longer Optimistic, and becomes either Preferred or Deprecated as per RFC 2462.
適切なDAD遅れがなった後に、完成していて、アドレスは、もうOptimisticでなく、RFC2462に従ってPreferredかDeprecatedのどちらかになります。
4.2. Collision Case
4.2. 衝突ケース
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.
衝突場合では、新しいノードによって構成されるOptimistic Addressはこのノードとコミュニケートしている隣人のNeighbor Caches(NCs)に別のノードで既に使用中であって、存在しています。
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.
ONによって送られた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.
ONは希望をいだいてルータに関して初期のRAからそれが必要があるすべてを既に知るでしょう。 しかしながら、それであるなら、それへの必要性は詳しい情報を求めるためにまだRSを送ることができますが、それはSLLAOを含まないかもしれません。 これは、ルータからオールノードマルチキャスト応答を強制しますが、他のノードのNCsを混乱させないでしょう。
Moore Standards Track [Page 10] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[10ページ]RFC4429
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.
関係を樹立することの間に、ONは容認されたNSesに対応してNAsを送ったかもしれません。 Optimistic Addressesから送られたNAsがO=0を持っているので、彼らは既存のNCエントリーをくつがえしていないでしょう、STALEを述べるために変えられる衝突エントリーをもたらしたかもしれませんが。 この変化は標準のNUDを通して回復可能です。
When an NA is received from the collidee defending the address, the ON immediately stops using the address and deconfigures it.
アドレスを防御するcollideeからNAを受け取るとき、ONはすぐに、アドレスを使用するのを止めて、それを反構成します。
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は新しいOptimistic Address(例えば、モバイルIPv6[RFC3775]のBinding Updates)の所有者としてそれを特定するパケットを送ったかもしれません。 そして、これは何らかの刑罰をONへ被るかもしれません、失意の接続のフォーム、およびアドレスの正当な持ち主への何らかの刑罰で、受信するので(潜在的に答える、)、的外れのパケット。 それはOptimistic DADが使用されるべきであるこの理由で衝突確率が非常に低いだけであるところにあります。
4.3. Interoperation Cases
4.3. Interoperationケース
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.
Optimistic AddressがいったんDADを完成すると、ちょうど正常なアドレスのように行動するので、アドレスはOptimisticですが、interoperationケースは起こるだけです。
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.
ONが、現在のTentativelyがStandard Nodeに割り当てたアドレスを構成するのを試みると、Standard NodeはNeighbor Solicitationを見るでしょう、そして、deconfigureはアドレスを見ます。
If a node attempts to configure an ON's Optimistic Address, the ON will see the NS and deconfigure the address.
ノードが、ONのOptimistic Addressを構成するのを試みると、ONはNSを見るでしょう、そして、deconfigureはアドレスを見ます。
4.4. Pathological Cases
4.4. 病理学的なケース
Optimistic DAD suffers from similar problems to Standard DAD; for example, duplicates are not guaranteed to be detected if packets are lost.
楽観的なDADは同様の問題からStandard DADまで苦しみます。 例えば、パケットが無くなるなら、写しは、検出されるために保証されません。
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.
これらの問題は、存在していて、Standard DADで優雅に回復可能ではありません。 OptimisticとStandard DADの両方のそれらの確率は、1以上に可変なRFC2462DupAddrDetectTransmitsを増加させることによって、減少できます。
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.
Optimistic DADのこのバージョンは例えば、ルータがRAsにSLLAOsを含んで、ルータが、ONのために交通を向け直しても構わないと思っているというルータの振舞いの詳細に依存しています。 ルータがこのように振る舞わないところでは、Optimistic DADの動きは本来Standard DADのものに戻ります。
Moore Standards Track [Page 11] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[11ページ]RFC4429
5. Security Considerations
5. セキュリティ問題
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.
NeighborディスカバリーとStateless Address Autoconfigurationがある既存の安全上の配慮があります、そして、このメモはそれらを修理することを意味しません。 しかしながら、このメモは安全上の配慮をかなり増加させません。
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.
安全なNeighborディスカバリー(SEND)[RFC3971]は[RFC3756]で説明されたNeighborディスカバリーへの脅威に対する保護を提供します。 SENDが使用されているなら、楽観的なDuplicate Address Detectionはどんな追加脅威もNeighborディスカバリーに紹介しません。
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.
楽観的なDADは、別のノードが既にアドレスを使用しているなら、既存のNeighbor Cacheエントリーにおける適切なリンクレイヤアドレスがOptimistic Nodeのリンクレイヤアドレスに取り替えられないのを保証するために手を打ちます。 しかしながら、まだ、一時的であるだけであるなら、シナリオが不正確なエントリーが作成されるかもしれないところにあります。 例えば、ルータ(パケットを進めている間)がアドレスのためにNeighbor Solicitationを出すなら、Optimistic Nodeが1番目を反応させるかもしれなくて、ルータに先在しないリンクレイヤアドレスがそのIPアドレスのためにあると、それは、応答を受け入れて、(不当に)どんな列に並ばせられたパケットもOptimistic Nodeに送るでしょう。 そして、不正確な方法(例えば、未知のTCP接続に対応してTCP RSTを送る)でOptimistic Nodeは応じるかもしれません。 多くの場合、そのような一時的な状態は短命であるべきです。
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.
同様に、Optimistic Nodeはまだ事実上、正統のノードから来るように見える「だまされた」パケットになるインターネットにIPパケットを注ぐことができます。 いくつかの場合、それらのパケットは誤りか他の運転上の問題に通じるかもしれません、人は、一般に、上側の層のプロトコルはそのようなパケットを強壮に扱うでしょう、同様に古くて他の写しパケットを扱わなければならないと予想するでしょうが。
Moore Standards Track [Page 12] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[12ページ]RFC4429
Appendix A. Probability of Collision
付録A.衝突確率
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.
Duplicate Address Detectionの有用性を評価する際に、衝突確率を考えなければなりません。 SLAAC[RFC2462]やDHCPv6[RFC3315]などの様々なメカニズムは、アドレスのユニークさを保証するのを試みます。 SLAACのユニークさを製造プロセスの信頼性に依存します、そして、(写しL2アドレスが割り当てられないように)L2アドレスであるなら手動で人間の要素は割り当てることができます。 DHCPv6-割り当てられたアドレスのユニークさは、与えられた同じくらいがアドレスであったかもしれないならそのノーtwoにノードを確実にするために実現の正当性を当てにします。
"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へのプライバシーExtensions」[RFC3041]は、2^62可能な64ビットのIIDsからInterface Identifier(IID)を無作為に、選ぶことによって、これらの潜在的誤り事件を避けます(予約されたUとGビットを考慮して)。 容易に確率を見積もることができます、そして、ユニークさを保証するのを試みを全くしませんが、以下の議論が示すように、衝突確率はきわめてわずかです。
A.1. The Birthday Paradox
A.1。 誕生日のパラドックス
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:
衝突が確率であると考えるとき、一般に、Birthday Paradoxは言及されます。 n可能性からk値を手当たりしだいに選択するとき、2つの同じである値の確率は以下の通りです。
Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )
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] )
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
Pb(2^62、500)<=5.4e-14Pb(2^62、5000)<=5.4e-12Pb(2^62、50000)<=5.4e-10Pb(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.
上で使用された上限公式は、A.ガルシアのM.Bagnulo、I.ソト、マルチネス、およびA.Azcorraによって「インタフェース識別子の無作為の世代」から取られて、作者の親切な許可と共に使用されます。
Moore Standards Track [Page 13] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[13ページ]RFC4429
A.2. Individual Nodes
A.2。 個々のノード
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:
個々のノードへの衝突の効果を考えるとき、私たちはBirthday Paradoxを考える必要はありません。 ノードがK存在ノードと共にネットワークに動くと、使用中の異なったアドレスのいずれも衝突しないという確率は単に1K/Nです。 回をそのようなネットワークMに動かすなら、それらの移動のいずれにも衝突を引き起こさないという確率は(1K/N)^Mです。 したがって、少なくとも1回の衝突を引き起こすという確率は以下の通りです。
Pc(n,k,m) = 1-[(1-k/n)^m]
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は1年間600000、1分あたりわずかに1つ以上の移動と等しい)と非常に多くのかなり混雑しているネットワーク(1ネットワークあたりのk=50000ノード)を考えても、与えられたノードのための衝突の可能性は消え失せて小さいです:
Pc(2^62, 5000, 600000) = 6.66e-10
Pc(2^62, 50000, 600000) = 6.53e-09
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つのノードに影響します。これ。 ノードが50000人のネットワークに動いても、100年、任意な点に衝突を引き起こすか、または受けるという確率のための分に一度ノードは100万のうちの1余りです。
Pc(2^62, 50000, 60000000) * 2 = 1.3e-06
Pc(2^62、50000、60000000)*2 = 1.3e-06
Moore Standards Track [Page 14] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[14ページ]RFC4429
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC2462、1998年12月。
Informative References
有益な参照
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、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"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、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.(エド))はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、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.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信用モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC3972]香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
Moore Standards Track [Page 15] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[15ページ]RFC4429
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.パーキンス、「モバイル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でグレッグ・デイリー、リチャード・ネルソン、ブレットPentland、およびAhmet Sekerciogluをありがとうございます。 詳しい情報は以下で利用可能です。
<http://www.ctie.monash.edu.au/ipv6/fastho/>
<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メンバーをありがとうございます: ヤリArkko、マルセロBagnulo、JinHyeockチェ、Youn-ヒー・ハン、ジェームス・ケンフ、トーマスNarten、ペッカNikander、エリックNordmark、Soohong'ダニエル'公園、モハンパルタサラティ、エドRemmel、ペッカSavola、Heshamソリマン、Ignatious Souvatzis、Jinmei Tatuya、デーヴThaler、パスカルThubert、クリスチャンのフォークト、ウラディスラフYasevich、およびAlper Yegin。
This work has been supported by the Australian Telecommunications Cooperative Research Centre (ATcrc):
この仕事はオーストラリアのTelecommunications Cooperative Research Centre(ATcrc)によって支持されました:
<http://www.telecommunications.crc.org.au/>
<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.
to <sharkey@zoic.org をコメントに送るべきである、gt;、そして/または、IPv6作業部会メーリングリスト。 Subject線で'RFC4429'を含めてください。
Moore Standards Track [Page 16] RFC 4429 Optimistic DAD April 2006
おとうさんの2006年4月に楽観的なムーア標準化過程[16ページ]RFC4429
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Moore Standards Track [Page 17]
ムーア標準化過程[17ページ]
一覧
スポンサーリンク
