要約

  • RFC 3692は、回収が難しく再利用時に危険を伴う一時的な専用割り当てより、汎用の試験値を選んだ。
  • 253と254は特定の実験を示さず、相互理解も保証しない。安全な利用にはローカルの合意と明示的な設定が必要で、恒久利用には通常の割り当て手続きが要る。

パケットに載せる値が、実験の入口になる

新しい拡張機能は、開発者の端末では動いていても、パケットに入れば受信側が意味を見分ける値を必要とする。閉じた検証環境なら、参加者がその場で選んでもよい。難しいのは、実際のプロトコル処理を通じて試したい一方で、既存の値を占有せず、後で返却を求められる仮の番号にも頼らない方法だ。

2004年1月にBest Current Practice 82として公開されたRFC 3692は、一時的な専用割り当ての残務を指摘した。連絡先は古くなり、実験の終了時期が分からなくなる。製品に値が組み込まれれば、いつ誰が使ったか見えないまま再利用する危険も生じる。番号の回収自体より、それに依存する実装が残っていないかを判定する方が難しい。

そこでRFC 3692は、実験用の汎用範囲を設けた。IPのProtocolフィールドでは、IANAが253と254を実験・テスト用に割り当てた。合意したシステムは同じ値を異なる試験に使える。値そのものは特定のプロトコルの意味を予約せず、他の実装者に義務を課さない。

同じ番号でも意味は共有されない

この仕組みは、試験ごとに一意の番号を付けて衝突をなくすものではない。衝突の可能性を認め、制御をローカル環境に置く。管理者は自分の環境で値を選び、既に別用途で使われていないか確認できる。その外側では一意性は保証されない。

したがって、試験の成功が示す範囲も限られる。253を含むパケットで、設定済みの相手が拡張を認識したことは示せる。しかし、関係のないネットワークも同じ意味に解釈するとは限らない。実験室で成功しても、そこでの端末と設定を超えた相互運用性の証拠にはならない。有用性が確認された拡張は、通常の割り当て手続きで恒久番号を取得する。

製品にも明確な境界がある。出荷時に実験的な認識機能を有効にしてはならず、利用者が明示的に有効化し、通常は値も設定する必要がある。共有値を製品に固定すれば、別の実験と衝突する可能性があるからだ。

RFC 4727は後にIPv4、IPv6、ICMP、UDP、TCPのヘッダー領域にまたがる値を整理したが、実装に値をハードコードしないよう警告し、RFC 3692の注意点へ読者を戻している。IANAの現行一覧もIPv4 Protocolの253と254を試験・実験用と示す。これは用途の登録であり、製品での普及やインターネット全体への配備を証明しない。IANA考慮事項の後年の一般指針はRFC 8126であり、RFC 3692が引用するRFC 2434は2004年当時の文脈として読む必要がある。

RFC 3692が残したのは、試行錯誤のための短い規律だ。汎用値を予約し、ローカルな合意を明らかにし、明示的な有効化を求め、恒久的な利用は通常の割り当てに進める。試験番号は実験の扉を開くが、相手も同じことを話しているとは保証しない。

参照資料