第 11 回 IP アドレスの配布

本日の内容

• 11-1. IP アドレスの配布
• 11-2. RARP
• 11-3. BOOTP
• 11-4. DHCP

このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。

11-1. IP アドレスの配布

ディスクレスワークステーション

多くのコンピュータを一括集中管理するのに、ディスクレスという方法があり ます。 これは各コンピュータにはハードディスク等の記憶装置を与えず、サーバ上の ネットワークドライブを利用するものです。 この仕組みにより、OS のバージョンアップ等の保守管理をサーバのみの操作 で可能になります。 但し、各コンピュータは起動ドライブすら存在しないので、起動するための仕 組みが必要です。 古くから行われてきた、 UNIX 系の OS では次の手順で起動します。

1. IP アドレスの取得
2. 初期プログラムの読み込み
3. 初期プログラムの実行による OS の起動

IP アドレスの取得には、歴史的な順番として RARP、 BOOTP と使われ、現在 の主流は DHCP になりました。 初期プログラムは TFTP(Trivial File Transport Protocol) という簡素化し たファイル転送プログラムを使用します。 ディスクレスコンピュータにはこの IP アドレスの取得プロトコルのどれかと TFTP クライアントのプログラムが内蔵され、 TFTP でダウンロードしたプロ グラムを実行するという機能が内蔵されます。

本章ではこの IP アドレスを取得する RARP、 BOOTP、 DHCP を解説します。

なお、パソコンにもネットワークから起動するための仕組みとして、 Intel が制定した PXE(Preboot eXtension Environment) があります。 これは最近のパソコンにはこの PXE が内蔵されています。 そのため、ちょっとした設定によりネットワーク上の OS を起動することがで きます。 一方、マイクロソフトは RIS(Remote Install Service)という、ネットワーク 上にある Windows OS のインストーラを起動する仕組みを提供しています。 これはディスクレスを実現するものではありませんが、ネットワークサーバに よる集中管理は実現できます。

11-2. RARP

RARP は RFC 903(1984) に規定されています。 これは ARP プロトコルを利用して、逆に MAC アドレスに対して IP アドレス を割り当てます。

RARPのプロトコル

ここでは、MAC アドレス E_X を持つ ホスト X が、RARP サーバ(IP アドレス I_Y、MAC アドレス E_Y)に対して、IP アドレス I_X を問い合わせる時のプ ロトコルの流れを示します。

問い合わせ

RARP の問い合わせをするには、次のようなパケットを Ethernet フレームに入 れてサーバにユニキャストします。

返答

RARP の問い合わせに対して、返答するには、次のようなパケットを Ethernet フレームに入 れて送信者にユニキャストします。

欠点

Ethernet 専用

Ethernet のパケットを利用するので、Ethernet のみにしか使えない。 IP アドレスを自動的に割り振る要求は Ethernet のみに限られる問題ではな いので、この方式だと同じ仕組のためにネットワーク方式ごとにプロトコルを 作らなければならない。

Ethernet アドレスを使う

ハードウェアアドレスを使用すると、サーバを入れ替える際、全ての端末 の設定を変える必要がある。

Ether パケット

同一 Ethernet 上のみで有効なので、ルータを越えられない。 複数のネットワークがある場合、それぞれのネットワークに RARP サーバが必 要。 この要求に応えるためには、 IP 層以上のレイアのプロトコルにする必要があ る。

Ethernet プロトコルとレイヤが同じ

このサーバのプロトコルはアプリケーションレイヤではなく、データリンク層 に存在する必要がある。 したがって、既存の Ethernet プロトコルドライバに対してサーバのみ書き換 えを必要とする 。

デフォルトゲートウェイアドレスが得られない

IP の端末の設定には必須な情報が欠落しているので、 RARP とは別に与 える必要がある。

11-3. BOOTP

BOOTP は RFC 951 (1985) に規定されています。 これは UDP の 67(サーバ用) と 68(クライアント用)を利用したアプリケーショ ンプロトコルです。 交換する情報は IP アドレス、サーバアドレス、サーバ名、ゲートウェイアド レス、起動ファイル名、オプションなどです。

1. パケットは単一。再送のためにタイムアウトが用いられる。双方で、同じ フィールドを用いる(ARP や RARP では一人称、二人称だったので、欄を交換 していた)。 ハードウェアアドレス欄は 16 バイトの固定長とし、パケットの解析を容易に した。
2. opcode は bootrequest と bootreply の二種類
3. サーバ名を書くことができ、クライアントは DNS サーバ使用せずにサー バを指定できる。
4. 起動用のファイル名を指定できる
5. サーバはハードウェアアドレスと IP アドレスのデータベースを持ってい て、クライアントが IP アドレスを要求した際は、クライアントのハードウェ アアドレスに対応した IP アドレスを渡す。
6. 同一物理ネットワーク上にサーバが無くても起動ができる

