RFC903 日本語訳
0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann,J.C. Mogul, M. Theimer. June 1984. (Format: TXT=9345 bytes) (Also STD0038) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group Finlayson、Mann、Mogul、Theimer
RFC: 903 Stanford University
1984年6月
逆アドレス解決プロトコル
Ross Finlayson、Timothy Mann、Jeffrey Mogul、Marvin Theimer
Computer Science Department
Stanford University
1984年6月
このメモのステータス
このRFCは、ワークステーションが自身のハードウェアアドレス（例えば、接
続されている物理ネットワークのアドレス）しか知らないときに、自身のプ
ロトコルアドレス（例えば、インターネットアドレス）を動的に知るための
方法を提案している。
このRFCはARPAインターネットコミュニティに対するプロトコル案を規定し、
改良に向けた議論と提案を求めるものである。
I. はじめに
ディスクレスワークステーションのようなネットワークホストは、起動時に
自身のプロトコルアドレスを知らない場合が多い。そして、自身のハードウ
ェアインタフェースアドレスだけは知っているという場合がしばしばである。
IPのような上位プロトコルを使って通信する場合、何か外部の情報源から自
身のプロトコルアドレスを見つけなければならない。我々の問題は、このよ
うなことを行うための標準的なメカニズムが無いことである。
Plummerの「アドレス解決プロトコル」（ARP）［1］は、ホストのプロトコル
アドレスを与えられてそのハードウェアアドレスを解決して、相補的な問題
を解決できるように設計されている。このRFCは「逆アドレス解決プロトコル」
（RARP）を提案するものである。ARPと同様に、我々はイーサネットのような
ブロードキャストメディアを仮定している。
II. 設計の考え方
以下の考え方に沿って、我々はRARPプロトコルを設計した。
A. ARPとRARPは異なる動作をする。ARPは、全てのホストが自身のハードウェ
アアドレスとプロトコルアドレスのマッピングを持っていることを仮定して
いる。他のホストについて集めた情報は、小さなキャッシュに蓄積される。
全てのホストのステータスは等しく、クライアントとサーバの区別は無い。
一方でRARPの要求では、1つ以上のサーバホストがハードウェアアドレスから
プロトコルアドレスへのマッピングのデータベースを保持し、クライアント
ホストからの要求に応えなければならない。
B. 先述のとおり、RARPはサーバホストが巨大なデータベースを保持する必要
Finlayson、Mann、Mogul、Theimer [Page 1]
RFC 903 1984年6月
がある。このようなデータベースをホストのオペレーティングシステムのカ
ーネル内部に保持することは、望ましくないし、場合によっては不可能であ
る。したがって、ほとんどの実装ではカーネルの外部のプログラムとの双方
向のやり取りといった形が何か必要になるだろう。
C. 既存のホストソフトウェアにおけるそれぞれの実装と与える影響を最小限
にすることは重要である。追加という形を意図していようと意図していまい
と、全ホストのソフトウェアに修正が必要となるようなプロトコルを設計し
てしまったら、それは失敗だろう。
D. オーバーヘッドおよび開発コストの最小化のために、既存ソフトウェアと
のコードの共有できる可能性があることが望ましい。
III. 提案するプロトコル
我々の提案では、RARPをデータリンクのレベルで独立したプロトコルとして
規定している。例えば、使用されるメディアがイーサネットの場合、RARPパ
ケットのイーサタイプ（未割り当て）はARPのものとは異なっている。これは、
ARPとRARPが2つの根本的に異なる動作であり、全てのホストが等しくサポー
トするわけではないことを認めているわけである。既存のシステムへの影響
は最小限に留めており、既存のARPサーバがRARPパケットによって混乱したり
はしない。そしてRARPは、ハードウェアアドレスから上位プロトコルアドレ
スへのマッピングに使用できる一般的な機能となる。
このアプローチは、RARPクライアントホストにとって最も簡単な実装となる
が、RARPサーバホストにとって最も困難である。しかし、付録Aに示すように
この困難は越えられないはずはない。付録Aでは4.2BSD Unixに対する2つの可
能な実装の概要を示している。
RARPはARPが使用するものと同じパケットフォーマットを使用する。すなわち、
ar$hrd（ハードウェアアドレス空間） - 16ビット
ar$pro（プロトコルアドレス空間） - 16ビット
ar$hln（ハードウェアアドレス長） - 8ビット
ar$pln（プロトコルアドレス長） - 8ビット
ar$op （オペコード） - 16ビット
ar$sha（送信元ハードウェアアドレス）- nバイト
（nはar$hlnフィールドの値）
ar$spa（送信元プロトコルアドレス） - mバイト
（mはar$plnフィールドの値）
ar$tha（目的ハードウェアアドレス） - nバイト
ar$tpa（目的プロトコルアドレス） - mバイト
ar$hrd、 ar$pro、 ar$hln、 ar$plnは標準ARPのときと同じである（［1］参
照）。
例えば、「ハードウェア」アドレスが48ビットのイーサネットアドレスで、
「プロトコル」アドレスが32ビットのインターネットアドレスであるとする。
Finlayson、Mann、Mogul、Theimer [Page 2]
RFC 903 1984年6月
すなわち、既知のイーサネットアドレスに対応するインターネットアドレス
を見つけたい。 この場合、各RARPパケットでは、ar$hrd = 1 （イーサネッ
ト）、ar$pro = 2048（10進数）（IPパケットのイーサタイプ）、ar$hln = 6、
ar$pln = 4となっている。
オペコードには、3（「逆要求」）および4（「逆応答」）の2つがある。オペ
コード1や2は［1］のときと同じ意味である。このようなオペコードを持つパ
ケットは標準ARPコードに渡してもかまわない。他のオペコードを持つパケッ
トは未定義である。RARPサーバが要求に応答するかしないかは自由であるた
め、ARPのときと同様、「見つからない」あるいは「エラー」といったパケッ
トは無い。RARP要求パケットの送信側は、適当な時間内にこの要求に対する
応答を受信しなかった場合にタイムアウトする必要がある。
RARPパケットのar$sha、ar$spa、ar$tha、ar$tpaフィールドは、以下のよう
に解釈される。
オペコードが3（「逆要求」）の場合
ar$shaはパケットの送信側のハードウェアアドレス。
ar$spaは未定義。
ar$thaは「目的」のハードウェアアドレス。
送信側が自身のプロトコルアドレスを決定したい場合、これは
ar$shaと同じ、送信側のハードウェアアドレスになるだろう。
ar$tpaは未定義。
オペコードが4（「逆応答」）の場合
ar$shaは応答側（応答パケットの送信側）のハードウェアアドレス。
ar$spaは応答側のプロトコルアドレス（以下の注意点を参照）。
ar$thaは目的のハードウェアアドレスで、要求時に与えられたものと同じ
である必要がある。
ar$tpaは目的のプロトコルアドレス、すなわち求めているアドレス。
オペコードが4のパケットにおけるar$spaが応答側のプロトコルで埋められる
という要求は、純粋に便宜上の話であることに注意。例えば、ARPとRARPの両
方を使用するシステムの場合、正しいプロトコルアドレス・ハードウェアア
ドレスの組（ar$spa、ar$sha）を入れれば、続いて出されるはずのARP要求が
不要になるかもしれない。
Finlayson、Mann、Mogul、Theimer [Page 3]
RFC 903 1984年6月
IV. 参考文献
[1] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,
MIT-LCS, November 1982.
付録A. 4.2BSDにおける2つの実装例
以下の実装は、4.2BSDにおけるRARPサーバの実装に対する2つの異なるアプロ
ーチの概略を述べたものである。
A. カーネルの外部でデータリンクレベルのパケットへのアクセスを提供する。
RARP サーバは完全にカーネルの外部で実装され、 カーネルとのやり取りは
RARPパケットの受信と送信のためだけである。カーネルは、これらのパケッ
トに対する適切なアクセスを提供できるよう修正される必要がある。現在、
4.2カーネルはIPパケットだけしかアクセスできない。この機能を提供する既
存のメカニズムの1つは、CMU「パケットフィルタ」擬似ドライバである。こ
れは、よく似た「ユーザレベル」ネットワークサーバの類を実装するために
CMUとStanfordでうまく使われた。
B. カーネル内部にデータベースエントリのキャッシュを保持する。 完全な
RARPサーバデータベースはユーザプロセスによってカーネルの外部で保持す
る。RARPサーバ自身はカーネルに直接実装され、その応答のためにデータベ
ースエントリの小さなキャッシュを持つ。このキャッシュはこれまでのARPに
使用されるものと同じであってもよい。
キャッシュは、2つの新しいioctlの利用によって実際のRARPデータベースか
ら埋められる （これらは実際には特定のソケットと結びついていない点で
SIOCIFADDRに似ている）。1つ目の利用は「トランザクションが完了するまで
スリープ状態にして、完了したらその要求をユーザプロセスに渡す」ことで
ある。もう1つは「このトランザクションをカーネルテーブルに記入する」こ
とである。したがって、カーネルがキャッシュ内にエントリを見つけられな
いときは、（グローバル）キューに要求を入れて、それからwakeup()を実行
する。最初のioctlの実装は、sleep()を行った後、最初のアイテムをこのキ
ューから取り出し、ユーザプロセスに返すことである。カーネルはユーザプ
ロセスが応答するまで割り込みレベルで待っていることはできないので、ギ
ブアップできるように（そして要求しているホストが少し後に要求パケット
を再送してくるように）するか、第2のioctlが要求のコピーをカーネルに戻
した場合、その時点で応答を形成し送信できるようにするかである。
Finlayson、Mann、Mogul、Theimer [Page 4]
一覧
スポンサーリンク
