要約

  • DHCPv4の動的リースでは、T1で貸与元サーバーとのRENEWINGが始まり、T2でブロードキャストによるREBINDINGへ移り、ACKがないまま満了すれば現在のアドレスを使う権限が終わる。
  • 再結合は到達できる全サーバーを権威者にする仕組みではない。別サーバーがリースを延ばせるのは、ローカルな管理権限を持つ場合だけであり、通信がまだ通るという観測は期限を延長しない。

見えないところで応答者が入れ替わる

DHCPを「起動時にアドレスをもらうプロトコル」と捉えると、重要な場面を見落とす。動的アドレスを使っている時間の大半で、クライアントは既に設定済みだ。通信も続いている。その裏で、誰に継続を尋ねるべきかだけが変わっていく。

最初の窓では、過去の判断を知る一台に聞く。次の窓では、障害を越えるために問いを広げる。そして最後には、どこからも肯定が得られなかったという事実よりも、期限そのものを優先する。

これは単なる再送アルゴリズムではない。残り時間に応じて権限の探索範囲を広げながら、クライアント自身には契約を延長させない状態機械である。

BOOTPから「返せるアドレス」へ

1993年10月の RFC 1541 は、DHCPの動的割り当てを、限られた期間または明示的な解放までのアドレス付与として記述した。サーバーが管理するのは、IPアドレスを含む設定とクライアントを結ぶbindingである。

この有限性によって、アドレスプールは再利用できる。同じアドレスを異なるクライアントへ時間をずらして貸せるのは、最初の割り当てを永久の所有と見なさないからだ。

1997年3月の RFC 2131 は、自動、動的、手動という三つの割り当て方を維持した。自動割り当ては永続的になり得る。手動割り当ては管理者の選択を運ぶ。時間制限と再取得状態が中心になるのは動的割り当てである。

したがって、リースはアドレス文字列に付いた有効期限ではない。ローカルな運用方針が、あるクライアントと構成を一定期間だけ結び付ける判断である。

51、58、59は別々の約束を表す

RFC 2132 は、オプション51をアドレスのリース時間、58を更新時間T1、59を再結合時間T2に割り当てている。どれも割り当てからの秒数であり、カレンダー上の時刻ではない。

有効なT1とT2がサーバーから渡されなかった場合、RFC 2131の既定値はそれぞれリースの二分の一と八分の七になる。多数の端末が同時に動かないよう、多少の揺らぎも推奨される。ただし、この比率は標準が用意したフォールバックであって、あらゆる現場に適した設定値ではない。

三つの値には役割の違いがある。T1は貸与元との対話に時間を確保する。T2は満了前に別の正当な経路を試す余地を残す。満了は再試行の目安ではなく、現在のbindingが終わる線である。

T1では、過去の判断を持つサーバーへ戻る

BOUNDのクライアントはT1でRENEWINGへ入る。貸与元のアドレスを知っていれば、そこへDHCPREQUESTを送り、使用中のアドレスを ciaddr に入れる。新しい複数の提案を選び直す場面ではない。

この優先関係には意味がある。貸与元は、自分が作ったbinding、プールの方針、延長時に変更すべき構成を最もよく知る。DHCPACKで新しい期間を与えることも、パラメーターを変えることも、管理方針に従って延長を拒むこともできる。

一度返事がないだけなら、既存リースは消えない。クライアントは残り時間を根拠に通信を続け、T2まで再送する。制御系の短時間の故障を即時の通信断にしない一方、無回答を無期限の承認にも変えない設計だ。

T2で広がるのは受信範囲であって、権威ではない

ACKがないままT2に達すると、クライアントはREBINDINGへ移る。DHCPREQUESTをブロードキャストし、ciaddr には現在のアドレスを置き、サーバー識別子は付けない。元の一台へ届かなくても、他のサーバーが要求を受け取れる。

だが、要求を受信したことは、リースを延ばす資格の証明にならない。RFC 2131が別サーバーによる延長を認めるのは、そのサーバーにローカルな管理権限がある場合だけである。複数サーバー構成では、リース状態と運用上の委任を整合させなければならない。