パケットの構造

鶏と卵問題

BOOTP をやり取りする端末は、アドレスを要求する端末です。つまり、その端 末にはアドレスがありません。 アドレスなしでやり取りするにはどうすればいいのでしょうか？

1. クライアントからサーバはブロードキャストアドレスを用います
2. サーバからクライアントには
   1. クライアントがアドレスを知っていれば通常のユニキャスト
   2. クライアントがアドレスを知らないときは
      1. サーバの OS が arp テーブルの変更を許してくれる時、 サーバはクライアントから送られてきた haddr(MAC アドレス)と設定させる IP アドレ スを arp テーブルに加え、ユニキャストする
      2. サーバの OS が arp テーブルの変更を許してくれない場合は、 UDP 68 ポートにブロードキャスト

クライアント

なお、一定時間返答が無かった場合は、クライアントは要求を再送する。 これは最初は 4 秒後に送り、その後は巾乗バックオフを行なう。 64秒まで達したら、その後もランダムにスロットを選ぶが、秒数を増やさない。 なお、再送時は secs フィールドに経過時間を入れる。

サーバ

BOOTREQUEST を受け取った場合

1. 受け取ったパケットの宛先ポート番号が BOOTP サーバで無ければパケッ トを捨てる
2. sname フィールドが NULL でなく、自分の名前以外が書かれている場合
   1. 単純に捨てても良い
   2. sname が同一ネットワーク上にあるとわかった場合は、パケットを捨てる
   3. sname が別ネットワークにあるとわかった場合は
      1. giaddr フィールドを調べる。0 だった場合、 giaddr に自分のアドレス、あるいは指定されているゲートウェ イアドレスを入れる。
      2. パケットを転送する。
3. ciaddr が 0 なら、chaddr, hlen, htype を元に、クライアントにふさわ しい IP アドレスをデータベースより求める。 ふさわしいアドレスが無ければパケットを捨てる。 あれば yiaddr に入れる。
4. file フィールドに書かれているファイル名と、手持ちの表を比較し、ど れとも該当してなければパケットを捨てる。 さもなければふさわしいファイル名を file フィールドに入れる。
5. vend フィールドを調べる。認証などに使用している場合はこの段階で処 理する。
6. 自アドレス(サーバアドレス)を siaddr に入れる。 op には BOOTREPLY を入れる。 ciaddr が 0 で無ければ、ここでパケットを送る。
7. giaddr が 0 でなければ UDP 宛先ポートを BOOTP のサーバポートし、 giaddr 宛にパケットを送る。
8. yiaddr フィールドを使って「ニワトリと卵」問題で議論した通りにパケッ トを送る

BOOTREPLY を受け取った場合

yiaddr が自分が接続しているネットワークに含まれるのなら、宛先ポートを BOOTP client に変更して、「ニワトリと卵」 問題で議論した通りにパケッ トを送る

11-4. DHCP

DHCP は RFC 2131 (1997) に規定されています(最初は 1993 年 に RFC 1531 に規定されました)。 BOOTP と上位互換を持ち、次のデザインゴールを持ちます。

1. ローカルな管理者はローカルなルールを反映できる
2. クライアントは手動操作を必要としない
3. クライアント毎の設定が不要
4. 全てのサブネット上にサーバを設置する必要は無い。 ルータあるいは BOOTP Relay Agent を利用してアクセスできる
5. クライアントは複数のサーバからの応答を受けることができる。これは パフォーマンスと信頼性の向上につながる
6. 手動設定された端末や他のプロトコルとの共存
7. BOOTP Relay Agent との協調
8. BOOTP クライアントへのサービス
9. どんなときでも二台以上が同一の IP アドレスを使用しない
10. クライアントは再起動しても設定を保持できること。また、可能な限りい つでも同じパラメータを使用できること
11. サーバが再起動してもクライアントはできるだけ同じ設定を使い続けられ ること
12. 新規の端末は手動操作無しで自動設定されること
13. 特定のクライアントに対して、固定あるいは恒常的な割り当てができること

特徴

DHCP は BOOTP の上位互換プロトコルになるように設計されています。 そのため、パケットのデータ構造も互換性があります。 そしてさらに、次のような高度な機能を持ちます。

