RFC5227 日本語訳
5227 IPv4 Address Conflict Detection. S. Cheshire. July 2008. (Format: TXT=53548 bytes) (Updates RFC0826) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Cheshire Request for Comments: 5227 Apple Inc. Updates: 826 July 2008 Category: Standards Track
コメントを求めるワーキンググループS.チェーシャー州要求をネットワークでつないでください: 5227のアップル株式会社アップデート: 826 2008年7月のカテゴリ: 標準化過程
IPv4 Address Conflict Detection
IPv4アドレス闘争検出
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
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アドレスを使用するのを試みるとき、問題は1かホストの両方のために続きます。 このドキュメントは(i) このmisconfigurationが現れるならホストがあらかじめ出来事、および(ii)からこのmisconfigurationを防ぐのを助けるために払うことができる簡単な注意について説明します、ホストがホストか管理者が応じることができるように起こったという事実の後に問題を調整するのを受け身に検出できる簡単なメカニズム。
Cheshire Standards Track [Page 1] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[1ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
Table of Contents
目次
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. RFC826との関係…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
1. Introduction
1. 序論
Historically, accidentally configuring two Internet hosts with the same IP address has often been an annoying and hard-to-diagnose problem.
しばしば偶然同じIPアドレスで2人のインターネット・ホストを構成するのは、歴史的に、煩わしい、そして、診断しにくい問題です。
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プロトコル(ARP)がmisconfigurationのこの種類を検出して、それをユーザに報告するためにホストに簡単な道で備えるので。 DHCP仕様[RFC2131]はmisconfigurationを検出しながら、簡潔にARPの役割について言明します、RFC2131から以下の3つの抜粋で例証されるように:
o the client SHOULD probe the newly received address, e.g., with ARP
o クライアントSHOULDは例えば、ARPと共に新たに受け取られたアドレスを調べます。
o The client SHOULD perform a final check on the parameters
(e.g., ARP for allocated network address)
o クライアントSHOULDはパラメタに最終的なチェックを実行します。(例えば、割り当てられたネットワーク・アドレスのためのARP)
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
o クライアントがそれを検出するならアドレスが既に使用中である(例えば、ARPの使用による)、クライアントはDHCPDECLINEメッセージをサーバに送らなければなりません。
Cheshire Standards Track [Page 2] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[2ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
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パケットの数に関して少しの指導もimplementersに与えません、パケットの間隔、アドレスが安全に使用されるかもしれないと結論を下す前か本当に、ホストが聞こうとするべきであるパケットのどの種類さえ待つか総時間、この決断をするように。 次にアドレスが安全に使用されるかもしれないと結論を下した後にそれが間違っていたと発見するなら、それはホストが取るべきである行動を不特定のままにします。 また、それは、DECLINEd複数の回DHCPクライアントが始めるべきであるどんな注意が繰り返して、それですが、同じくらいが扱うOFFERsがそうである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:
これらの質問の答えが簡単で、明白で、言及する価値があるように思えないほど簡単に見えた時間、しかし、残念ながら、これがプロトコルデザインの何らかの負担をそれぞれの個々のimplementerに残したと思う際に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. アドレスの使用がアドレシング闘争に通じそうであるかどうか決定します。 これは(a) アドレスが別のホストによる活発に使用中に同じリンクの初霜であるケース、および(b) 2人のホストが、うっかり同じアドレスを使用し始めようとしていることになっていて、同時に、アドレスが安全に使用されるかもしれないかどうか決定するために調べること(セクション2.1)の途中に両方があるケースを含んでいます。
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人のホストが初期のインタフェース構成時点でコミュニケーションを使い果たしたなら、闘争はまだ起こることができます。 これは、ホストが範囲から一時脱しているならワイヤレス・ネットワークインタフェースで起こるかもしれないか、または2個のイーサネットハブの間のリンクがアドレス構成時点で機能しないなら、イーサネットに連結します。 よくたくらみがあるホストはインタフェース構成の間に検出された闘争だけではなく、後で検出された闘争も扱うでしょう、ホストがアドレス(セクション2.4)を使用する現代の全体の持続時間のために。
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,
IPv4 Address Conflict Detection(ACD)に関するユーティリティはDHCPクライアントに制限されません。 人間のユーザによるスライド式入力装置を通ってか否かに関係なく、アドレスが構成された問題は全くDHCPサーバ、または設定情報のいかなる他の源でも情報で受信されませんでした。
Cheshire Standards Track [Page 3] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[3ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
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.
闘争を検出するのは役に立ちます。 闘争を検出すると、構成しているエージェントは誤りについて通知されるべきです。 構成しているエージェントが人間のユーザである場合では、その通知はスクリーンの上のエラーメッセージ、Simple Network Managementプロトコル(SNMP)通知、または携帯電話へのテキストメッセージで送られたエラーメッセージの形を取るかもしれません。 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 Link地方のAddresses[RFC3927]の配分を考えることができて、それが持っていく闘争について通知される動作は、異なった乱数を選んで、再試行することです。(そこでは、構成しているエージェントが疑似乱数生成器です)。 事実上、これはちょうどIPv4 Link地方のAddressingが1998年にMac OS9でどう実装されたかということです。 DHCPクライアントがどんなDHCPサーバからも返事をもらわないなら、それは単に無作為の169.254.x.xアドレスを含むにせの応答を作るでしょうに。 ARPモジュールがそのアドレスのための闘争を報告するなら、DHCPクライアントは再試行するでしょうに、成功するまで必要なだけだったことの回を新しい無作為の169.254.x.xアドレスにして。 IPv4 Link地方のAddressingのための仕事の半分がそれが意味する副作用ですが、ネットワークスタックの標準装備が既にしていた状態で実装したようにACDを実装します。
1.1. Conventions and Terminology Used in This Document
1.1. 本書では使用されるコンベンションと用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは「RFCsにおける使用が要件レベルを示すキーワード」[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.
どこでも、このドキュメントが文脈で'送付者IPアドレス'か'目標IPアドレス'という用語を使用するところと、ARPパケットでは、それは'ar$鉱泉'(送付者プロトコルAddress)と'ar$tpa'(目標プロトコルAddress)としてARP仕様[RFC826]でそれぞれ特定されたARPパケットの野原を呼んでいます。 本書では説明されたARPの使用法のために、それぞれのこれらの分野はいつも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
本書では、存在というARP Requestパケットについて言及するのに使用される用語'ARP Probe'は地方のリンクの上に放送します、オールゼロ'送付者IPアドレス'で。 '送付者ハードウェア・アドレス'はパケットを送るインタフェースのハードウェア・アドレスを含まなければなりません。 '送付者IPアドレス'分野をARPキャッシュを汚染するのを避けるようにすべてのゼロに設定しなければなりません。
Cheshire Standards Track [Page 4] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[4ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
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.").
同じくらいの他のホストはアドレスが既に別のホストによる使用であるように判明する場合でリンクします。 '目標ハードウェアアドレス'分野が無視される、SHOULD、すべてのゼロに設定されてください。 '目標IPアドレス'分野を調べられるアドレスに設定しなければなりません。 ARP Probeは質問(「だれかこのアドレスを使用していますか?」)と暗示している声明の両方を伝えます(「これは私が使用することを望んでいるアドレスです」。)。
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 Requestパケットについて言及するのに使用される用語'ARP Announcement'は地方のリンクの上に放送します、上で説明されたARP Probeと同じです、送付者と目標IPアドレス・フィールドの両方が発表されるIPアドレスを含んでいるのを除いて。 それはすなわち、ARP Probe、「これは私が現在使用しているアドレスである」より強い声明を伝えます。
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で参照をつけられます。(それは、詳細にプロトコルの操作について説明します)。 (定数がここに記載された値に固定されていることに注意してください。 彼らはimplementers、オペレータ、またはエンドユーザが修正できることを意図しません。 書くことを容易にするために定数というこれらのために異価があるこのドキュメントを参照に必要とするかもしれない将来の規格についてここの英字名をこれらの定数に与えます。 しかしながら、現在では、そのようなどんな将来の規格も存在していません。)
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)
1.2. Relationship to RFC 826
PROBE_WAIT1 2番目の(初期の無作為の遅れ)のPROBE_NUM3(徹底的調査パケットの数)PROBE_MIN1第2(最小の繰り返された徹底的調査までの遅れ)PROBE_MAX2秒(最大の繰り返された徹底的調査までの遅れ)ANNOUNCE_WAIT2秒(発表する前の遅れ)ANNOUNCE_NUM2; (Announcementパケットの数)ANNOUNCE_INTERVAL2秒(Announcementパケットの間の時間)マックス_CONFLICTS10(レートを制限している前の最大闘争)RATE_LIMIT_INTERVAL60秒(連続した試みの間の遅れ)DEFEND_INTERVAL10秒(防衛的なARPsの最小間隔)1; 2. RFC826との関係
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.
このドキュメントはRFC826のプロトコル規則のいずれも変更しません。 それはパケット・フォーマット、または分野のどれかの意味を変更しません。 「パケット世代」と「パケットレセプション」のための既存の規則はちょうどRFC826で指定されるようにまだ適用されています。
This document expands on RFC 826 by specifying:
このドキュメントは指定することによって、RFC826について詳述します:
(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 Requestが生成されるべきである。
Cheshire Standards Track [Page 5] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[5ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
(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が既に*であるので、RFC826で指定されたPacket Reception規則に従ってあらゆる容認されたARPパケットを処理するのが必要です。 これらの規則は、ARPパケットの'送付者IPアドレス'がホストのARPキャッシュにおけるエントリーのどれかに現れるかどうかを見るためにチェックするのを既に含みます。 追加テストは'送付者IPアドレス'がホストの*自己の*IPアドレスであるかどうか確認するために単にチェックすることです、多くのアーキテクチャに関するただ一つの追加機械語命令と潜在的に同じくらい小さいです。
As already specified in RFC 826, an ARP Request packet serves two functions, an assertion and a question:
RFC826で既に指定されるように、ARP Requestパケットは2つの機能、主張、および質問を果たします:
* 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'(送付者Hardware Address)と'ar$鉱泉'(送付者プロトコルAddress)は事実の主張として役立ちます: 述べられたプロトコルAddressは述べられたHardware Addressに写像されます。
* 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'(Hardware Addressを狙ってください、ゼロ)と'ar$tpa'(目標プロトコルAddress)は質問として機能します、述べられたプロトコルAddressのためにそれがどのHardware Addressに写像されるかを尋ねて。
This document clarifies what it means to have one without the other.
このドキュメントは、それが、もう片方なしで1つを持っていることを何を意味するかをはっきりさせます。
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.
何人かの読者が、どんな本当に純粋な質問もするのがたぶん不可能であると指摘しました。 どんな質問もすると、質問者が答えを知りたがっている理由に関する思惑は必ず招待されます。 「ちょうど空いている席を示して、「だれかここに座っていますか?」と尋ねるのが含意するだれか、言外、」 … そうでなければ、次に、私が本当であるつもりであるので、」 同じくらいはここで本当です。 オールゼロ'送付者IPアドレス'があるARP Probeは、IPv4 Address Conflict Detection作品が先駆としてどのようにアドレスを要求するのにこの質問を認識するはずであることができるかを潔白な質問(「だれかこのアドレスを使用していますか?」)、しかし、それが知っている知的な実装に表面上単に尋ねているかもしれません。
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.
その正確な瞬間に全く同じ質問をすることの途中にその結果、また、その実装がそうなら、彼らが同じ席にともに座ることができないと認めるべきであるので、ある他の席に関して尋ねるのは慎重でしょう。
Cheshire Standards Track [Page 6] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[6ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
1.2.1. Broadcast ARP Replies
1.2.1. 放送ARP回答
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 Address Conflict Detection(ACD)のいくつかのアプリケーションでは、ARP Repliesを提供するのは、これが、そうでなければ、起こるかもしれないよりアドレス闘争がさらに早く検出されるのを許容するのでユニキャストの代わりに放送を使用することで有利であるかもしれません。 例えば、「IPv4のリンクローカルのアドレスの動的設定」[RFC3927]は、ここでちょうど指定されるとしてのACDを使用しますが、ARP Repliesは放送を使用させられるべきであるとさらに、指定します、改良された信頼性と欠点寛容と引き換えに増強された放送トラフィックのトレードオフがその文脈で適切なものであると考えられたので。 仕様が他の未来に同じトレードオフが適切であるところにあるかもしれません。 追加詳細がセクション2.6に述べられると「放送ARPは返答します」。
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 Requestsへの回答がユニキャストを使用することで通常提供されますが、また、放送を使用するARP Repliesを提供するのが許容できるのを含意します。 RFC826のPacket Reception規則が、'ar$鉱泉'分野の内容が*以前*'ar$オプアート'分野を調べながら処理されるべきであると指定するので、正しくRFC826で指定されたPacket Receptionアルゴリズムを実装するどんなホストも正しくリンク層ブロードキャストで提供されたARP Repliesを扱うでしょう。
1.3. Applicability
1.3. 適用性
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.
この仕様はすべてのIEEE802ローカル・エリア・ネットワーク(LAN)[802]に適用されます、イーサネット[802.3]、Token-リング[802.5]、およびIEEE802.11無線LAN[802.11]を含んでいて、よく少なくとも1Mb/sのデータ信号速度で作動して、高々1秒の往復の潜在を持って、IPからアドレスを写像するARP[RFC826]をリンクレイヤハードウェア・アドレスに使用する他のリンクレイヤ技術のように。 このドキュメントがどこで「IEEE802」という用語を使用しても、テキストは等しくこれらのネットワーク技術のいずれにも適用されます。
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をサポートしますが、それでも1Mb/sか1秒より上における潜在がこのプロトコルで正しく扱うレートで操作しますが、それがProbingフェーズが検出された後に検出された遅い闘争を扱うために、よりしばしば完成させるかもしれないリンクレイヤ技術。 これらの種類のリンクでは、以下のパラメタに異価を指定するのは望ましいかもしれません:
(a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval
between, ARP Probes, explained in Section 2.1.
(a) PROBE_ヌム、PROBE_MIN、およびPROBE_MAX、数、間の間隔(ARP Probes)はセクション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 Announcements)はセクション2.3で説明しました。
Cheshire Standards Track [Page 7] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[7ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
(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とマックス_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(ホストがアドレスを防御するのを試みてはいけない闘争ARPsの間の時間間隔)はセクション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アドレスが現在使用中であるかどうか決定するのに他のテクニックを使用できるかもしれません。 しかしながら、このドキュメントの範囲の外にそのようなネットワークのためにAddress Conflict Detectionを実装するのがあります。
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プロトコルを実装するということです。 具体的に言うと、同輩ホストがARP RequestのTargetプロトコルAddressが合っているARP Requestを受け取る、(1つ、)、そのホストのIPアドレス(es)は、長さがaで適切に応じるようにそして、正しく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人のホストの間の闘争を検出しません、そして、本当にそれは検出するべきではありません。 例えば、.1[RFC1918]があるアドレス10.0.0は世界中で無数の私設のネットワークで無数のデバイスを使用します、そして、これは闘争ではありません、異なったリンクの上にそれらがあるので。 そのような2台のデバイスが同じリンクに接続されることになっている場合にだけ、それは闘争でしょうに、そして、起こるとき(時々するように)、これはACDが検出して、報告するために非常に役に立つのと(自動的に正しい)である状況に関する好例です。この誤り。
For the purposes of this document, a set of hosts is considered to be "on the same link" if:
このドキュメントの目的のために、1セットのホストが「同じリンク」にいると考えられる、:
- 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はパケットをいかなる他のホストにも送ります、B、設定されるので、ユニキャストを使用して、マルチキャスト、または、広く、全体のリンクレイヤパケットペイロードが変更されていなく届く。
- a broadcast sent over that link by any host from that set of hosts
can be received by every other host in that set.
- すべての他のホストが、設定されるので、それからのどんなホストによるリンクも設定した移動されたホストの放送を受けることができます。
Cheshire Standards Track [Page 8] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[8ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
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.
リンクレイヤ*ヘッダー*は変更されるかもしれません、リンクレイヤ*ペイロード*ではなく、Token Ring Sourceルート設定[802.5]などのように。パケットを進めるどれかデバイスが何かIPヘッダーかIPペイロードの一部分を変更するなら、特に、もう同じリンクの上にパケットがあると考えられません。 パケットがリピータ、ブリッジ、ハブ、またはスイッチなどのデバイスで通過して、同じくらいにあるとまだ考えられているかもしれないこの手段は、このドキュメントの目的のためにリンクしますが、TTLを減少させるか、またはそうでなければIPヘッダーを変更する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サーバがクライアントに通常伝えるパラメタの1つです、そして、DHCPサーバがそのアドレスが変化するかどうかをクライアントに知らせる少しの実用的な方法もありません(DHCP Reconfigure[RFC3203]のようなメカニズムが少なくとも広く実装されるようになるまで)。 その結果、そのようなデバイスのために新しい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技術でさえ。
2. Address Probing, Announcing, Conflict Detection, and Defense
2. アドレスの調べ、発表、闘争検出、およびディフェンス
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.
このセクションはアドレスが既に使用中であるかどうか安全に決定するために初期の調べについて説明します、より速い闘争検出を提供するために放送ARP Repliesの選ばれたアドレス、進行中の闘争の照合、および任意の使用を発表して。
Cheshire Standards Track [Page 9] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[9ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
2.1. Probing an Address
2.1. アドレスを調べます。
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.
IPv4アドレス(手動の構成、DHCP、またはある他の手段から受け取るか否かに関係なく)を使用し始める前に、この仕様を履行するホストはアドレスが既に使用中であるかどうか確認するためにテストしなければなりません、ARP Probeパケットを放送することによって。 また、インタフェースが移行するネットワークであるときにこれが適用される、活動的な状態に不活発であることで、コンピュータがいつ眠りから覚めるか、そして、リンク州の変化が、いつ新しい基地局の802.11のワイヤレスのインタフェース関連であるときに、イーサネットケーブルを接続してあると合図するか、そして、または接続性における変化がいかなる他のもいつホストが活発になるところに起こるかが論理的なリンクに接続しました。
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.
ホストは当然のこととしてこのチェックを定期的に実行してはいけません。 これは、ネットワーク回線容量の浪費であるだろう、ホストが闘争を受け身に発見する能力のために不要です、セクション2.4で説明されるように。
2.1.1. Probe Details
2.1.1. 詳細を調べてください。
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'.
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'.
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.
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.
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.
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.
Cheshire Standards Track [Page 10] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 10] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
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.
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.
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".
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".
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.
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.
2.2. Shorter Timeouts on Appropriate Network Technologies
2.2. Shorter Timeouts on Appropriate Network Technologies
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.
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.
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
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
Cheshire Standards Track [Page 11] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 11] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
2.3. Announcing an Address
2.3. Announcing an Address
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.
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.
2.4. Ongoing Address Conflict Detection and Address Defense
2.4. Ongoing Address Conflict Detection and Address Defense
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:
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:
(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) 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.
Cheshire Standards Track [Page 12] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 12] RFC 5227 IPv4 Address Conflict Detection July 2008
(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) 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.
(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) 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.
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.
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.
Cheshire Standards Track [Page 13] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 13] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
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.
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.
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.
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.
2.5. Continuing Operation
2.5. Continuing Operation
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.
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.
2.6. Broadcast ARP Replies
2.6. Broadcast ARP Replies
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.
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.
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
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
Cheshire Standards Track [Page 14] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 14] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
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.
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.
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.
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.
3. Why Are ARP Announcements Performed Using ARP Request Packets and
Not ARP Reply Packets?
3. Why Are ARP Announcements Performed Using ARP Request Packets and Not ARP Reply Packets?
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?"
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?"
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.
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.
Cheshire Standards Track [Page 15] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 15] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
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.
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.
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.
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.
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:
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:
* 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 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 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.
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tha' doesn't match its hardware address.
* An incorrect ARP implementation may ignore ARP Replies where
'ar$tpa' doesn't match its IP address.
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tpa' doesn't match its IP address.
Cheshire Standards Track [Page 16] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 16] RFC 5227 IPv4 Address Conflict Detection July 2008
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).
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).
4. Historical Note
4. Historical Note
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.
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.
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.
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.
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.
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.
5. Security Considerations
5. Security Considerations
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 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.
Cheshire Standards Track [Page 17] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 17] RFC 5227 IPv4 Address Conflict Detection July 2008
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.
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.
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.
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.
6. Acknowledgments
6. Acknowledgments
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.
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.
7. References
7. References
7.1. Normative References
7.1. Normative References
[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.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Cheshire Standards Track [Page 18] RFC 5227 IPv4 Address Conflict Detection July 2008
Cheshire Standards Track [Page 18] RFC 5227 IPv4 Address Conflict Detection July 2008
7.2. Informative References
7.2. Informative References
[802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[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.3] ISO/IEC8802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: 衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様、(ANSI/IEEE Std802.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.5] ISO/IEC8802-5情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート5: トークンリングアクセス法と物理的な層の仕様、(ANSI/IEEE Std802.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.
[802.11]情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11: ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様、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.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC3203] T'JoensとY.とHublet、C.とP.De Schrijver、「DHCPは拡大を再構成する」RFC3203、2001年12月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC3927]チェーシャー州(S.、Aboba、B.、およびE.Guttman、「IPv4のリンクローカルのアドレスの動的設定」、RFC3927)は、2005がそうするかもしれません。
[Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, 1994.
[Ste94]W.スティーブンス、「TCP/IPは例証して、ボリュームは1です」。 「プロトコル」、アディソン-ウエスリー、1994。
Cheshire Standards Track [Page 19] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[19ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
Author's Address
作者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino California 95014 USA
スチュアートチェーシャー州アップル株式会社1無限ループカルパチーノカリフォルニア95014米国
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
以下に電話をしてください。 +1 3207年の408 974メール: rfc@stuartcheshire.org
Cheshire Standards Track [Page 20] RFC 5227 IPv4 Address Conflict Detection July 2008
チェーシャー州標準化過程[20ページ]RFC5227IPv4は、2008年7月に闘争が検出であると扱います。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Cheshire Standards Track [Page 21]
チェーシャー州標準化過程[21ページ]
一覧
スポンサーリンク
