原文：ftp://ftp.rfc-editor.org/in-notes/rfc826.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
-- or --
Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware
-- または --
イーサネットハードウェア上での通信のための
ネットワークプロトコルアドレスから
48.bit イーサネットアドレスへの変換
The implementation of protocol P on a sending host S decides, through protocol P's routing mechanism, that it wants to transmit to a target host T located some place on a connected piece of 10Mbit Ethernet cable. To actually transmit the Ethernet packet a 48.bit Ethernet address must be generated. The addresses of hosts within protocol P are not always compatible with the corresponding Ethernet address (being different lengths or values). Presented here is a protocol that allows dynamic distribution of the information needed to build tables to translate an address A in protocol P's address space into a 48.bit Ethernet address. 送信側ホスト S 上のプロトコル P の実装は、プロトコル P のルーティングメカニズムを通して、10M ビットイーサネットケーブルの接続要素上のある場所に位置する目的ホスト T に送信したいと決定する。実際にイーサネットパケットを送信するためには、48.bit イーサネットアドレスを生成しなければならない。プロトコル P におけるホストのアドレスは、対応するイーサネットアドレスと常に互換性を持つわけではない(異なる長さや異なる値を持つ場合がある)。ここで提示するのは、プロトコル P のアドレス空間内のアドレス A を 48.bit イーサネットアドレスに変換するためのテーブルを構築するのに必要となる情報を、動的に配布できるようにするプロトコルである。
Generalizations have been made which allow the protocol to be used for non-10Mbit Ethernet hardware. Some packet radio networks are examples of such hardware. 10M ビットイーサネットハードウェア以外のために使用されるプロトコルを許容するための一般化が為されている。パケット無線ネットワークなどがそのようなハードウェアの例である。
--------------------------------------------------------------------
The protocol proposed here is the result of a great deal of discussion with several other people, most notably J. Noel Chiappa, Yogen Dalal, and James E. Kulp, and helpful comments from David Moon. ここで提案されているプロトコルは何人かの人々、特に J. Noel Chiappa, Yogen Dalal, James E. Kulp との多くの議論、および David Moon からの有益なコメントの結果である。
[The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is a issue of general concern in the ARPA Internet community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of a Internet Standard.] [本 RFC の目的は、プロトコルアドレス(例えば IP アドレス)をローカルネットワークアドレス(例えばイーサネットアドレス)へと変換する手段を示すことである。これは現在、ARPA インターネットコミュニティ全体の関心事である。ここで提案されているプロトコルは、あなたの検討材料と批評とのために示されている。これはインターネットスタンダードの仕様ではない。]
This protocol was originally designed for the DEC/Intel/Xerox 10Mbit Ethernet. It has been generalized to allow it to be used for other types of networks. Much of the discussion will be directed toward the 10Mbit Ethernet. Generalizations, where applicable, will follow the Ethernet-specific discussion. 本プロトコルは元々 DEC/Intel/Xerox 10M ビットイーサネットのために設計された。それ以外のネットワークでも使用できるように一般化されている。多くの議論は 10M ビットイーサネットに対して行われる。適用可能な場合には、一般化はイーサネット固有の議論に従うだろう。
DOD Internet Protocol will be referred to as Internet. DOD インターネットプロトコルはインターネットと呼ばれる。
Numbers here are in the Ethernet standard, which is high byte first. This is the opposite of the byte addressing of machines such as PDP-11s and VAXes. Therefore, special care must be taken with the opcode field (ar$op) described below. ここでの数値はイーサネットの標準に従い、上位バイトが先に来る。PDP-11 や VAX などのマシンのバイトアドレッシングとは逆である。そのため、以降の opcode フィールド(ar$op)の扱いには特に注意しなければならない。
An agreed upon authority is needed to manage hardware name space values (see below). Until an official authority exists, requests should be submitted to ハードウェアの名前空間の値(後述)を管理するために同意された権威が必要となる。公式な権威ができるまで、要求は以下に提出するべきである：
David C. Plummer Symbolics, Inc. 243 Vassar Street Cambridge, Massachusetts 02139
Alternatively, network mail can be sent to DCP@MIT-MC. 代替として DCP@MIT-MC にメールを送ってもよい。
The world is a jungle in general, and the networking game contributes many animals. At nearly every layer of a network architecture there are several potential protocols that could be used. For example, at a high level, there is TELNET and SUPDUP for remote login. Somewhere below that there is a reliable byte stream protocol, which might be CHAOS protocol, DOD TCP, Xerox BSP or DECnet. Even closer to the hardware is the logical transport layer, which might be CHAOS, DOD Internet, Xerox PUP, or DECnet. The 10Mbit Ethernet allows all of these protocols (and more) to coexist on a single cable by means of a type field in the Ethernet packet header. However, the 10Mbit Ethernet requires 48.bit addresses on the physical cable, yet most protocol addresses are not 48.bits long, nor do they necessarily have any relationship to the 48.bit Ethernet address of the hardware. For example, CHAOS addresses are 16.bits, DOD Internet addresses are 32.bits, and Xerox PUP addresses are 8.bits. A protocol is needed to dynamically distribute the correspondences between a <protocol, address> pair and a 48.bit Ethernet address. 一般に世界はジャングルであり、ネットワーク構築のゲームは多くの動物を生み出す。ネットワークアーキテクチャのほぼすべてのレイヤにおいて、使用できる潜在的なプロトコルが複数存在する。例えば上位レベルだと、リモートログインのための TELNET や SUPDUP がある。その下位のどこかには、信頼できるバイトストリームプロトコルが存在する。それは CHAOS プロトコルかもしれないし、DOD TCP、Xerox BSP、DECnet かもしれない。さらにハードウェアの近くには、論理的なトランスポートレイヤが存在する。それは CHAOS かもしれないし、DOD インターネット、Xerox PUP、DECnet かもしれない。10M ビットイーサネットは、イーサネットパケットヘッダ内のタイプフィールドによって、単一ケーブル上にこれらのプロトコルのすべて(それ以上も)が共存することを可能にする。しかしながら、10M ビットイーサネットは物理ケーブル上の 48.bit アドレスを必要とし、一方で大部分のプロトコルアドレスは 48 ビット長ではなく、また必ずしもハードウェアの 48.bit イーサネットアドレスと関連を持たない。例えば CHAOS アドレスは 16 ビット、DOD インターネットアドレスは 32 ビット、Xerox PUP アドレスは 8 ビットである。プロトコルは、<プロトコル, アドレス> の組と 48 ビットイーサネットアドレスとの対応を動的に配布する必要がある。
Use of the 10Mbit Ethernet is increasing as more manufacturers supply interfaces that conform to the specification published by DEC, Intel and Xerox. With this increasing availability, more and more software is being written for these interfaces. There are two alternatives: (1) Every implementor invents his/her own method to do some form of address resolution, or (2) every implementor uses a standard so that his/her code can be distributed to other systems without need for modification. This proposal attempts to set the standard. DEC、Intel、Xerox によって公開された仕様に従うインターフェイスを提供するメーカーが増えるにつれて、10M ビットイーサネットの使用が増えている。この可用性の増加とともに、ますます多くのソフトウェアがこれらのインターフェイスのために書かれている。二つの選択肢がある：(1) すべての実装者が何らかの形式のアドレス解決を行う彼/彼女独自の方法を考案する。(2) すべての実装者が彼/彼女のコードを修正の必要なしに他のシステムに配布できるように標準を使用する。この提案は標準を定めることを試みる。
Define the following for referring to the values put in the TYPE field of the Ethernet packet header: イーサネットパケットヘッダの TYPE フィールドに置かれる値を参照するために、以下の値を定義する：
ether_type$XEROX_PUP, ether_type$DOD_INTERNET, ether_type$CHAOS,
and a new one: そして新しい値：
ether_type$ADDRESS_RESOLUTION.
Also define the following values (to be discussed later): また以下の値を定義する(後で議論するために)：
ares_op$REQUEST (= 1, high byte transmitted first) and ares_op$REPLY (= 2), and ares_hrd$Ethernet (= 1).
ares_op$REQUEST (= 1, 上位バイトが先に転送される) ares_op$REPLY (= 2), ares_hrd$Ethernet (= 1)
To communicate mappings from <protocol, address> pairs to 48.bit Ethernet addresses, a packet format that embodies the Address Resolution protocol is needed. The format of the packet follows. <プロトコル, アドレス> の組から 48 ビットイーサネットアドレスへのマッピングを行うために、アドレス解決プロトコルを具現化するパケットフォーマットが必要となる。パケットのフォーマットは以下の通り。
Ethernet transmission layer (not necessarily accessible to
the user):
48.bit: Ethernet address of destination
48.bit: Ethernet address of sender
16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION
Ethernet packet data:
16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,
Packet Radio Net.)
16.bit: (ar$pro) Protocol address space. For Ethernet
hardware, this is from the set of type
fields ether_typ$<protocol>.
8.bit: (ar$hln) byte length of each hardware address
8.bit: (ar$pln) byte length of each protocol address
16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
nbytes: (ar$sha) Hardware address of sender of this
packet, n from the ar$hln field.
mbytes: (ar$spa) Protocol address of sender of this
packet, m from the ar$pln field.
nbytes: (ar$tha) Hardware address of target of this
packet (if known).
mbytes: (ar$tpa) Protocol address of target.
イーサネット通信レイヤ(必ずしもユーザーにアクセス可能ではない)：
48.bit: 宛先イーサネットアドレス
48.bit: 送信元イーサネットアドレス
16.bit: プロトコルタイプ = ether_type$ADDRESS_RESOLUTION
イーサネットパケットデータ：
16.bit: (ar$hrd) ハードウェアアドレス空間(例：イーサネット、
パケット無線ネットワーク)
16.bit: (ar$pro) プロトコルアドレス空間。イーサネットの場合、
これはタイプフィールド ether_typ$<protocol>
の集合に由来する。
8.bit: (ar$hln) 各ハードウェアアドレスのバイト長
8.bit: (ar$pln) 各プロトコルアドレスのバイト長
16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
nbytes: (ar$sha) このパケットの送信者のハードウェアアドレス。
n は ar$hln フィールドに由来する。
mbytes: (ar$spa) このパケットの送信者のプロトコルアドレス。
m は ar$pln フィールドに由来する。
nbytes: (ar$tha) このパケットの宛先のハードウェアアドレス
(分かっている場合)。
mbytes: (ar$tpa) 宛先のプロトコルアドレス。
As a packet is sent down through the network layers, routing determines the protocol address of the next hop for the packet and on which piece of hardware it expects to find the station with the immediate target protocol address. In the case of the 10Mbit Ethernet, address resolution is needed and some lower layer (probably the hardware driver) must consult the Address Resolution module (perhaps implemented in the Ethernet support module) to convert the <protocol type, target protocol address> pair to a 48.bit Ethernet address. The Address Resolution module tries to find this pair in a table. If it finds the pair, it gives the corresponding 48.bit Ethernet address back to the caller (hardware driver) which then transmits the packet. If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer), and generates an Ethernet packet with a type field of ether_type$ADDRESS_RESOLUTION. The Address Resolution module then sets the ar$hrd field to ares_hrd$Ethernet, ar$pro to the protocol type that is being resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet address), ar$pln to the length of an address in that protocol, ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address of itself, ar$spa with the protocol address of itself, and ar$tpa with the protocol address of the machine that is trying to be accessed. It does not set ar$tha to anything in particular, because it is this value that it is trying to determine. It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation. It then causes this packet to be broadcast to all stations on the Ethernet cable originally determined by the routing mechanism. パケットがネットワークレイヤを通して送られるとき、ルーティングがそのパケットの次ホップのプロトコルアドレスと、直近の宛先プロトコルアドレスを持つステーションが見つかると期待されるハードウェアとを決定する。10M ビットイーサネットの場合、アドレス解決が必要とされ、何らかの下位レイヤ(恐らくハードウェアドライバ)は、<プロトコルタイプ, 宛先プロトコルアドレス> の組から 48 ビットイーサネットアドレスに変換するために、アドレス解決モジュール(恐らくイーサネットサポートモジュール内に実装される)に相談しなければならない。アドレス解決モジュールは、テーブル内でこの組を見つけようとする。その組が見つかった場合、アドレス解決モジュールは対応する 48 ビットイーサネットアドレスを、その後にパケットを送信する呼び出し元(ハードウェアドライバ)に返す。見つけられなかった場合、アドレス解決モジュールは(そのパケットが上位レイヤによって再送信されるだろうという仮定のもとに)パケットを破棄することを呼び出し元に通知し、ether_type$ADDRESS_RESOLUTION のタイプフィールドを持つイーサネットパケットを生成する。次にアドレス解決モジュールは、ar$hrd フィールドに ares_hrd$Ethernet を、ar$pro に解決中のプロトコルタイプを、ar$hln に 6 (48 ビットイーサネットアドレスのバイト数)を、ar$pln にそのプロトコルにおけるアドレスの長さを、ar$op に ares_op$REQUEST を、ar$sha に自身の 48 ビットイーサネットアドレスを、ar$spa に自身のプロトコルアドレスを、ar$tpa にアクセスしようとしているマシンのプロトコルアドレスを、それぞれセットする。ar$tha は決定しようとしている値そのものであるため、何もセットしない。何らかの実装の側面から都合がよければ、ar$tha にそのハードウェアのためのブロードキャストアドレス(10M ビットイーサネットの場合はすべて 1)をセットしよもよい。次にアドレス解決モジュールは、もともとルーティングメカニズムが決定したイーサネットケーブル上のすべてのステーションにそのパケットをブロードキャストする。
When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. アドレス解決パケットを受信したとき、受信側イーサネットモジュールはそのパケットを、以下のようなアルゴリズムを実行するアドレス解決モジュールに引き渡す。否定条件節は処理の終了とパケットの破棄とを意味する。
Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the <protocol type, sender protocol address> pair, then the new hardware address supersedes the old one. Related Issues gives some motivation for this. <プロトコルタイプ, 送信者のプロトコルアドレス, 送信者のハードウェアアドレス> の組み合わせは、opcode が調べられる前にテーブルにマージされることに注意してほしい。これは通信が双方向であるという仮定に基いている。A が B と通信する理由を持つなら、恐らく B も A と通信する理由を持つだろう。<プロトコルタイプ, 送信者のプロトコルアドレス> の組のためのエントリがすでに存在する場合には、新しいハードウェアアドレスが古いものを上書きすることにも注意してほしい。"関連する問題" セクションにその動機を示す。
Generalization: The ar$hrd and ar$hln fields allow this protocol and packet format to be used for non-10Mbit Ethernets. For the 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other hardware networks, the ar$pro field may no longer correspond to the Ethernet type field, but it should be associated with the protocol whose address resolution is being sought. 一般化：ar$hrd フィールドと ar$hln フィールドとにより、このプロトコルとパケットフォーマットとを 10M ビットイーサネット以外でも使用できる。10M ビットイーサネットの場合、<ar$hrd, ar$hln> は <1, 6> という値を取る。別のハードウェアのネットワークの場合、ar$pro フィールドはイーサネットのタイプフィールドに対応しないかもしれないが、アドレス解決をしようとするプロトコルとは関連付けられなければならない。
Periodic broadcasting is definitely not desired. Imagine 100 workstations on a single Ethernet, each broadcasting address resolution information once per 10 minutes (as one possible set of parameters). This is one packet every 6 seconds. This is almost reasonable, but what use is it? The workstations aren't generally going to be talking to each other (and therefore have 100 useless entries in a table); they will be mainly talking to a mainframe, file server or bridge, but only to a small number of other workstations (for interactive conversations, for example). The protocol described in this paper distributes information as it is needed, and only once (probably) per boot of a machine. 言うまでもなく定期的なブロードキャストは好ましくない。単一のイーサネット上に 100 台のワークステーションが存在し、(パラメータの取りうる設定のひとつとして)10 分に一度の割合でアドレス解決情報がブロードキャストされると仮定する。これは 6 秒ごとに 1 パケットになる。これはほぼ理にかなっているが、何の役に立つだろうか？ 一般にワークステーションが互いに通信することはない。(したがってテーブル内に 100 個の無駄なエントリがある)。ワークステーションは主にメインフレームやファイルサーバーやブリッジと通信し、他のワークステーションとの通信はごく少数である(例えば双方向の対話のため)。この文書で説明されているプロトコルは、必要なときに、そして(恐らく)マシンのブートごとに一度だけ情報を配布する。
This format does not allow for more than one resolution to be done in the same packet. This is for simplicity. If things were multiplexed the packet format would be considerably harder to digest, and much of the information could be gratuitous. Think of a bridge that talks four protocols telling a workstation all four protocol addresses, three of which the workstation will probably never use. このフォーマットは、同じパケット内で二つ以上の解決が行われることを許可しない。これは簡潔性のためである。もし多重化された場合、そのパケットフォーマットは相当に扱い難いものになり、多くの情報が無駄になり得る。4 種類のプロトコルを話すブリッジがワークステーションにその 4 つすべてを伝えても、そのワークステーションはその内の 3 つをまったく使用しないだろう。
This format allows the packet buffer to be reused if a reply is generated; a reply has the same length as a request, and several of the fields are the same. このフォーマットにより、リプライを生成する際にパケットバッファを再利用することができる。リプライはリクエストと同じ長さであり、いくつかのフィールドも同じである。
The value of the hardware field (ar$hrd) is taken from a list for this purpose. Currently the only defined value is for the 10Mbit Ethernet (ares_hrd$Ethernet = 1). There has been talk of using this protocol for Packet Radio Networks as well, and this will require another value as will other future hardware mediums that wish to use this protocol. ハードウェアフィールドの値 (ar$hrd) はこの目的のためのリストから取られる。現時点で唯一定義されている値は、10M ビットイーサネットのための値 (ares_hrd$Ethernet = 1) である。パケット無線ネットワークでもこのプロトコルを使用するという議論があり、それには別の値が必要になるだろう。これは本プロトコルを使用することを望む将来のハードウェアメディアでも同様である。
For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is taken from the set ether_type$. This is a natural reuse of the assigned protocol types. Combining this with the opcode (ar$op) would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor/debugger more complex (see Network Monitoring and Debugging below). It is hoped that we will never see 32768 protocols, but Murphy made some laws which don't allow us to make this assumption. 10M ビットイーサネットの場合、プロトコルフィールドの値 (ar$pro) は ether_type$ の集合から取られる。これは割り当て済みプロトコルタイプの自然な再利用である。これを opcode(ar$op) と組み合わせれば、本プロトコルの下で解決されるプロトコルの数を事実上半減させ、モニター/デバッガーをより複雑にするだろう(後述の "ネットワークのモニタリングとデバッグ" 参照)。32768 種類ものプロトコルに出会わないことを望むが、マーフィーはそのような仮定を許さない法則を作った。
In theory, the length fields (ar$hln and ar$pln) are redundant, since the length of a protocol address should be determined by the hardware type (found in ar$hrd) and the protocol type (found in ar$pro). It is included for optional consistency checking, and for network monitoring and debugging (see below). 理論上、プロトコルアドレスの長さはハードウェアタイプ (ar$hrd) とプロトコルタイプ (ar$pro) とによって決定されるはずであるため、レングスフィールド (ar$hln および ar$pln) は冗長である。このフィールドは、オプションの一貫性チェックとネットワークのモニタリング/デバッギング(後述)とのために含まれている。
The opcode is to determine if this is a request (which may cause a reply) or a reply to a previous request. 16 bits for this is overkill, but a flag (field) is needed. opcode は、それがリクエスト(これはリプライを引き起こす可能性がある)なのか、以前のリクエストに対するリプライなのかを決定する。このために 16 ビットというのは過剰だが、フラグ(フィールド)は必要である。
The sender hardware address and sender protocol address are absolutely necessary. It is these fields that get put in a translation table. 送信者のハードウェアアドレスと送信者のプロトコルアドレスとは絶対に必要である。これらは変換テーブルに入れられるフィールドである。
The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table). 宛先プロトコルアドレスはリクエスト形式のパケットで必要となる。これは送信者の情報をテーブルに入れるかどうか、またはリプライを送信するかどうかをマシンが決定できるようにするためである。リプライがリクエストによってのみ引き起こされると仮定すると、これはリプライ形式には必ずしも必要ない。これは完全性やネットワークのモニタリングのため、および前述の処理アルゴリズムを単純化する(送信者の情報をテーブルに入れるまで opcode を見ない)ために含まれている。
The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet. 宛先ハードウェアアドレスは完全性とネットワークのモニタリングとのために含まれている。マシンが要求しているのがこの数字であるため、これはリクエスト形式では意味がない。リプライ形式での意味は、リクエストを行ったマシンのアドレスである。一部の実装(例えば 14 バイトのイーサネットヘッダを見ない実装)では、このフィールドをそのパケットのハードウェア宛先アドレスとしてハードウェアドライバに送ることで、レジスタの入れ替えやスタック領域を多少節約できるかもしれない。
There are no padding bytes between addresses. The packet data should be viewed as a byte stream in which only 3 byte pairs are defined to be words (ar$hrd, ar$pro and ar$op) which are sent most significant byte first (Ethernet/PDP-10 byte style). アドレスの間にパディングバイトはない。パケットデータはバイトストリームとして見られるべきだが、3 つの 2 バイトの組 (ar$hrd, ar$pro, ar$op) だけは上位バイトが先に送信される(つまりイーサネット/PDP-10 のバイトスタイルの)ワードとして定義される。
The above Address Resolution protocol allows a machine to gain knowledge about the higher level protocol activity (e.g., CHAOS, Internet, PUP, DECnet) on an Ethernet cable. It can determine which Ethernet protocol type fields are in use (by value) and the protocol addresses within each protocol type. In fact, it is not necessary for the monitor to speak any of the higher level protocols involved. It goes something like this: 前述のアドレス解決プロトコルにより、マシンはイーサネットケーブル上の上位レベルプロトコルの活動(例えば CHAOS、インターネット、PUP、DECnet)を知ることができる。(その値によって)どのイーサネットプロトコルタイプフィールドが使用されているかと、各プロトコルタイプのプロトコルアドレスとが決定する。実際のところモニターは、関与する上位レベルプロトコルを話す必要はない。これは以下のようになる：
When a monitor receives an Address Resolution packet, it always enters the <protocol type, sender protocol address, sender hardware address> in a table. It can determine the length of the hardware and protocol address from the ar$hln and ar$pln fields of the packet. If the opcode is a REPLY the monitor can then throw the packet away. If the opcode is a REQUEST and the target protocol address matches the protocol address of the monitor, the monitor sends a REPLY as it normally would. The monitor will only get one mapping this way, since the REPLY to the REQUEST will be sent directly to the requesting host. The monitor could try sending its own REQUEST, but this could get two monitors into a REQUEST sending loop, and care must be taken. モニターはアドレス解決パケットを受信したとき、常に <プロトコルタイプ, 送信者のプロトコルアドレス, 送信者のハードウェアアドレス> をテーブルに入れる。モニターはハードウェアアドレスの長さとプロトコルアドレスの長さとを、ar$hln フィールドと ar$pln フィールドとから判断できる。opcode が REPLY の場合、モニターはそのパケットを捨てることができる。opcode が REQUEST であり、かつ宛先プロトコルアドレスがモニターのプロトコルアドレスと一致する場合、モニターは通常通り REPLY を送信する。REQUEST に対する REPLY は要求したホストに直接送信されるため、モニターはこの方法でただひとつのマッピングを得ることになる。モニターは自身の REQUEST を送信しようとすることもできるが、二つのモニターに REQUEST 送信のループを起こさせる可能性があるため、注意しなければならない。
Because the protocol and opcode are not combined into one field, the monitor does not need to know which request opcode is associated with which reply opcode for the same higher level protocol. The length fields should also give enough information to enable it to "parse" a protocol addresses, although it has no knowledge of what the protocol addresses mean. プロトコルと opcode とがひとつのフィールドにまとめられていないため、モニターはリクエスト opcode が同じ上位レベルプロトコルのどのリプライ opcode に対応するかを知る必要はない。レングスフィールドは、たとえプロトコルアドレスの意味することの知識を持たなくても、モニターがそのプロトコルアドレスを "解析(parse)" できるようにするだけの十分な情報を与えるはずである。
A working implementation of the Address Resolution protocol can also be used to debug a non-working implementation. Presumably a hardware driver will successfully broadcast a packet with Ethernet type field of ether_type$ADDRESS_RESOLUTION. The format of the packet may not be totally correct, because initial implementations may have bugs, and table management may be slightly tricky. Because requests are broadcast a monitor will receive the packet and can display it for debugging if desired. アドレス解決プロトコルが稼動している実装を、未稼働の実装をデバッグするために使用することもできる。おそらくハードウェアドライバは、ether_type$ADDRESS_RESOLUTION のイーサネットタイプフィールドを持つパケットのブロードキャストに成功するだろう。初期の実装はバグを持つ可能性があり、またテーブル管理は少々扱いにくい可能性があるため、そのパケットのフォーマットが完全に正しいとは限らない。リクエストはブロードキャストであるため、モニターはそのパケットを受信し、必要であればデバッグのためにそれを表示することができる。
Let there exist machines X and Y that are on the same 10Mbit Ethernet cable. They have Ethernet address EA(X) and EA(Y) and DOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet type of Internet be ET(IP). Machine X has just been started, and sooner or later wants to send an Internet packet to machine Y on the same cable. X knows that it wants to send to IPA(Y) and tells the hardware driver (here an Ethernet driver) IPA(Y). The driver consults the Address Resolution module to convert <ET(IP), IPA(Y)> into a 48.bit Ethernet address, but because X was just started, it does not have this information. It throws the Internet packet away and instead creates an ADDRESS RESOLUTION packet with マシン X と Y とが同じ 10M ビットイーサネットケーブル上に存在していると仮定する。それらはイーサネットアドレス EA(X) および EA(Y)、DOD インターネットアドレス IPA(X) および IPA(Y) を持つ。インターネットのイーサネットタイプを ET(IP) と仮定する。マシン X は起動したばかりであり、遅かれ早かれ、同じケーブル上のマシン Y にインターネットパケットを送信したいと考える。X は IPA(Y) に送信する必要があることを知り、ハードウェアドライバ(ここではイーサネットドライバ)に IPA(Y) を伝える。ドライバは <ET(IP), IPA(Y)> を 48 ビットイーサネットアドレスに変換するためにアドレス解決モジュールに相談するが、X は起動したばかりであるためその情報を持たない。モジュールはそのインターネットパケットを破棄し、代わりに以下の内容のアドレス解決パケットを生成する。
(ar$hrd) = ares_hrd$Ethernet (ar$pro) = ET(IP) (ar$hln) = length(EA(X)) (ar$pln) = length(IPA(X)) (ar$op) = ares_op$REQUEST (ar$sha) = EA(X) (ar$spa) = IPA(X) (ar$tha) = don't care (ar$tpa) = IPA(Y)
and broadcasts this packet to everybody on the cable. そしてこのパケットをケーブル上のすべてにブロードキャストする。
Machine Y gets this packet, and determines that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet) and that the packet is for it ((ar$tpa)=IPA(Y)). It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X). It then notices that it is a request, so it swaps fields, putting EA(Y) in the new sender Ethernet address field (ar$sha), sets the opcode to reply, and sends the packet directly (not broadcast) to EA(X). At this point Y knows how to send to X, but X still doesn't know how to send to Y. マシン Y はこのパケットを受信し、自身がそのハードウェアタイプ(イーサネット)を理解すること、提示されたプロトコル(インターネット)を話すこと、そしてパケットが自身に向けられたものであること ((ar$tpa)=IPA(Y)) を見つけ出す。Y は <ET(IP), IPA(X)> を EA(X) にマップする情報を(おそらく既存のエントリを置き換えて)入力する。次にそれがリクエストであることを知り、フィールドを入れ替え、新しい送信者のイーサネットアドレスフィールド (ar$sha) に EA(Y) を置き、opcode をリプライに設定し、そのパケットを EA(X) に(ブロードキャストではなく)直接送信する。この時点で Y は X に送信する方法を知っているが、X はまだ Y に送信する方法を知らない。
Machine X gets the reply packet from Y, forms the map from <ET(IP), IPA(Y)> to EA(Y), notices the packet is a reply and throws it away. The next time X's Internet module tries to send a packet to Y on the Ethernet, the translation will succeed, and the packet will (hopefully) arrive. If Y's Internet module then wants to talk to X, this will also succeed since Y has remembered the information from X's request for Address Resolution. マシン X は Y からリプライパケットを受け取り、<ET(IP), IPA(Y)> から EA(Y) へのマッピングを作り、パケットがリプライであることを知り、それを破棄する。次に X のインターネットモジュールがそのイーサネット上で Y にパケットを送信しようとするとき、変換は成功し、パケットは(うまくいけば)到達するだろう。その後 Y のインターネットモジュールが X と通信したいとき、Y は X のアドレス解決リクエストからの情報を覚えているため、それも成功するだろう。
It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC). テーブルは劣化やタイムアウトを持つことが望ましいかもしれない。それらの実装は本プロトコルの範囲外である。ここでより詳細に説明する(MOON@SCRC@MIT-MC に感謝する)。
If a host moves, any connections initiated by that host will work, assuming its own address resolution table is cleared when it moves. However, connections initiated to it by other hosts will have no particular reason to know to discard their old address. However, 48.bit Ethernet addresses are supposed to be unique and fixed for all time, so they shouldn't change. A host could "move" if a host name (and address in some other protocol) were reassigned to a different physical piece of hardware. Also, as we know from experience, there is always the danger of incorrect routing information accidentally getting transmitted through hardware or software error; it should not be allowed to persist forever. Perhaps failure to initiate a connection should inform the Address Resolution module to delete the information on the basis that the host is not reachable, possibly because it is down or the old translation is no longer valid. Or perhaps receiving of a packet from a host should reset a timeout in the address resolution entry used for transmitting packets to that host; if no packets are received from a host for a suitable length of time, the address resolution entry is forgotten. This may cause extra overhead to scan the table for each incoming packet. Perhaps a hash or index can make this faster. ホストが移動する場合、そのアドレス変換テーブルは移動時にクリアされると考えられるため、そのホストから開始される接続は正しく動作するだろう。しかしながら他のホストからそのホストへの接続は、古いアドレスが破棄されたことを知る特別な理由がない。しかし 48 ビットイーサネットアドレスは常にユニークかつ変化しないと予想されるため、変化しないはずである。ホスト名(および何らかの他のプロトコルにおけるアドレス)が異なる物理的ハードウェアに再割り当てされれば、ホストは "移動する(move)" ことができる。また経験から分かるように、ハードウェアまたはソフトウェアのエラーにより図らずも転送される不正なルーティング情報の危険性は常に存在する。永遠に存続することは許されるべきではない。おそらく接続開始の失敗は、ホストがダウンしているか古い変換がもはや有効でないということであるため、ホストが到達不能であることに基づいて情報を削除するようアドレス変換モジュールに通知するべきである。または、ホストからのパケットの受信は、そのホストへパケットを送信するために使用されるアドレス解決エントリ内のタイムアウトをリセットするべきだろう。適当な時間だけホストからパケットを受信しなかった場合、そのアドレス解決エントリは忘れられる。これは各入力パケットごとのテーブル読み取りのための余分なオーバーヘッドを引き起こす可能性がある。ハッシュまたはインデックスによってこれを高速化できるだろう。
The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move. Recall that if the <protocol type, sender protocol address> is already in the translation table, then the sender hardware address supersedes the existing entry. Therefore, on a perfect Ethernet where a broadcast REQUEST reaches all stations on the cable, each station will be get the new hardware address. アドレス解決パケットを受信するための推奨されるアルゴリズムは、ホストが移動した場合の復旧に必要となる時間を減少させようと試みる。変換テーブル内に <プロトコルタイプ, 送信者のプロトコルアドレス> がすでに存在する場合、送信者のハードウェアアドレスが既存のエントリを上書きすることを思い出してほしい。そのため、ブロードキャストのリクエストがケーブル上の全ステーションに到達する完全なイーサネットでは、各ステーションが新しいハードウェアアドレスを取得するだろう。
Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained. 別の選択肢は、タイムアウトを実行するデーモンを持つというものである。適当な時間の経過後、デーモンはエントリの削除を検討する。デーモンは最初に opcode が REQUEST のアドレス解決パケットをテーブル内のイーサネットアドレスに直接送信する(必要なら数回だけ再送信する)。短時間で REPLY が帰ってこなかった場合、そのエントリは削除される。イーサネット上のすべてのステーションの邪魔をしないように、このリクエストは直接送信される。単純にエントリを忘れることは、再取得されなければならない有用な情報を忘れることになるだろう。
Since hosts don't transmit information about anyone other than themselves, rebooting a host will cause its address mapping table to be up to date. Bad information can't persist forever by being passed around from machine to machine; the only bad information that can exist is in a machine that doesn't know that some other machine has changed its 48.bit Ethernet address. Perhaps manually resetting (or clearing) the address mapping table will suffice. ホストは自分以外の情報を送信しないため、ホストのリブートはアドレスマッピングテーブルを最新化するだろう。不正な情報がマシンからマシンへと伝達されることはない。不正な情報は、他のマシンの 48 ビットイーサネットアドレスが変化したことを知らないマシン内だけに存在し得る。おそらく、手動によるアドレスマッピングテーブルのリセット(またはクリア)で十分だろう。
This issue clearly needs more thought if it is believed to be important. It is caused by any address resolution-like protocol. この問題が重要だと考えられるなら、明らかにさらなる検討が必要である。これは、あらゆる種類のアドレス解決プロトコルで起こる問題である。