1. クライアントの設定操作は不要
2. 同一ネットワーク上にサーバーを複数設置し、多重化できる
3. クライアントは再起動しても同一の IP アドレスを取得できる
4. サーバが再起動してもクライアントのアドレスを付け替える必要がな い
5. 手動で設定したクライアントと共存できる

パケットのの形式

DHCP のパケットの形式は、表面的には BOOTP のパケットと同じ形式になりま す。 しかし、実際に DHCP のプロトコルで交わす多くの情報は OPTION フィールド に書かれます。 Option フィールドの先頭に Magic cookie と呼ばれる特殊なバイト列が書か れた後、に必要な情報を書くことにより、 BOOTP プロトコルと区別します。 OPTION の書式は次の通りです。

なお、OPTION の最後はコード FF のみの END OPTION が置かれます。

OPTION フィールドに書かれる DHCP に必要とされる項目には次があります。

1. DHCP MESSAGE TYPE
2. Server Identifier
3. IP ADDRESS LEASE TIME
4. Requested IP ADDRESS

DHCP MESSAGE TYPE(コード 53)

Server Identifier(コード54)

クライアントがサーバを指定するときに IP アドレスを入れて使用する。

IP ADDRESS LEASE TIME(コード51)

IP アドレスの貸出し秒数を 32 bit の符号無し整数で指定する

Requested IP ADDRESS(コード50)

DHCPDISCOVER メッセージにクライアントが使用したい IP アドレスを入れ る。

DHCP のサービス

1. クライアントに対するネットワークパラメータの永続的な保存。 そのため、サーバにはデータベースを設置する。 クライアントとのやりとりにより、適切なパラメータを提供する。
2. クライアントに永続的、または一時的に IP アドレスを貸し出す。 通常、クライアントは定期的に REQUEST を行なう。 DHCP群は、 貸出し時間内に同じアドレスを割り当てないことを保証し、また、 同一クライアントには同一アドレスを割り当てる。 なおクライアントは貸出し期間内に、貸出し延長を申し出るか、アドレスを返 却する。 貸出し期間を過ぎると他のクライアントに貸し出すことがある。 この場合、割り当て時に重複チェックとして、サーバは ping、クライアント は ARP で調べる。

プロトコルの流れ

新規の割当

1. クライアントは DHCPDISCOVER メッセージを物理アドレス上にブロードキャス トする。 DHCPDISCOVER メッセージにはオプションとしてネットワークアドレスやリー スの継続時間の提案を含めてよい。 BOOTP リレーエージェントは別のネットワークの DHCP サーバに転送しても良 い。

2. 各サーバは、利用可能なアドレスを yiaddr に入れ(他のパラメータも入 れた) DHCPOFFER メッセージで返答する。 このときのアドレスに関しては排他的に確保すれば、他との競合が無くなるが、 別に確保しておく義務は無い。 新たなアドレスを割り当てる場合、サーバは ping(ICMP Echo) により未使用 かどうか調べるべきである。 但し、この未使用を調べるかどうかは管理者により設定可能にすべきである。 もし必要なら、サーバは BOOTP リレーエージェントによりクライアントにメッ セージを送る。

   但し、 DHCP OFFER をする前に、サーバは割り当て履歴を確認し、以前要求が あった MAC アドレスに対しては、前回と同じ IP アドレスを割り当てます。

3. クライアントは複数のサーバからひとつ以上の DHCPOFFER を受け取る。 クライアントは DHCPOFFER のメッセージの設定項目に基づいてひとつのサー バを選択する。 クライアントは、選んだサーバの server identifier を含めた DHCPREQUEST を作成しブロードキャストする。 このとき、 request IP address オプションには必ず DHCPOFFER に含まれて いる yiaddr をセットしなければいけない。 また、 sec フィールドには DHCPDISCOVER でセットした sec フィールドと同 じ値を入れ、 DHCPDISCOVER メッセージをブロードキャストしたのと同じアド レスへブロードキャストする。

   なお、DHCPOFFER メッセージをひとつも受信できなかった場合は、タイムアウト して DHCPDISCOVER メッセージを再送する。

