Bootstrap Protocol（ブートストラップ プロトコル、BOOTP）は、コンピュータネットワークに接続されたクライアントが、IPアドレスやホスト名、サブネットマスク等を自動的に取得するためのプロトコルである。元々は RFC 951 で定義された。主に、オペレーティングシステムがブート（起動）する際に用いられる。
概要
ネットワークに接続されているコンピュータの電源を入れてオペレーティングシステムを起動すると、システムソフトウェアはBOOTPメッセージをネットワークにブロードキャストで送信し、IPアドレスの割り当てを要求する。BOOTP設定サーバは、要求に基づいて、管理者によって設定されたアドレスプールからIPアドレスを割り当てる。
BOOTPは転送プロトコルとしてUDPを使用する。サーバがクライアントの要求を受信するためにポート番号67を、クライアントがサーバからの応答を受信するためにポート番号68が使用される。なお、これらのポート番号はDHCPと同じである。BOOTPはIPv4でのみ動作する。
歴史的に、BOOTPはIPアドレスの割り当てのほか、UNIX系のディスクレスノード（英語版）でブートイメージ（英語版）のネットワーク上での場所を取得するのにも使用された。企業では、これを使用して、事前に設定されたクライアントのブートイメージを新しく導入したPCにロールアウトした。
ネットワークカードの製造元は、当初は初期のネットワーク接続を確立するためにブート用のフロッピーディスクを用意する必要があったが、後にインターフェイスカードのBIOSやオンボードネットワークアダプタを備えたシステムボードにプロトコルを組み込み、直接ネットワークブートを行うことが可能となった。
BOOTPにリースの機能を追加したDynamic Host Configuration Protocol(DHCP)によりBOOTPは置き換えられているが、BOOTPの一部はDHCPプロトコルにサービスを提供するために使用される。DHCPサーバは、従来のBOOTP機能も提供する。
歴史
BOOTPは、1985年9月に公開された RFC 951 で最初に定義された。これは、1984年6月に RFC 903 で公開されたReverse address resolution protocol（逆アドレス解決プロトコル、RARP）を置き換えるものだった。RARPをBOOTPに置き換えることになったのは、RARPがリンク層プロトコルだったからである。このため、多くのサーバープラットフォームでの実装が困難となり、かつ、サーバを個々のサブネットに配置する必要があったためである。
BOOTPは、標準IPルーティングを使用してローカルネットワークからBOOTPパケットを転送するリレーエージェントの技術を導入し、これによって1つのBOOTPサーバで多数のサブネット上のホストにサービスを提供できるようになった[1]。
動作
クライアントとサーバが同じネットワーク上にある場合
BOOTPサーバ側では、MACアドレスとIPアドレス・ホスト名の対応表を事前に用意する。ネットワークに接続された機器は自らのMACアドレスをブロードキャストし、これを受け取ったBOOTPサーバが、対応表に従ってIPアドレスを配布する。DHCPのような動的なIPアドレスの配布は行えない。
- BOOTPサーバはUDPポート67でパッシブオープンコマンドを発行し、クライアントを待ち受ける。
- クライアントは起動時にポート68でアクティブオープンコマンドを発行する。このメッセージはUDPユーザデータグラムにカプセル化されており、UDPユーザデータグラムはIPデータグラムにカプセル化されている。クライアントは送信元アドレスにオール0(0.0.0.0)、宛先アドレスにオール1(255.255.255.255)を使用する。
- サーバはクライアントのMACアドレスから割り当てるべきIPアドレスを認識する。サーバは、送信元ポート67・宛先ポート68のブロードキャストまたはユニキャストのUDPメッセージで応答する。
クライアントとサーバが異なるネットワーク上にある場合
BOOTPリクエストの問題は、リクエストがブロードキャストで送信されることある。ブロードキャストのIPデータグラムはルータによって破棄されるため、ルータを通過することができない（異なるサブネットへ送信できない）。この問題を解決するために、リレーエージェントが導入された。ホストまたはルータは、リレーエージェントとして動作するようにアプリケーション層で設定できる。以下に、リレーエージェントの動作を示す。
- リレーエージェントはBOOTPサーバのユニキャストアドレスを知っており、ポート67でブロードキャストメッセージを待ち受ける。
- リレーエージェントがブロードキャストパケットを受信すると、メッセージをユニキャストデータグラムにカプセル化し、BOOTPサーバに要求を送信する。
- ユニキャストのパケットはルータを通過することができ、パケットがBOOTPサーバに到達する。BOOPサーバはリレーエージェント宛に応答を送信する。
- BOOPサーバからの応答を受け取ったリレーエージェントは、それをクライアントに送る。
IETF標準ドキュメント
| RFC #
|
タイトル
|
発行日
|
廃止・更新
|
| RFC 3942
|
Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
|
2004年11月
|
RFC 2132 を更新
|
| RFC 2132
|
DHCP Options and BOOTP Vendor Extensions
|
1997年3月
|
RFC 1533 を廃止。 RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494 により更新。
|
| RFC 1542
|
Clarifications and Extensions for the Bootstrap Protocol
|
1993年10月
|
RFC 1532 を廃止。 RFC 951 を更新。
|
| RFC 1534
|
Interoperation Between DHCP and BOOTP
|
1993年10月
|
|
| RFC 1533
|
DHCP Options and BOOTP Vendor Extensions
|
1993年10月
|
RFC 1497, RFC 1395, RFC 1084, RFC 1048 を廃止。 RFC 2132 により廃止。
|
| RFC 1532
|
Clarifications and Extensions for the Bootstrap Protocol
|
1993年10月
|
RFC 1542 により廃止。RFC 951 を更新。
|
| RFC 1497
|
BOOTP Vendor Information Extensions
|
1993年8月
|
RFC 1395, RFC 1084, RFC 1048 を廃止。RFC 1533 により廃止。 RFC 951 を更新。
|
| RFC 1395
|
BOOTP Vendor Information Extensions
|
1993年1月
|
RFC 1084, RFC 1048 を廃止。 RFC 1497, RFC 1533 により廃止。 RFC 951 を更新。
|
| RFC 1084
|
BOOTP vendor information extensions
|
1988年12月
|
RFC 1048 を廃止。 RFC 1395, RFC 1497, RFC 1533 により廃止。
|
| RFC 1048
|
BOOTP vendor information extensions
|
1988年2月
|
RFC 1084, RFC 1395, RFC 1497, RFC 1533 により廃止。
|
| RFC 951
|
Bootstrap Protocol
|
1985年9月
|
RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494 により更新。
|
関連項目
脚注
外部リンク
