この文書はRFC 4429の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group N. Moore
Request for Comments: 4429 Monash University CTIE
Category: Standards Track April 2006
Optimistic Duplicate Address Detection (DAD) for 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.
この文書はインターネット共同体のためのインターネット標準化中のプロト
コルを指定し、そして改良のために議論と提案を求めます。このプロトコル
と標準化状態と状況は「インターネット公式プロトコル標準」（ＳＴＤ１）
の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
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.
楽天的な重複アドレス検出は現在のＩＰｖ６近隣探索（ＲＦＣ２４６１）と
ステートレスアドレス自動設定（ＲＦＣ２４６２）処理と同時利用可能な修
正です。意図は成功した場合のアドレス設定遅延を最小にして、失敗の場合
に可能な限り中断を減らし、未修正のホストやルータと同時使用可能なまま
でいることです。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Problem Statement
1.1. 問題言明
1.2. Definitions
1.2. 定義
1.3. Address Types
1.3. アドレス種別
1.4. Abbreviations
1.4. 略語
2. Optimistic DAD Behaviors
2. 楽天的なＤＡＤ行動
2.1. Optimistic Addresses
2.1. 楽天的アドレス
2.2. Avoiding Disruption
2.2. 中断を避けること
2.3. Router Redirection
2.3. ルータリダイレクト
2.4. Contacting the Router
2.4. ルータと接触すること
3. Modifications to RFC-Mandated Behavior
3. ＲＦＣで義務づけられた行動の修正
3.1. General
3.1. 概要
3.2. Modifications to RFC 2461 Neighbor Discovery
3.2. ＲＦＣ２４６１近隣探索の修正
3.3. Modifications to RFC 2462 Stateless Address Autoconfiguration
3.3. ＲＦＣ２４６２ステートレスアドレス自動設定への修正
4. Protocol Operation
4. プロトコル運用
4.1. Simple Case
4.1. 単純な場合
4.2. Collision Case
4.2. 衝突の場合
4.3. Interoperation Cases
4.3. 相互運用の事例
4.4. Pathological Cases
4.4. 病的な事例
5. Security Considerations
5. セキュリティの考察
Appendix A. Probability of Collision
付録Ａ. 衝突の確率
A.1. The Birthday Paradox
A.1. 誕生日パラドックス
A.2. Individual Nodes
A.2. 個別のノード
Normative References
参照する参考文献
Informative References
有益な参考文献
Acknowledgements
謝辞
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.
楽天的な重複アドレス発見（ＤＡＤ）は現在のＩＰｖ６近隣探索（ＮＤ）
[RFC2461]とステートレスアドレス自動設定（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.
ほとんどの場合ＤＡＤが失敗より成功する可能性が高いので、楽天的なＤＡ
Ｄは有用な最適化です。 これは付録Ａ.でさらに論じられます。アドレス
がまだ不確定に間に、ノードの近隣探索への参加を制限する事で、中断を最
小にします。
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.
既存の標準のＤＡＤのセキュリティと信頼性と安定性の改善はこの文書の意
図ではなく、早くする方法の供給だけです。
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.
既存のＩＰｖ６アドレス設定メカニズムは固定ホストに設計されたホストに
適切な衝突発見メカニズムを提供します。しかしながら、ネットワーク接続
をしばしば変更し、絶え間ないネットワークアクセス維持をする必要がある
ノードが増加しています。十分に速いアドレス設定をこれらのノードに提供
するためにＤＡＤ処理の最適化が必要とされます。
An optimized DAD method needs to:
最適化されたＤＡＤ方法が以下の必要があります：
* 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を減らすだけでは十分ではありません。
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]
キーワード（'MUST NOT'と'SHOULD NOT'と'MAY'と'SHOULD'と'MUST'）の定義
はがＩＥＴＦ現在最良実践のＲＦＣ２１１９[RFC2119]に従っいます。
Address Resolution - Process defined by [RFC2461], section 7.2.
アドレス解決−［ＲＦＣ２４６１］７．２章で定義された手順。
Neighbor Unreachability Detection (NUD) - Process defined by
[RFC2461], section 7.3.
近隣非接続発見（ＮＵＤ）−［ＲＦＣ２４６１］７．３章で定義された手順。
Standard Node - A Standard Node is one that is compliant with
[RFC2461] and [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.
近隣−同じリンク上にあり従って同じＩＰアドレスで競合しているかもしれ
ないノード。
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]に従う）−インタフェース割当前で、そのリンク上
での一意性を検証しているアドレス。仮アドレスは通常の意味でイン
タフェースに割当てられているとは考えられていません。インタフェー
スは仮アドレス宛てに受け取ったパケットを捨てますが、仮アドレス
の重複アドレス発見と関係がある近隣探索パケットを受け入れます。
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 ］に従う）−インタフェースに割当てられたア
ドレスで、使用は禁じられていないが、推奨されない。抑制アドレス
は新しい通信のソースアドレスとして使用すべきではありませんが、
抑制アドレスからあるいは宛てに送られたパケットが予期されたよう
に配達されます。抑制アドレスから推奨アドレスへの切替が特定の上
位レイヤ活動（例えば、既存のＴＣＰ接続）で困難である場合、抑制
アドレスが通信のソースアドレスとして使用され続けるかもしれませ
ん。
1.4. Abbreviations
1.4. 略語
DAD - Duplicate Address Detection. Technique used for SLAAC. See
[RFC2462], section 5.4.
ＤＡＤ−重複アドレス発見。ＳＬＡＡＣのために使われたテクニック。
[RFC2462]の５.４章参照。
ICMP Redirect - See [RFC2461], section 4.5.
ＩＣＭＰリダイレクト−[RFC2461]の４.５章参照。
NA - Neighbor Advertisement. See [RFC2461], sections 4.4 and 7.
ＮＡ−近隣広告。[RFC2461]の４.４章と７章参照。
NC - Neighbor Cache. See [RFC2461], sections 5.1 and 7.3.
ＮＣ−近隣キャッシュ。[RFC2461]の５.１章と７.３章参照。
ND - Neighbor Discovery. The process described in [RFC2461].
ＮＤ−近隣探索。[RFC2461]で記述された手順。
NS - Neighbor Solicitation. See [RFC2461], sections 4.3 and 7.
ＮＳ−近隣要請。[RFC2461]の４.３章と７章参照。
RA - Router Advertisement. See [RFC2462], sections 4.2 and 6.
ＲＡ−ルータ広告。[RFC2462]の４.２章と６章参照。
RS - Router Solicitation. See [RFC2461], sections 4.1 and 6.
ＲＳ−ルータ要請。[RFC2461]の４.１章と６章参照。
SLAAC - StateLess Address AutoConfiguration. The process described
in [RFC2462].
ＳＬＡＡＣ−ステートレスアドレス自動設定。[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.
ＳＬＬＡＯ−ソースリンクレイヤアドレスオプション。ＮＳとＲＡとＲＳ
メッセージのオプション、メッセージのソースのリンクレイヤアドレ
スを与える。[RFC2461]の４.６.１章参照。
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.
ＴＬＬＡＯ−目標リンクレイヤアドレスオプション。ＩＣＭＰリダイレクト
メッセージと近隣広告のオプション。[RFC2461]の４.４章と４.５章と
４.６.１章参照。
2. Optimistic DAD Behaviors
2. 楽天的なＤＡＤ行動
This non-normative section discusses Optimistic DAD behaviors.
この標準でない章は楽天的なＤＡＤの行動を論じます。
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]は（５.４で）仮アドレスと（５.５.４で）抑制アドレスの概念を
提起しました。いずれもでないアドレスが推奨と言われます。仮アドレスは
通信で使われないかもしれません、そして抑制アドレスが新しい通信で使わ
れるべきではありません。これらのアドレス状態は他の標準文書、例えば、
デフォルトアドレス選択[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.
特に記述がなければ、ＩＰｖ６プロトコルスタックの要素は楽天的状態のア
ドレスを抑制状態と同一に扱います、もし他の推奨アドレスが利用可能であ
るなら、使われるべきではありません。例えば、デフォルトアドレス選択
[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]に従って推奨か抑制アドレ
スになります。
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.
妨害を避けるために、楽天的なノードは、近隣の近隣キャッシュ（ＮＣ）項
目を上書きするメッセージを、設定しようとしている楽天的アドレスからの
送らないことは重要です：送ると衝突した場合にアドレスの正当な所有者を
混乱させるでしょう。
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.
* 近隣が既存のＮＣ項目を上書きするのを阻止するため、楽天的アドレスの
ための近隣広告の「優先」フラグをクリアします。「優先」フラグは
すでに[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.
* 決して近隣要請（ＮＳ）を楽天的アドレスから行いません。ＮＳは近隣
キャッシュ中断を起こすかもしれないソースリンクレイヤアドレスオプ
ション（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.
* 楽天的アドレスをＳＬＬＡＯを含むルータ要請の情報源アドレスとして使
用しません。他のアドレスか特定されていないアドレスが使われるか、
あるいはＲＳはＳＬＬＡＯなしで送られるかもしれません。
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フラグを
使っていないように思われ、そして衝突に応えて送られたＮＡは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.
近隣要請は楽天的アドレスから行こなうことができません、それで楽天的ノー
ドは近隣キャッシュにない近隣と直接連絡を取ることができません。その代
わりに、楽天的ノードは、ルータがパケットをその宛先に転送することを当
てにして、デフォルトルータにパケットを転送します。ＲＦＣ２４６１に従っ
て、ルータは目標リンクレイヤアドレスオプション（ＴＬＬＡＯ）を含むか
もしれないＩＣＭＰリダイレクトを楽天的ノードに提供するべきです。もし
こうするなら、これは楽天的ノードの近隣キャッシュを更新し、直接伝達を
始めることができます。もしこうしないなら、楽天的ノードが近隣要請を送
れる非楽天的アドレスを持つまで、パケットがルータ経由で転送され続けま
す。
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.
「重複インターフェースでの内行き負荷分散を容易にするために除かれるか
もしれません」[RFC2461]とされていますが、一般にルータ広告がＳＬＬＡＯ
を含むでしょう。ただ楽天的なアドレスだけしか持たないノードは、ユニキャ
ストルータ広告を求めるためにルータ要請を送る事も、ルータ広告を求める
ために近隣要請を送る事もできないので、ルータのリンクレイヤアドレスを
決定することが不可能です。この場合、少なくとも１つのアドレスが楽天的
でなくなるまで、楽天的ノードはルータと通信することが不可能であるでしょ
う。
3. Modifications to RFC-Mandated Behavior
3. ＲＦＣで義務づけられた行動の修正
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]か、ＩＰｖ６の動的ホス
ト設定プロトコル(DHCPv6)[RFC3315]で割り当てられたと、実装が気付
いている場合にだけ使われます(SHOULD)。楽観的ＤＡＤは手作業で登録
されたアドレスに使われないべきです(SHOULD NOT)。
3.2. Modifications to RFC 2461 Neighbor Discovery
3.2. ＲＦＣ２４６１近隣探索の修正
* (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.
* （６.３.７章の修正）ノードが楽天的アドレスからＳＬＬＡＯを含むルー
タ要請を送ってはなりません(MUST NOT)。ルータ要請は非楽天的か特定
されていないアドレスから送るべきです(SHOULD)；しかしながら、ＳＬ
ＬＡＯが含まれていない限り、楽天的アドレスから行われるかもしれま
せん(MAY)。
* (modifies section 7.2.2) A node MUST NOT use an Optimistic Address
as the source address of a Neighbor Solicitation.
* （７.２.２章の修正）ノードが楽天的アドレスを近隣要請のソースアドレ
スとして使用してはなりません(MUST NOT)。
* 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.
* もしルータ広告でＳＬＬＡＯが示されず、楽天的ノードが上記の規則を破
らないでこの情報を決定することができないなら、楽天的ノードはルー
タにパケットを送れないくてもアドレスをＤＡＤが終わるで仮にままに
しなければなりません(MUST)。
* (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.
* （７.２.２章の修正）ノードが楽天的アドレスから近隣に送るべきユニキャ
ストパケットを持っているが、近隣のリンクレイヤアドレスを知らない
とき、アドレス決定を実行してはなりません(MUST NOT)。パケットがリ
ダイレクトされるという希望でパケットをリンク上のデフォルトルータ
に転送するべきです(SHOULD)。さもなければ、ＤＡＤが完了するまで、
パケットをバッファに入れるべきです(SHOULD)。
3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration
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.
* （５.５章の修正）ホストが新しいアドレスを楽天的アドレスとして設
定することに決めるかもしれません(MAY)。そのルータのＳＬＬＡＯ
を知らないホストが新しいアドレスを楽天的に設定するべきではあ
りません(SHOULD NOT)。ルータが楽天的アドレスを設定するべきで
はありません(SHOULD NOT)。
* (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.
* （５.４.２章の修正）ホストは全ノードマルチキャストアドレスと仮ア
ドレスの要請ノードマルチキャストアドレスに参加しなくてはなり
ません(MUST)。近隣要請メッセージを送る前に、ホストは遅延を入
れるべきではありません(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'.
* （５.４章の修正）楽天的アドレスは構成を設定され、そしてインタフェー
ス上ですぐに使用可能です。アドレスは「楽天的」という印をつけ
られなくてはなりません。
* 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.
* 楽天的アドレスのＤＡＤが完了するとき、アドレスはもう楽天的ではな
く、ＲＦＣ２４６２の規則に従って推奨か、抑制アドレスになりま
す。
* (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.
* （５.４.３章の修正）ノードは特定されていないアドレスから楽天的アド
レスへの近隣要請に答えてはなりません(MUST NOT)。このような近隣
要請の受信はアドレスが重複していることを示し、仮アドレスについ
てＲＦＣ２４６２で指定された行動に従って設定を解除しなくてはは
なりません(MUST)。
* (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).
* （５.４.３章の修正）ノードはユニキャストアドレスからの楽天的アドレ
スの近隣要請に答えなくてはなりません(MUST)、しかし応答は上書き
フラグをクリア（O=0）しなければなりません(MUST)。
4. Protocol Operation
4. プロトコル運用
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.
楽天的ノードは新しい楽天的アドレスがすでに使用中であるかどうか決定す
るためにすぐに近隣要請を送るでしょう。
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.
衝突しない場合で、新しいノードが設定した楽天的アドレスは使用されず、
その近隣の近隣キャッシュにも存在しません。
There will be no response to its NS (sent from ::), and this NS will
not modify the state of neighbors' 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.
楽天的ノードはすでにルータの（ＲＡから）リンクレイヤアドレスを持ちま
す、そしてルータは標準的なアドレス決定を通して楽天的ノードのリンクレ
イヤアドレスを決定することができます。ルータと楽天的ノードがお互いの
リンクレイヤアドレスを得られれば、通信がすぐに始められます。
After the appropriate DAD delay has completed, the address is no
longer Optimistic, and becomes either Preferred or Deprecated as per
RFC 2462.
適切なＤＡＤ遅延が完了した後、アドレスは楽天的ではなくなり、ＲＦＣ２
４６２に従って推奨か抑制のいずれかになります。
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.
衝突の場合で、新しいノードの設定する楽天的アドレスはすでに他のノード
で使用中で、そしてこのノードと通信している近隣の近隣キャッシュ（ＮＣ）
に存在しています。
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.
楽天的ノードの送る近隣要請は、特定されていないソースアドレス、::、で、
ＳＬＬＡＯはありません。この近隣要請は隣接するホストのＮＣ項目に対す
る変更を起こさないでしょう。
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.
希望的に、楽天的ノードは最初のルータ広告からルータについて必要とす
るすべてを知るでしょう。しかしながら、もしより多くの情報を求める必
要があるなら、ルータ要請を送ることが出来ます、しかしＳＬＬＡＯは含
めないでしょう。これはルータからの全ノードマルチキャスト応答を強制
しますが、他のノードの近隣キャッシュを混乱させないでしょう。
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.
接続を確立する過程で、楽天的ノードは受け取った近隣要請に応えて近隣広
告を送ったかもしれません。楽天的アドレスから送られた近隣広告はＯ＝０
なので、衝突している項目の状態がＳＴＡＬＥ（古い）に変わる結果になる
かもしれませんが、既存の近隣キャッシュを上書きしないでしょう。この変
更は標準的な近隣非接続発見を通して回復可能です。
When an NA is received from the collidee defending the address, the
ON immediately stops using the address and deconfigures it.
衝突者からのアドレス定義の近隣広告を受信するとき、楽天的ノードはアド
レスの使用をやめて、再構築します。
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.
もちろん、その間に楽天的ノードは自分が新しい楽天的アドレスの所有者と
確認するパケットを送ったかもしれません（例えば、モバイルＩＰｖ６の結
合更新[RFC3775]）。これは楽天的ノードに接続の破壊というペナルティを与
え、アドレスの正しい所有者は間違った宛先のパケットを受信する（そして
応答するかも知れない）ので、何らかのペナルティを与えるかもしれません。
楽天的なＤＡＤはただ衝突の確率が非常に低いところでだけ使われるべきな
のはこの理由です。
4.3. Interoperation Cases
4.3. 相互運用の事例
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.
楽天的アドレスがＤＡＤを完了した途端に、それは正確に普通のアドレスの
ように振る舞います、それで、アドレスが楽天的の間だけ相互運用の事例が
生じるだけです。
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.
もしノードが楽天的ノードの楽天的アドレスを設定しようと試みるなら、楽
天的ノードは近隣要請を見て、アドレスを再設定するでしょう。
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.
楽天的ＤＡＤは標準ＤＡＤの問題と類似の問題を起こします；例えば、もし
パケットが失われるなら、重複が発見されることが保証されません。
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.
これらの問題は標準ＤＡＤに存在し、優雅に回復可能ではありません。楽天
的と標準的ＤＡＤでのこれらの確率は、ＲＦＣ２４６２の
DupAddrDetectTransmits変数を１より大きくすることで減できます。
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.
楽天的ＤＡＤのこの版がルータ行動の詳細に依存します、つまり、ルータが
ルータ広告にＳＬＬＡＯを含め、ルータが楽天的ノードのトラフィックを転
送することをいとわないことです。ルータがこのようにして振る舞わない場
合、楽天的ＤＡＤの行動は本質的に標準的ＤＡＤに逆戻りします。
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.
近隣探索とステートレスアドレス自動設定に既存のセキュリティの懸念が
あり、そしてこの文書はそれらを修正しません。しかしながら、この文書
は、特にセキュリティの問題を増やしません。
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.
安全な近隣探索(SEND)[RFC3971]が[RFC3756]で記述された近隣探索に対す
る脅威に対して保護を提供します。もしSENDが使われるなら、楽天的重複
アドレス発見が追加の脅迫を近隣探索に導入しません。
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.
楽天的ＤＡＤは他のノードがすでにアドレスを使っている場合に備えて、
既存の近隣キャッシュ項目の正しいリンクレイヤアドレスが楽天的ノード
のリンクレイヤアドレスに置き換えられないことを保証するための処置を
取ります。しかしながら、まだ一時的に正しくない項目が作られるかもし
れない筋書きがあります。例えば、もしルータが（パケットを転送する間
に）そのアドレスの近隣要請を送るなら、楽天的ノードが最初に応答する
かも知れず、そしてもしルータがそのＩＰアドレスの既存の前のリンクレ
イヤアドレスを持っていないなら、ルータは応答を受け入れて、そして
（間違って）待ち行列に入れられたパケットを楽天的ノードに転送するで
しょう。楽天的ノードは正しくない方法でそれから反応するかもしれませ
ん（例えば、未知のＴＣＰ接続に応えてＴＣＰ ＲＳＴを送ります）。この
ような短期状態は、ほとんどの場合に短命であるべきです。
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.
同じく、楽天的ノードが、結果的に正しいノードから来るように思われ
「偽装」パケットと同じ効果があるＩＰパケットを、インターネットに注
入することができます。ある場合には、こらのパケットはエラーあるいは
他の運用上の問題を導くかもしれません、上位層プロトコルが一般にこの
ようなパケットを強靭に扱うと思われますが、うであろうけれども、上位
層プロトコルはこれらを古い重複パケットと扱わなくてはなりません。
Appendix A. Probability of Collision
付録Ａ. 衝突の確率
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.
重複アドレス発見の有用性を評価する際に、衝突確率を考慮しなくてはな
りません。ＳＬＡＡＣ[RFC2462]やＤＨＣＰｖ６[RFC3315]のような種々な
メカニズムがアドレスの一意さを保証しようと試みます。ＳＬＡＡＣの一
意さは製造処理（重複Ｌ２アドレスが割り当てられない）と、もしＬ２ア
ドレスが手作業で割り当てできるなら人間の信頼性に依存します。ＤＨＣ
Ｐｖ６によって割り当てられたアドレスの一意さは、実装が２つのノード
が同じアドレスを与えられることがないことの保証に依存します。
"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.
２^６２個（予約のＵとＧ部を考慮）の６４ビットのインタフェース識別子
（ＩＩＤ）からランダムにＩＩＤを選ぶ事でことによって、「ＳＬＡＡＣへ
のプライバシー拡張」[RFC3041]がこれらの可能性があるエラーの事例を避
けます。いかなる試みも一意性を保証しませんが、確率は容易に見積ること
ができます、そして次の議論が衝突の確率が非常に小さい事を示します。
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:
衝突確率を考慮に入れるとき、誕生日パラドックスが一般を言われます。
ｎ個の値からランダムにｋ個の値を選択する時、２つの値が一致する確率
は以下の通りです：
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:
しかしながら、項の１つが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:
我々は大きいネットワークでも２つのノードの衝突確率が本当に非常に小さ
いと計算できます：
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の「インタフェース識別子のランダム生成」からのもので、著者の
親切な許可で使われます。
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:
個別のノードに対する衝突の効果を考えるとき、我々は誕生日パラドックス
を考慮する必要がありません。Ｋ個の既存のノードのあるネットワークの中
にノードが入るとき、使用中の別のアドレスのいずれにも衝突しない確率は
単純に1-K/Nです。もしこれがＭ回このようなネットワークに移動し、どの移
動でも衝突を起こさない確率は(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＝６０００００、１年の間、１分毎に動くより多い）と
やや混雑したネットワーク（ネットワーク毎にｋ＝５００００のノード）を
考えても、あるノードが衝突する見込みはとても小さいです：
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.
衝突は２つのノードに影響を与えます、それで衝突によって影響を与えられる
確率はこの２倍です。たとえノードが１００年間５００００ノードのネットワー
クの中で分毎に１度移動しても、衝突を起こすか起こされる確率は百万分の１
を少し超えるぐらいです。
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.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Informative References
有益な参考文献
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
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".
期限切れのインターネットドラフトとモバイルＩＰ作業班のメーリングリ
ストとＩＥＴＦ−５４の議論にこの仕事のいくつかの先例があります。類
似の概念は、現在は期限切れのR. KoodliとC. Perkinsの「モバイルＩＰｖ
６の早いハンドオーバ」によって使われた「楽天的」ビットに存在します。
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:
フィードバックと励ましに対し、Monash大学CTIEのGreg DaleyとRichard
NelsonとBrett PentlandとAhmet Sekerciogluに感謝します。情報が利用可
能なさらに多く：
<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.
討論に貢献したすべてのモバイルＩＰとＩＰｎｇ/ＩＰｖ６作業班のメンバー
に感謝します、特に、アルファベット順に：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.
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
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>かＩＰｖ６作業班メーリングリストに送られ
るべきです。どうか件名に「RFC4429」を含めてください。
Full Copyright Statement
著作権表示全文
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。