4. 全サーバはクライアントから DHCPREQUEST を受け取る。 選ばれなかったサーバはこのメッセージをクライアントからの断りのメッ セージとする。 選ばれたサーバはクライアントのための割り当てを記録し、クライアントから 要求されたパラメータの入っている DHCPACK メッセージを作り応答する。 client identifier または chaddr と割り当てられたネットワークアドレスの 組はクライアントの識別子として使われる。 なお、DHCPACK 内のパラメータは全て DHCPREQUSET と整合性がとれてないと いけない。 また、ここで提供するネットワークアドレスに関してはチェックすべきでは無 い。 DHCPACK の yiaddr には割り当てるネットワークアドレスを入れる。

   選ばれたサーバが DHCPREQUEST の要求を満たせない場合は、DHCPNAK を返答 すべきである。

   サーバはクライアントに割り当てたアドレスを利用不能としてもよい。 一方、もしサーバが DHCPREQUEST をクライアントから受け取ってないときは、 サーバは DHCPOFFER 中でクライアントに提案したアドレスは利用可能とすべ きである。

5. クライアントは 設定パラメータ付きのDHCPACK を受け取る。クライアントは そのパラメータに対して最終チェックを行なう。 ネットワークアドレスについては ARP 問い合わせを行なう。 この時点で、クライアントは設定が完了する。

   もし、クライアントがアドレスが既に使われていると ARP により察知した場 合は、クライアントは DHCPDECLINE を送り、プロトコルの最初からやり直す。 但し、ネットワークの混雑を避けるため、少なくとも 10 秒待ってから行なう。

   クライアントが DHCPNAK を受け取った、最初からやり直す

   もし、DHCPACK も DHCPNAK も受け取らなかったら、クライアントはタイムア ウトし、 DHCPREQUEST を再送する。 再送は巾乗バックオフにより行なう。 もし、巾乗バックオフによっても DHCPACK も DHCPNAK も受け取れなかった場 合はユーザに告知し、プロトコルを再起動する。

6. クライアントは DHCPRELEASE メッセー ジをサーバに送ることで、ネットワークの借用を止めてよい。 DHCPRELEASE メッセージには、アドレスを借りる時に使用した client identifier または chaddr とネットワークアドレスを入れ無ければならない。

前回のアドレスを使う場合

もし、クライアントが前回割り当てられたネットワークアドレスを覚えていて、 再度使用したい場合は、クライアントは前回のプロトコルの一部を省略できま す。

1. クライアントは DHCPREQUEST をブロードキャストします。メッセージ内の requested IP address に希望の IP アドレスを入れておきます。 但し、 IP address を受け取ってない場合は ciaddr 欄にはアドレスを入れて はいけません。 もし、IP address を受け取った際に client identifier を使用していたら、 今回も同一の client identifier を使用します。 なお、メッセージは BOOTP リレーエージェントにより転送されます。

2. クライアントの設定情報を覚えているサーバは DHCPACK を返します。 但し、ここでアドレスが素手にしようしているかどうかをチェックすべきでは ありません。 クライアントはもうアドレスを使用していて ping(ICMP Echo) に反応するか もしれません。

   もし(クライアントがサブネットをまたいで移動することなどにより)クライア ントの要求が誤っていたら、サーバは DHCPNAK をクライアントに送ります。 なお、クライアントの提示している情報が他のサーバの管理下にある場合など、 サーバは情報の正確さを保証できない場合は返答すべきではありません。

   giaddr が 0x0 なら、クライアントは同一物理ネットワーク上にあります。 したがって、サーバは DHCPNAK を 0xffffffff ブロードキャストアドレスに 送らなければなりません。これは、クライアントは誤った情報を持っているた め、ネットワークアドレス、サブネットマスクも当てにできず ARP にも反応 できないかもしれないからです。 giaddr が 0x0 でなければサーバは DHCPNAK を BOOTP リレーエージェントに 送ります。

3. クライアントは DHCPACK を受け取ったら、前回同様最終のチェック(ARP)を行 い、設定を完了させます。 但し、 IP アドレスが既に他に使用されていることがわかったら DHCPDECLINE をサーバーに送り、 DHCPDISCOVER からやり直します。 また、 DHCPNAK を受け取った場合も同様に DHCPDISCOVER からやり直します。

   もし、クライアントがタイムアウトした場合は巾乗バックオフにより DHCPREQUESET の再送を行います。 巾乗バックオフも失敗した場合、クライアントは前回得たアドレスや設定 を使っても構いません。

4. クライアントがアドレスの借用を止めようとした場合 DHCPRELEASE をサーバ に送ります。

IP アドレスは手動設定

新たなネットワークアドレスの割り当てが不要なクライアントが、他の設定項 目をサーバから取得したい場合は DHCPINFORM を送ります。 DHCPINFORM を受け取ったサーバは設定項目を記述した DHCPACK を作成します。 但し、 yiaddr には何も入れず、 ciaddr 宛のユニキャストで送ります。