要約

  • オプション60はクラスの手掛かり、61はアドレス割当てのバインディングを探す鍵、55は要求と優先順、43はベンダー固有の不透明な情報である。
  • 観測したパケットは送受信された値の証拠にはなる。しかし製造元の真正性、物理端末の永続的な同一性、設定の適用や通信の成功までは証明しない。

1997年の運用担当者がDHCPの要求を一通だけ保存したとする。そこには製品名らしい文字列があり、別の識別子があり、設定項目の番号が並んでいる。三つを「この端末の情報」として台帳に貼り付けたくなる。ところが、その台帳ではサーバーによる分類、既存の割当ての検索、クライアントの希望が区別できなくなる。RFC 2132は、この違いを読み取るための資料でもある。

Steve AlexanderとRalph Dromsが1997年3月に公表した文書は、DHCPオプションとBOOTPのベンダー拡張を定義した。外側では原則としてタグ、長さ、値の順に読み、PadとEndだけ扱いが異なる。BOOTPのベンダー領域では、冒頭の四オクテットのマジッククッキーが後続の解釈方法を指定する。前史のRFC 1048から続くこの文法は、異なる実装がフィールドの境界を見つけるためのものだ。値の発信者が本物かどうかは、構文からは分からない。

オプション60は、クライアントが任意で示すベンダークラス識別子だ。サーバーが解釈するオクテット列であり、端末の種類や構成を示すようにベンダーが定められる。解釈できないサーバーは、そのクラス固有情報を無視しなければならない。対応して情報を返すなら、ベンダー固有の値にはオプション43を使うことが推奨される。つまり60は設定方針を分岐させる手掛かりになり得るが、製造証明でもサーバーへの命令でもない。

オプション43はその返答を入れる別の箱だ。内容は不透明で、意味を定めるのはベンダーである。複数項目があれば内側にもコード・長さ・値の形で封入することが推奨され、内側のコードは外側の共通DHCP番号と同じ意味とは限らない。内側のEndは封入された拡張の終わりであり、外側の選択肢全体の終わりではない。内側にEndがなければ、包んでいるフィールドの長さが終点になる。返答のバイト列を見ても、受信端末が解釈して適用したかどうかは残る。

オプション61の「クライアント識別子」はクラスとは違い、サーバーがアドレスのバインディングを保管するデータベースの索引になる。サーバーは不透明な対象として扱うことが推奨される。ハードウェア種別とアドレスでもよいが、それ以外の識別子もあり得る。接続先サブネットで使われる識別子の間で一意であることが必要で、選定責任はベンダーと管理者にある。索引に必要な一意性は、相手の認証ではない。同じ鍵が再び見えても、同一人物や同じ物理機器の継続を自動的に示さない。

オプション55は欲しい設定パラメータのコードを並べる。クライアントは好みの順に記せるが、サーバーが同じ順序で返す義務はなく、要求順に挿入するよう試みる義務がある。全項目が返る保証もない。さらに57はクライアントが受け取れるDHCPメッセージの最大長を示し、その合法的な下限は576オクテットだ。希望と受信可能な大きさは交渉の材料であって、実際に適用済みの設定一覧ではない。

RFC 2131を合わせて読むと、発見、提示、要求、確認、クライアント側の最終確認は別の段階だと分かる。特定のネットワークで何が動いたかを調べるには、一連のパケット、サーバーの方針とバインディング記録、端末が受け入れた状態、目的の通信の試験が要る。ここで挙げた文書は実在する事業者の導入率や結果を測定していない。RFC 2132のセキュリティ節も、セキュリティ問題を論じないと明記している。

この文書の歴史的な成果は、一つの拡張可能な交換で異種の設定を扱いながら、分類、割当ての記憶、要求、ベンダー内部の意味を区別したことにある。Heng Luの稼働するコードを重んじる議論は、仕様と現場の挙動を混同しないための編集上の視点として使える。RFCに存在しない認証機能を付け加える根拠ではない。

資料：RFC 2132、RFC 2131、RFC 1048、Heng LuのRunning-Code Primacy（編集上の解釈）。