RFC826 日本語訳
0826 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission onEthernet Hardware. D. Plummer. November 1982. (Format: TXT=21556 bytes) (Updated by RFC5227) (Also STD0037) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group David C. Plummer
RFC: 826 （DCP@MIT-MC）
1982年11月
イーサネットアドレス解決プロトコル
-- あるいは --
イーサネットハードウェアでの転送のための
ネットワークプロトコルアドレスから
48ビットイーサネットアドレスへの変換
概要
発信側ホストSにおけるプロトコルPの実装は、プロトコルPのルーティング
メカニズムによって、接続されている10Mビットイーサネットケーブル上に
存在する目的のホストTへ転送することを決定する。イーサネットパケット
を実際に転送する場合、48ビットのイーサネットアドレスを求める必要があ
る。しかし、プロトコルPにおけるホストアドレスは、対応するイーサネッ
トアドレスと（長さや値が異なっているなど）常に互換性があるとは限らな
い。ここで示するのは、プロトコルPのアドレス空間のアドレスAから48ビッ
トのイーサネットアドレスへの変換テーブルを構築するのに必要となる情報
を動的配布できるようにするプロトコルである。
一般化によって、このプロトコルは10Mビットイーサネットハードウェア以
外でも使用できるようになっている。このようなハードウェアの一例として、
いくつかのパケット無線ネットワークがある。
--------------------------------------------------------------------
ここで提案するプロトコルは、幾人かの方々、特にJ. Noel Chiappa、Yogen
Dalal、James E. Kulpとの多くの議論と、David Moonからの助言によるもの
である。
［このRFCの目的は、プロトコルアドレス（例えばIPアドレス）をローカル
ネットワークアドレス（例えばイーサネットアドレス）に変換する手法を提
供することである。これは、現時点でARPAインターネットコミュニティ全体
が関心をもっていることである。ここで提案される手法は、あなたが検討し
論評していただくために公開されている。これはインターネット標準の仕様
書ではない］
メモ
----
このプロトコルは元々、DEC／Intel／Xeroxの10Mビットイーサネットのため
に設計されたものである。しかし、それ以外のタイプのネットワークでも使
用することができるように一般化されている。議論の多くは10Mビットイー
サネットに対して書いていく。一般化は、適切なところでイーサネットに特
化した議論の後に書くことにする。
DODインターネットプロトコルは、インターネットと呼ぶことにする。
ここで使われる数値はイーサネット標準のもので、上位バイト優先である。
これはPDP-11やVAXのようなコンピュータのバイトアドレス方式とは逆であ
る。ゆえに、後述するオペコードフィールド（ar$op）には特に注意を払う
必要がある。
合意機関は、ハードウェアの名前空間の値を管理する上で必要である（以降
を参照）。公式の機関ができるまで、要望については
David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts 02139
に提出いただきたい。また、ネットワークメールでDCP@MIT-MCに送っていた
だくことも可能である。
課題
----
世界は概してジャングルであり、ネットワーキングゲームは多数の動物を与
えてくれる。ネットワークアーキテクチャのほぼ全ての階層に、利用可能な
プロトコルが複数存在する。例えば、上位部分ではTELNETやSUPDUPがリモー
トログインのためにある。これ以降で、信頼性の高いバイトストリームプロ
トコルが出てくる。このプロトコルにはCHAOSプロトコルかもしれないし、
DOD TCPやXerox BSP、DECnetなどもありえる。もっとハードウェアに近いの
が論理トランスポート層である。 これは、 CHAOS、 DODインターネット、
Xerox PUP、DECnetなどがありえる。10Mビットイーサネットでは、ここに挙
げたプロトコル全て（以上）がイーサネットパケットヘッダのタイプフィー
ルドを使うことで1つのケーブル上に混在できる。しかし、10Mビットイーサ
ネットは物理ケーブル上で48ビットアドレスを必要とするが、ほとんどのプ
ロトコルのアドレスは48ビット長ではなく、ハードウェアの48ビットのイー
サネットアドレスとの関連を必ずしも持っていない。例えば、CHAOSプロト
コルアドレスは17ビット、DODインターネットアドレスは32ビット、 Xerox
PUPアドレスは8ビットである。そこで、〈プロトコル，アドレス〉の組合せ
と48ビットのイーサネットアドレスとの対応関係を動的に配布するプロトコ
ルが必要になる。
動機
----
DEC、Intel、Xeroxが発表した仕様書に従うインタフェースを供給するメー
カーが増えてくるにつれ、10Mビットイーサネットの利用は増えてきている。
入手が容易になることで、このインタフェース用に書かれるソフトウェアの
数蛾ますます増えてきている。このとき2つの選択肢がある。（1）全ての実
装者がある形式のアドレス解決を行うため独自の手法を考案する。（2）全
ての実装者が標準を使用して、自分のコードが修正を必要とせずに別のシス
テムへ配布できる。この提案は標準を決める試みの方である。
定義
----
イーサネットパケットヘッダのタイプフィールドに入れる値を表すため、以
下を定義する。
ether_type$XEROX_PUP
ether_type$DOD_INTERNET
ether_type$CHAOS
さらに、新たに以下を定義する。
ether_type$ADDRESS_RESOLUTION
また、以下の値を定義する（後で説明する）。
ares_op$REQUEST（=1、上位バイトが先に転送される）
ares_op$REPLY （=2）
および
ares_hrd$Ethernet（=1）
パケットのフォーマット
----------------------
〈プロトコル，アドレス〉の組合せから48ビットイーサネットアドレスへの
対応関係を伝えるために、アドレス解決プロトコルを具体化するパケットフ
ォーマットが必要である。パケットのフォーマットは以下の通りである。
イーサネット転送層（必ずしもユーザがアクセス可能であるとは
限らない）
48ビット： 宛先のイーサネットアドレス
48ビット： 発信側のイーサネットアドレス
16ビット： プロトコルタイプ = ether_type$ADDRESS_RESOLUTION
イーサネットパケットデータ
16ビット：（ar$hrd）ハードウェアアドレス空間（例えば、イーサ
ネット、パケット無線ネット）
16ビット：（ar$pro）プロトコルアドレス空間。イーサネットハー
ドウェアの場合、これはタイプフィールド
ether_type$<プロトコル>から選ばれる
8ビット：（ar$hln）各ハードウェアアドレスのバイト長
8ビット：（ar$pln）各プロトコルアドレスのバイト長
16ビット：（ar$op） オペコード
（ares_op$REQUEST | ares_op$REPLY）
nバイト：（ar$sha）このパケットの発信側ハードウェアアドレス。
nはar$hlnフィールドの値
mバイト：（ar$spa）このパケットの発信側プロトコルアドレス。
mはar$plnフィールドの値
nバイト：（ar$tha）このパケットの目的ハードウェアアドレス
（既知の場合）
mバイト：（ar$tpa）目的プロトコルアドレス
パケットの生成
--------------
パケットがネットワーク層で送出される際、ルーティングは、そのパケット
のネクストホップのプロトコルアドレスを決め、さらにその直接の目的プロ
トコルアドレスを持つステーションがあると思われるハードウェアを決める。
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）をセットしても構わない。そしてこのパケットは、先にルーテ
ィングメカニズムが決定したイーサネットケーブル上の全ステーションにブ
ロードキャストされる。
パケットの受信
--------------
アドレス解決パケットを受信すると、受信側のイーサネットモジュールはア
ドレス解決モジュールにパケットを渡す。アドレス解決モジュールは次のよ
うなアルゴリズムを実行する。ここで、否定条件節は処理終了とパケット廃
棄となる。
？ar$hrdのハードウェアタイプを持っているか？
Yes:（ほぼ間違い無く）
［オプションでハードウェア長ar$hlnを確認］
？ar$proのプロトコルを話せるか？
Yes:
［オプションでプロトコル長ar$plnを確認］
Merge_flag := false
〈プロトコルタイプ，発信側プロトコルアドレス〉の組合せがすでに変
換テーブルにある場合、エントリーの発信側ハードウェアアドレス
フィールドをパケットの中の新しい情報で更新し、 Merge_flagに
trueをセットする。
？自身が目的プロトコルアドレスか？
Yes:
Merge_flagがfalseである場合、〈プロトコルタイプ，発信側プロト
コルアドレス，発信側ハードウェアアドレス〉の組合せが変換テ
ーブルに加えられる。
？オペコードがares_op$REQUESTであるか？
（オペコードを見るのはこの時点！！）
Yes:
ハードウェアフィールドの交換とプロトコルフィールドの交換を行
い、ローカルのハードウェアアドレスおよびプロトコルアドレ
スを発信側フィールドに入れる。
ar$opフィールドにares_op$REPLYをセットする。
要求を受信したハードウェア上でパケットを（新しい）目的ハード
ウェアアドレスへ送信する。
〈プロトコルタイプ，発信側プロトコルアドレス，発信側ハードウェアアド
レス〉の組合せは、オペコードを調べる前にテーブルにマージされる。これ
には通信が双方向であるという仮定をしている。AはBとやり取りする理由が
あるなら、BはおそらくAとやり取りする理由があるだろうという仮定である。
また、〈プロトコルタイプ，発信側プロトコルアドレス〉の組合せに対する
エントリーがすでに存在するなら、新しいハードウェアアドレスによって古
いアドレスが置換される。「関連する問題」の節でこのようにする動機を挙
げる。
一般化：ar$hrdフィールドとar$hlnフィールドのおかげで、このプロトコル
およびパケットフォーマットは10Mビットイーサネット以外でも使用可能で
ある。10Mビットイーサネットの場合、〈ar$hrd，ar$hln〉は〈1，6〉とい
う値になる。他のハードウェアネットワークの場合、もはやar$proフィール
ドはイーサネットのタイプフィールドと対応しないこともあるが、アドレス
の解決が必要なプロトコルとの対応付けが必ずある。
この方法を取る理由
------------------
周期的なブロードキャストが望まれないのは言うまでもない。100台のワー
クステーションが1つのイーサネット上にあり、（パラメータの可能性の1つ
として）それぞれがアドレス解決情報を10分に1回ブロードキャストしてい
る状況を想像しよう。これは6秒ごとに1パケットとなる。これはほとんど理
に適っているが、何の役にも立たない。ワークステーションは一般的にお互
いにやり取りすることはない（それゆえ、テーブルには無駄な100エントリ
ーがあることになる）。ワークステーションは主にメインフレームやファイ
ルサーバ、ブリッジと通信を行うが、他のワークステーションと通信するの
はごく一部だけである（例えば、双方向の対話のためなど）。この文書で述
べているプロトコルは、情報が必要とするときに配布し、しかも（大抵は）
マシン起動1回につき1回だけ配布する。
このフォーマットは、複数のアドレス解決が同一パケット中で行われること
を許していない。これは簡単のためである。多重されていると、パケットフ
ォーマットを処理するのはかなり大変になり、情報の多くは無駄になってし
まう。4つのプロトコルを使い、その4つのプロトコルアドレス全てをワーク
ステーションに伝えているブリッジにを考えてみよう。この場合おそらくプ
ロトコルアドレスのうち3つは、ワークステーションが全く使わないだろう。
このフォーマットでは、応答を生成するときパケットバッファを再利用でき
る。応答と要求が同じ長さで、いくつかのフィールドが同一だからである。
ハードウェアフィールドの値（ar$hrd）は、専用のリストから選ばれる。現
時点では、定義値は10Mビットイーサネットに対する値（ares_hrd$Ethernet
= 1）しかない。同様にパケット無線ネットワークでこのプロトコルを使用
することについても言及しており、将来このプロトコルを使おうとする他の
ハードウェア媒体が現れたとき、別の値が必要となる。
10Mビットイーサネットに対して、プロトコルフィールド（ar$pro）に入る
値は、ether_type$群から選ばれる。割当て済みのプロトコルタイプを再利
用するのが自然である。このプロトコルタイプとオペコード（ar$op）を組
み合わせると、このプロトコルの下で解決可能なプロトコルの数が実質半減
し、モニタ／デバッガがより複雑になってしまう（後述の「ネットワーク監
視およびデバッグ」を参照）。32768種類のプロトコルを扱うような事態は
決して訪れないことを望むが、このような仮定をマーフィーの法則は許して
くれない。
原理的には、（ar$hrdの）ハードウェアタイプと（ar$proの）プロトコルタ
イプによってプロトコルアドレスの長さが決まるはずであるから、長さのフ
ィールド（ar$hlnとar$pln）は冗長である。これは、オプションで整合性確
認を行うため、そしてネットワーク監視とデバッグ（後述）のために入れて
ある。
オペコードは、このパケットが（応答を生じさせることが可能な）要求であ
るか、あるいは前の要求に対する応答であるかを決定する。これに16ビット
も与えるのは過剰であるが、フラグ（フィールド）は必要とされる。
発信側ハードウェアアドレスと発信側プロトコルアドレスは必須である。こ
のフィールドが転送テーブルに入れられることになる。
目的プロトコルアドレスはパケットの要求形式の場合に必要である。これは、
発信側の情報をテーブルに入れるかどうか、応答を送るかどうかをコンピュ
ータが決定できるようにするためである。応答は必ず要求によって作られる
と仮定するなら、目的プロトコルアドレスは応答形式には必要無い。これが
含まれているのは、完全性やネットワーク監視のため、そして上記の推奨処
理アルゴリズムを簡単にするためである（このアルゴリズムでは、発信側情
報をテーブルに置いた『後に』初めてオペコードを見る）。
目的ハードウェアアドレスは完全性およびネットワーク監視のために含まれ
ている。コンピュータが要求しているのがこの番号なのだから、要求形式で
は何の意味もなしていない。応答形式の中では、要求を出したコンピュータ
のアドレスを意味する。実装によっては（例えば、14バイトのイーサネット
ヘッダを確認しないような実装）、このフィールドをパケットのハードウェ
ア宛先アドレスとしてハードウェアドライバに送信することで、レジスタシ
ャッフルを幾分抑えたり、スタック空間を節約することができる。
アドレスとアドレスの間にパディングのバイトは入らない。パケットデータ
はバイトストリームとして見るべきであるが、3つの2バイトの組だけはワー
ドとして定義されている（ar$hrd，ar$pro，ar$op）。これらは最上位バイ
ト優先形式（イーサネット／PDP-10バイトスタイル）で送信される。
ネットワーク監視およびデバッグ
------------------------------
上記のアドレス解決プロトコルによって、コンピュータはイーサネットケー
ブル上の上位プロトコルの動作状況（例えば、CHAOS、インターネット、PUP、
DECnetなど）を知ることができる。どのイーサネットプロトコルタイプの領
域が（値に）使用されているか判断でき、また各プロトコルタイプのプロト
コルアドレスが分かる。実際、モニタは関与する上位プロトコルを話す必要
は全くない。これは次のようになる。
モニタがアドレス解決パケットを受信すると、必ずその〈プロトコルタイプ，
発信側プロトコルアドレス，発信側ハードウェアアドレス〉をテーブルに入
れる。 ハードウェアアドレスとプロトコルアドレスの長さは、 パケットの
ar$hlnフィールドおよびar$plnフィールドから判る。 オペコードがREPLYな
らば、モニタはパケットを投げることができる。 オペコードがREQUESTで、
目的プロトコルアドレスがモニタのプロトコルアドレスと一致した場合は、
モニタはREPLYを通常通り送信する。このやり方では、モニタは1つしか対応
付けが得られない。というのも、REQUESTへのREPLYは要求をしているホスト
に直接送信されるからだ。モニタは自身のREQUESTを送信することもできる
が、これをすると、2つのモニタをREQUEST送信ループ状態にしてしまうこと
もあり、注意が必要である。
プロトコルとオペコードは1つのフィールドに組み合わさっていないので、
モニタはどの要求オペコードがどの応答オペコードと同一の上位プロトコル
で関係付けられるのか知る必要は無い。プロトコルアドレスは何の意味も持
っていないが、プロトコルアドレスの「構文解析」はできるように長さフィ
ールドには十分な情報を与えることも必要である。
稼動中のアドレス解決プロトコル実装を、未稼動の実装のデバッグに使用す
ることもできる。ハードウェアドライバはイーサネットタイプフィールドが
ether_type$ADDRESS_RESOLUTIONであるパケットをブロードキャストで送る
ことにおそらく成功するだろう。そのパケットのフォーマットは完全に正し
いとは限らない。初期の実装にはバグがあるかもしれず、テーブル管理は多
少注意を要するかもしれないからである。要求の方はブロードキャストだか
ら、そのパケットはモニタに受信されており、望むならデバッグのために表
示することもできる。
具体例
------
コンピュータ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) = 何でも構わない
(ar$tpa) = IPA(Y)
そして、このパケットをケーブル上にある全ホストにブロードキャストする。
コンピュータYはこのパケットを受け、ハードウェアタイプ（イーサネット）
を解するかどうか、指定のプロトコル（インターネット）を使っているかど
うか、このパケットがY宛（(ar$tpa)=IPA(Y)）であるかを判断する。また、
〈ET(IP)，IPA(X)〉がEA(X)に対応付けられるという情報を（おそらく既存
のエントリーを置き換えて）入れる。そして、このパケットが要求であるこ
とに注目し、その結果EA(Y)を新しい発信側イーサネットアドレスフィール
ド（ar$sha）に入れるといったフィールドのスワップを行い、オペコードを
応答にしてパケットをEA(X)に直接（ブロードキャストを使わず）送信する。
この時点でYはXへ送信するやり方は知っているが、Xは未だにYへ送信するや
り方を知らない。
コンピュータXは、Yからの応答パケットを受け取り、〈ET(IP)，IPA(Y)〉と
EA(Y)との対応付けを行い、パケットが応答であることに注目して捨てる。
それ以降、Xのインターネットモジュールはイーサネット上でYへのパケット
送信を試みると、変換は成功し、パケットが（上手くいけば）到着する。そ
の後、YのインターネットモジュールがXと通信を行いたい場合、YがXのアド
レス解決要求からの情報を記憶しているので、これも成功するはずだ。
関連する問題
------------
テーブルのエージングやタイムアウトがあるのは望ましいだろう。これらの
実装はこのプロトコルの範疇から外れる。 ここで、より詳しく説明したい
（MOON@SCRC@MIT-MCに感謝する）。
ホストが移動する場合、移動時に自身のアドレス解決テーブルがクリアされ
ると考えられるので、そのホストから開始する接続は動作するだろう。しか
し、他のホストから開始する接続は、古いアドレスの破棄を知る特別な理由
は何もない。しかし、48ビットイーサネットアドレスはいかなる時もユニー
クであり固定されていると仮定されているので、変更されるべきではない。
もしホスト名（および他のプロトコルにおけるアドレス）が異なる物理的ハ
ードウェアに再割当されるとしたら、ホストは「移動」できるだろう。さら
に、経験から知っているように、ハードウェアもしくはソフトウェアの障害
中に転送されてしまう不正なルーティング情報による危険は常につきまとう。
恒久的に残り続けることは許されるべきではない。大抵の場合、接続開始の
際の失敗はホスト到達不能に基づいて情報を削除するようアドレス解決モジ
ュールに通知すべきである。なぜなら、ホストがダウンしているか、変換の
エントリーが古くてすでに無効である可能性があるからである。あるいは、
あるホストからパケットを受信することで、そのホストへのパケット転送に
使用しているアドレス解決エントリーのタイムアウトをリセットすべきであ
る。ある適当な時間内にあるホストから受信するパケットが無いなら、アド
レス解決エントリーは捨て去られる。これは、各入力パケットに対してテー
ブルをスキャンするための余計なオーバーヘッドを生む可能性がある。大抵
の場合、ハッシュまたはインデックスを使って、これを高速化することがで
きる。
アドレス解決パケットを受信する際、推奨アルゴリズムは、ホストが移動し
た場合に復旧にかかる時間を短縮することに努めるものである。もし〈プロ
トコルタイプ，発信元プロトコルアドレス〉がすでに転送テーブルに存在す
る場合、その発信元ハードウェアアドレスで既存のエントリーが置き換えら
れることを思い出してほしい。したがって、ブロードキャストのREQUESTが
ケーブル上の全ステーションに到着するような完全なイーサネットにおいて、
各ステーションは新しいハードウェアアドレスを得るだろう。
別の選択肢として、タイムアウトを実行するデーモンを使うというのもある。
適当な時間の後、デーモンはエントリーを削除することを考える。最初にオ
ペコードREQUESTのアドレス解決パケットをテーブル内のイーサネットアド
レスに直接送信する（必要なら何回か再送される）。もしREPLYが短期間で
来ない場合は、そのエントリーは削除される。要求が直接送信されるのは、
イーサネット上の全ステーションに負担をかけさせないようにするためであ
る。エントリーの取り消しは、おそらく有用な情報を取り消すことになるだ
ろう。この情報は再取得せねばならない。
ホストは自分以外のホストに関する情報を転送しないので、ホストを再起動
することはそのアドレス対応テーブルを最新にすることになる。不正な情報
が、コンピュータからコンピュータに巡回されて永遠に残り続けるというこ
とはない。他のコンピュータの48ビットイーサネットアドレスが変更された
ことを知らないコンピュータにしか、不正な情報は存在し得ない。おそらく、
アドレスマッピングテーブルを手動でリセット（もしくはクリア）すること
で十分である。
この問題は明らかに、それが重要だと考えられているかどうかもっと考える
必要がある。これは、どのアドレス解決系プロトコルでも引き起こされる問
題である。
一覧
スポンサーリンク
