計算機の世界 Top
新規
編集
2008年7月に公開された、RFC5227 [IPv4 アドレス競合検出]の日本語訳です。同一ネットワーク上で、複数ホストに同一の IP アドレスがアサインされないようにするための技術、ならびに、万一アサインした場合にどうすればよいか、等を規定する標準です。
原文は、http://www.ietf.org/rfc/rfc5227.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。
なお、可読性向上のため、ページのヘッダ・フッタを省略し、原文には無い改行を、適宜挿入しております。ご了承下さい。
Network Working Group S. Cheshire Request for Comments: 5227 Apple Inc. Updates: 826 July 2008 Category: Standards Track
IPv4 Address Conflict Detection
IPv4 アドレス競合検出
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.
本文書は、インターネットコミュニティに向けて、インターネットの標準規格プロトコルを規定し、改良のための議論と提案を求めるものである。本プロトコルの標準化の進捗、および位置づけは、"Internet Official Protocol Standards" (STD 1)の最新版を参照されたい。このメモの配布に制限はない。
When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem.
単一リンク上の2台のホストが、同じ IPv4 アドレスを同時に使用すると、 (問題を生じないようアレンジされているといった非常に稀なケースを除き) その片方または双方に問題を引き起こす。
本文書では、次の事項について説明する。
(i) ホストが、このような誤った設定を回避できるようにするための、簡単な事前注意事項
(ii) 万一、誤って設定された場合、ホストが受動的にこれを感知し、直ちにホストおよび管理者が、問題の修正に取り掛かれるようにするための、シンプルな機構
1. Introduction ....................................................2
1.1. Conventions and Terminology Used in This Document ..........4
1.2. Relationship to RFC 826 ....................................5
1.2.1. Broadcast ARP Replies ...............................7
1.3. Applicability ..............................................7
2. Address Probing, Announcing, Conflict Detection, and Defense ....9
2.1. Probing an Address ........................................10
2.1.1. Probe Details ......................................10
2.2. Shorter Timeouts on Appropriate Network Technologies ......11
2.3. Announcing an Address .....................................12
2.4. Ongoing Address Conflict Detection and Address Defense ....12
2.5. Continuing Operation ......................................14
2.6. Broadcast ARP Replies .....................................14
3. Why Are ARP Announcements Performed Using ARP Request
Packets and Not ARP Reply Packets? .............................15
4. Historical Note ................................................17
5. Security Considerations ........................................17
6. Acknowledgments ................................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................19
1. はじめに ...........................................................2
1.1. 本文書の記述ルールおよび専門用語 ..............................4
1.2. RFC 826 との関係 ..............................................5
1.2.1. ブロードキャスト ARP 応答 ................................7
1.3. 適用可能性 ....................................................7
2. アドレス探知, 通知, 競合検出, 抗告 .................................9
2.1. アドレス探知 .................................................10
2.1.1. 探知の詳細 ..............................................10
2.2. 特殊なネットワーク技術における短いタイムアウト ........,......11
2.3. アドレス公知 .................................................12
2.4. 実行後のアドレス競合・抗告 ...................................12
2.5. オペレーション継続 ...........................................14
2.6. ブロードキャスト ARP 応答 ....................................14
3. ARP 通知が ARP 応答パケットでなく、ARP 要求パケットを使用する理由..15
4. 経緯 ..............................................................17
5. セキュリティの考察 ................................................17
6. 謝辞 ..............................................................18
7. 参照 ..............................................................18
7.1. 標準 .........................................................18
7.2. 参考文献 .....................................................19
Historically, accidentally configuring two Internet hosts with the same IP address has often been an annoying and hard-to-diagnose problem.
同じ IP アドレスを二台のインターネット・ホストに誤って割り当ててしまうことは、有史以来、悩ましく、また原因究明が難しい問題であった。
This is unfortunate, because the existing Address Resolution Protocol (ARP) provides an easy way for a host to detect this kind of misconfiguration and report it to the user. The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131:
不幸なことに、既存の Address Resolution Protocol (ARP) に実装された、この手のミスの検出、およびそれをユーザに通知するメカニズムは、とても簡易なものである。更に RFC2131 から以下三点引用するが、DHCP [RFC2131] の仕様で述べられている、「誤設定の検出において ARP が果たす役割」の記述も、手短なものに過ぎない。
o the client SHOULD probe the newly received address, e.g., with ARP
o The client SHOULD perform a final check on the parameters
(e.g., ARP for allocated network address)
o If the client detects that the address is already in use
(e.g., through the use of ARP), the client MUST send a DHCPDECLINE
message to the server
Unfortunately, the DHCP specification does not give any guidance to implementers concerning the number of ARP packets to send, the interval between packets, the total time to wait before concluding that an address may safely be used, or indeed even which kinds of packets a host should be listening for, in order to make this determination. It leaves unspecified the action a host should take if, after concluding that an address may safely be used, it subsequently discovers that it was wrong. It also fails to specify what precautions a DHCP client should take to guard against pathological failure cases, such as a DHCP server that repeatedly OFFERs the same address, even though it has been DECLINEd multiple times.
残念ながら DHCP の仕様は、競合検出に必要な「送出する ARP パケットの数」「パケット送出のインターバル」「アドレスが安全に使用できると断定するまでに必要な待ち時間」「ホストが聴取 (Listen) すべきパケット」等の実装について、なんらガイドラインを提示していない。
ひいては、ホストが「アドレスを安全に使用できる」と結論付けた後で、実はそれが間違っていたことが分かった場合、一体どのように振舞うべきか、曖昧なまま放置されている。また、「おかしな DHCP サーバが、再三の DECLINE に対して同じアドレスを繰り返し OFFER してくるような状況」に備え、DHCP クライアントが採用すべき予防措置についても、定義がなされていない。
The authors of the DHCP specification may have been justified in thinking at the time that the answers to these questions seemed too simple, obvious, and straightforward to be worth mentioning, but unfortunately this left some of the burden of protocol design to each individual implementer. This document seeks to remedy this omission by clearly specifying the required actions for:
DHCP 仕様の著者らは、これらの問いに対する回答は、非常にシンプルかつ明らか、そして分かりやすいものであるから、説明するまでもないと考えていたのかもしれない。だが残念なことに、これがプロトコル設計におけるある種の重荷となって、実装者に圧し掛かっている。
本文書は、以下を成し遂げるために必要なアクションを明確化し、この「省略箇所」の改善策を模索する。
1. Determining whether use of an address is likely to lead to an
addressing conflict. This includes (a) the case where the address
is already actively in use by another host on the same link, and
(b) the case where two hosts are inadvertently about to begin
using the same address, and both are simultaneously in the process
of probing to determine whether the address may safely be used
(Section 2.1.).
1. あるアドレスの採用が、アドレス競合に結びつく可能性があるか否かの判定 (2.1 節) 。以下2つの状況を想定する。
(a) そのアドレスを、既に同一リンク上の別ホストが使用している場合
(b) 2台のホストが、不注意で、同一のアドレスを使い始めようとしており、かつ双方とも、そのアドレスが安全に使用できるかの探査を行っている最中の場合
2. Subsequent passive detection that another host on the network is
inadvertently using the same address. Even if all hosts observe
precautions to avoid using an address that is already in use,
conflicts can still occur if two hosts are out of communication
at the time of initial interface configuration. This could occur
with wireless network interfaces if the hosts are temporarily out
of range, or with Ethernet interfaces if the link between two
Ethernet hubs is not functioning at the time of address
configuration. A well-designed host will handle not only
conflicts detected during interface configuration, but also
conflicts detected later, for the entire duration of the time
that the host is using the address (Section 2.4.).
2. (他ホストの不注意によって起きる) アドレス競合の、継続的・受動的なチェック (2.4 節) 。すべてのホストが、既に払い出されているアドレスを使わないよう、事前の確認を怠らなかったとしても、競合は起こりうる。例えば、 (ネットワーク) インターフェイスの初期化時には、互いに通信できない状況に置かれていた場合などである。アドレス設定のタイミングで、「無線インターフェイスを使っており、圏外だった場合」や、「イーサネットを使っており、2つのハブ間のリンクがうまく動いていなかった場合」に、こうしたことが起きる。
うまく設計されたホストは、インターフェイス設定時だけでなく、設定後、そのアドレスを使っている限り、どのタイミングで検出された競合であっても、正しく取り扱うことができるだろう。
3. Rate-limiting of address acquisition attempts in the case of
an excessive number of repeated conflicts (Section 2.1.).
3. 度を越して競合が繰り返される場合に、アドレス要求試行のペースを落とす機構 (2.1 節)
The utility of IPv4 Address Conflict Detection (ACD) is not limited to DHCP clients. No matter how an address was configured, whether via manual entry by a human user, via information received from a DHCP server, or via any other source of configuration information, detecting conflicts is useful. Upon detecting a conflict, the configuring agent should be notified of the error. In the case where the configuring agent is a human user, that notification may take the form of an error message on a screen, a Simple Network Management Protocol (SNMP) notification, or an error message sent via text message to a mobile phone. In the case of a DHCP server, that notification takes the form of a DHCP DECLINE message sent to the server. In the case of configuration by some other kind of software, that notification takes the form of an error indication to the software in question, to inform it that the address it selected is in conflict with some other host on the network. The configuring software may choose to cease network operation, or it may automatically select a new address so that the host may re-establish IP connectivity as soon as possible.
IPv4 アドレス競合検出 (ACD) の恩恵を受けるのは、DHCP クライアントだけではない。アドレスがどのように設定されたか (人間による手動入力。DHCP サーバから情報を得て。その他様々な設定情報源に基づいて) によらず、競合検出は有用である。
競合検出の途中に発生したエラーは、「 (アドレスの) 設定を行う主体」 (configuring agent) に通知されるべきである。主体が人間の場合、画面上のエラーメッセージ、SNMP 通知や、携帯電話への Text (訳注: 携帯メール) 等の形で通知されるだろう。主体が DHCP サーバの場合、DHCP DECLINE メッセージの形でサーバに送信される。
それ以外のソフトウェアの場合、「選択したアドレスが、ネットワーク内の他ホストと競合する」旨を含むエラーとなって通知される。当該ソフトウェアは、ネットワーク作業を取りやめるか、即座に別の新しいアドレスを使って IP 接続の再確立を試みるだろう。
Allocation of IPv4 Link-Local Addresses [RFC3927] can be thought of as a special case of this mechanism, where the configuring agent is a pseudo-random number generator, and the action it takes upon being notified of a conflict is to pick a different random number and try again. In fact, this is exactly how IPv4 Link-Local Addressing was implemented in Mac OS 9 back in 1998. If the DHCP client failed to get a response from any DHCP server, it would simply make up a fake response containing a random 169.254.x.x address. If the ARP module reported a conflict for that address, then the DHCP client would try again, making up a new random 169.254.x.x address as many times as was necessary until it succeeded. Implementing ACD as a standard feature of the networking stack has the side effect that it means that half the work for IPv4 Link-Local Addressing is already done.
IPv4 リンクローカルアドレスの割り当て [RFC3927] は、このメカニズムの特殊ケースと捉えることができる。 (アドレス) 設定主体は擬似乱数 (pseudo-random number) 生成機であり、アドレスが競合している旨の通知を外部から受けた際には、異なる乱数値を選びなおし、 (アドレス割り当てを) 再試行する。
(( (訳注: RFC3927 は、「IP アドレスの設定主体が存在しない状況で、ホストが自発的に、169.254.1.0 〜 169.254.254.255 の範囲からランダムに IP アドレスを選び、自分自身に割り当てる」という機能に関する仕様。この 2.1 節で、各ホストを、「ランダムな IP アドレスを選択するための乱数生成機」と表現している) ))
この IPv4 リンクローカルアドレス割り当て方式は、実は 1998 年に Mac OS 9 に実装されたものと全く同一である。DHCP クライアントは、DHCP サーバから応答がない状況に置かれると、ランダムな 169.254.x.x アドレスを含む「偽の応答」を生成する。もし、 (そのクライアントの) ARP モジュールから、「このアドレスが誰かと競合している」と報告があった場合、別な 169.254.x.x アドレスを再度ランダムに生成し、以下、成功するまで繰り返す。
ACD を、ネットワークスタックの標準機能として組み込めば、一石二鳥で、IPv4 リンクローカルアドレス割り当て機能についても、半分くらい実装してしまえることになる。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文書中の、"MUST (必ず守ることの強制) "、"MUST NOT (必ず避けることの強制) "、"REQUIRED (必ず守ることの強制) "、"SHALL (必ず守ることの強制) "、"SHALL NOT (必ず避けることの強制) "、"SHOULD (守ることの要請) "、"SHOULD NOT (避けることの要請) "、"RECOMMENDED (守ることの要請) "、"MAY (可能であることの示唆) "、"OPTIONAL (可能であることの示唆) "は、「RFC における "要求レベル定義語"」[RFC2119]のとおり解釈される。
Wherever this document uses the term 'sender IP address' or 'target IP address' in the context of an ARP packet, it is referring to the fields of the ARP packet identified in the ARP specification [RFC826] as '#ar$spa#' (Sender Protocol Address) and '#ar$tpa#' (Target Protocol Address), respectively. For the usage of ARP described in this document, each of these fields always contains an IPv4 address.
本文書中の、ARP パケットに言及している箇所で "sender IP address (送信元 IP アドレス) "、"target IP address (送信先 IP アドレス) " とある場合、それぞれ、ARP 仕様 [RFC826] 定義中の "ar$spa (Sender Protocol Address) " と "ar$tpa (Target Protocol Address) " を表すものとする。本文書中で、ARP の用法に言及している箇所では、これら2つのフィールドに、常に、IPv4 アドレスがセットされているものとする。
In this document, the term 'ARP Probe' is used to refer to an ARP
Request packet, broadcast on the local link, with an all-zero 'sender
IP address'. The 'sender hardware address' MUST contain the hardware
address of the interface sending the packet. The 'sender IP address'
field MUST be set to all zeroes, to avoid polluting ARP caches in
other hosts on the same link in the case where the address turns out
to be already in use by another host. The 'target hardware address'
field is ignored and SHOULD be set to all zeroes. The 'target IP
address' field MUST be set to the address being probed. An ARP Probe
conveys both a question ("Is anyone using this address?") and an
implied statement ("This is the address I hope to use.").
本文書中の "ARP Probe (ARP 探知) " という単語は、"sender IP address (送信元 IP アドレス) " がすべて0(ゼロ)の、ローカルリンクに対する ARP リクエストパケットのブロードキャストを指す。
"sender hardware address (送信元ハードウェアアドレス) " は、送信元インターフェイスのハードウェアアドレスを含まなければならない(MUST)。
"sender IP address" のすべての値には、0(ゼロ)がセットされていなければならない(MUST)。もし、セットしたアドレスを他ホストが既に使用していた場合、 (同一ローカルリンク内のホストの) ARP キャッシュを汚してしまうからである。
(訳者注: その瞬間たまたま、当該 IP アドレスに対応する MAC アドレスを ARP で問い合わせているホストが他に居た場合、誤った情報が、そのホストの ARP テーブルに登録されてしまうこととなる。ARP スプーフィング状態!)
"target hardware address (送信先ハードウェアアドレス) " は無視されるが、すべての値には、0(ゼロ)がセットされているべきである(SHOULD)。
"target IP address (送信先 IP アドレス) " には、探知する IP アドレスがセットされていなければならない(MUST)。
In this document, the term 'ARP Announcement' is used to refer to an ARP Request packet, broadcast on the local link, identical to the ARP Probe described above, except that both the sender and target IP address fields contain the IP address being announced. It conveys a stronger statement than an ARP Probe, namely, "This is the address I am now using."
本文書中の "ARP Announcement (ARP 通知) " という単語は、上記 ARP Probe (ARP 探知) と同一の ARP リクエストパケットのうち、ローカルリンク上にブロードキャストされるものを指す。ただし、sender IP address (送信元 IP アドレス) と target IP address (送信先 IP アドレス) フィールドには、通知したい IP アドレスがセットされる点が異なる。この機構によって、ARP Probe (ARP 通知) よりも強いニュアンスで宣言を行うことができる。すなわち、「このアドレスは、いま私が使用中です」という宣言である。
The following timing constants used in this protocol are referenced in Section 2, which describes the operation of the protocol in detail. (Note that the values listed here are fixed constants; they are not intended to be modifiable by implementers, operators, or end users. These constants are given symbolic names here to facilitate the writing of future standards that may want to reference this document with different values for these named constants; however, at the present time no such future standards exist.)
本プロトコル中で使用される、以下の「タイミング関連の定数」について、プロトコルの詳細動作を説明する2章で述べる。 (ここで列挙する値は、不変の定数であり、実装者、運用者、エンドユーザに変更されることは想定していない。各定数にはシンボル名が付与されており、将来、本文書の定義とは異なる値とみなして参照するような規格書も、容易に作成できるようになっている。しかし現時点では、そのような規格書は存在しない)
PROBE_WAIT 1 second (initial random delay) PROBE_NUM 3 (number of probe packets) PROBE_MIN 1 second (minimum delay until repeated probe) PROBE_MAX 2 seconds (maximum delay until repeated probe) ANNOUNCE_WAIT 2 seconds (delay before announcing) ANNOUNCE_NUM 2 (number of Announcement packets) ANNOUNCE_INTERVAL 2 seconds (time between Announcement packets) MAX_CONFLICTS 10 (max conflicts before rate-limiting) RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) DEFEND_INTERVAL 10 seconds (minimum interval between defensive ARPs)
PROBE_WAIT 探知_待ち 1秒 (最初のランダムな待ち時間) PROBE_NUM 探知_回数 3 (探知パケットの数) PROBE_MIN 探知_最小 1秒 (探知繰り返しの最小待ち時間) PROBE_MAX 探知_最大 2秒 (探知繰り返しの最大待ち時間) ANNOUNCE_WAIT 通知_待ち 2秒 (通知前の待ち時間) ANNOUNCE_NUM 通知_回数 2 (通知パケットの数) ANNOUNCE_INTERVAL 通知_間隔 2秒 (通知パケットの送信間隔) MAX_CONFLICTS 最大_競合 10回 (この回数だけ競合が繰り返されたら、アドレス取得の試行ペースを落とす) RATE_LIMIT_INTERVAL 制限_間隔 60秒 (連続したアドレス取得試行の間隔) DEFEND_INTERVAL 守備_間隔 10秒 (守備 ARP の最小間隔)
This document does not modify any of the protocol rules in RFC 826. It does not modify the packet format, or the meaning of any of the fields. The existing rules for "Packet Generation" and "Packet Reception" still apply exactly as specified in RFC 826.
本文書は、RFC 826 の規則に変更を加えることはない。パケットのフォーマット、各フィールドの意味も変更されない。従来の規則である "Packet Generation (パケット生成) " および "Packet Reception (パケット受信) " は、依然、RFC 826 の定義どおりに有効である。
This document expands on RFC 826 by specifying:
本文書は、以下の定義により RFC 826 を拡張する。
(1) that a specific ARP Request should be generated when an interface
is configured, to discover if the address is already in use, and
(1) アドレスが既に使用中か確認するために、インターフェイスの設定時、ある特定の ARP 要求を生成するべきであり、かつ
(2) an additional trivial test that should be performed on each
received ARP packet, to facilitate passive ongoing conflict
detection. This additional test creates no additional packet
overhead on the network (no additional packets are sent) and
negligible additional CPU burden on hosts, since every host
implementing ARP is *already* required to process every received
ARP packet according to the Packet Reception rules specified in
RFC 826. These rules already include checking to see if the
'sender IP address' of the ARP packet appears in any of the
entries in the host's ARP cache; the additional test is simply to
check to see if the 'sender IP address' is the host's *own* IP
address, potentially as little as a single additional machine
instruction on many architectures.
(2) 受動的な競合検出 (のうち、インターフェイス使用中に行われるもの) を容易にするため、ARP パケット受信の都度、簡単なテストを追加実施するべきである。このテストは、パケットのオーバーヘッドを増やしたりはせず (別途パケットが送出される訳ではない) 、ホストの CPU にかかる負荷も微々たるものである。なぜなら ARP を実装するすべてのホストは、既に RFC 826 の Packet Reception (パケット受信) ルールに基づき、全 ARP パケットを精査するようになっているからである。既にこのルールには、「ホストの ARP キャッシュに、"sender IP address (送信元 IP アドレス) "が含まれているか」のチェックが盛り込まれており、追加テストは、単に「"sender IP address (送信元 IP アドレス) "が、ホスト自身の IP アドレスと一致するか」を見るだけである。大概のアーキテクチャで、たかだか1命令も追加すれば済む話だろう。
As already specified in RFC 826, an ARP Request packet serves two functions, an assertion and a question:
RFC 826 で既に規定されているように、ARP 要求パケットは、二つの役目を帯びている。主張、および問い合わせである。
* Assertion:
The fields '#ar$sha#' (Sender Hardware Address) and '#ar$spa#' (Sender
Protocol Address) together serve as an assertion of a fact: that
the stated Protocol Address is mapped to the stated Hardware
Address.
'ar$sha' (送信元ハードウェアアドレス) と 'ar$spa' (送信元プロトコルアドレス)の組み合わせで、次の事実を主張する: 「このプロトコルアドレスが、このハードウェアアドレスに割り当てられる」
* Question:
The fields '#ar$tha#' (Target Hardware Address, zero) and '#ar$tpa#'
(Target Protocol Address) serve as a question, asking, for the
stated Protocol Address, to which Hardware Address it is mapped.
'ar$tha' (送信先ハードウェアアドレス, 値ゼロ) と 'ar$tpa' (送信先プロトコルアドレス) の組み合わせで、次の内容を問い合わせる: 「このプロトコルアドレスに割り当てられているハードウェアアドレスは何か?」
This document clarifies what it means to have one without the other.
本文書では、この説明の曖昧な点を取り除き、真に意味するところを明らかにしたい。
Some readers pointed out that it is probably impossible to ask any
truly pure question; asking any question necessarily invites
speculation about why the interrogator wants to know the answer.
Just as someone pointing to an empty seat and asking, "Is anyone
sitting here?" implies an unspoken "... because if not then I will,"
the same is true here. An ARP Probe with an all-zero 'sender IP
address' may ostensibly be merely asking an innocent question ("Is
anyone using this address?"), but an intelligent implementation that
knows how IPv4 Address Conflict Detection works should be able to
recognize this question as the precursor to claiming the address.
「純粋に質問だけを行うこと」は恐らく不可能だろう、と何名かの読者から指摘が寄せられている。質問という行為は、必然的に「質問者は、なぜ答えを知りたがっているのだろう?」という推測を生むからである。例えば、空いている席を見つけたときに「ここ誰か座ってる?」と質問すれば、「…もし誰も座ってないなら座りたいんだけど」と暗喩することになる。上記の状況においても同様である。'sender IP address (送信元 IP アドレス) ' の値がすべてゼロの ARP Probe (ARP 探知) は、一見、まったく無意味の質問 ──「誰かこのアドレスを使ってますか?」──であるが、IPv4 アドレス競合検出の仕組みを知る、察しのいい実装なら、これが、アドレス要求の前振りだと気づくに違いない。
Consequently, if that implementation is also, at that exact moment, in the process of asking the very same question, it should recognize that they can't both sit in the same seat, so it would be prudent to ask about some other seat.
更に、もしその実装 (察しのいい実装) が、ちょうど同じ質問をしようとしている所だったら、「同じ席には座れないから、念のため、別な席を探してみよう」という事にも気づくであろう。
In some applications of IPv4 Address Conflict Detection (ACD), it may be advantageous to deliver ARP Replies using broadcast instead of unicast because this allows address conflicts to be detected sooner than might otherwise happen. For example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] uses ACD exactly as specified here, but additionally specifies that ARP Replies should be sent using broadcast, because in that context the trade-off of increased broadcast traffic in exchange for improved reliability and fault- tolerance was deemed to be an appropriate one. There may be other future specifications where the same trade-off is appropriate. Additional details are given in Section 2.6, "Broadcast ARP Replies".
IPv4 アドレス競合検出 (ACD) を実装するアプリケーションは、ARP 応答 (ARP Reply) をユニキャスト (単一ホストへの送信) でなくブロードキャストで送信した方がよい。それは、将来起こりうるアドレス競合を、可能な限り前もって検知するのに好都合だからである。
例えば、"IPv4 リンクローカルアドレスの動的設定" [RFC3927] では、正にこのような意図で ACD を用いている。そして同時に、この状況においては、ブロードキャストによるトラフィック増加に見合うだけの信頼性・冗長性の向上が充分に期待できることから、ARP 応答 (ARP Reply) に関しても、ブロードキャストで送信されるべきと規定している。今後も、同様のトレードオフを許容する仕様がいろいろ登場するだろう。
その他の詳細は、2.6章 "ブロードキャスト ARP 応答 (ARP Replies) " を参照のこと。
RFC 826 implies that replies to ARP Requests are usually delivered using unicast, but it is also acceptable to deliver ARP Replies using broadcast. The Packet Reception rules in RFC 826 specify that the content of the '#ar$spa#' field should be processed *before* examining the 'ar$op' field, so any host that correctly implements the Packet Reception algorithm specified in RFC 826 will correctly handle ARP Replies delivered via link-layer broadcast.
RFC826 では、通常 ARP 要求 (ARP Requests) がユニキャストで送信されることを示唆しているが、ARP 応答 (ARP Replies) がブロードキャストで返されることもまた許している。
RFC826 におけるパケット受信ルール(Packet Reception rule)では、'ar$spa' (送信元プロトコルアドレス)フィールドの内容は、'ar$op' (オペレーションコード)フィールドの精査前に処理しなければならないと決まっており、従って RFC826 が規定するパケット受信アルゴリズム (Packet Reception algorithm) を実装するホストは、データリンク層のブロードキャストで配送される ARP 応答 (ARP Replies) を正しく処理できることが期待される。
This specification applies to all IEEE 802 Local Area Networks (LANs) [802], including Ethernet [802.3], Token-Ring [802.5], and IEEE 802.11 wireless LANs [802.11], as well as to other link-layer technologies that operate at data rates of at least 1 Mb/s, have a round-trip latency of at most one second, and use ARP [RFC826] to map from IP addresses to link-layer hardware addresses. Wherever this document uses the term "IEEE 802", the text applies equally to any of these network technologies.
本仕様は、あらゆるタイプの IEEE 802 ローカルエリアネットワーク (LAN) に適用できる。イーサネット (802.3) 、トークンリング (802.5) 、IEEE 802.11 無線 LAN (802.11) などが該当するが、「1Mbit/s 以上の転送速度」と「1秒以下のターンアラウンドタイム」を持ち、かつ「データリンク層ハードウェアアドレスと IP アドレスのマッピングに ARP[RFC826]を使っている」任意のデータリンク技術もこれに含まれる。
本文書中の "IEEE 802" という語は、これらのネットワーク技術仕様すべてに等しく当てはまるものとする。
Link-layer technologies that support ARP but operate at rates below 1 Mb/s or latencies above one second will still work correctly with this protocol, but more often may have to handle late conflicts detected after the Probing phase has completed. On these kinds of links, it may be desirable to specify different values for the following parameters:
ARP をサポートするが転送速度が 1Mbit/s 未満であったり、レイテンシが 1秒を超えるデータリンクであっても、本プロトコルは、依然正しく動作すると思われる。ただし、探知 (Probe) フェーズが終わった後に遅れてやってくる競合検出の面倒を、しばしば見なければならないだろう。
このようなデータリンクでは、以下のパラメータについて、異なる値を採用することが望ましい。
(a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval
between, ARP Probes, explained in Section 2.1.
(a) PROBE_NUM, PROBE_MIN, PROBE_MAX ── ARP 探知 (ARP Probe) の回数と間隔 (2.1 節)
(b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval
between, ARP Announcements, explained in Section 2.3.
(b) ANNOUNCE_NUM, ANNOUNCE_INTERVAL ── ARP 通知 (ARP Announcement) の回数と間隔 (2.3 節)
(c) RATE_LIMIT_INTERVAL and MAX_CONFLICTS, controlling the maximum
rate at which address claiming may be attempted, explained in
Section 2.1.
(c) RATE_LIMIT_INTERVAL, MAX_CONFLICTS ── アドレス要求を行うペースの調整 (2.1 節)
(d) DEFEND_INTERVAL, the time interval between conflicting ARPs below
which a host MUST NOT attempt to defend its address, explained in
Section 2.4.
(d) DEFEND_INTERVAL ── 競合する ARP に対する抗告の間隔下限。ホストは、これより短い間隔で抗告を発してはならない(MUST NOT) (2.4 節)
Link-layer technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, implementing Address Conflict Detection for such networks is outside the scope of this document.
ARP をサポートしないデータリンクの場合、特定の IP アドレスが使用中かを確認する何らかの手段を、他に有しているだろう。しかし、そのようなネットワークに対する (本文書で述べる) アドレス競合検出の実装は、本書の記述の対象外である。
For the protocol specified in this document to be effective, it is not necessary that all hosts on the link implement it. For a given host implementing this specification to be protected against accidental address conflicts, all that is required is that the peers on the same link correctly implement the ARP protocol as given in RFC 826. To be specific, when a peer host receives an ARP Request where the Target Protocol Address of the ARP Request matches (one of) that host's IP address(es) configured on that interface, then as long as it properly responds with a correctly-formatted ARP Reply, the querying host will be able to detect that the address is already in use.
本文書で規定するプロトコルを実際に使うにあたり、データリンク上の全ホストがこれを実装する必要はない。アドレス競合を防ぐために、あるホストに求められる要件は、「通信相手が、RFC826 で規定される ARP を正しく実装している」の一点のみである。
具体的には、通信相手が、「送信先プロトコルアドレス(Target Protocol Address)が自身インターフェイスに設定されたいずれかの IP アドレスと一致する ARP 要求 (ARP Request) 」を受け取った際、アドレスが既に使用中であることを伝えるために、正しいフォーマットの ARP 応答 (ARP Reply) を適切に返してくれさえすれば良い。
The specifications in this document allow hosts to detect conflicts between two hosts using the same address on the same physical link. ACD does not detect conflicts between two hosts using the same address on different physical links, and indeed it should not. For example, the address 10.0.0.1 [RFC1918] is in use by countless devices on countless private networks throughout the world, and this is not a conflict, because they are on different links. It would only be a conflict if two such devices were to be connected to the same link, and when this happens (as it sometimes does), this is a perfect example of a situation where ACD is extremely useful to detect and report (and/or automatically correct) this error.
本文書で述べる各仕様は、「同一の物理リンク上で、同一のアドレスを使っている2つのホストの競合」を、ホストが検出できるようにするためのものである。
ACD は、「異なる物理リンク上で、同一のアドレスを使っている2つのホストの競合」は検出しないし、検出すべきでない。例えば、10.0.0.1 [RFC1918] というアドレスは、世界中の無数のネットワーク上の無数の機器が使っているが、それらは全て、違うデータリンクに属しているので、これは「競合」ではない。
「競合」と呼べるのは、これらの機器が同一のデータリンクに接続された場合だけである。そして、これが起きた状態(往々にして起きる)は、ACD が問題の検出と報告 (、加えて自動修正) に極めて役立つ、典型的なシチュエーションである。
For the purposes of this document, a set of hosts is considered to be "on the same link" if:
本文書では便宜上、あるホスト群は、以下の条件が成立する場合、「同一のリンクに置かれている」と仮定する。
- when any host, A, from that set, sends a packet to any other host,
B, in that set, using unicast, multicast, or broadcast, the entire
link-layer packet payload arrives unmodified, and
- a broadcast sent over that link by any host from that set of hosts
can be received by every other host in that set.
The link-layer *header* may be modified, such as in Token Ring Source Routing [802.5], but not the link-layer *payload*. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload, then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs, or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the TTL or otherwise modifies the IP header.
データリンク層に係る「ヘッダ」は、トークンリング・ソースルーティング[802.5]のように変更されても問題ないが、「ペイロード」は変更されない。とりわけ、パケットを転送する機器が IP ヘッダや IP ペイロードに変更を加える場合、そのパケットは、同一リンク上にあるとは見なされない。
パケットは、リピータ、ブリッジ、ハブ、スイッチなどを経由しても、本文書の意図における「同一データリンク」にあるものとして扱ってよいが、IP ルータのように、TTL を減らしたり、IP ヘッダを書き換えたりする機器を経由した場合、そうとは認められない訳である。
Where this document uses the term "host", it applies equally to
interfaces on routers or other multi-homed hosts, regardless of
whether the host/router is currently forwarding packets. In many
cases a router will be critical network infrastructure with an IP
address that is locally well known and assumed to be relatively
constant. For example, the address of the default router is one of
the parameters that a DHCP server typically communicates to its
clients, and (at least until mechanisms like DHCP Reconfigure
[RFC3203] become widely implemented) there isn't any practical way
for the DHCP server to inform clients if that address changes.
Consequently, for such devices, handling conflicts by picking a new
IP address is not a good option. In those cases, option (c) in
Section 2.4 ("Ongoing Address Conflict Detection and Address
Defense") applies.
本文書中の "ホスト" という語は、ルータ、その他の複数のネットワークアドレスをホストするインターフェイスを等しく表す。そのホスト/インターフェイスが、いま現在パケットの転送に携わっているか否かは関係ない。
多くの状況で、ルータはクリティカルなインフラ機器であり、ローカルに周知の行き届いた比較的静的な IP アドレスを割り当てられている。例えば、デフォルト・ルータ (ゲートウェイ) のアドレスは、DHCP サーバがクライアントと通信を行うのに必要なパラメータの一つで、 (少なくとも DHCP 再構成[RFC3203] のような実装が一般的となるまでは、) もしそれに変更が加えられると、DHCP サーバは、クライアントに情報を提供する具体的手段を失ってしまう。
従って、ルータのような機器にとって、「新しい IP アドレスを使う」という選択肢は、アドレス競合を避ける手段として適切でない。この場合、2.4 節 (実行後のアドレス競合・抗告) の選択肢(c)を用いる。
However, even when a device is manually configured with a fixed address, having some other device on the network claiming to have the same IP address will pollute peer ARP caches and prevent reliable communication, so it is still helpful to inform the operator. If a conflict is detected at the time the operator sets the fixed manual address, then it is helpful to inform the operator immediately; if a conflict is detected subsequently, it is helpful to inform the operator via some appropriate asynchronous communication channel. Even though reliable communication via the conflicted address is not possible, it may still be possible to inform the operator via some other communication channel that is still operating, such as via some other interface on the router, via a dynamic IPv4 link-local address, via a working IPv6 address, or even via some completely different non-IP technology such as a locally-attached screen or serial console.
しかしながら、固定アドレスを手動で設定した場合でも、同一ネットワーク上に、同じ IP アドレスを要求する他の機器が存在すると、ノードの ARP キャッシュが汚染され、通信の信頼性が損なわれることがあるので、 (競合を) オペレータに通知することには意味がある。
アドレス競合を検出したタイミングが、オペレータが固定アドレスを手動設定した瞬間だった場合、即座に通知することが重要である。設定後に検出した場合、別な非同期の通信チャネルを使って伝えるのがよい。
アドレスが競合しているチャネルでの通信が期待できない場合でも、まだ生きているその他の通信チャネルで、コミュニケーションできる可能性は残されている。例えば、ルータ上のその他のインターフェイス、動的 IPv4 リンクローカルアドレス、動作中の IPv6 アドレスなどである。もしくは非 IP なテクノロジーである、ローカル接続のスクリーンや、シリアルコンソールなども使えるかもしれない。
This section describes initial probing to safely determine whether an address is already in use, announcing the chosen address, ongoing conflict checking, and optional use of broadcast ARP Replies to provide faster conflict detection.
本節では、
について述べる。
Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification MUST test to see if the address is already in use, by broadcasting ARP Probe packets. This also applies when a network interface transitions from an inactive to an active state, when a computer awakes from sleep, when a link-state change signals that an Ethernet cable has been connected, when an 802.11 wireless interface associates with a new base station, or when any other change in connectivity occurs where a host becomes actively connected to a logical link.
(手動設定、DHCPなど、設定手段にかかわらず、) 本仕様を実装するホストは、ある IPv4 アドレスを使う場合、あらかじめ ARP 探知 (ARP Probe) パケットをブロードキャストして、そのアドレスが既に使われていないか確認しなければならない(MUST)。
これは、以下の状況でも同様に当てはまる。
A host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.4.
当然のことながら、ホストはこのチェックを周期的に繰り返したりしてはいけない(MUST NOT)。ネットワーク帯域の浪費であり、そもそもホストは、2.4 節で述べる「受動的な競合検出」を行う能力を持っているのだから、不要なことである。
A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the 'sender hardware address' field of the ARP Request with the hardware address of the interface through which it is sending the packet. The 'sender IP address' field MUST be set to all zeroes; this is to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Request constructed this way, with an all-zero 'sender IP address', is referred to as an 'ARP Probe'.
ホストは、希望のアドレスに対する ARP 要求 (ARP Request) をブロードキャストすることで、そのアドレスが既に使用中かどうかを探知する。
クライアント(ARP 要求の送信元)は、ARP 要求 (ARP Request) の 'sender hardware address (送信元ハードウェアアドレス) ' フィールドに、ARP の送出を行うインターフェイスのハードウェアアドレスを設定しなければならない(MUST)。
'sender IP address (送信元 IP アドレス) ' フィールドには、すべてゼロを設定しなければならない(MUST)。 (適当に決めた) IP アドレスを、万一、他のホストが使っていると、同一リンク上のホストの ARP キャッシュが汚染されてしまうからである。
'target hardware address (送信先ハードウェアアドレス) ' フィールドは無視されるが、すべてゼロに設定されるべきである(SHOULD)。
'target IP address (送信先 IP アドレス) ' フィールドには、探知したい IP アドレスを設定しなければならない(MUST)。
'sender IP address (送信元 IP アドレス) ' を、このようにすべてゼロに設定した ARP 要求 (ARP Request) は、ARP 探知 (ARP Probe) と呼ばれる。
When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to PROBE_WAIT seconds, and should then send PROBE_NUM probe packets, each of these probe packets spaced randomly and uniformly, PROBE_MIN to PROBE_MAX seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously.
探知の準備が整ったら、まずホストは、0〜PROBE_WAIT の範囲から偏り無く選んだランダムな秒数だけ、待機しなければならない。次いで、PROBE_NUM 個の探知パケットを送出するが、個々の送出の間に、PROBE_MIN 〜 PROBE_MAXの範囲から偏り無く選んだランダムな秒数だけ、待ち時間を設けなければならない。
初期探知にランダムな遅延を設けることで、多数のホストが同時に電源を投入された時に、一斉に探知パケットを投げるような事態を招かずに済む。
If during this period, from the beginning of the probing process until ANNOUNCE_WAIT seconds after the last probe packet is sent, the host receives any ARP packet (Request *or* Reply) on the interface where the probe is being performed, where the packet's 'sender IP address' is the address being probed for, then the host MUST treat this address as being in use by some other host, and should indicate to the configuring agent (human operator, DHCP server, etc.) that the proposed address is not acceptable.
もし、「探知プロセスの開始」〜「最後の探知パケット送出から ANNOUNCE_WAIT 秒後」の間に、探知を行ったインターフェイスに、探知するアドレスが 'sender IP address (送信元 IP アドレス) ' に設定された ARP パケット (Request または Reply) が届いた場合、ホストは、この IP アドレスを他のホストが使用中とみなさなければならず(MUST)、アドレス設定者(人間のオペレータや DHCP サーバなど)に、提案されたアドレスが受け入れられない旨を通知するべきである。
In addition, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces, then the host SHOULD similarly treat this as an address conflict and signal an error to the configuring agent as above. This can occur if two (or more) hosts have, for whatever reason, been inadvertently configured with the same address, and both are simultaneously in the process of probing that address to see if it can safely be used.
また、探知するアドレスが 'target IP address (送信先 IP アドレス) ' に設定され、かつ 'sender hardware address (送信元ハードウェアアドレス) ' が、そのホストのどのインターフェイスのハードウェアアドレスとも一致しない ARP Probe (ARP 探知) が届いた場合も、ホストは同様に、これをアドレス競合とみなし、上記アドレス設定者に、エラーを送るべきである(SHOULD)。
このような状況は、二台(またはそれ以上)のホストが、何らかの理由でうっかり同じアドレスを使うように設定され、両方が同時に、そのアドレスは使っても安全かどうか確認した場合に起こりうる。
NOTE: The check that the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces is important. Some kinds of Ethernet hub (often called a "buffered repeater") and many wireless access points may "rebroadcast" any received broadcast packets to all recipients, including the original sender itself. For this reason, the precaution described above is necessary to ensure that a host is not confused when it sees its own ARP packets echoed back.
注意: 'sender hardware address (送信元ハードウェアアドレス) ' が、そのホストのどのインターフェイスのハードウェアアドレスとも一致しないことの確認は、重要である。
ある種のイーサネットハブ(しばしば「バッファド・リピータ」と呼ばれる)や無線アクセスポイントは、受け取ったブロードキャストパケットを、元々の送信者を含むすべての宛先に「再ブロードキャスト」することがある。このような事情があるので、(元々の送信者である)ホストが、自分が送ったはずの ARP パケットが撥ね返ってくるのを見て混乱しないよう、上記のような注意が必要なのである。
A host implementing this specification MUST take precautions to limit the rate at which it probes for new candidate addresses: if the host experiences MAX_CONFLICTS or more address conflicts on a given interface, then the host MUST limit the rate at which it probes for new addresses on this interface to no more than one attempted new address per RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP storms in pathological failure cases, such as a defective DHCP server that repeatedly assigns the same address to every host that asks for one. This rate-limiting rule applies not only to conflicts experienced during the initial probing phase, but also to conflicts experienced later, as described in Section 2.4 "Ongoing Address Conflict Detection and Address Defense".
本仕様を実装するホストは、新しい IP アドレス候補の探知を行うペースに、注意を払わなければならない(MUST)。もし、あるインターフェイス上で、MAX_CONFLICTS 回以上のアドレス競合に遭遇した場合、ホストは、そのインターフェイスからの新アドレス探知のペースを、RATE_LIMIT_INTERVAL に1度以下に制限しなければならない(MUST)。これは、全ホストに同じアドレスを繰り返しオファーし続ける「問題ある DHCP サーバ」がいるような、病的におかしくなった状況で、壊滅的な ARP の嵐が起きないようにするためである。
この上限制定のしくみは、探知フェーズで起きる競合だけでなく、2.4 節「実行後のアドレス競合・抗告」で述べる、後になって起きる競合にも適用される。
If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP Probe no conflicting ARP Reply or ARP Probe has been received, then the host has successfully determined that the desired address may be used safely.
最後の ARP 探知 (ARP Probe) を送って ANNOUNCE_WAIT 秒経過しても、ARP 応答 (ARP Reply) やARP 探知 (ARP Probe) が一つも帰ってこなければ、晴れて、希望するアドレスを使用しても安全であることが確定する。
Network technologies may emerge for which shorter delays are appropriate than those required by this document. A subsequent IETF publication may be produced providing guidelines for different values for PROBE_WAIT, PROBE_NUM, PROBE_MIN, and PROBE_MAX on those technologies.
本文書での要件よりも遅延時間が短いほうがよいネットワーク技術が、将来出現するであろう。これらの技術に向いた PROBE_WAIT, PROBE_NUM, PROBE_MIN, PROBE_MAX の別な設定値については、今後 IETF から、逐次ガイドラインが公表される予定である。
If the situation arises where different hosts on a link are using different timing parameters, this does not cause any problems. This protocol is not dependent on all hosts on a link implementing the same version of the protocol; indeed, this protocol is not dependent on all hosts on a link implementing the protocol at all. All that is required is that all hosts implement ARP as specified in RFC 826, and correctly answer ARP Requests they receive. In the situation where different hosts are using different timing parameters, all that will happen is that some hosts will configure their interfaces more quickly than others. In the unlikely event that an address conflict is not detected during the address probing phase, the conflict will still be detected by the Ongoing Address Conflict Detection described below in Section 2.4.
同一リンク上のホストが、それぞれ異なるタイミング・パラメータを使うような状況が発生しても、それは問題とはならない。本プロトコルは、「同一リンク上で、同一バージョンの同一プロトコルを使う全ホスト」に対し、独立して稼動するが、実のところは、「同一リンク上で、同一プロトコルを使う全ホスト」に対しても、まったく独立して稼動する。唯一必須なのは、全ホストが RFC826 で規定されるとおり、ARP 要求 (ARP Request) に正しく応答することだけである。複数のホストが違うタイミング・パラメータを使ったら何が起きるかというと、何台かのホストが、他より早くインターフェイスの設定を完了するだけである。
万一、アドレス探知フェーズで競合が検出できなかった場合でも、下記 2.4 節で述べる「実行後のアドレス競合・抗告」によって、競合は依然、検出可能である。
Having probed to determine that a desired address may be used safely, a host implementing this specification MUST then announce that it is commencing to use this address by broadcasting ANNOUNCE_NUM ARP Announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP Announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host's newly selected IPv4 address. The purpose of these ARP Announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address. The host may begin legitimately using the IP address immediately after sending the first of the two ARP Announcements; the sending of the second ARP Announcement may be completed asynchronously, concurrent with other networking operations the host may wish to perform.
希望するアドレスが安全に使えることを結論付けるための探知を行った後、本仕様を実装するホストは、ARP 通知 (ARP Announcement) を、ANNOUNCE_NUM 回、各々 ANNOUNCE_INTERVAL 秒のインターバルでブロードキャストすることで、当該アドレスの使用開始を宣言しなければならない(MUST)。
ARP 通知 (ARP Announcement) は、送信元・送信先アドレスが新しく使う IPv4 アドレスに設定されるという以外、ARP 探知 (ARP Probe) とまったく同一である。
ARP 通知 (ARP Announcement) の目的は、以前ほかのホストがそのアドレスを使っていた頃の古い ARP キャッシュが、リンク上のホストに保持されないようにすることである。ホストは、2の ARP 通知 (ARP Announcement) のうち1つめの送出後、速やかにその IP アドレスを使い始めることができる。2つめの ARP 通知 (ARP Announcement) は、元来ホストが行いたいと考えていたネットワークオペレーションと非同期に行ってもよいし、そのネットワークオペレーション自体を2つめの ARP Announcement と位置づけてもよい。
Address Conflict Detection is not limited to only the time of initial interface configuration, when a host is sending ARP Probes. Address Conflict Detection is an ongoing process that is in effect for as long as a host is using an address. At any time, if a host receives an ARP packet (Request *or* Reply) where the 'sender IP address' is (one of) the host's own IP address(es) configured on that interface, but the 'sender hardware address' does not match any of the host's own interface addresses, then this is a conflicting ARP packet, indicating some other host also thinks it is validly using this address. To resolve the address conflict, a host MUST respond to a conflicting ARP packet as described in either (a), (b), or (c) below:
アドレス競合検出は、インターフェイスの初期設定時、すなわちホストが ARP 探知 (ARP Probe) を送出する時のためだけではない。ホストがそのアドレスを使っている間ずっと、有用な技術である。
もしホストが、「'sender IP address (送信元 IP アドレス) ' が自身のいずれかのインターフェイスに設定されている IP アドレスと一致し、かつ 'sender hardware address (送信元ハードウェアアドレス) ' が自身のインターフェイスと一致しない ARP パケット (要求または応答)」を受信したら、それは ARP パケットの競合であり、他にも、このアドレスを合法的に使えていると思っているホストが居ることを示している。
このアドレス競合を解消するために、ホストは、競合する ARP パケットに対し、以下 (a)(b)(c)いずれかで述べる手段で対処しなればならない(MUST)。
(a) Upon receiving a conflicting ARP packet, a host MAY elect to
immediately cease using the address, and signal an error to the
configuring agent as described above.
(a) 競合する ARP パケットを受信したら、ホストはそのアドレスの使用を即刻中止し、以前述べたとおり、設定主体にエラーを通知してもよい(MAY)。
(b) If a host currently has active TCP connections or other reasons
to prefer to keep the same IPv4 address, and it has not seen any
other conflicting ARP packets within the last DEFEND_INTERVAL
seconds, then it MAY elect to attempt to defend its address by
recording the time that the conflicting ARP packet was received,
and then broadcasting one single ARP Announcement, giving its own
IP and hardware addresses as the sender addresses of the ARP,
with the 'target IP address' set to its own IP address, and the
'target hardware address' set to all zeroes. Having done this,
the host can then continue to use the address normally without
any further special action. However, if this is not the first
conflicting ARP packet the host has seen, and the time recorded
for the previous conflicting ARP packet is recent, within
DEFEND_INTERVAL seconds, then the host MUST immediately cease
using this address and signal an error to the configuring agent
as described above. This is necessary to ensure that two hosts
do not get stuck in an endless loop with both hosts trying to
defend the same address.
(b) アクティブな TCP 接続が存在する等、同じアドレスを保持したい理由があり、かつ過去 DEFEND_INTERVAL 秒以内に、競合する ARP パケットが再び現れなかった場合、ホストは、そのパケットの受信時刻を記録した上で、当該アドレスの継続保持を試みてもよく(MAY)、その時は、「ARP の送信者アドレス部に、自身の IP アドレスとハードウェアアドレス」「'target IP address (送信先 IP アドレス) ' に、自身の IP アドレス」「'target hardware address (送信先ハードウェアアドレス) ' に、すべてゼロ」をセットした ARP 通知 (ARP Announcement) を、一回だけブロードキャストする。これによって、ホストは、それ以後特に何も行わなくとも、そのアドレスを普通に使い続けることができる。
ただし、この ARP パケット競合が、初めて起きた競合でなく、かつ、前回の発生がつい最近 ── DEFEND_INTERVAL 秒以内だった場合、ホストはそのアドレスの使用を即刻中止し、以前述べたとおり、設定主体にエラーを通知しなければならない(MUST)。これは二台のホストが、あるアドレスの保持を互いに延々と試みて、無限ループに陥ることを回避するために必要である。
(c) If a host has been configured such that it should not give up its
address under any circumstances (perhaps because it is the kind
of device that needs to have a well-known stable IP address, such
as a link's default router or a DNS server) then it MAY elect to
defend its address indefinitely. If such a host receives a
conflicting ARP packet, then it should take appropriate steps to
log useful information such as source Ethernet address from the
ARP packet, and inform an administrator of the problem. The
number of such notifications should be appropriately controlled
to prevent an excessive number of error reports being generated.
If the host has not seen any other conflicting ARP packets
recently, within the last DEFEND_INTERVAL seconds, then it MUST
record the time that the conflicting ARP packet was received, and
then broadcast one single ARP Announcement, giving its own IP and
hardware addresses. Having done this, the host can then continue
to use the address normally without any further special action.
However, if this is not the first conflicting ARP packet the host
has seen, and the time recorded for the previous conflicting ARP
packet is within DEFEND_INTERVAL seconds, then the host MUST NOT
send another defensive ARP Announcement. This is necessary to
ensure that two misconfigured hosts do not get stuck in an
endless loop flooding the network with broadcast traffic while
they both try to defend the same address.
(c) ホストが、そのアドレスを放棄すべきでないと規定されている状況では(例えば「ホスト」が、デフォルトゲートウェイや DNS サーバといった、周知された静的な IP アドレスを保持しなければならない機器の場合)、ホストは、そのアドレスを永続的に保持することを選んでもよい(MAY)。このようなホストは、もし競合する ARP パケットを受信したら、その ARP パケットに含まれる送出元イーサネットアドレスなどの有用な情報を記録し、管理者に問題を通知するべく、適切な手順を踏む必要がある。この通知を行う回数は、極端な数のエラーレポートが生成されないよう、適切に調整されなければならない。
DEFEND_INTERVAL 秒以内に、再度、競合する ARP パケットが現れなかった場合、ホストは、そのパケットの受信時刻を記録しなければならず(MUST)、かつ、自身の IP アドレスとハードウェアアドレスをセットした ARP 通知 (ARP Announcement) を、一回だけブロードキャストしなければならない(MUST)。これによって、ホストは、それ以後特に何も行わなくとも、そのアドレスを普通に使い続けることができる。
ただし、この ARP パケット競合が、初めて起きた競合でなく、かつ、前回の発生がつい最近 ── DEFEND_INTERVAL 秒以内だった場合、もうホストは、抗告の ARP 通知 (ARP Announcement) を送出してはならない(MUST NOT)。これは、設定に誤りのある二台のホストが、あるアドレスの保持を互いに延々と試みて、ネットワークがブロードキャストで溢れて膠着してしまわないようにするために必要である。
A host wishing to provide reliable network operation MUST respond to conflicting ARP packets as described in (a), (b), or (c) above. Ignoring conflicting ARP packets results in seemingly random network failures that can be hard to diagnose and very frustrating for human users.
高信頼のネットワークオペレーションを提供するつもりのあるホストは、競合する ARP パケットに、上記(a)(b)(c)いずれかの方法で対処をしなければならない(MUST)。ARP パケットの競合を無視することは、表面上は、予測のつかないネットワークエラーの原因となるが、その解析は困難で、ユーザ(人)にとって、非常に不満のたまるものである。
Forced address reconfiguration may be disruptive, causing TCP (and other transport-layer) connections to be broken. However, such disruptions should be exceedingly rare, and if inadvertent address duplication happens, then disruption of communication is inevitable. It is not possible for two different hosts using the same IP address on the same network to operate reliably.
アドレスの強制的な再設定は、状況の混乱を招く恐れもあり、TCP (および、その他のトランスポート層) 接続を切断する原因ともなり得る。しかしながら、破壊的な事態となることは極めて稀だし、もし、同一アドレスの複製が不慮に起きた場合、通信の破壊が起きることは避けられない。異なる二台のホストが、同一ネットワーク上で同一の IP アドレスを使用しつつ、高信頼のネットワークオペレーションを行うことは不可能だからである。
Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. This mitigates some security threats posed by address reconfiguration, as discussed in Section 5.
競合のためアドレスを廃止する前に、ホストは自発的に、そのアドレスを使用している既存の接続を、すべてリセットするべきである(SHOULD)。5.節で述べるように、これは、アドレスの再設定が引き起こす、セキュリティ上の種々の脅威を軽減する。
For most client machines that do not need a fixed IP address, immediately requesting the configuring agent (human user, DHCP client, etc.) to configure a new address as soon as the conflict is detected is the best way to restore useful communication as quickly as possible. The mechanism described above of broadcasting a single ARP Announcement to defend the address mitigates the problem somewhat, by helping to improve the chance that one of the two conflicting hosts may be able to retain its address.
固定 IP アドレスが不要な、大抵のクライアント機器等においては、競合を検知したら速やかに設定主体 (ユーザ、DHCP クライアント等) に、新アドレスの設定をリクエストするのが、必要な通信を可能な限り速やかに回復するうえで最も良い方法である。
上で述べた、ARP 通知 (ARP Announcement) を抗告のために一度だけブロードキャストする機構は、競合する二台のホストのうち一つが、そのアドレスを保持し続けられるチャンスを増やすことによって、いくばくか、問題を緩和する。
From the time a host sends its first ARP Announcement, until the time it ceases using that IP address, the host MUST answer ARP Requests in the usual way required by the ARP specification [RFC826]. Specifically, this means that whenever a host receives an ARP Request, that's not a conflicting ARP packet as described above in Section 2.4, where the 'target IP address' of the ARP Request is (one of) the host's own IP address(es) configured on that interface, the host MUST respond with an ARP Reply as described in RFC 826. This applies equally for both standard ARP Requests with non-zero sender IP addresses and Probe Requests with all-zero sender IP addresses.
ホストは、ARP の仕様 [RFC826] の要件どおり、最初の ARP 通知 (ARP Announcement) を送出してから、その IP アドレスの使用を止めるまでの間、ARP 要求 (ARP Request)に対し、決められた通りに応答しなければならない(MUST)。
もっとはっきり言うと、ホストは、上記 2.4 節で述べたように、'target IP address (送信先 IP アドレス) ' が、自身のインターフェイスに割り当てられた、自身の IP アドレス(のうちの一つ)と一致する「競合でない」ARP 要求(ARP Request)を受信したら、必ず、RFC826 で述べるとおり、ARP 応答 (ARP Reply) を返さなければならない(MUST)、ということである。
これは、送信元 IP アドレスがゼロでない通常の ARP 要求 (ARP Request) にも、すべてゼロの探知リクエストにも、等しく適用される。
In a carefully-run network with manually-assigned addresses, or a network with a reliable DHCP server and reliable DHCP clients, address conflicts should occur only in rare failure scenarios, so the passive monitoring described above in Section 2.4 is adequate. If two hosts are using the same IP address, then sooner or later one host or the other will broadcast an ARP Request, which the other will see, allowing the conflict to be detected and consequently resolved.
細心の注意をもって IP アドレスが手動設定されたネットワークや、信頼性の高い DHCP サーバ/クライアントの置かれたネットワークであれば、アドレス競合が起きるのは、稀なケースに違いない。従って 2.4 節で述べた、受動的なモニタリングが適している。二台のホストが同じ IP アドレスを使ったら、速やかに、又はしばらくして、どちらか一方が ARP 要求 (ARP Request) をブロードキャストするが、それはもう片方のホストによって観測され、ひいては必然的に競合は検出され、そして解決されるだろう。
It is possible, however, that a conflicting configuration may persist for a short time before it is detected. Suppose that two hosts, A and B, have been inadvertently assigned the same IP address, X. Suppose further that at the time they were both probing to determine whether the address could safely be used, the communication link between them was non-functional for some reason, so neither detected the conflict at interface-configuration time. Suppose now that the communication link is restored, and a third host, C, broadcasts an ARP Request for address X. Unaware of any conflict, both hosts A and B will send unicast ARP Replies to host C. Host C will see both Replies, and may be a little confused, but neither host A nor B will see the other's Reply, and neither will immediately detect that there is a conflict to be resolved. Hosts A and B will continue to be unaware of the conflict until one or other broadcasts an ARP Request of their own.
しかし、競合を起こす設定が、検出される前のほんの短い間、存在してしまうこともあるだろう。二台のホスト A ・B に、不注意から、同じアドレス X が割り当てられたとしよう。更に、両ホストがアドレスを安全に使用できるかを確認中に、何らかの理由で、両者間の通信リンクが機能せず、インターフェイス設定時の競合検出処理が実行できなかったと仮定する。
そしてここで、通信リンクが復旧し、第三のホスト C が、アドレス X に対するブロードキャスト ARP 要求 (ARP Request) を送出したとしよう。
ホスト A・B は、競合に気づかないまま、ユニキャストの ARP 応答 (ARP Reply) を、ホスト C に送信する。ホスト C は両方の応答を受け取ってちょっと混乱するかもしれない。一方ホスト A・B は、共に、お互いの出した応答を受け取ることができない。そしてどちらも、競合が解決したかを即座に確認できないだろう。
ホスト A・B は、どちらかが別の ARP 要求 (ARP Request) をブロードキャストするまで、競合に気づくことができないままとなる。
If quicker conflict detection is desired, this may be achieved by having hosts send ARP Replies using link-level broadcast, instead of sending only ARP Requests via broadcast, and Replies via unicast. This is NOT RECOMMENDED for general use, but other specifications building on IPv4 ACD may choose to specify broadcast ARP Replies if appropriate. For example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] specifies broadcast ARP Replies because in that context, detection of address conflicts using IPv4 ACD is not merely a backup precaution to detect failures of some other configuration mechanism; detection of address conflicts using IPv4 ACD is the sole configuration mechanism.
より速やかに競合を検出したいときは、「ARP 要求 (ARP Request) だけをブロードキャストで送り、応答 (Reply) はユニキャストで送る」代わりに、ARP 応答 (ARP Reply) も、リンクレベルのブロードキャストで送ることで実現できる可能性がある。
これを常用することは推奨されない(NOT RECOMMENDED)。ただし、IPv4 アドレス競合検出(ACD)を基礎に作られる仕様の中には、適切でさえあれば、ブロードキャストで ARP 応答 (ARP Reply) を送出することを選ぶものもあるだろう。
例えば、"IPv4 リンクローカルアドレスの動的設定" [RFC3927] では、ARP 応答 (ARP Reply) をブロードキャストで送出するよう規定している。この状況では、IPv4 ACD での競合検出は、単に、何か設定上の問題を検出する、バックアップ的な予防技術であるにとどまらないからである。競合を IPv4 ACD で検出することが、唯一無二の、設定機構なのである。
Sending ARP Replies using broadcast does increase broadcast traffic, but in the worst case by no more than a factor of two. In the traditional usage of ARP, a unicast ARP Reply only occurs in response to a broadcast ARP Request, so sending these via broadcast instead means that we generate at most one broadcast Reply in response to each existing broadcast Request. On many networks, ARP traffic is such an insignificant proportion of the total traffic that doubling it makes no practical difference. However, this may not be true of all networks, so broadcast ARP Replies SHOULD NOT be used universally. Broadcast ARP Replies should be used where the benefit of faster conflict detection outweighs the cost of increased broadcast traffic and increased packet processing load on the participant network hosts.
ARP 応答 (ARP Reply) をブロードキャストで送出すると、ブロードキャストトラフィックは、確かに増加する。ただし最悪のケースでも、増加分は(元の分量の) 1/2 を超えることはない。ARP の伝統的な用法では、ユニキャストの ARP 応答 (ARP Reply) は、ブロードキャスト ARP 要求 (ARP Request) に対する応答としてのみ起こりうるので、これを代わりにブロードキャストで送ると、既存のブロードキャスト要求 (Request) 一つに対し、高々一つのブロードキャスト応答 (Response) を発生させることとなる。
大概のネットワークでは、ARP のトラフィック量は、全トラフィックに対し些細な分量に過ぎないので、これが二倍になっても、現実な違いは無い。ただし、これがあらゆるネットワークで常に当てはまるとは限らないから、ARP 応答 (ARP Reply) のブロードキャストを普遍的に行うべきではない(SHOULD NOT)。
ARP 応答 (ARP Reply) のブロードキャストは、高速な競合検出が、ブロードキャストトラフィックの増加と、参加ホストのパケット処理量に見合う価値を提供できる状況で使うべきである。
During IETF deliberation of IPv4 Address Conflict Detection from 2000 to 2008, a question that was asked repeatedly was, "Shouldn't ARP Announcements be performed using Gratuitous ARP Reply packets?"
IETF が 2000〜2008年に IPv4 アドレス競合検出の審議を行ってきた過程で、頻繁に投げかけられた質問のひとつは、「ARP 通知 (ARP Announcement) に、"余計な ARP 応答 (ARP Reply) " パケットを使うべきでは無いのでは?」であった。
On the face of it, this seems reasonable. A conventional ARP Reply is an answer to a question. If in fact no question had been asked, then it would be reasonable to describe such a reply as gratuitous.
実際のところ、これは妥当に思える。従来 ARP 応答 (ARP Reply) というものは、「質問」に対する「応答」である。「質問」が全く行われていない状況において「応答」することを、「余計」と表現するのは妥当であろう。
The term "gratuitous reply" would seem to apply perfectly to an ARP Announcement: an answer to an implied question that in fact no one asked.
「余計な応答」という表現は、ARP 通知 (ARP Announcement) ── 実際には誰も尋ねていない暗黙の質問に応答すること ── に、ぴったりだと思われる。
However reasonable this may seem in principle, in practice there are two reasons that swing the argument in favor of using ARP Request packets. One is historical precedent, and the other is pragmatism.
しかし、この「妥当」は定義に過ぎず、実のところ、議論を、ARP 要求 (ARP Request) パケットの使用に賛成する側に振るに足る理由が二つある。一つは歴史的経緯、もう一つは実用的な理由である。
The historical precedent is that (as described above in Section 4) Gratuitous ARP is documented in Stevens Networking [Ste94] as using ARP Request packets. BSD Unix, Microsoft Windows, Mac OS 9, Mac OS X, etc., all use ARP Request packets as described in Stevens. At this stage, trying to mandate that they all switch to using ARP Reply packets would be futile.
歴史的経緯については、 (4節で述べるように、) "余計な ARP" (Gratuitous ARP) が、Stevens Networking [Ste94]によって、ARP 要求 (ARP Request) パケットとして使用するよう文書化されていることにある。
BSD UNIX・Microsoft Windows・Mac OS X 等は、すべて、ARP 要求 (ARP Request) パケットを Stevens で述べられている通り使っている。今更これらすべてに対し、ARP 応答 (ARP Reply) パケットに切り替えるよう命令する努力は、無駄である。
The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which may not implement RFC 826 entirely correctly. The Packet Reception rules in RFC 826 state that the opcode is the last thing to check in packet processing, so it really shouldn't matter, but there may be "creative" implementations that have different packet processing depending on the 'ar$op' field, and there are several reasons why these are more likely to accept Gratuitous ARP Requests than Gratuitous ARP Replies:
実用的な理由なついては、ARP 要求 (ARP Request) パケットは、より多くの ARP の実装── RFC826 を完全には実装していないものも含む ──において、正しく動作すると期待されるからである。RFC826 のパケット受信ルール (Packet Reception rule) では、パケット処理の過程で、命令コード (opcode) を一番最後に確認するべきと規定しているので、これが真に問題となることはないはずである。しかし中には、'ar$op' フィールドの内容に基づいて異なるパケット処理を行うような「先進的な」実装もあって、それゆえ、余計な ARP 要求 (ARP Requests) が、余計な ARP 応答 (ARP Replies) より受け入れられやすいと考える理由が存在する。
* An incorrect ARP implementation may expect that ARP Replies are
only sent via unicast. RFC 826 does not say this, but an incorrect
implementation may assume it; the "principle of least surprise"
dictates that where there are two or more ways to solve a
networking problem that are otherwise equally good, the one with
the fewest unusual properties is the one likely to have the fewest
interoperability problems with existing implementations. An ARP
Announcement needs to broadcast information to all hosts on the
link. Since ARP Request packets are always broadcast, and ARP
Reply packets are not, receiving an ARP Request packet via
broadcast is less surprising than receiving an ARP Reply packet via
broadcast.
* An incorrect ARP implementation may expect that ARP Replies are
only received in response to ARP Requests that have been issued
recently by that implementation. Unexpected unsolicited Replies
may be ignored.
* An incorrect ARP implementation may ignore ARP Replies where
'#ar$tha#' doesn't match its hardware address.
ar$tha' が自身のハードウェアアドレスと一致しない ARP 応答 (ARP Replies) を無視する場合がある。
* An incorrect ARP implementation may ignore ARP Replies where
'#ar$tpa#' doesn't match its IP address.
ar$rpa' が自身の IP アドレスと一致しない ARP 応答 (ARP Replies) を無視する場合がある。
In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited).
まとめると、常にクライアントからの要求により生じる所の ARP 応答 (ARP Reply) は、要求に基づかず生じる ARP 要求 (ARP Request) と比べ、より多くの事由で、間違った ARP の実装によって、もっともらしく拒絶されてしまうのである。
Some readers have claimed that "Gratuitous ARP", as described in Stevens [Ste94], provides duplicate address detection, making ACD unnecessary. This is incorrect. What Stevens describes as Gratuitous ARP is the exact same packet that this document refers to by the more descriptive term 'ARP Announcement'. This traditional Gratuitous ARP implementation sends only a single ARP Announcement when an interface is first configured. The result is that the victim (the existing address holder) logs an error, and the offender continues operation, often without even detecting any problem. Both machines then typically proceed to try to use the same IP address, and fail to operate properly because they are each constantly resetting the other's TCP connections. The human administrator is expected to notice the log message on the victim machine and repair the damage after the fact. Typically this has to be done by physically going to the machines in question, since in this state neither is able to keep a TCP connection open for long enough to do anything useful over the network.
Stevens [Ste94] で述べられているように、「余計な ARP」 (Gratuitous ARP) が重複アドレス検出を提供するのだから、ACD は不要であると指摘する読者もいるだろうが、これは正しくない。
Stevens が「余計な ARP」 (Gratuitous ARP) と言っているものは、本文書における、より描写的な語句である ARP 通知 (ARP Announcement) と全く同一のパケットを指している。 この伝統的な「余計な ARP」 (Gratuitous ARP) の実装では、ARP 通知 (ARP Announcement) は、インターフェイスが初めて設定される時に、たった一回しか送出されない。結果、犠牲者(もともとのアドレス保持者)にはエラーが記録されるが、攻撃者は、問題を検出することさえなく作業を継続することとなる。典型的には、両方のマシンとも同じアドレスを使い続けようとして、双方の TCP 接続を互いにリセットし続けるので、作業を正しく行うことは出来なくなる。
人間の管理者は、全てが終わった後になって、犠牲となっているマシン上のログメッセージに気づき、被害の修復を行わなければならない。こういった状況の場合、TCP 接続を、ネットワーク越しに何かが行えるのに充分な時間、維持しておくことも出来ないので、通常は、問題が起きているマシンの所に、物理的に出向かなければならなくなる。
Gratuitous ARP does not in fact provide effective duplicate address detection and (as of January 2008) many of the top results for a Google search for the phrase "Gratuitous ARP" are articles describing how to disable it.
「余計な ARP」 (Gratuitous ARP) は、実のところ、効果的な重複アドレス検出を提供してはおらず、また (2008年7月の段階では、) Google で "Gratuitous ARP" を検索し、上位に現れるページには、それをどうやって無効にするかを述べたものが多い。
However, implementers of IPv4 Address Conflict Detection should be aware that, as of this writing, Gratuitous ARP is still widely deployed. The steps described in Sections 2.1 and 2.4 of this document help make a host robust against misconfiguration and address conflicts, even when the other host is *not* playing by the same rules.
しかしながら、IPv4 アドレスの競合検出の実装者は、ここで書いたように、「余計な ARP」(Gratuitous ARP)は、依然、広く普及していることに留意しなければならない。本文書の 2.1 から 2.4 節で述べたステップは、ホストの、設定ミスとアドレス競合に対する耐性を高めるのに役立つだろう(たとえ、他ホストが同じルールに従わない場合でも)。
IPv4 Address Conflict Detection (ACD) is based on ARP [RFC826] and it inherits the security vulnerabilities of that protocol. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP Requests with Replies giving its own hardware address, thereby claiming ownership of every address on the network.
IPv4 アドレス競合検出 (ACD) は ARP [RFC826] からの派生物であるため、このプロトコルが持つセキュリティ上の脆弱性も、継承してしまっている。不正な ARP パケットをネットワークに送出することで、悪意あるホストが、他ホストの正常な動作を妨害することもありうる。例えば、あらゆる ARP 要求 (ARP Requests) に自分のハードウェアアドレスをもって応答し、ネットワーク上の全アドレスの所有権を宣言することもできる。
This specification makes this existing ARP vulnerability no worse, and in some ways makes it better: instead of failing silently with no indication why, hosts implementing this specification either attempt to reconfigure automatically, or at least inform the human user of what is happening.
本文書の仕様は、ARP の持つ既存の脆弱性をこれ以上悪化させることはなく、むしろある意味、改善しさえする ─── ホストは、本仕様を実装することにより、不具合の原因を何も表示せず黙りこくるのではなく、自動的に設定を修正したり、最悪でも「何が起きているか」を人に通知することができるようになるだろう。
If a host willingly selects a new address in response to an ARP conflict, as described in Section 2.4, subsection (a), this potentially makes it easier for malicious attackers on the same link to hijack TCP connections. Having a host actively reset any existing connections before abandoning an address helps mitigate this risk.
万一ホストが、2.4 節 (a) で説明した方法で、ARP 競合 (ARP conflict) に対する応答で新しいアドレスを選択すると、同一リンク上にいる悪意ある攻撃者が TCP 接続をハイジャックすることを、潜在的に容易にしてしまう。ホストがアドレスを放棄する時は、能動的に、前もって全ての接続をリセットすることで、このリスクを低減できる。
This document arose as a result of Zeroconf Working Group discussions on IPv4 Link-Local Addressing [RFC3927], where it was not clear to many participants which elements of link-local address management were specific to that particular problem space (e.g., random selection of an address), and which elements were generic and applicable to all IPv4 address configuration mechanisms (e.g., the detection of address conflicts). The following people made valuable comments in the course of that work and/or the subsequent editing of this document: Bernard Aboba, Randy Bush, Jim Busse, James Carlson, Alan Cox, Spencer Dawkins, Pavani Diwanji, Ralph Droms, Donald Eastlake III, Alex Elder, Stephen Farrell, Peter Ford, Spencer Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard, Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, Rod Lopez, Rory McGuire, Satish Mundra, Thomas Narten, Erik Nordmark, Randy Presuhn, Howard Ridenour, Pekka Savola, Daniel Senie, Dieter Siegmund, Valery Smyslov, Mark Townsley, Oleg Tychev, and Ryan Troll.
本文書は、Zeroconf Working Group での IPv4 リンクローカルアドレス設定 [RFC3927] に関する議論に端を発する。この議論では、リンクローカルアドレス管理の各要素の位置づけ ───
─── が、多くの参加者にとって不明瞭であった。
次の方々から、各位の業務として貴重なコメントを頂き、また、本文書の著述・編集を頂いた。Bernard Aboba, Randy Bush, Jim Busse, James Carlson,Alan Cox, Spencer Dawkins, Pavani Diwanji, Ralph Droms, DonaldEastlake III, Alex Elder, Stephen Farrell, Peter Ford, SpencerGiacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard,Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, RodLopez, Rory McGuire, Satish Mundra, Thomas Narten, Erik Nordmark,Randy Presuhn, Howard Ridenour, Pekka Savola, Daniel Senie, DieterSiegmund, Valery Smyslov, Mark Townsley, Oleg Tychev, Ryan Troll。
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol
-- or -- Converting Network Protocol Addresses to 48.bit
Ethernet Address for Transmission on Ethernet Hardware",
STD 37, RFC 826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. 参考文献 (Informative References)
[802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[802.3] ISO/IEC 8802-3 Information technology - Telecommunications
and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3-1996), 1996.
[802.5] ISO/IEC 8802-5 Information technology - Telecommunications
and information exchange between systems - Local and
metropolitan area networks - Common specifications -
Part 5: Token ring access method and physical layer
specifications, (also ANSI/IEEE Std 802.5-1998), 1998.
[802.11] Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11-1999, 1999.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, 1994.
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino California 95014 USA
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
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 は、本文書に記述された技術の実装や使用に付随して主張されるいかなる知的所有権、あるいは他の権利の正当性や範囲に関して、あるいはその様な権利の下でいかなる許可が利用可能であり、また利用不可能であるかの範囲に関して、いかなる立場も取らない。すなわち、そのような権利を識別するためのいかなる独立的調査を行った事も明言しない。 IETF ドキュメントの権利に関する IETF の手続きについては、BCP 78 と BCP 79 にある。
IETF 事務局による知的所有権の開示のコピーや、利用可能とされるようなライセンスの保証や、この仕様書の実装者や利用者によってそのような所有者の権利の使用のために一般的なライセンスや許可を得るためになされた試みの結果は、http://www.ietf.org/ipr にある IETF オンライン IPR リポジトリから得る事ができる。
IETF は、この標準を実装するために必要な技術をカバーするためのあらゆる著作権、特許、特許の出願、あるいは他の所有権について明らかにする事に興味を持つ団体を募集している。IETFのietf-ipr@ietf.orgにその情報をお寄せいただきたい。
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.
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.
