要約
- RFC 1542は、あるクライアントのBOOTREQUESTを常に同じ宛先または宛先群へ中継するよう求めた。
- ラウンドロビンで要求ごとにサーバーを替えると、同じクライアントの連続した要求が別々のサーバーに届く。
- クライアント識別情報に基づいて安定的に振り分ければ、複数クライアントを分散しながら各クライアントの交換を保てる。
ローカルブロードキャストの先へ
BOOTPは、起動時に自分のIPアドレスも起動情報を持つサーバーも知らない機器を想定していた。1985年のRFC 951は、アドレスを決め、起動ファイルを選ぶまでを最初の段階として記述する。クライアントはローカルネットワークにBOOTREQUESTをブロードキャストできる。しかしサーバーが別ネットワークにあれば、そのブロードキャストが通常のIPルーティングだけでサーバーまで届くわけではない。
そこでRFC 951は、協力するゲートウェイを介した起動を認めた。中継機能は任意で、ルーター上でもクライアントと同じネットワークにつながる別ホスト上でもよい。エージェントは要求を受け取り、giaddrが空なら受信インターフェースのアドレスを入れ、hopsを増やす。サーバーはgiaddrを返信先の手掛かりにできる。初期文書はこの仕組みを示したものの、中継エージェントの振る舞いは十分に細かく定義していなかった。
1993年10月のRFC 1532はBOOTPを明確化しようとした。同じ月のRFC 1542はRFC 951を更新し、RFC 1532の編集過程で誤りが入ったとして同文書を置き換えた。要約は、BOOTPリレーエージェントの動作が強化すべき対象だったと説明する。中継は単なる転送処理ではなく、クライアントの一連の通信が成立するかどうかに関わる役割として記述されるようになった。
要求単位の順番制御が抱えた問題
RFC 1542は設定の余地を運用者に残した。リレーの有効・無効を切り替える機構が必要で、初期状態は無効とする。hopsが16を超える要求は破棄し、より低い閾値も設定できるようにする。giaddrがゼロなら受信インターフェースのアドレスを入れ、hopsを増やし、残りのBOOTPフィールドは維持する。送信先も、単一アドレスか宛先群かを含めて設定できる。
一方、同じクライアントから届いたすべてのBOOTREQUESTは、同じ送信先または送信先群に向けなければならない。RFC 1542は、少なくとも一つの既知の中継実装がラウンドロビンで負荷を分散していたと記す。要求を受けるたびにサーバー一覧の次の宛先を選ぶため、同じクライアントの連続要求が異なるサーバーに届き得た。
問題はサーバーが複数あることではない。パケットごとに送信先を変える点にある。複数回の要求と応答を必要とするプロトコルでは、最初の要求を受けたサーバーと次の要求を受けたサーバーが異なると、交換に必要な状態が分かれてしまう可能性がある。RFC 1542はDHCPや他の複数交換型BOOTP変種で相性が悪いと説明する。特定の事故や、この方式の普及率を報告しているわけではない。
文書の提案は、負荷分散そのものを禁じるものではない。クライアントのリンク層アドレスなど、信頼できる識別情報をハッシュし、その結果で送信先を選べばよい。別々のクライアントを複数サーバーへ分散しつつ、同一クライアントの行き先を保てる。最も単純なのは、全要求を同じ宛先群に送ることだ。つまり分散の単位をパケットからクライアントへ変える。
規則が決めること、決めないこと
RFC 1542が保証するのは、中継先の一貫性までだ。サーバーが稼働していること、複数サーバーが状態を共有すること、起動が最後まで成功することまでは約束しない。全クライアントを一台に固定する義務もない。複数宛先を設定し、クライアントごとに安定して振り分ける方式が認められる。
同じ1993年10月のRFC 1534は、BOOTP形式を基礎とするDHCPとの相互運用条件を説明する。1997年のRFC 2131は、DHCPの段階的な流れをより詳しく定めた。クライアントがサーバーを発見し、オファーを受け、選択し、後続の要求を送る。これらは複数の交換が必要となる背景を示すが、RFC 1542の例が実際の本番障害を引き起こした証拠ではない。
RFC EditorはRFC 1542に一件の検証済み勘誤を掲載している。第3.1.1節のブロードキャストフラグ説明で、BOOTREPLYをBOOTREQUESTに直すものだ。ここで扱う第4.1.1節の中継先ルールとは別の箇所であり、クライアント別の宛先維持を変更しない。
この規則が引く線は具体的だ。クライアントを単位にサーバーへ分散することはできる。同じクライアントのパケットごとにサーバーを替えると、複数段階の会話を切り離すおそれがある。RFC 1542は共通の制約を定め、リレーを有効にするか、どう安定して分散するかはネットワークの運用者に委ねた。
出典
- RFC 951 — Bootstrap Protocol
- RFC 1532 — Clarifications and Extensions for the Bootstrap Protocol
- RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol
- RFC 1542 検証済み勘誤 544
- RFC 1534 — Interoperation Between DHCP and BOOTP
- RFC 2131 — Dynamic Host Configuration Protocol
- Heng Lu, Note 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
