[要約] RFC 5227は、IPv4アドレスの競合検出に関する標準仕様であり、ネットワーク上でのアドレス競合を検出し解決するための手法を提供します。目的は、ネットワーク上でのアドレス競合を最小限に抑え、正常な通信を確保することです。
Network Working Group S. Cheshire
Request for Comments: 5227 Apple Inc.
Updates: 826 July 2008
Category: Standards Track
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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アドレスを同時に使用しようとする場合（これが事前の調整によって調整されたまれな特殊な場合を除いて）、一方または両方のホストで問題が発生します。このドキュメントでは、（i）この誤構成の発生を防ぐためにホストが事前に取ることができる簡単な予防策、および（ii）この誤構成が発生した場合に、ホストが事後に受動的に検出できる簡単なメカニズムについて説明します。これが発生したため、ホストまたは管理者が問題を修正するために応答できます。
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
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:
これは残念なことです。既存のアドレス解決プロトコル（ARP）は、ホストがこの種の誤構成を検出してユーザーに報告する簡単な方法を提供するためです。 DHCP仕様[RFC2131]は、RFC 2131からの次の3つの抜粋に示されているように、設定ミスの検出におけるARPの役割について簡単に述べています。
o the client SHOULD probe the newly received address, e.g., with ARP
o クライアントは、新しく受信したアドレスをプローブする必要があります（例：ARP）。
o The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)
o クライアントは、パラメータ（たとえば、割り当てられたネットワークアドレスのARP）の最終チェックを実行する必要があります（SHOULD）。
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メッセージをサーバーに送信する必要があります
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パケットの数、パケット間の間隔、アドレスを安全に使用できると結論付けるまでに待機する合計時間、またはホストがどのような種類のパケットであっても、実装者にガイダンスを提供していませんこの決定を行うために、耳を傾ける必要があります。アドレスが安全に使用される可能性があると結論付けた後、ホストが後でそれが間違っていたことが判明した場合にホストが実行する必要のあるアクションは未指定のままになります。また、同じアドレスが複数回拒否されている場合でも、同じアドレスを繰り返し提供するDHCPサーバーなど、病理学的障害のケースを防ぐために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. アドレスの使用がアドレスの競合につながる可能性が高いかどうかの判断。これには、（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, 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サーバーから受信した情報、またはその他の構成情報ソースのいずれを使用しても、アドレスの構成方法に関係なく、競合の検出は役立ちます。競合を検出すると、構成エージェントにエラーが通知されます。構成エージェントが人間のユーザーである場合、その通知は、画面上のエラーメッセージ、簡易ネットワーク管理プロトコル（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リンクローカルアドレスの割り当て[RFC3927]は、このメカニズムの特殊なケースと考えることができます。この場合、構成エージェントは疑似乱数ジェネレーターであり、競合が通知されたときに実行されるアクションは、別のものを選択することです。乱数を入力して、もう一度お試しください。実際、これは1998年にMac OS 9でIPv4リンクローカルアドレッシングが実装された方法とまったく同じです。DHCPクライアントがDHCPサーバーからの応答の取得に失敗した場合、ランダムな169.254.xxを含む偽の応答を作成します。住所。 ARPモジュールがそのアドレスの競合を報告した場合、DHCPクライアントは再試行し、成功するまで必要なだけ新しいランダム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パケットのコンテキストで「送信者IPアドレス」または「ターゲットIPアドレス」という用語を使用している場合、ARP仕様[RFC826]で識別されているARPパケットのフィールドを「ar $ spa」（送信者プロトコルアドレス）および 'ar $ tpa'（ターゲットプロトコルアドレス）、それぞれ。このドキュメントで説明されている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 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プローブ」という用語は、すべてゼロの「送信者IPアドレス」を持つローカルリンクでブロードキャストされるARP要求パケットを指すために使用されます。 「送信側ハードウェアアドレス」には、パケットを送信するインターフェイスのハードウェアアドレスを含める必要があります。 「送信者IPアドレス」フィールドはすべてゼロに設定する必要があります。これは、アドレスが別のホストによってすでに使用されていることが判明した場合に、同じリンク上の他のホストのARPキャッシュを汚染しないようにするためです。 「ターゲットハードウェアアドレス」フィールドは無視され、すべてゼロに設定する必要があります。 「ターゲットIPアドレス」フィールドは、プローブされるアドレスに設定する必要があります。 ARPプローブは、質問（「このアドレスを使用している人はいますか？」）と暗黙のステートメント（「これは使用したいアドレスです。」）の両方を伝えます。
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アナウンス」という用語は、ローカルリンクでブロードキャストされるARPリクエストパケットを指し、上記のARPプローブと同じですが、送信元とターゲットの両方のIPアドレスフィールドにアナウンスされるIPアドレスが含まれている点が異なります。 。これは、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) 1.2. Relationship to RFC 826
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間の最小間隔）1.2。 RFC 826との関係
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のプロトコルルールは変更されません。パケット形式やフィールドの意味は変更されません。 「パケット生成」と「パケット受信」の既存のルールは、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負荷はごくわずかです。 RFC826。これらのルールには、ARPパケットの「送信者IPアドレス」がホストのARPキャッシュのいずれかのエントリにあるかどうかを確認するチェックがすでに含まれています。追加のテストは、「送信者IPアドレス」がホストの*自分の* IPアドレスであるかどうかを確認することだけです。多くのアーキテクチャでは、1つの追加のマシン命令と同じくらい少ない可能性があります。
As already specified in RFC 826, an ARP Request packet serves two functions, an assertion and a question:
RFC 826で既に指定されているように、ARP要求パケットは、アサーションと質問の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」（送信側ハードウェアアドレス）と「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.
このドキュメントでは、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プローブは、表面上は無実の質問をしているだけかもしれません（「このアドレスを使用している人はいますか？」）ですが、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応答を配信すると、他の場合よりも早くアドレス競合を検出できるため、有利な場合があります。たとえば、「IPv4リンクローカルアドレスの動的構成」[RFC3927]は、ここで指定されたとおりにACDを使用しますが、さらに、ARP応答がブロードキャストを使用して送信されるように指定します。信頼性とフォールトトレランスの向上は適切なものであると見なされました。同じトレードオフが適切である将来の他の仕様があるかもしれません。詳細については、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.
RFC 826は、ARP要求への応答が通常ユニキャストを使用して配信されることを示唆していますが、ブロードキャストを使用してARP応答を配信することも許容されます。 RFC 826のパケット受信ルールでは、「ar $ spa」フィールドの内容を「ar $ op」フィールドを調べる前に処理する必要があるため、RFC 826で指定されているパケット受信アルゴリズムを正しく実装するホストは正しく処理されます。リンク層ブロードキャストを介して配信されるARP応答を処理します。
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.
この仕様は、イーサネット[802.3]、トークンリング[802.5]、IEEE 802.11ワイヤレスLAN [802.11]を含むすべてのIEEE 802ローカルエリアネットワーク（LAN）[802]、および動作する他のリンク層テクノロジーに適用されます。少なくとも1 Mb / sのデータレートで、最大1秒の往復遅延があり、ARP [RFC826]を使用してIPアドレスからリンク層ハードウェアアドレスにマップします。このドキュメントで「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をサポートしているが、1 Mb / s未満の速度または1秒を超えるレイテンシで動作するリンク層テクノロジーは、このプロトコルでも正常に機能しますが、多くの場合、プロービングフェーズの完了後に検出された遅い競合を処理する必要があります。これらの種類のリンクでは、次のパラメータに異なる値を指定することが望ましい場合があります。
(a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval between, ARP Probes, explained in Section 2.1.
（a）セクション2.1で説明したARPプローブの数と間隔、PROBE_NUM、PROBE_MIN、PROBE_MAX。
(b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval between, ARP Announcements, explained in Section 2.3.
（b）セクション2.3で説明されているARPアナウンスの数と間隔、ANNOUNCE_NUMおよびANNOUNCE_INTERVAL。
(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間の時間間隔。セクション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.
このドキュメントで指定されているプロトコルが有効であるためには、リンク上のすべてのホストがそれを実装する必要はありません。この仕様を実装している特定のホストを偶発的なアドレスの競合から保護するには、同じリンク上のピアがRFC 826で規定されているようにARPプロトコルを正しく実装している必要があります。具体的には、ピアホストがARP要求を受信したときARP要求のターゲットプロトコルアドレスが、そのインターフェイスで構成されているそのホストのIPアドレス（の1つ）と一致する場合、正しくフォーマットされたARP応答で適切に応答する限り、クエリを実行するホストはそれを検出できます。このアドレスは既に使用されています。
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]は世界中の数え切れないほどのプライベートネットワーク上の数え切れないほどのデバイスで使用されています。これらは異なるリンク上にあるため、これは競合ではありません。このような2つのデバイスが同じリンクに接続された場合にのみ、競合が発生します。これが発生すると（ときどき発生します）、これは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が、ユニキャスト、マルチキャスト、またはブロードキャストを使用して、そのセット内の他のホスト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.
- そのホストのセットからの任意のホストによってそのリンクを介して送信されたブロードキャストは、そのセット内の他のすべてのホストで受信できます。
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ペイロードの一部を変更した場合、そのパケットは同じリンク上にあるとは見なされなくなります。つまり、パケットはリピーター、ブリッジ、ハブ、スイッチなどのデバイスを通過しても、このドキュメントでは同じリンク上にあると見なされますが、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再構成[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.
このセクションでは、アドレスがすでに使用されているかどうかを安全に判断するための初期プローブ、選択されたアドレスの通知、継続的な競合チェック、およびより高速な競合検出を提供するためのブロードキャストARP応答のオプションの使用について説明します。
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プローブパケットをブロードキャストすることにより、アドレスがすでに使用されているかどうかをテストする必要があります。これは、ネットワークインターフェイスが非アクティブ状態からアクティブ状態に移行するとき、コンピューターがスリープから復帰するとき、イーサネットケーブルが接続されていることを示すリンク状態変更が信号を送るとき、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で説明されているように、ホストがパッシブに競合を検出する機能があるため不要です。
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要求の「送信者ハードウェアアドレス」フィールドに、パケットを送信するインターフェイスのハードウェアアドレスを入力する必要があります。 「送信者IPアドレス」フィールドはすべてゼロに設定する必要があります。これは、アドレスが別のホストですでに使用されていることが判明した場合に、同じリンク上の他のホストのARPキャッシュを汚染しないようにするためです。 「ターゲットハードウェアアドレス」フィールドは無視され、すべてゼロに設定する必要があります。 「ターゲットIPアドレス」フィールドは、プローブされるアドレスに設定する必要があります。この方法で作成された、すべてゼロの「送信者IPアドレス」を持つARP要求は、「ARPプローブ」と呼ばれます。
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プローブパケットを送信する必要があります。この初期ランダム遅延により、同時に電源が投入された多数のホストがすべて初期プローブパケットを同時に送信しないことが保証されます。
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秒まで、ホストは、プローブが実行されているインターフェイスでパケットのARPパケット（要求*または*応答）を受信します。送信者IPアドレス」はプローブされるアドレスであり、ホストはこのアドレスを他のホストで使用されているものとして扱う必要があり、提案されたアドレスがそうでないことを構成エージェント（人間のオペレーター、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.
さらに、この期間中にホストがパケットの「ターゲットIPアドレス」がプローブされるアドレスであるARPプローブを受信し、パケットの「送信側ハードウェアアドレス」がホストのいずれのインターフェースのハードウェアアドレスでもない場合、ホストは同様にこれをアドレスの競合として扱い、上記のように構成エージェントにエラーを通知する必要があります（SHOULD）。これは、何らかの理由で2つ（またはそれ以上）のホストが誤って同じアドレスで構成されており、両方が同時にそのアドレスをプローブして、安全に使用できるかどうかを確認している場合に発生する可能性があります。
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.
注：パケットの「送信側ハードウェアアドレス」がホストのインターフェースのハードウェアアドレスではないことを確認することが重要です。ある種のイーサネットハブ（「バッファリピーター」と呼ばれることが多い）と多くのワイヤレスアクセスポイントは、受信したブロードキャストパケットを、元の送信者自体を含むすべての受信者に「再ブロードキャスト」する場合があります。このため、ホストが自身の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".
この仕様を実装するホストは、新しい候補アドレスをプローブする速度を制限するための予防策を講じる必要があります。ホストが特定のインターフェースでMAX_CONFLICTS以上のアドレス競合を経験した場合、ホストは新しいアドレスをプローブする速度を制限する必要があります。このインターフェースは、RATE_LIMIT_INTERVALごとに1つだけ試行された新しいアドレスにアクセスします。これは、1つのアドレスを要求するすべてのホストに同じアドレスを繰り返し割り当てる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プローブの送信からANNOUNCE_WAIT秒までに、競合するARP応答またはARPプローブが受信されなかった場合、ホストは目的のアドレスを安全に使用できると判断しました。
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.
このドキュメントで必要とされるよりも短い遅延が適切であるネットワーク技術が出現する可能性があります。後続のIETFパブリケーションが作成され、これらのテクノロジーのPROBE_WAIT、PROBE_NUM、PROBE_MIN、およびPROBE_MAXのさまざまな値のガイドラインが提供される場合があります。
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.
リンク上の異なるホストが異なるタイミングパラメータを使用している状況が発生しても、問題は発生しません。このプロトコルは、同じバージョンのプロトコルを実装するリンク上のすべてのホストに依存するわけではありません。実際、このプロトコルは、プロトコルを実装するリンク上のすべてのホストにまったく依存していません。必要なのは、すべてのホストがRFC 826で指定されているARPを実装し、受け取ったARP要求に正しく応答することだけです。異なるホストが異なるタイミングパラメータを使用している状況では、一部のホストが他のホストよりも迅速にインターフェースを構成するということが起こります。万一、アドレスプローブ段階でアドレスの競合が検出されない場合でも、セクション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.
目的のアドレスを安全に使用できることを確認した後、この仕様を実装するホストは、ANNOUNCE_NUM ARPアナウンスをANNOUNCE_INTERVAL秒間隔でブロードキャストすることにより、このアドレスの使用を開始していることを通知する必要があります。 ARPアナウンスは、送信者IPアドレスとターゲットIPアドレスの両方がホストの新しく選択されたIPv4アドレスに設定されることを除いて、上記のARPプローブと同じです。これらのARPアナウンスの目的は、リンク上の他のホストが、以前に同じアドレスを使用していた可能性がある他のホストから残っている古いARPキャッシュエントリがないことを確認することです。ホストは、2つのARPアナウンスのうちの最初のアナウンスを送信した直後に、正当にIPアドレスの使用を開始できます。 2番目のARPアナウンスの送信は、ホストが実行したい可能性のある他のネットワーク操作と同時に、非同期で完了する場合があります。
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パケット（リクエスト*または*返信）を受信した場合、「送信者IPアドレス」は、そのインターフェースで構成されたホスト自身のIPアドレス（の1つ）ですが、「送信者ハードウェアアドレス」がホスト自身のインターフェイスアドレスのいずれとも一致しない場合、これは競合するARPパケットであり、他のホストもこのアドレスを有効に使用していると見なしていることを示します。アドレスの競合を解決するには、ホストは、以下の（a）、（b）、または（c）のいずれかで説明されているように、競合するARPパケットに応答する必要があります。
(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接続または同じIPv4アドレスを保持することを好む他の理由を持ち、最後のDEFEND_INTERVAL秒以内に他の競合するARPパケットを検出しなかった場合、ホストはそのアドレスの防御を試みることを選択できます。競合するARPパケットが受信された時間を記録し、単一のARPアナウンスをブロードキャストし、独自のIPおよびハードウェアアドレスをARPの送信者アドレスとして指定し、「ターゲットIPアドレス」を独自のIPアドレスに設定し、 「ターゲットハードウェアアドレス」がすべてゼロに設定されています。これにより、ホストは特別なアクションを行うことなく、通常どおりアドレスを使用できます。ただし、これがホストで検出された最初の競合するARPパケットではなく、以前の競合するARPパケットについて記録された時間が最近の場合、DEFEND_INTERVAL秒以内に、ホストはこのアドレスの使用を直ちに中止し、設定エージェントにエラーを通知する必要があります上記のように。これは、2つのホストが同じアドレスを防御しようとする無限ループに陥らないようにするために必要です。
(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）ホストがどのような状況でもアドレスをあきらめないように構成されている場合（おそらく、リンクのデフォルトルーターやネットワークなど、既知の安定したIPアドレスが必要な種類のデバイスであるため） DNSサーバー）次に、アドレスを無期限に保護することを選択できます（MAY）。そのようなホストが競合するARPパケットを受信した場合、ARPパケットからのソースイーサネットアドレスなどの有用な情報をログに記録し、管理者に問題を通知するための適切な手順を実行する必要があります。このような通知の数は、過剰な数のエラーレポートが生成されないように適切に制御する必要があります。ホストが最近、他の競合するARPパケットを最後のDEFEND_INTERVAL秒以内に検出しなかった場合、競合するARPパケットが受信された時間を記録し、独自のIPアドレスとハードウェアアドレスを指定して1つのARPアナウンスをブロードキャストする必要があります。これにより、ホストは特別なアクションを行うことなく、通常どおりアドレスを使用できます。ただし、これがホストが検出した最初の競合するARPパケットではなく、以前の競合するARPパケットについて記録された時間がDEFEND_INTERVAL秒以内である場合、ホストは別の防御的なARPアナウンスを送信してはなりません。これは、2つの誤って設定されたホストが、同じアドレスを防御しようとしている間に、ブロードキャストトラフィックでネットワークをあふれさせるエンドレスループでスタックしないようにするために必要です。
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）、（b）、または（c）で説明されているように、競合するARPパケットに応答する必要があります。競合する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アドレスを使用する2つの異なるホストが確実に動作することはできません。
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.
競合のためにアドレスを破棄する前に、ホストはそのアドレスを使用して既存の接続をリセットしようとする必要があります。これにより、セクション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アナウンスをブロードキャストしてアドレスを防御する上記のメカニズムは、2つの競合するホストの1つがアドレスを保持できる可能性を高めることで、問題をある程度軽減します。
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アナウンスを送信してから、そのIPアドレスを使用しなくなるまで、ホストは、ARP仕様[RFC826]で要求される通常の方法でARP要求に応答する必要があります。具体的には、これは、ホストがARP要求を受信するときはいつでも、セクション2.4で説明した競合ARPパケットではないことを意味します。ARP要求の「ターゲットIPアドレス」は、ホスト自身のIPアドレス（の1つ）です。そのインターフェースで構成されたホストは、RFC 826で説明されているようにARP応答で応答する必要があります。これは、ゼロ以外の送信者IPアドレスを持つ標準のARP要求とすべてゼロの送信者IPアドレスを持つプローブ要求の両方に等しく適用されます。
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.
手動で割り当てられたアドレスを使用して慎重に実行されるネットワーク、または信頼性のあるDHCPサーバーと信頼性のあるDHCPクライアントを使用するネットワークでは、まれな障害シナリオでのみアドレスの競合が発生するため、セクション2.4で説明したパッシブモニタリングで十分です。 2つのホストが同じIPアドレスを使用している場合は、遅かれ早かれ、一方のホストまたは他方のホストがARP要求をブロードキャストし、もう一方のホストがそれを検出して、競合を検出し、その結果解決します。
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.
ただし、競合する構成が検出される前に、短時間持続する可能性があります。 2つのホストAとBに同じIPアドレスXが誤って割り当てられたと想定します。さらに、両方のホストがアドレスを安全に使用できるかどうかを確認するためにプローブしていたときに、それらの間の通信リンクが機能しなかったとします。何らかの理由で、どちらもインターフェイス構成時に競合を検出しませんでした。通信リンクが復元され、3番目のホストCがアドレスXのARP要求をブロードキャストしたとします。競合が認識されないため、ホストAとBの両方がユニキャストARP応答をホストCに送信します。ホストCは両方の応答を表示します。少し混乱しているかもしれませんが、ホストAもホストBも相手の返信を見ることができず、解決すべき競合があることをすぐに検出することもできません。ホストAとBは、いずれかが独自のARP要求をブロードキャストするまで、競合を認識しません。
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返信を送信させることでこれを実現できます。これは一般的な使用には推奨されませんが、IPv4 ACDに基づいて構築されている他の仕様では、必要に応じてブロードキャストARP応答を指定することを選択できます。たとえば、「IPv4リンクローカルアドレスの動的構成」[RFC3927]は、ブロードキャストARP応答を指定しています。これは、そのコンテキストでは、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応答を送信すると、ブロードキャストトラフィックが増加しますが、最悪の場合、2倍以下です。 ARPの従来の使用法では、ユニキャストARP応答はブロードキャストARP要求への応答でのみ発生するため、これらをブロードキャスト経由で送信することは、既存の各ブロードキャスト要求への応答で最大1つのブロードキャスト応答を生成することを意味します。多くのネットワークでは、ARPトラフィックは総トラフィックのほんのわずかな割合であるため、2倍にしても実際的な違いはありません。ただし、これはすべてのネットワークに当てはまるとは限らないため、ブロードキャストARP応答を普遍的に使用するべきではありません。ブロードキャストARP応答は、競合検出の高速化の利点が、ブロードキャストネットワークの増加と参加者ネットワークホストのパケット処理負荷の増加のコストを上回る場合に使用する必要があります。
3. Why Are ARP Announcements Performed Using ARP Request Packets and Not ARP Reply Packets?
3. ARPアナウンスがARP応答パケットではなくARP要求パケットを使用して実行されるのはなぜですか？
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?"
2000年から2008年までのIPv4アドレス競合検出のIETF審議中に、繰り返し尋ねられた質問は、「無償のARP応答パケットを使用してARPアナウンスを実行すべきではないか？」でした。
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応答は、質問に対する回答です。実際に質問されていない場合は、そのような返信を不当であると説明するのが妥当です。
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アナウンスに完全に当てはまるようです。つまり、実際には誰も尋ねなかった暗黙の質問に対する答えです。
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要求パケットの使用を支持して議論を揺るがす2つの理由があります。 1つは歴史的な先例であり、もう1つは実用主義です。
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で説明したように）Gratuitous ARPがStevens Networking [Ste94]でARP要求パケットを使用するものとして文書化されていることです。 BSD Unix、Microsoft Windows、Mac OS 9、Mac OS Xなど、すべてがStevensで説明されているARP要求パケットを使用します。この段階で、すべてがARP応答パケットの使用に切り替えることを義務付けようとしても無駄です。
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実装で正しく機能する可能性が高く、その一部はRFC 826を完全に正しく実装していない場合があるためです。 RFC 826のパケット受信ルールでは、オペコードはパケット処理でチェックする最後の要素であると記載されているため、実際には問題になりませんが、「ar $ op」に応じて異なるパケット処理を行う「クリエイティブ」実装がある場合があります。フィールド、そしてこれらが無償のARP応答よりも無償のARP要求を受け入れる可能性が高い理由はいくつかあります。
* 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.
* 誤ったARP実装では、ARP応答がユニキャスト経由でのみ送信されると想定する場合があります。 RFC 826はこれを述べていませんが、間違った実装はそれを想定しているかもしれません。 「最小の驚きの原則」は、ネットワークの問題を解決するために2つ以上の方法があり、他の点では同等に優れている場合、異常なプロパティが最も少ない方法が、既存の実装との相互運用性の問題が最も少ない可能性があることを示します。 ARPアナウンスは、リンク上のすべてのホストに情報をブロードキャストする必要があります。 ARP要求パケットは常にブロードキャストされ、ARP応答パケットは常にブロードキャストされないため、ブロードキャストを介してARP要求パケットを受信することは、ブロードキャストを介してARP応答パケットを受信するよりも驚くべきことではありません。
* 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.
* 誤ったARP実装は、ARP応答がその実装によって最近発行されたARP要求への応答としてのみ受信されることを期待する場合があります。予期しない迷惑な返信は無視される場合があります。
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tha' doesn't match its hardware address.
* 誤ったARP実装では、「ar $ tha」がハードウェアアドレスと一致しない場合、ARP応答が無視されることがあります。
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tpa' doesn't match its IP address.
* 誤ったARP実装では、「ar $ tpa」がIPアドレスと一致しない場合、ARP応答が無視されることがあります。
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応答（通常、クライアントからの要請によって発生する）をもっともらしいと拒否する方法は、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]で説明されている「Gratuitous ARP」が重複アドレス検出を提供し、ACDが不要になると主張しています。これは誤りです。 StevensがGratuitous ARPと説明しているのは、このドキュメントが「ARPアナウンス」というより説明的な用語で参照しているのとまったく同じパケットです。この従来のGratuitous ARP実装は、インターフェイスが最初に構成されたときに単一のARPアナウンスのみを送信します。その結果、被害者（既存のアドレス所有者）がエラーをログに記録し、攻撃者は問題を検出せずに操作を続行します。次に、両方のマシンは通常、同じIPアドレスを使用しようとしますが、お互いが常に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.
Gratuitous ARPは実際には効果的な重複アドレス検出を提供しておらず、（2008年1月現在）フレーズ「Gratuitous ARP」のGoogle検索の上位結果の多くは、それを無効にする方法を説明した記事です。
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アドレスの競合の検出の実装者は、この記事の執筆時点で、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要求に返信で応答するのは簡単であり、それによってネットワーク上のすべてのアドレスの所有権を主張します。
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の競合に応じてホストが喜んで新しいアドレスを選択すると、同じリンク上の悪意のある攻撃者が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.
このドキュメントは、IPv4リンクローカルアドレス指定[RFC3927]に関するZeroconfワーキンググループの議論の結果として生まれました。リンクローカルアドレス管理のどの要素がその特定の問題空間に固有であるか（たとえば、アドレス）、およびどの要素が一般的で、すべてのIPv4アドレス構成メカニズムに適用可能であったか（たとえば、アドレスの競合の検出）。以下の人々は、その作業および/またはこのドキュメントのその後の編集の過程で貴重なコメントをしました：Bernard Aboba、Randy Bush、Jim Busse、James Carlson、Alan Cox、Spencer Dawkins、Pavani Diwanji、Ralph Droms、Donald Eastlake III、アレックス・エルダー、スティーブン・ファレル、ピーター・フォード、スペンサー・ジャカローン、ジョシュ・グレイスリー、エリック・ガットマン、マイロン・ハティグ、マイク・ハード、ヒュー・ホルブルック、リチャード・ジョンソン、キム・ヨンウン、マーク・クロッマル、ロッド・ロペス、ロリー・マクガイア、サティッシュ・マンドラ、トーマス・ナーテン、エリックノードマーク、ランディプレスーン、ハワードリデノール、ペッカサヴォラ、ダニエルセニー、ディータージークムント、ヴァレリースミスロフ、マークタウンズリー、オレグティシェフ、ライアントロール。
[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]プラムマー、D。、「イーサネットアドレス解決プロトコル-または-イーサネットハードウェアで伝送するためにネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[802]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ、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 / IEC 8802-3情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-共通仕様-パート3：衝突検出（CSMA / CD）アクセス方式を備えたキャリアセンスマルチアクセスおよび物理層仕様、 （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.5] ISO / IEC 8802-5情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-共通仕様-パート5：トークンリングアクセス方法および物理層仕様（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.
[802.11]情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件パート11：ワイヤレス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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、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 reconfigure extension」、RFC 3203、2001年12月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4リンクローカルアドレスの動的構成」、RFC 3927、2005年5月。
[Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94] W.スティーブンス、「TCP / IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、1994。
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
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。