Bootstrap Protocol
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 により更新。 |
関連項目
編集脚注
編集- ^ Bill Croft (September 1985). “RFC 951 - Bootstrap Protocol”. Network Working Group. 2019年3月28日閲覧。
外部リンク
編集- RFC 951 - BOOTSTRAP PROTOCOL (BOOTP)
- BOOTP Sequence Diagram (PDF)
- Multicast BOOTP for configuring a network device