ARPの逆(Reverse)の機能を持ったプロトコル。
このプロトコルは、自ノードのハードウェアアドレスから、その上位で動作するプロトコルアドレスを得るためのプロトコルである。
仕様はRFC 903
に簡潔に書かれている。
OSI参照モデルのネットワーク層に属するプロトコルで、Ethernetの上に直接実装されている。
EtherType(Ethernetフレームタイプ番号)は0x8035である。
プロトコル構造はARPと同様で、その応用となっており、実際には様々なハードウェアアドレスやプロトコルアドレスに対応する汎用性の高いプロトコルとなっている。
最もよく使われたのがEthernetでの利用で、MACアドレスからIPアドレスを得るのに用いられた。
以降は、このEthernetでの利用を前提として解説する。
このプロトコルで自分のMACアドレスをLAN上にブロードキャストすると、ネットワーク上にいるRARPサーバーが(あれば)、そのノードのIPアドレスを返してくれる。
このような事をするのは、ディスクレス端末等は起動時に自分のMACアドレスは分かってもIPアドレスは分からないためである。MACアドレスは常に固定なのでROM等に記録できる。一方、IPアドレスは環境依存の可変なので何らかの方法で保存することが必要だが、このような端末ではそれができない。
そこで、RARPにより自分のIPアドレスを求める。この方法では、IPアドレスとMACアドレスの関係をRARPサーバー上だけで管理すれば良くなり、クライアント側でIPアドレスを設定する手間が必要なくなるというメリットがある。
先頭より順番に、次の情報が格納される。
ARPと全く同じである。RARPではオペコードが二つ拡張されている。
基本的には要求を投げ、その応答を待つ。
オペレーティングシステム(OS)であれば、通常は下位層(デバイスドライバーなど)が処理している。この処理が必要に応じてRARPパケットをブロードキャストし、その際、RARPサーバーが(あれば)応答を返すので、それを待つことになる。
RARPサーバーを実装する場合、自分で解決可能かを確認し、もしそうであったら、パケットの所定の欄に自分のMACアドレスを入れ、質問主にユニキャストで返信する。
ARPの仕様を記載したRFCは古いため現在主流の書式と違って分かりづらいが、基本はこれだけである。
送信時に未知のIPアドレスが必要になった場合、RARPの要求をネットワークに送信する。このパケットはブロードキャストで送信されるため、同じセグメント内にある全てのノードが受信できる。
この際、次の内容を設定して送信する。
RARP要求を受け取ったRARPサーバーは、そのRARP要求が自身で解決可能かどうかを判断せねばならない。もし無理であれば、そのRARP要求パケットは、そのまま破棄する。
まず、ar$thaが自分の管理下にあるかを確認し、あればRARP応答を、その送信元に対して返信せねばならない。
このとき、次の手順が必要である。
受信はブロードキャストだが、返信はユニキャストになる。
RARP応答を受信したノードは、送信元のIPアドレス(ar$spa)を参照し、IPアドレスを得る。
RARPで得られる情報はIPアドレスだけである。
ネットマスクやゲートウェイアドレス、DNSサーバーアドレスなどの情報は得られない。このため、この情報を使わない範囲でしか対応できない。
一時期は、RARPで設定するネットワークプリンターが良く見られた。
こういった限定された範囲内での用途であれば、これで充分だった。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます
通信用語の基礎知識検索システム WDIC Explorer Version 7.04a (27-May-2022)
通信プロトコル
