要約

  • RFC 3396 は、同じ DHCPv4 オプションコードの反復を一つの論理値の連続断片とした。分割理由は255オクテット上限だけでなく、オーバーロード先フィールドの残量でもよかった。
  • 復元順は options、file、sname で、パケット内の物理順とは異なった。切れ目に意味はなく、正しい送信だけでは既存受信機の再構成成功を証明できなかった。

古い形式を拡張すると、パケットには二つの順序が生まれることがある。フィールドが実際に並ぶ順序と、中身を一つの値として読む順序である。RFC 3396 は DHCPv4 に後者を明示し、前者をそのまま意味の順序にしてはならないと警告した。

文書は2002年11月に標準化過程の RFC として公開された。可変長 DHCP オプションは、1オクテットのコード、1オクテットの長さ、0から255オクテットの値で構成された。長さ欄そのものが、一インスタンスに入る値を255までに制限していた。

RFC 2131 は同じコードの反復を連結すると述べていたが、完全な順序を定めていなかった。さらに、別文書の指定がなければ一度しか現れないという一般文もあった。RFC 3396 はその文を削除し、同一コードの複数出現を、解釈前に連結すべき断片として統一した。

分割は長さだけの問題ではない。255未満の値でも、現在の出力領域の空きが足りず、別のオプション領域に余裕がある場合がある。送信側は規定の方法で分けるか、オプションを送らないかを選ぶ。一つの符号化インスタンスが二つのフィールド境界をまたぐことはできない。

三領域は BOOTP 由来だった。通常の optional parameters に加え、option overload が有効なら固定の file と sname もオプションを格納できる。RFC はこれらを論理的な集約オプションバッファとして扱い、通常 options、file、sname の順に並べた。

そして、この順序はパケットの物理フィールド順ではないと明記した。集約バッファは読み書きの抽象であり、線上形式を変えるものではない。構造体のアドレス順に同一コードを足すだけの実装は、合法な断片を逆順にする恐れがあった。

各断片は通常の可変長オプションとして符号化され、同じコードを持ち、値は255オクテット以下だった。断片長の合計は元の長さになる。三領域を使うなら、第一片は通常領域、第二片は file、第三片は sname へ入り、物理位置の見かけでは順序を変えない。

切断は任意のオクテット境界で許された。だからこそ、切れ目に意味を持たせることは禁止された。ドメイン名、経路、サブオプション、レコードの終端ではない。前の容器の容量が尽きたことしか表さない。

受信側は解釈を待たなければならない。同じコードを二つ以上見つけたら、集約順に値を連結し、一つのオプションとして初めて処理する。断片ごとに検証や公開を行えば、送信側が作っていないオブジェクトを作り出す。

メモリアラインメントも受信側の責任だった。送信側は相手 CPU に都合のよい位置で切る義務を負わない。復元した値を安全にコピー・参照するための処理は、各機械の実装が担う。

Bootfile Name の例は、短い /diskless/foo をオプション67の二片に分けた。/diskle と ss/foo は別々のファイル名ではない。二片が連続して初めて元の名前になる。境界が無意味だから、短い例でも規則が見える。

歴史的に重要なのは互換性の告白である。2002年当時、配備済み DHCP エージェントの多くは連結を実装していなかった。標準に従った送信者でも、片方しか読まない、反復を別物とする、全体を捨てる受信者に遭遇し得た。送信の正しさは受信の証拠ではなかった。

そこで RFC は、連結を必須とするオプションと、そうでないものを分けた。前者になるには、当該オプションの仕様が RFC 3396 を明示的に参照し、実装を要求する必要があった。送信側は、不可避、相手能力の根拠、または管理者による明示設定がなければ分割を避けるべきだった。

相手が必須カテゴリのオプションを一つでも要求・提供していれば、連結能力を仮定できた。ただしそれは限定的な信号で、全長、全フィールド、全パーサー経路、下流適用の成功を保証しない。通常カテゴリを分割しない実装は許されたが、必須カテゴリを一つでも支える実装は、受信時には両カテゴリの反復を連結できなければならなかった。

認証の注意は、論理オブジェクトがセキュリティ計算にも先行することを示した。RFC 3118 の認証オプション自体が分割され得る。MAC の生成・検証前に認証フィールドをゼロ化するとき、そのフィールドが複数インスタンスにまたがる可能性を処理しなければならない。

RFC 3397 のドメイン検索、RFC 3361 の SIP プロキシ、RFC 3442 のクラスレス経路、RFC 3925 のベンダー識別は、それぞれ異なる内容でこの基盤を利用した。各文書が文法を定め、RFC 3396 が文法へ渡す一続きの値を復元した。

したがってキャプチャの証拠能力は狭い。全断片が観測点を通過したことは示せるが、クライアントが overload を認識し、正しい集約順を用い、反復を保持し、アラインメントと認証を処理し、設定を適用したことまでは示さない。各段階に実行時の受領証が必要だ。

RFC Editor の現行検索では RFC 3396 に該当する正誤情報はない。それは刊行記録であり、実装証明ではない。文書自体が、以前の曖昧さと既配備コードの不統一を修復するために存在した。

Lu Heng の「最小初期仕様」は、コード同一性、論理順、連続性、境界無意味性だけを共有契約にした節度を説明する。「動くコードの優位性」は、扱いにくい切断、三フィールド、最終適用までを実機で試す責任を付け加える。

RFC 3396 は、場所を輸送手段に戻し、意味を復元後の一体性へ置いた。断片の大きさも場所も違ってよい。受信側に必要だった最初の知性は、個々を早く理解することではない。まだ理解しないことだった。

出典