要約

  • RFC 5211は準備期、移行期、2012年1月以降の移行後期を提案し、IPv6中心の接続を目標にした。同時に、これは義務を生じさせない情報提供上の一案だと明記した。
  • 日付と大文字のMUSTは期待を明確にできる。IPv6が注文可能か、開通したか、往復できるか、選ばれたか、アプリが完了したかまでは証明しない。

日付が持つ権限

2008年7月のRFC 5211は、単一の指揮者を持たないインターネットで移行の順番を共有しようとした。2009年末までを準備、2010年から2011年を移行、2012年以降を移行後とする三段階である。事業者は試験提供から本番へ進み、組織は公開サーバーにIPv6を加える構想だった。

文書は自らの限界も書いた。「一つの可能な計画」であり、他の計画もあり得る。どの当事者にも義務を課さない。RFC 2119の語は提案を曖昧なく記述するためだけに使う。IESG注記も、インターネット標準の候補ではなく、通常のIETF合意文書と同じ技術審査に基づくものではないとした。

したがって、期日は会議、投資、依存関係の確認を促せるが、装置を変える権限はない。2012年に自動で成立したのは時刻条件だけだった。

「提供済み」を一項目にしない

TRANS1とPOST1は、事業者がIPv6インターネットサービスを提供するという座標を置く。実務上の「提供」は、商品掲載、対象地域、回線種別、申込資格、受注、プレフィックス払い出し、顧客装置、往路、復路、DNS、監視、サポートに分かれる。

商品があっても受注システムで落ちることがある。設定が入っても復路がないことがある。経路があってもアドレス選択によりIPv4が使われ続ける。疎通試験が成功しても、認証、決済、メール、外部APIのどれかがIPv6経路で完了しないことがある。

AAAAの公開も、DNS上の存在を示すだけだ。名前解決、経路選択、接続、取引、継続性は別のレシートである。一地点の成功から全利用者、全アプリ、全時間帯を推定してはならない。「主としてIPv6」と言うなら、指標、母集団、期間が必要だ。

MUSTは監督機関ではない

RFC 5211はMUST、SHOULD、MAYを意図的に用いた。ただし、その目的は計画を明確にすることで、義務を作ることではない。共通の監査人、試験方法、対象集合、制裁は定められていない。

危険なのは、文が別の帳票へ移る時である。「事業者は提供しなければならない」が、調達表を経て「世界の移行は完了した」になる。どの事業者、商品、地域、利用者、時点を誰が確かめたのかが消えている。

動詞には必ず証拠を戻す。提供には商品と受注記録、開通には設定と経路、本番には取引と保守、優勢には分母付き測定、IPv4廃止には依存関係と復旧手順を結び付ける。

POST4が残した現実

移行後期はIPv4停止を意味しない。POST4は、事業者がIPv4を提供し続け、組織が使い続けることを許した。想定されたのはIPv6の役割が拡大する共存であり、全世界同時の切替ではない。

後続文書がデュアルスタック、変換、顧客側ルーター、コンテンツ、企業導入、セキュリティ、IPv4-as-a-Serviceを別々に扱うのも、この組合せを運用するためだ。IPv6-onlyのコア、IPv4aaS、デュアルスタックの公開面、IPv4専用の古いアプリは同じ組織に共存し得る。

IPv4を早く外せば隠れた依存を切る。無期限に残せば費用と攻撃面を固定する。どちらの判断も年号からは出てこない。

文書の更新と稼働状態を分ける

RFC 6144は2011年、IPv4アドレス枯渇が有意なIPv6導入より先に来る可能性を記した。RFC 6180は長い移行の尾を想定した。RFC 6540はIP対応ノードのIPv6支持をBCPとした。コンテンツ、顧客装置、企業導入にも個別の指針が続いた。

これは仕様作業が進んだ証拠であって、ある製品や回線が実装された証拠ではない。文書の地位、コードの対応、設定の有効化、配置された経路、観測した結果を混ぜてはならない。期日未達も、日付が状態を作らなかったことは示すが、プロトコル失敗や原因までは示さない。

移行を観測可能にする

台帳には、計画、責任者、予算、商品、受注、開通、アドレス、DNS、往復経路、選択、通信量、アプリ結果、継続性、例外、廃止判断を順に残す。各記録に時刻、範囲、主体、対象、出所を付ける。

全てを中央に集める必要はない。共通にするのは証拠の最小形式だけでよい。各ネットワークがしきい値と判断を保持すれば、自発的な採用と検証可能性を両立できる。

期日の正しい用途はレビューを起動することだ。現実が計画と違えば、計画を直す。現実の名前を変えて完了扱いにしない。

情報源

  1. RFC 5211情報
  2. RFC 5211 HTML版
  3. RFC 5211テキスト版
  4. IETF Datatracker：RFC 5211
  5. RFC 5211の履歴
  6. RFC 5211の参照関係
  7. RFC 5211の正誤表
  8. RFC 3932：独立投稿
  9. RFC 2119：要件語
  10. RFC 8174：BCP 14の更新
  11. RFC 6144：IPv4/IPv6変換
  12. RFC 6180：IPv6移行指針
  13. RFC 6540：IPv6対応要件
  14. RFC 6589：コンテンツ移行
  15. RFC 7084：顧客エッジ要件
  16. RFC 7381：企業導入指針
  17. RFC 8170：導入事例
  18. RFC 9099：IPv6運用セキュリティ
  19. RFC 9313：IPv4-as-a-Service技術
  20. Heng Lu：現実の層と象徴的権力
  21. Heng Lu：最小初期仕様
  22. Heng Lu：稼働コードの優先