ここに再結合の本質がある。障害に備えて応答者集合を広げるが、ネットワーク上の到達可能性を権限へ昇格させない。状態が古いサーバーが応答できてしまえば、利用中のアドレスを空きと判断する危険がある。ブロードキャストは共有管理を作るのではなく、共有管理があることを前提にする。

三つの結果を混ぜてはいけない

RENEWINGまたはREBINDINGでDHCPACKを受けると、クライアントは返されたリースと構成を記録し、新しいT1とT2を始める。構成値が変わる場合もあるため、更新は単なる期限の儀式的な延長ではない。

DHCPNAKは、現在の構成が受け入れられないという明示的な否定だ。クライアントはアドレスの使用を止め、初期化へ戻る。否定後も使い続ければ、古い記憶は管理された割り当てと競合する主張になる。

沈黙は、残り時間がある間はどちらでもない。既存リースを維持したまま有限の再送を行う。しかしACKなしでリースが満了すれば、RFC 2131はINITへの移行、他のネットワーク処理の停止、未設定状態からの再取得を求める。

その瞬間にも、スイッチのリンク表示は点灯し、近隣キャッシュは応答し、ルーターは転送するかもしれない。それらは物理的・局所的な可用性の証拠であり、アドレス使用権の証拠ではない。

保存済みアドレスは再起動で権利に変わらない

再起動した端末が以前のアドレスを覚えていることは珍しくない。INIT-REBOOTは、そのアドレスをもう一度求める道を用意する。しかし保存値は提案であり、現在の許可ではない。

古いサーバーやネットワークがまだ適切か分からないため、要求はブロードキャストされる。サーバーはDHCPACKで認めるか、DHCPNAKで退ける。サーバーに接触できない場合も、RFC 2131が旧構成の使用を認めるのは、元リースの未満了部分に限られる。

継続を尊重しながら、クライアントの記憶だけでは現在の権威を作らない。この線引きが、同じアドレスで再開できる便利さを安全側に保つ。

FORCERENEWは時計の前に判断を呼び戻した

初期の状態機械は主にクライアント側のタイマーで動く。RFC 3203 は後に、サーバーがT1より前に通常のRENEW状態へ移るよう促すユニキャストFORCERENEWを導入した。構成変更を早く反映したい場合などが想定される。

FORCERENEW自体が新設定を書き込むわけではない。通常のDHCPREQUESTを起こし、アドレスを撤回したいサーバーはDHCPNAKで応答して、クライアントを発見工程へ戻す。

偽造された要求は稼働中の通信を何度も中断できる。このためRFC 3203は、RFC 3118 の手続きによるFORCERENEW認証を要求した。早期の再判断にも、出所と正規の状態遷移が要る。

ACKはリンク上の重複不在まで証明しない

正当なDHCPACKがあっても、同じローカルリンクで別ホストがそのアドレスを使っていないとは限らない。管理サービスによる割り当てと、現場で観測される競合は別の証拠である。

RFC 5227 は、新たに設定したIPv4アドレスを使い始める前にプローブするよう求める。競合を検出したDHCPクライアントはDHCPDECLINEを送る。サーバーの計画がリンク上の反証に出会えば、割り当ては見直される。

リースから言えるのは、管理されたサービスがある期間、あるクライアントへアドレスを割り当てたことまでだ。利用者本人の認証、法的所有、エンドツーエンドの到達性、重複の不存在までを保証するものではない。

出典と証拠の限界

歴史およびプロトコル上の記述は、RFC 1541、RFC 2131、RFC 2132、RFC 3118、RFC 3203、RFC 5227に基づく。

これらが定義するのはDHCPv4の契約である。現在の特定製品やネットワークの既定値、フェイルオーバー構成、実装の正しさ、普及率は示さない。DHCPv6は別のプロトコルであり、T1とT2の既定比率も、全サーバーが送信し全クライアントが採用する証拠にはならない。