要約

  • 通常の割り当てでDHCPACKはサーバー側のバインディングを確定する。クライアントは競合確認後にBOUNDへ入り、期限内の利用を得るが、所有権は得ない。
  • T1では元のサーバーへ更新を求め、T2では他のサーバーにも再バインドを求められる。更新なしに期限を迎えれば、直ちに利用を止めてINITへ戻る。
  • DHCPINFORMへのDHCPACKはアドレスを一つも割り当てない。同じメッセージ名でも、交換の文脈とフィールドが違えば意味も変わる。

設定完了が「自分のアドレス」に見えるまで

IPv4設定を持たない端末がネットワークに加わる。サーバーを探し、提示を受け、一つを要求してDHCPACKを待つ。応答後はインターフェースにアドレスが現れ、アプリケーションが動き、ログがその値で活動を整理する。利用者には、アドレスを受け取って所有したように映る。

RFC 2131が記述するのは、クライアントと設定のリース・バインディングである。選ばれたサーバーはデータベース上の関係を確定するが、クライアントは利用前にリンク上の重複をもう一度調べる。競合を見つければDHCPDECLINEを送り、最初からやり直す。サーバーの肯定は、現場で得られた反証を無効にしない。

RFC 2131の著者はRalph Dromsである。IETFの人物紹介は、1989年にDHCPを設計した作業部会を組織した人物とも説明する。彼が状態と期限を持つ動的設定の標準化を率いた、というのが慎重な帰属だ。その後の拡張、製品実装、個別運用まで一人の発明とするものではない。

許可を構成する時計

クライアントは希望アドレスや期間を示せるが、それはサーバーへの要求であって権利の宣言ではない。サーバーは管理方針に従って値を決め、DHCPACKで受け入れた設定を返す。リース期間は付加情報ではなく、権限の範囲そのものを形作る。

通常は期間の半分に当たるT1でRENEWINGへ移り、最初のサーバーへDHCPREQUESTを直接送る。成功しなければ、通常は八分の七に設定されるT2でREBINDINGとなり、応答可能な別サーバーにも要求を広げる。いずれも開始からの相対値で、サーバーが別の時刻を指定することもできる。

更新DHCPACKを得ないまま期限が切れた場合、扱いは明確だ。クライアントはそのアドレスによるネットワーク処理を直ちに停止し、設定を手放してINITへ戻る。アドレスは別の端末へ再利用され得る。終了点を明記した許可を、恒久的所有と読むことはできない。

無期限リースにも権利証はない

RFC 2132のIP Address Lease Timeでは、すべてのビットが1の値を無期限として使える。長期または無期限のリースは、端末設定を実質的に安定させ、制御通信を減らす。さらに有効期間中のDHCPACKは、その管理領域でサーバーが下した実効的な許可であり、単なる助言ではない。

しかし無期限は、予定された満了時刻がないという時間表現だ。操作する人を認証せず、他のネットワークに対する権利を作らず、管理者による構成変更も禁止しない。「長く続く」と「所有する」の間には、オプションが埋めない隔たりがある。

RFC 5227はリンク上の現実を別に確認させる。ホストはIPv4アドレスを使う前に競合を探り、衝突に応じて防御または放棄する。これはDHCPサーバーを上書きする仕組みではないが、リース台帳だけが完全な現況ではないことを示す。制御面の許可と媒体上の空きを合わせて判断する設計だ。

アドレスを割り当てない確認

メッセージ名だけを読む危険はDHCPINFORMで明瞭になる。別の方法ですでにアドレスを設定したクライアントは、追加のローカル情報を問い合わせられる。サーバーはDHCPACKを返すが、この交換ではアドレスを割り当てず、バインディングを調べず、yiaddrを空にし、リース時間も含めない。

つまり同じDHCPACKが異なる行為に使われる。割り当ての状態機械ではバインディングを確定できる一方、INFORMでは追加設定を届けるだけだ。観測したDHCPACKをすべて「このサーバーがこのクライアントへアドレスを配った」と記録すれば、資産台帳は存在しない由来を作る。

RFC 6842は応答の対応付けを改善する。定められた場合にDHCPOFFERとDHCPACKへクライアント識別子を反映させ、どの交換への返答かを認識しやすくする。ただし識別子は自然人の認証でも、所有権の資格情報でもない。

サーバーが権威を持つ範囲

RFC 4388のLeasequeryは、サーバーの見方をACTIVE、UNASSIGNED、UNKNOWNとして返し、有効なリースなら残り時間も示せる。照会は状態を取得するだけでバインディングを変えない。その答えは照会先のリース・データベースについて権威を持つが、セグメント上の全端末や全パケットを網羅するとは限らない。

調査では、アドレス割り当てと行為の帰属を別の命題にすべきだ。履歴は、あるサービスがある期間、特定のクライアント識別子へ利用を認めたことを裏付ける。一人の人物が操作したこと、全トラフィックが同じ端末から出たこと、期間外も同じ関係だったことまでは単独で証明しない。

DHCPの証拠価値が低いのではない。サーバー履歴、識別子、リレー情報、リンク層の観測、競合検出、同期した時刻と組み合わせれば、むしろ堅い説明になる。確認応答には、それが設計された問いを尋ねる必要がある。

出典