要約
- RFC 3679は、回収できる提案番号と、公開RFCの説明はないがすでに使用されていたPXE・Appleの番号を区別した。
- RFC 3942はプライベート範囲の番号に移行手順を設けた。後年、RFC 8910は実験でPolycomによる番号160の別用途が判明した後、キャプティブポータルの通知先を114へ移した。レジストリが示すのは調整状況であり、稼働機器の全数調査ではない。
文献目録が空でも、ネットワークは空ではない
DHCPはアドレス設定の際、サブネットマスクやルーターのアドレスなど、小さなパラメーターを運ぶ。オプション番号は共有名前空間の一部だ。放棄された提案が番号を永久に占有すれば、後続の作業余地が減る。一方、実際に展開済みのコードを再割り当てすれば、二つの機器が同じフィールドを異なる意味に解釈しかねない。
2004年1月のRFC 3679は、この両面を扱った。提案が失効したもの、公開定義に至らなかったもの、当時のフェイルオーバープロトコルで使われなくなったものなど、過去の割り当てを列挙し、それらをIANAの利用可能プールへ戻せるとした。しかし別の節では、PXEのオプション93、94、97は公開RFCに記載がなくても広く使われていると説明した。また、RFC文書がないAppleによる95および112〜114の利用にも言及し、DHCワーキンググループが方針を決めるまで割り当てを維持するよう求めた。判断の要点は、文書の有無だけではなく、使用実態の報告だった。RFC 3679
これは、文書化されていない用途ならすべて恒久的な公開番号に値する、という主張ではない。RFC 3679は回収理由を個別に示し、既知のPXE・Appleの用途とは分けて扱った。回収対象は、未割り当てまたはすでに返却された番号を使い切った後に利用可能プールへ戻すようIANAに指示している。これはInformational文書であり、そこに記された実装が今もすべて存在することや、現場の全割り当てが解決済みであることを証明するものではない。RFC 3679の状態
一覧から移行手順へ
同年後半のRFC 3942は、DHCPv4の公開定義済みオプション空間を1〜127から1〜223へ広げ、上位部分をプライベート用途から再分類した。しかし、すでに存在するローカル設定を消すことはできない。そこで標準は移行手順を設けた。既知のプライベート利用がある番号は、ベンダーがワーキンググループとIANAに通知する間、Unavailableとして扱える。暫定的な公開割り当てには6か月の通知期間と、Internet-Draft提出までの18か月の期限を設けた。サイトには残りのプライベート範囲へ番号を移すよう促した。RFC 3942
衝突時の規則はさらに厳しい。同じ番号が複数ベンダーによって相当広く使われていると示された場合、どのベンダーも自社専用のコードとしてその番号を維持できず、それぞれ通常の公開割り当てを申請しなければならない。私的利用を不当と断じたのではない。各社がローカルに使ったというだけでは、互換性のない二つの意味を一つの番号で調整できないからだ。RFC 3942は、初期採用者に負担をかける16ビット拡張や、互換性・発見のコストを増やす新形式やマジッククッキーも退けた。
後の衝突が違いを具体化した
RFC 4578は後に、PXEオプション93、94、97が広く使われていると記した一方、PXEクライアントが要求する128〜135はPXE用に正式割り当てられておらず、同一ネットワーク内の別用途と衝突しうると述べた。クライアントが番号を要求したという事実だけで、正式な割り当てになるわけではない。
キャプティブポータルでは、より明確な事例が生じた。RFC 7710は当初、ポータルURIの通知にDHCPv4オプション160を使っていた。IETF 106のネットワーク実験で、一部のPolycom機器が160を別の目的に使用していることが分かり、ポータルURIをその番号で運ぶと期待どおり動作しなかった。そこでRFC 8910は通知先を114へ移し、RFC 3679を更新して、既知のPolycom用途を記録した上で160を未割り当てに戻した。これはその実験で観測された衝突の記録であり、あらゆるネットワークでの発生率を示すものではない。RFC 7710 RFC 8910
現在のIANA表からは、いくつかの番号のその後が分かる。83はiSNS、88と89はBCMCSのオプションに使われ、114はCaptive-Portalとなった一方、96は未割り当てのままである。126と127も未割り当てだ。これらはレジストリの状態であり、稼働中のネットワークで当該値を送る機器が存在しない証拠ではない。後の割り当ても、それ以前の実装がすべて消えた証明にはならない。IANA BOOTP/DHCPパラメーター登録簿 RFC 4174 RFC 4280
Lu Hengの後年のNote 72は、調整記録と運用実態を異なる種類の証拠として見る、限定的な分析の視点を与える。同ノートの対象はインターネット番号の一意性調整であり、DHCP割り当てではない。これらのRFC判断を引き起こしたり、承認したりしたわけでもない。実務上の教訓はDHCPの文書そのものにある。番号の回収には使用状況の確認が必要であり、再割り当ては台帳の修正ではなく移行作業である。Note 72
出典
- RFC 3679 — 未使用のDHCPオプション番号
- RFC 3942 — DHCPv4オプションの再分類
- RFC 4578 — PXE DHCPオプション
- RFC 7710 — キャプティブポータルの識別
- RFC 8910 — DHCPによるキャプティブポータル識別
- IANA BOOTP/DHCPパラメーター登録簿
- RFC 4174 — iSNS DHCPオプション
- RFC 4280 — BCMCS DHCPオプション
- Lu Heng、Note 72 — The Bill of Rights of Uniqueness Coordination
関連する規格資料
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
