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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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.
楽観的な重複アドレス検出は、既存のIPv6近隣探索（RFC 2461）およびステートレスアドレス自動設定（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]とステートレスアドレス自動設定（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は便利な最適化です。これは、付録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.
既存の標準のそれを超えDADのセキュリティ、信頼性、または堅牢性を向上させるために、単により速くそれを作るための方法を提供するために、このメモの意図ではありません。
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を低下させるのに十分ではありません。
Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current Practice, RFC 2119 [RFC2119]
要件のキーワードの定義は（ 'いけません'、 'べきではない'、 'MAY'、 'SHOULD'、 '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.
楽観ノード（ON） - 楽観的なノードは、このメモで指定された規則に準拠しているものです。
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アドレスのために競合することができる同じリンク、上のノード。
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.
DAD - 重複アドレス検出。 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 - ステートレスアドレス自動設定。 [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.
この非標準セクションでは、楽観的DADの動作について説明します。
[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.
このメモは使用可能ですが、それは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]のアドレス生涯ルールがまだ適用されることに注意することが重要であり、そのアドレスは非推奨と同様に楽観することができます。 DADが問題なく完了すると、アドレスは[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.
そうする正当な所有者を乱す：干渉を避けるために、楽観ノードが設定しようとしているアドレスのその隣人の近隣キャッシュ（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）を含みます。 DADの一部として送信されるの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.
近隣要請は楽観アドレスから送信することはできません、というように、直接その近隣キャッシュになっていない隣人に連絡することはできません。代わりに、ONは、その宛先にパケットを転送するルータに頼って、そのデフォルトルータを経由してパケットを転送します。 RFC 2461によれば、ルータは、ターゲットリンク層アドレスオプションを含むことができるICMPリダイレクト、（TLLAO）でON提供すべきです。それがない場合は、これがONのNCを更新する、との直接通信を開始することができます。そうでない場合はONが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を送信しない、またNAを要求するためにNSを送ることができるようにのみ楽観アドレスを持つノードは、ルータのリンク層アドレスを決定することができません。そのアドレスの少なくとも一方がもはや楽観的であるまで、この場合には、ONは、ルータと通信することができないであろう。
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]のように）可能性が最も高い固有のインターフェース識別子に基づいていることを知っている場合オプティDADにのみ使用する必要があり、ランダムに[RFC3041]を生成し、又はよく分散ハッシュ関数[RFC3972]によってまたはIPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]によって割り当てられます。楽観的DADは、手動で入力されたアドレスには使用しないでください。
* (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.
*ノードオプティアドレスからSLLAOとルータ要請を送ってはいけません（セクション6.3.7を修正します）。ルーター要請は非楽観または未指定アドレスから送信されます。しかし、彼らは限り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.
* ONがRAにルータのSLLAOに語っていない、それが上記の規則に違反せずに、この情報を判別できない場合DADルータに任意のパケットを送信することができないにもかかわらず完了するまで、それは仮アドレスを残しておく必要があります。
* (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を修正）。これは、パケットがリダイレクトされることを期待して、リンク上のデフォルトルータにパケットを転送する必要があります。 DADが完了するまでそれ以外の場合は、パケットをバッファリングすべきです。
* (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を修正します）。ホストは、近隣要請メッセージを送信する前に遅らせるべきではありません。
* (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.
DADは楽観アドレスのために完了すると*、アドレスはもはや楽観的ではありません、それは好ましいまたは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.
以下の例はすべて、楽観ノード（ON）は、新たなプレフィックスを含むルータアドバタイズメントを受信し、そのプレフィックスに新しい楽観アドレスを自動設定することを決定することを検討してください。
The ON will immediately send out a Neighbor Solicitation to determine if its new Optimistic Address is already in use.
ONは、すぐにその新しい楽観アドレスがすでに使用されているかどうかを判断するために、近隣要請を送信します。
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は隣人の近隣キャッシュの状態を変更しません。
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）からルータのリンク層アドレスを有しており、ルータは、標準的なアドレス解決を介して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遅延が完了した後、アドレスはもはや楽観的ではない、と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.
新しいノードが別のノードによって既に使用されていることにより、衝突の場合には、楽観アドレスが構成され、このノードと通信している近隣の近隣キャッシュ（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を含まなくてもよいです。これは、ルータから全ノードマルチキャスト応答を強制しますが、他のノードのの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.
接続を確立する過程では、ONは、受信のNSEに対応してNASに送信されている場合があります。 NASはO = 0を有するオプティアドレスから送信されたので、彼らは状態STALEに変更される衝突エントリをもたらしたかもしれないが、彼らは、既存のNCエントリを上書きしていないであろう。この変更は、標準NUDて回復可能です。
When an NA is received from the collidee defending the address, the ON immediately stops using the address and deconfigures it.
NAは、アドレスを防御collideeから受信した場合、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は、その新たな楽観アドレスの所有者として識別パケット（例えば、モバイルIPv6で更新をバインディング[RFC3775]）を送ったかもしれません。それは誤ったパケットを受信（及び潜在に返信）するので、これは、アドレスの正当な所有者に壊れ接続の形態でONにいくつかのペナルティ、およびいくつかの不利益を被ることができます。これは、衝突の確率が非常に低い場合にのみ楽観的DADを使用しなければならないのはこのためです。
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.
ONは現在、暫定的に標準的なノードに割り当てられたアドレスを設定しようとすると、標準ノードは近隣要請を参照し、アドレスを構成解除します。
If a node attempts to configure an ON's Optimistic Address, the ON will see the NS and deconfigure the address.
ノードがONの楽観アドレスを設定しようとすると、ONは、NSを参照し、アドレスを構成解除します。
Optimistic DAD suffers from similar problems to Standard DAD; for example, duplicates are not guaranteed to be detected if packets are lost.
楽観的DAD標準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.
これらの問題は存在しており、標準DADで、優雅に回復可能ではありません。両方の楽観と標準DADにおけるその確率は1より大きいRFC 2462 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.
オプティミスティックDADのこのバージョンでは、ルータはRAの中SLLAOsを含み、ルータがONのトラフィックをリダイレクトする意思があることをことを、例えば、ルータの動作の詳細に依存しています。ルータがこのように動作しない場合は、楽観的DADの挙動は、本質的に標準DADのものに戻ります。
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.
[RFC3756]に記載の近隣探索（SEND）[RFC3971]は近隣探索に脅威に対する保護を提供確保します。 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.
楽観的DADは、別のノードがすでにアドレスを使用している場合は、既存の近隣キャッシュエントリで適切なリンク層アドレスは楽観ノードのリンク層アドレスに置き換えされていないことを確実にするための手順を実行します。一時的にしかただし、間違ったエントリが作成されたシナリオは、まだあります。例えば、ルータは（パケットの転送中）アドレスのために近隣要請を送信した場合、楽観ノードが最初に応答することができ、ルータはそのIPアドレスには、既存のリンク層アドレスを持っていない場合、それは受け入れます応答と（間違って）楽観ノードへのキューイングされたパケットを転送します。楽観ノードは、（例えば、未知のTCP接続に応答してTCP RSTを送信する）不正確な方法で応答することができます。このような過渡的な条件は、ほとんどの場合、短命である必要があります。
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パケットを注入することができます。 1は、上位層プロトコルは、一般的に、彼らは古いと他の重複パケットを処理しなければならないのと同じ方法で、確実にそのようなパケットを処理することを期待するもののいくつかのケースでは、これらのパケットは、エラーやその他の運用上の問題につながる可能性があります。
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.
重複アドレス検出の有用性を評価する際に、衝突の確率が考慮されなければなりません。そのようなSLAAC [RFC2462]とDHCPv6 [RFC3315]などの様々なメカニズムは、アドレスの一意性を保証することを試みます。 L2アドレスを手動で割り当てることができる場合SLAACの一意性は、製造プロセス（重複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）を選ぶことによって、これらの潜在的なエラーケースを回避します。試みは一意性を保証するために行われていないが、確率は容易に推定することができ、以下の議論が示すように、衝突の確率は非常に小さいです。
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:
衝突確率を考慮すると、誕生日パラドックスは、一般的に言及されています。ランダムに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:
この方法との衝突の確率を計算すると、用語の一つが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
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.ソト、A.ガルシア・マルティネス、および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:
個々のノード上の衝突の影響を考慮すると、我々は誕生日パラドックスを検討する必要はありません。ノードはK既存のノードとネットワークに移動するとき、それは使用中の異なるアドレスのいずれとも衝突しない確率は単に1-K / Nです。そのようなネットワークにM回移動する場合、それはそれらの移動のいずれかに衝突を生じない確率は（1-K / N）である^ M。このように、少なくとも一つの衝突を引き起こし、それの確率は次のとおりです。
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 = 600000）とかなり混雑したネットワーク（ネットワークごとkは= 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個のノードのネットワークに移動しても、どの時点で衝突を引き起こすか、または苦しんで、それの確率は万人に少し1を超えています。
Pc(2^62, 50000, 60000000) * 2 = 1.3e-06
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
Informative References
参考文献
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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".
期限切れのインターネットドラフトでとモバイルIP WGメーリングリストでの議論ではとIETF-54で、この作品のためのいくつかの先例があります。同様の概念は今期限切れ、「モバイルIPv6における高速ハンドオーバ」でR. KoodliとC.パーキンスによって使用されるビット「楽観的」で発生します。
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のグレッグ・デイリー、リチャード・ネルソン、ブレット・ペントランドとアフメット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.
議論に貢献したすべてのモバイルIPとのIPng / IPv6のWGメンバーのおかげで、特にアルファベット順：ヤリArkko、マルセロBagnulo、JinHyeockチェ、ユン・喜漢、ジェームズ・ケンプ、トーマスNarten氏、ペッカNikander、エリックNordmarkと、Soohong "ダニエル・パーク、モハンパルタサラティ、エドRemmel、ペッカSavola、Heshamソリマン、Ignatious Souvatzis、神明達也、デーブターラー、パスカルThubert、クリスチャン・フォークト、ウラジスラフYasevich、及びアルパース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
電気通信・情報工学のためのニック「シャーキー」ムーアセンターモナッシュ大学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).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。