RARP/ARP の謎

SunOS では、RARPサーバである rarpd が TFTP とも絡んでいます。rarpdは、ディスクレスクライアントから RARPのリクエストを受け取ると、まず /tftpboot 以下にある、TFTP用のブートファイル (クライアントのIPアドレスが 192.168.1.1 なら、 ブートファイルは C0A80101.SUN4M のようなファイル名になる) を調べて、該当のファイルがあればすぐにRARPに応答し、 無ければ delayed responder と呼ばれるモードでわざと少し遅れて応答します。

これは、同じネットワーク内にRARPサーバが複数存在する場合に、 /tftpboot 以下にブートファイルを持つ適切なサーバに先に応答させ、 そのサーバをブートサーバとしてディスクレスクライアントをブートさせるためです。

RARP と TFTPとの絡みはこれだけではありません。 rarpd は、RARPに応答する際に、カーネルの ARP テーブルに、問い合わせのあったクライアントの IPアドレスとMACアドレスの組みを直接書き込みます。 これは、古い SPARCマシンの ROMモニタが、RARP で取得した自分のIPアドレスに対する ARPに応答できないため、RARPサーバ側であらかじめ ARPテーブルを作成して、クライアントのIPアドレスに対して ARPの問い合わせを行なわないようにするためです。

この仕組みにより、ディスクレスクライアントは RARP のあと、すぐに IP的に通信が行なえるようになり、TFTP で自分がブートするためのブートファイルを読み込むことができるのです。

RARPサーバの設定の際、テストのため、サーバマシン自体の MACアドレスを /etc/ethers に登録し、適当なテストプログラムでサーバマシン自身の MACアドレスを使って RARPの問い合わせを行なうこともあるでしょう。

この場合、上記の ARPテーブル作成の仕組みにより、自分自身の MACアドレスとIPアドレスの組みが自分のカーネルの ARPテーブルに登録されます。

このように自分自身のARPテーブルができてしまうと、悪いことに、 SunOS 4.1.4 では、自分自身と IP的に通信できなくなってしまうのです！

NIS を使用している場合、自分自身が NISサーバかつ NISクライアントになりますが、 自分自身と IP的に通信できないと、まず、NISの問い合わせがすべてできなくなり、 たとえば ls -l のような通常のコマンドのほとんどがハングして動かなくなります。

どうやら、SunOS 4.1.4 では、ARPテーブルに登録された IPアドレスは、無条件に自分以外のマシンであるとみなしているようで、自分自身と通信しようとして不適切にもイーサネット上にパケットを送信してしまうようです。 これは、宛先が自分自身のIPアドレスなので、当然誰も応答しません。

このようなことがあるため、/etc/ethers に自分のMACアドレスを登録して、そのMACアドレスを使った RARP の問い合わせを行なってはいけません。

現状では、このような RARP と TFTP との絡み (ARPテーブルと delayed responderの2点)はすでに obsolete と思われるため、純粋に MAC->IP 変換機能のみを実装した rarpd を自作するのもいいかも知れません。その際には、データリンク層へのアクセスのため、SunOS 4.xでは NIT (SunOS 5.x では DLPI, FreeBSD などでは BPF) を使う必要がありますが、プログラム自体はそれほど難しくないはずです。