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サーバで多数のサブネット上のホストにサービスを提供できるようになった。

## 動作

### クライアントとサーバが同じネットワーク上にある場合

BOOTPサーバ側では、MACアドレスとIPアドレス・ホスト名の対応表を事前に用意する。ネットワークに接続された機器は自らのMACアドレスをブロードキャストし、これを受け取ったBOOTPサーバが、対応表に従ってIPアドレスを配布する。DHCPのような動的なIPアドレスの配布は行えない。

1. BOOTPサーバはUDPポート67でパッシブオープンコマンドを発行し、クライアントを待ち受ける。
2. クライアントは起動時にポート68でアクティブオープンコマンドを発行する。このメッセージはUDPユーザデータグラムにカプセル化されており、UDPユーザデータグラムはIPデータグラムにカプセル化されている。クライアントは送信元アドレスにオール0(0.0.0.0)、宛先アドレスにオール1(255.255.255.255)を使用する。
3. サーバはクライアントのMACアドレスから割り当てるべきIPアドレスを認識する。サーバは、送信元ポート67・宛先ポート68のブロードキャストまたはユニキャストのUDPメッセージで応答する。

### クライアントとサーバが異なるネットワーク上にある場合

BOOTPリクエストの問題は、リクエストがブロードキャストで送信されることある。ブロードキャストのIPデータグラムはルータによって破棄されるため、ルータを通過することができない(異なるサブネットへ送信できない)。この問題を解決するために、リレーエージェントが導入された。ホストまたはルータは、リレーエージェントとして動作するようにアプリケーション層で設定できる。以下に、リレーエージェントの動作を示す。

1. リレーエージェントはBOOTPサーバのユニキャストアドレスを知っており、ポート67でブロードキャストメッセージを待ち受ける。
2. リレーエージェントがブロードキャストパケットを受信すると、メッセージをユニキャストデータグラムにカプセル化し、BOOTPサーバに要求を送信する。
3. ユニキャストのパケットはルータを通過することができ、パケットがBOOTPサーバに到達する。BOOPサーバはリレーエージェント宛に応答を送信する。
4. 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 により更新。 |
|