要約

  • RFC 3011のオプション118は、DHCP要求が到着したネットワークとは別のサブネットからアドレスを割り当てるよう要求できるようにし、観測された入口と資源選択を分離した。
  • 応答中の同一オプションは処理能力についての限定的な受領証であり、要求者の身元、プールを使う権限、経路、重複不在、最終サービスを証明するものではなかった。

サーバーが見るものは、必ずしも利用者がいる場所ではない。リモートアクセス装置を考えるとよい。装置は内部ネットワークからDHCPサーバーへ到達する。一方、その配下の利用者には、別の外部ネットワーク用アドレスを渡さなければならない。内部と外部の間に通常のIP経路が存在しないことさえある。

RFC 2131の通常動作では、サーバーは中継のgiaddr、またはgiaddrがゼロなら受信したローカルインターフェースから割り当てサブネットを推定する。多くの場合、それは正しい。パケットの到着経路が、クライアントのネットワークを示すからだ。

しかしリモートアクセス装置の場合、その正しい観測から誤ったプールが選ばれる。要求は内部から来たという事実と、外部プールが必要だという事実は矛盾しない。2000年11月のRFC 3011は、両方を同時に表せるようにした。

IPv4 Subnet Selection Optionは、四オクテットのサブネットアドレスを運ぶ。対象サブネット内のIPv4アドレスにマスクを適用し、ホスト部をゼロにした値である。現在のIANA BOOTP/DHCPパラメータ登録簿でも、コード118、長さ4として記録されている。

対応を有効にしたサーバーにとって、これは参考情報ではない。オプション118はgiaddrや受信インターフェースからの通常推定に優先する。サーバーは指定サブネット、または同じネットワークセグメント上の関連サブネットから割り当てなければならず、その境界外のアドレスを提示してはならない。

ここで三つの座標が生まれる。第一は要求を観測した入口。第二は割り当て対象のサブネット。第三は応答を届ける先である。RFC 3011は第二だけを上書きし、第一や第三を消さなかった。

そのため、オプション118を含む要求では、要求者がDHCPパケットを受け取れるIPv4アドレスをgiaddrに設定する必要があった。更新時にサーバーが割り当て済みアドレスへ直接DHCPACKを送ろうとしても、外部アドレスへの経路がない場合がある。割り当て先と戻り道は同じフィールドでは表せない。

混在環境には、もう一つ小さな仕組みが用意された。オプションを処理するサーバーは、受け取った値を応答に同一のまま返さなければならない。クライアントがParameter Request Listで求めていなくても同様である。利用クライアントは、オプションがないDHCPOFFERやDHCPACKを破棄しなければならない。

古いサーバーは未知のコードを無視し、内部プールから普通に提示できる。新しいサーバーでも管理者が機能を無効にしていれば同じである。応答形式は正しくても、要求した割り当て契約は成立していない。エコーの欠如は、その差を失敗として見えるようにした。

ただし、エコーの意味を膨らませてはいけない。同じ四オクテットが返ったことは、サーバーがRFC 3011の処理経路を通った証拠である。要求者を認証した証拠でも、対象プールを使う資格の証拠でもない。アドレスへの経路、重複の不存在、利用者への引き渡し、通信成功も別に確認しなければならない。

この自由は攻撃面も広げた。当時のDHCPはそれ自体で認証を提供していない。ローカルプールにしか影響できなかった悪意あるクライアントが、非ローカルのサブネットを指定できれば、複数のプールを枯渇させられる可能性がある。

したがってRFC 3011は機能を既定で無効とした。明示的な設定が必要であり、特定のclient-id、特定の要求元、あるいは許可された対象サブネットだけに限定できることが望まれた。標準は命令の書式を定めたが、誰にでも命令権を与えなかった。

RFC 2132が与えたのはコード・長さ・値の共通文法だった。文法が解釈を可能にし、ローカル設定が実行権限を決める。公開されたオプション番号は、資源に対する委任状ではない。

その後の仕様は、類似する主張を運用者側の中継へ寄せた。RFC 3046はRelay Agent Informationを定め、回線や遠隔端を示す中継ローカル識別子を運べるようにした。RFC 3527は、サーバーが中継と通信するアドレスとは別に、割り当てリンクを指定するLink Selectionサブオプションを追加した。

クライアントのオプション118と中継のLink Selectionが同時に存在すると、後者が割り当てを支配する。これは同じ値の競争ではない。運用者が管理する中継と任意のクライアントでは、主張が置かれた信頼境界が異なるからである。

それでも、応答内にサブオプションが見えたことだけで処理済みとは断定できない。Relay Agent Informationは容器としてコピーされ得るため、RFC 3527は対応サーバーへの送信を管理上保証するよう求めた。RFC 3118はDHCP認証を定義したが、仕様の存在は個別ネットワークでの導入証拠ではない。

RFC 7969は後に、トポロジーに基づくDHCPカスタマイズを整理した。Subnet Selection、Link Selection、Virtual Subnet Selectionは似た名前でも異なる切れ目を扱う。到着点、物理リンク、論理ネットワーク、VPN、プール、戻り先を一つの位置情報に押し込めなくなった歴史である。

監査可能な記録は、入力インターフェース、観測した送信元、giaddr、client-id、オプション118、適用したポリシー、選択したプール、提示アドレス、返却オプション、応答先を別々に残す。その後にリース、ルート、近隣状態、加入者セッション、アプリケーション結果が続く。

Lu Hengのいう実行コードの優位性から見れば、RFC 3011は最小限の共同仕様だった。変更したのは、許可された場合のプール選択入力である。標準は相互運用を可能にし、採用範囲と権限判断はローカルに残した。

要求は内側から来た。アドレスは外側から取られた。応答は到達可能な第三の座標へ戻った。RFC 3011が残した重要な境界は、三つを一つの「場所」に見せないことである。

Sources