要約

  • RFC 3925は、複数ベンダーのデータを明確な境界付きで一つのDHCPv4メッセージに運ぶ方法を定めた。
  • 外側のオプション番号は登録したが、内側のサブオプションコードと意味は各ベンダーに残した。PENは名前空間を示す番号で、認証の証明ではない。

RFC 3925以前、DHCPv4でベンダー固有情報をやり取りする一般的な形は限定的だった。RFC 2132のオプション60でクライアントがベンダークラス文字列を送り、オプション43で不透明なベンダー定義データを運ぶ。サーバーは60が示すベンダーの文脈で43を解釈する。単一ベンダーの語彙で足りる間は機能したが、機器や業界プロファイルが複数ベンダーの独立した情報を必要とすると曖昧さが生じる。RFC 3925が扱ったのは、アドレス割り当ての故障ではなく、情報の枠組みの衝突だった。

そこで新しい二つのオプションが導入された。124はVendor-Identifying Vendor Class、125はVendor-Identifying Vendor-Specific Informationで、各ベンダーのデータにIANAのPrivate Enterprise Numberを添える。125には複数の項目を含められ、項目ごとに企業番号、長さ、ベンダーデータを記す。長さがデータの境界を、番号が適用するベンダー文脈を示す。RFC 3925は旧来の60と43を変更せず、両方式の併存を認めている。

重要なのは、登録と意味の階層が別だという点だ。IANAは外側のDHCPオプション番号を割り当て、Enterprise Numbersの登録簿はベンダー空間を指す番号を割り当てる。しかし、どちらの登録簿も中身の意味を決めない。内側はコード・長さ・値の形式を使うが、そのサブオプションコードは各ベンダーが定義し、IANAは管理しない。標準化されたのは複数の方言を混同せず運ぶ枠であって、それらを翻訳する共通辞書ではない。

パケットの長さにも上限がある。集約したデータが一つのオプションの長さ上限を超え得るため、RFC 3925は124と125をRFC 3396に基づく連結対象とする。受信側は重複する断片を一つの論理オプションに結合してから内部の項目を読む。各断片を別々のベンダー記録として扱うのではない。また、企業番号は全インスタンスを通じて一度だけ現れることが推奨され、重複時の動作は未定義だ。複数のベンダーを収容する枠組みでも、壊れた形式や重複のあらゆる組み合わせに意味を与えるわけではない。

RFC 3925は、先行するRFC 3315のDHCPv6用ベンダークラス／ベンダー情報オプションの設計を再利用した。これは文書に残る設計上の系譜であり、両プロトコルのデータ意味や普及状況が同じことを示すものではない。また、番号はベンダーを認証しない。RFC 3925自体はセキュリティを提供せず、必要な場合に使えるDHCP認証方式はRFC 3118が別に規定する。オプション内の番号は名前空間の選択子であり、署名ではない。

この点にRFC 3925の歴史的な意味がある。共存のため境界を明示しつつ、ローカルな意味はローカルに残した。外側の登録簿はコンテナの解析と名前空間の識別を助けるが、ベンダー固有バイトが何をするか、機器が本当にそのベンダーに属するか、実装がオプションを扱えるかまでは答えない。その確認には別の証拠が要る。RFCとIANA登録簿が示すのは設計とコード割り当てであり、採用率、相互運用性、運用結果ではない。

出典