要約

  • RFC 3053 は、利用者を認可して設定を編成する Tunnel Broker と、IPv6-over-IPv4 トンネルを終端して通信を運ぶ Tunnel Server を分けた。
  • 登録、アドレス割り当て、DNS 更新、設定応答の成功は、両端の整合、IPv4 下位網の通過、双方向通信、アプリケーション成果を証明しなかった。

2001 年 1 月、孤立したホストを生まれたばかりの IPv6 Internet につなぐには、管理者が設定トンネルを手で組むことがあった。利用者には IPv4 接続がある。足りないのは IPv6 の接点、プレフィックス、ルート、インターフェース、場合によっては DNS である。利用者が一人増えるたびに、小さな運用案件が一つ増えた。

RFC 3053 は、その案件をサービスに変えようとした。IPv4 で到達できる Broker に接続し、認証し、IPv4 終端を伝え、必要なパラメーターを受け取る。手作業の列を再現可能な手続きに変える価値は大きかった。

ただし、この Informational RFC は新しいプロトコルを規定していない。提示したのは枠組みである。その枠組みは、使いやすい窓口と、命令を実行する装置と、通信を運ぶ経路が同じ権威ではないことを示した。

Broker は注文を扱い、必ずしもパケットを扱わない

Tunnel Broker は登録と有効化の窓口で、利用者に代わって作成、変更、削除を管理した。規模を広げるため、複数の Tunnel Server にネットワーク側終端を分配し、選んだサーバーに設定命令を送ることができた。

Tunnel Server は別の役割を持つ。Internet に接続されたデュアルスタックルーターであり、Broker の命令を受けて自分側のトンネルを作成、変更、削除し、利用統計も持ち得た。データ経路はクライアントとこのサーバーの間にある。アカウント画面を Broker が持つからといって、パケットが Broker を通るわけではない。

分離は拡張性を生んだが、証拠も分けた。Broker のデータ行は意図の記録、管理応答は命令の到達、サーバー状態は片側の設定を示す。それだけではクライアント設定、IPv4 通過、戻り経路、アプリケーション成功は分からない。

認可は依頼を許し、終端の到達性までは保証しない

クライアントは IPv4 Internet に接続されたデュアルスタックのホストまたはルーターだった。最初に本人性と資格情報を出し、Broker が認証、認可、必要なら課金記録を行う。RFC は RADIUS などの AAA を例示した。

認可後、IPv4 終端、DNS 用の名前、ホストかルーターかという役割を提出する。Broker は Server を選び、IPv6 割り当てと寿命を決め、DNS を更新し得て、サーバー側を設定し、最後にパラメーターを返した。

認証が証明するのは、そのアカウントがサービスを頼めることだけである。提出した IPv4 アドレスを今も本人が使い、外部から到達でき、カプセル化を通すことまでは証明しない。IPv6 割り当てや DNS 登録も、遠隔クライアントの設定を代行しない。

設定スクリプトは root の権限を借りた

クライアント側を簡単にするため、Broker が個別の起動・停止スクリプトを生成する案があった。追加ソフトウェアは要らないが、ネットワークインターフェースを変えるには管理者権限が必要になる。

RFC 3053 は、利用者がダウンロードしたスクリプトの危険な動作を検証しにくいと警告した。より安全な案として、HTTPS 上の専用 MIME 型でパラメーターを送り、信頼されたローカル部品が解釈する方法を挙げた。しかし、そのプロトコルは将来の仕事だった。

スクリプトは指示、実行コード、権限を一体化する。構造化パラメーターは要求状態と、それを適用するローカルコードを分離する。Broker–Server、Broker–DNS の管理経路にも、それぞれ固有の保護と適用証拠が必要だった。

安定した IPv6 名は、動く IPv4 の床に載っていた

ダイヤルアップで IPv4 アドレスが変わっても、IPv6 アドレスと DNS 名を長く保つことが目標だった。再接続時には新しい IPv4 終端でトンネルを作り直し、以前の IPv6 割り当てを再利用できた。

上位の識別子を下位の変化から切り離す発想は有用である。しかし、IPv6 文字列そのものが経路を永続化したわけではない。Broker は記録を保ち、戻ってきた利用者を認識し、終端を書き換え、Server を再設定し、新しいクライアント設定を渡す必要がある。下位網も新しいアドレスへ届かなければならない。

永続的な IPv6 アドレスは永続的な道ではない。記録と再設定に支えられた約束だった。

寿命は掃除の規則であって、生存証明ではない

トンネルは Server のメモリーと処理を消費するため、各トンネルに寿命を与え、延長されなければ削除することが勧められた。だが動的 IPv4 セッションは、記録上の寿命より早く終わり得る。

統計、無通信削除、keep-alive は判断材料になる。ただし沈黙は切断、フィルター、単なる待機、戻り経路障害のどれでもあり得る。カウンターの増加も、期待する利用者がその終端を現在占有していることを証明しない。

古い状態は機密性を破ることもある。利用者が切断後にトンネルを残せば、Server は古い IPv4 アドレスへ IPv6 通信を送り続ける。そのアドレスは別の加入者に再割り当て済みかもしれない。必要なのは将来の期限だけでなく、現在の終端支配の確認だった。

NAT は下位網の拒否権を残した

RFC 3053 は、利用者が NAT の背後で私用 IPv4 アドレスを持つ場合、仕組みが動かない可能性を明記した。Broker はフォームを受理し、認可し、IPv6 を割り当て、DNS を書けても、下位網はトンネルを拒める。

終端を名乗ることと、終端へ届くことは違う。私用アドレスはローカルには正しくても、公衆 Server の相手には使えない。途中装置が protocol 41 を通さないこともある。制御面の確信は転送面を変更しない。

管理を守っても、運ばれる会話は自動的に守られない

クライアント–Broker、Broker–Server、Broker–DNS の三関係は保護すべきだとされた。HTTPS、資格情報、AAA、安全な SNMP、IPsec で守る管理などが候補だった。

これらが守るのはサービス制御であり、トンネル内の IPv6 パケットを自動的に暗号化するものではない。アカウント認証は依頼権を確認するが、各アプリケーション通信の機密性、経路の正当性、配達結果を保証しない。

自動化は資源枯渇の入口も作る。多数のトンネル要求で Server を消耗させられるため、利用者ごとの上限が防御策として挙げられた。人手を節約するほど、要求権限と割当量の管理が重要になる。

後の RFC は設定トンネル、IPsec、TSP、展開指針、方式比較を詳しくした。だが後年の機能を RFC 3053 の実装へ遡って付与することはできない。

歴史的な要点は、登録、認可、割り当て、DNS、命令、Server 状態、クライアント状態、IPv4 通過、IPv6 経路、戻り、アプリケーションを別々の受領証として保つことにある。Broker はトンネルを発注できた。運んだのは別の機械であり、パケットが現れる前に経路の証明を発行できる者はいなかった。

出典

Lu Heng は RFC 3053 や関連規格の著者でも承認者でもない。ここでは明示した分析視点としてのみ参照する。