RFC1868 日本語訳
1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: TXT=7681 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Malkin Request For Comments: 1868 Xylogics, Inc. Category: Experimental November 1995
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 1868年のXylogics Inc.カテゴリ: 実験的な1995年11月
ARP Extension - UNARP
ARP拡張子--UNARP
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries. This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.
Address Resolutionプロトコルで、IPノードは放送網の隣接しているノードのハードウェア(データリンク)アドレスを決定できます。 プロトコルは、遠くで古いARPエントリーの年をとるようにタイマによります。 このドキュメントはパケット・フォーマットではなく、ノードが、他のすべてのノードがネットワークを出ていて、それに従って、それらのARPテーブルを変更するはずであると発表できるARPメカニズムへの些細な変更を指定します。
Acknowledgements
承認
Thanks to James Carlson/Xylogics for reviewing this document and proposing the backwards compatibility mechanism.
このドキュメントを再検討して、ジェームスカールソン/Xylogicsに遅れている互換性メカニズムを提案してくださってありがとうございます。
1. Introduction
1. 序論
The primary purpose of the Address Resolution Protocol, as defined in [1], is to determine a node's hardware address based on its network address (protocol address in ARPspeak). The ARP protocol specifically states that nodes should not periodically advertise their existence for two reasons: first, this would generate a lot of network traffic and table maintenance overhead; second, it is highly unlikely that all nodes will need to communicate to all other nodes. Since a node does not advertise its existence, neither does it advertise its imminent departure. This is not a serious problem since most ARP implementations maintain timers to age away old entries, and departing nodes seldom depart gracefully in any case.
[1]で定義されるAddress Resolutionプロトコルのプライマリ目的はネットワーク・アドレス(ARPspeakのプロトコルアドレス)に基づくノードのハードウェア・アドレスを決定することです。 ARPプロトコルは、ノードが2つの理由で定期的にそれらの存在の広告を出すはずがないと明確に述べます: まず最初に、これは、多くのネットワークトラフィックとテーブルメインテナンスがオーバーヘッドであると生成するでしょう。 2番目に、すべてのノードが、他のすべてのノードに交信する必要があるのは、非常にありそうもないです。 ノードが存在の広告を出さないので、どちらも、それは差し迫っている出発の広告を出しません。 ほとんどのARP実装が古いエントリーであって、出発しているのに遠くで年をとるタイマを維持するのでどのような場合でも、ノードがめったに優雅に出発しないことにおいてこれは重大な問題ではありません。
Over time, an additional use has been found for ARP: Proxy ARP. While there are those who believe Proxy ARP is an evil thing, it does serve a purpose; that is, it allows for communication in ways never considered in the original IP architecture. For example, allows dial-in hosts to connect to a network without consuming a large
時間がたつにつれて、追加使用はARPに関して見つけられました: プロキシARP。 Proxy ARPが不吉なものであると信じている人がいる間、目的に役立ちます。 すなわち、それはオリジナルのIPアーキテクチャで決して考えられなかった方法でコミュニケーションを考慮します。 例えば、多、を消費しないで、ダイヤルインのホストはネットワークでaに接続できます。
Malkin Experimental [Page 1] RFC 1868 UNARP November 1995
[1ページ]RFC1868UNARP1995年11月に実験的なマルキン
amount of the IP address space (i.e., all of the hosts contain addresses on the same subnet, even though they are not directly attached to the physical network associated with that subnet address. It is this use of Proxy ARP which produces the problem addressed by this document.
IPアドレス空間を達させてください。すなわち、ホストは皆、同じサブネットに関するアドレスを含みます、それらが直接そのサブネットアドレスに関連している物理ネットワークに付けられていませんが。(それはこのドキュメントによって扱われた問題を生産するProxy ARPのこの使用です。
2. The Problem
2. 問題
Consider the following topology:
以下のトポロジーを考えてください:
+--------+
| Host A |
+--------+
|
======================================== LAN
| |
+--------+ +--------+
| CS1 | comm. servers | CS2 |
+--------+ +--------+
| | | |
+-+ +-+ +-+ +-+
| | | | modems | | | |
+-+ +-+ +-+ +-+
+--------+ | ホストA| +--------+ | ======================================== LAN| | +--------+ +--------+ | CS1| commサーバ| CS2| +--------+ +--------+ | | | | +-+ +-+ +-+ +-+ | | | | モデム| | | | +-+ +-+ +-+ +-+
Assume that all of the modems are on the same rotary; that is, when a remote host dials in, it may be assigned a modem on either of the communication servers. Further assume that all of the remote hosts' IP addresses have the same subnet address as the servers and Host A, this in order to conserve address space.
モデムのすべてが同じロータリーにあると仮定してください。 すなわち、リモートホストが直通電話にかけると、それはモデムをコミュニケーションサーバーのどちらかに割り当てられるかもしれません。 リモートホストのIPアドレスのすべてにはサーバとHost Aと同じサブネットアドレスがあるとさらに仮定してください、これ、アドレス空間を保存してください。
To begin, a remote host dials into CS1 and attempts to communicate with Host A. Host A will assume, based on the subnet mask, that the remote host is actually attached to the LAN and will issue an ARP Request to determine its hardware address. Naturally, the remote host will not hear this request. CS1, knowing this, will respond in the remote host's place with its own hardware address. Host A, on receiving the ARP Reply, will then communicate with the remote host, transparently through CS1. So far everything is just fine.
始まるように、リモートホストはCS1にダイヤルして、Host A.Host Aとコミュニケートする試みは、サブネットマスクに基づいてリモートホストが実際にLANに取り付けられて、ハードウェア・アドレスを決定するためにARP Requestを発行すると仮定するでしょう。 当然、リモートホストはこの要求を聞かないでしょう。 これを知っていて、CS1はリモートホストのところでそれ自身のハードウェア・アドレスで応じるでしょう。 そして、ARP Replyを受けるとき、ホストAは透過的にCS1を通してリモートホストとコミュニケートするでしょう。 今までのところ、すべてが問題ありません。
Now, the remote host disconnects and, before Host A can age its ARP cache, reconnects through CS2. Herein lies the problem. Whenever Host A attempts to send a packet to the remote host, it will send it to CS1 because it cannot know that its ARP cache entry is invalid. If, when the remote host disconnects, the server to which it was attached could inform other nodes on the LAN that the protocol address/hardware address mapping was no longer valid, the problem would not occur.
今、リモートホストは、切断して、Host AがARPキャッシュに年をとらせることができる前にCS2を通して再接続します。 ここに横たわっている、問題。 Host Aが、リモートホストにパケットを送るのを試みるときはいつも、ARPキャッシュエントリーが無効であることを知ることができないので、それはそれをCS1に送るでしょう。 リモートホストが切断すると、それが取り付けられたサーバが、LANに関してプロトコルアドレス/ハードウェアアドレス・マッピングがもう有効でなかったことを他のノードに知らせることができるなら、問題は起こらないでしょうに。
Malkin Experimental [Page 2] RFC 1868 UNARP November 1995
[2ページ]RFC1868UNARP1995年11月に実験的なマルキン
3. The Solution
3. ソリューション
When a server, as described above, disconnects from a remote host for which it has responded to a Proxy ARP, it broadcasts an UNARP. An UNARP is an unsolicited ARP Reply with the following field values:
上で説明されるサーバがそれがProxy ARPに応じたリモートホストから切断すると、それはUNARPを放送します。 UNARPは以下の分野値がある求められていないARP Replyです:
Hardware Address Space as appropriate
Protocol Address Space 0x800 (IP)
Hardware Address Length 0 (see Backwards Compatibility)
Protocol Address Length 4 (length of an IP address)
Opcode 2 (Reply)
Source Hardware Address Not Included
Source Protocol Address IP address of detaching host
Target Hardware Address Not Included
Target Protocol Address 255.255.255.255 (IP broadcast)
ホストTarget Hardware Address Not Included TargetプロトコルAddress255.255.255.255を取り外す適切なプロトコルAddress Space0x800(IP)ハードウェアAddress Length0(Backwards Compatibilityを見ます)プロトコルAddress Length4(IPアドレスの長さ)Opcode2(回答)ソースHardware Address Not Included SourceプロトコルAddress IPアドレスとしてのハードウェアAddress Space(IP放送)
NOTE: this is a 16-byte packet (not including MAC header)
以下に注意してください。 これは16バイトのパケットです。(MACヘッダーを含んでいません)
On receiving an UNARP, a node deletes the ARP cache entry associated with the IP address.
UNARPを受けると、ノードはIPアドレスに関連しているARPキャッシュエントリーを削除します。
It is not strictly necessary that a server keep state information about whether or not it has actually sent a Proxy ARP Reply; it would be sufficient if a server always sends an UNARP when a remote host disconnects.
それが実際にProxy ARP Replyを送ったか否かに関係なく、サーバが州の情報を置くのは厳密に必要ではありません。 リモートホストが切断するとサーバがいつもUNARPを送るなら、十分でしょう。
Of course, there is no reason why a host which gracefully detaches from a LAN cannot also send an UNARP for itself. This would be especially useful if, upon re-attaching, it might have a different hardware address.
もちろん、またaからLANを優雅に取り外すホストがそれ自体のためにUNARPを送ることができない理由が全くありません。 それに異なったハードウェア・アドレスが再の付くときにあるかもしれないなら、これは特に役に立つでしょう。
4. Backwards Compatibility
4. 遅れている互換性
The modifications to support UNARP are trivial, so there is every expectation that it will be widely supported. Of course, there will be a period of time during which nodes which support UNARP will coexist with nodes which do not support UNARP. To prevent unenlightened nodes from adding spurious ARP cache entries with hardware addresses of zero, UNARP packets specify a hardware address length of zero. This should be rejected by nodes which do not support UNARP. As a consequence of this, the source and target hardware address fields do not exist in UNARP packets (as previously described).
UNARPをサポートする変更が些細であるので、それが広くサポートされるあらゆる期待があります。 もちろん、UNARPを支えるノードがUNARPを支えないノードと共存する期間があるでしょう。 無教養なノードがゼロのハードウェア・アドレスで偽りのARPキャッシュエントリーを加えるのを防ぐために、UNARPパケットはハードウェア・アドレスの長さのゼロを指定します。 これはUNARPを支えないノードによって拒絶されるべきです。 この結果として、ソースと目標ハードウェアアドレス・フィールドはUNARPパケット(以前に説明されているとしての)にいません。
It is recommended that implementors include a configuration switch to disable UNARP in the event that some vendor's ARP implementation might take offense at the abbreviated UNARP packet format.
あるベンダーのARP実装に簡略化されたUNARPパケット・フォーマットで腹を立てるかもしれないなら作成者がUNARPを無効にするために設定スイッチを入れるのは、お勧めです。
Malkin Experimental [Page 3] RFC 1868 UNARP November 1995
[3ページ]RFC1868UNARP1995年11月に実験的なマルキン
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, MIT, November 1982.
[1] プラマー、D.、「イーサネットアドレス解決プロトコル」、STD37、RFC826、MIT、1982年11月。
Author's Address
作者のアドレス
Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803
ゲーリースコットマルキンXylogics Inc.53第3アベニューバーリントン、MA 01803
Phone: (617) 272-8140 EMail: gmalkin@xylogics.com
以下に電話をしてください。 (617) 272-8140 メールしてください: gmalkin@xylogics.com
Malkin Experimental [Page 4]
マルキンExperimentalです。[4ページ]
一覧
スポンサーリンク
