要約

  • RFC 8799は、開かれたインターネット全体で使えることを約束せず、限定された技術領域の中で相互運用する仕組みを認める。その代わりに、メンバーシップ、境界ノード、情報流出、ドメインの重複や接続を明示的に扱う責任を課す。
  • この文書の著者はBrian CarpenterとBing Liuである。InformationalのIndependent Submissionであり、IETFの合意でもインターネット標準でもない。安全な参加機構の完成仕様ではなく、設計が答えるべき問いを保存した研究文書である。

ルーターは図面の色を読まない

ある企業ネットワークが、内部だけで意味を持つ値をパケットに書き込んでいるとする。設計資料では全機器が青い枠の内側にある。構成変更でデフォルト経路が変わり、そのパケットが外向きのインターフェースへ出た。隣のネットワークにとって、ビット列は正常でも、内部の合意は存在しない。値は無視されるか、別の意味で読まれるか、外部に出すべきでない運用情報を運び続ける。

障害の原因を経路変更だけに求めると、本質を見失う。人間が認識する境界を、プロトコルが検証できる事実だと扱ったことが先の誤りである。アドレス範囲やファイアウォールは管理意図を表すが、ノードが現在も構成員か、どの面が外を向くか、以前の権限が失効したかまでは証明しない。

2020年7月に発行されたRFC 8799は、この範囲を限定ドメインと呼ぶ。家、車両、工場、キャンパスのような物理的領域だけではない。複数地域にまたがる仮想ネットワーク、データセンター、ネットワークスライス、管理された事業者網も含み得る。共通するのは距離ではなく、特定の要求、動作、意味が一定の構成員にだけ有効だという点だ。

文書はcontrolled environmentも実務上ほぼ同じ意味で扱う。ただしDNSのドメインを指すのではなく、政治的・言語的にインターネットを分断する議論でもない。局所的な技術要件を認めながら、開かれたインターネットを普遍的な相互接続手段として残すには何が必要か、という問題である。

狭い範囲にも相互運用性は要る

用途を限定する理由はある。産業制御は遅延の上限を求め、制約機器は電力と帯域を節約する。事業者内部では、世界共通ではない命令や識別子が必要になることもある。公開インターネット向けの仕組みが複雑すぎる場合や、実際の経路では機能しない場合もある。

しかし、局所仕様を曖昧にしてよいわけではない。同じ機能を複数ベンダーが実装し、何千もの独立したドメインが採用するなら、それぞれの内部で共通の文法と動作が必要になる。切り離されたネットワークでも機器同士は理解し合わなければならない。現在は孤立していても、将来は買収、委託、クラウド移行によって別のドメインと接続される。

そこでlocalは免責ではなく、追加の証明責任になる。どこで意味が始まり、どこで終わり、範囲外の機器がどう振る舞うかを示す必要がある。手作業のフィルターやアドレス管理は誤りやすく、デフォルト経路が流出を生む。RFC 8799は、限定利用が弱い安全設計の口実にはならず、境界で信頼モデルが変わるため複雑さが増すと指摘する。

同じ越境ではない四つの場面

第5節は、限定ドメインの仕組みが境界に出会う場面を四つに分ける。

第一は、標準のIP形式を守る場合である。一つの仮想ドメインの離れた二拠点は、公開インターネットを通じて通信できる。途中の網は端点の局所的な意味を理解せず、通常のパケットとして運ぶ。

第二は、非標準のIPv6拡張ヘッダーなど、標準形式を外れる場合である。公開インターネットが透過的に運ぶと仮定できない。カプセル化、専用経路、別の封じ込めが必要になる。

第三は、出身ドメインの外では無効だと定義された仕組みである。離れた拠点をトンネルで一つの仮想領域にできるが、境界ノードは外へ出ようとする該当パケットを破棄しなければならない。破棄は運用上の親切ではなく、正しい動作の一部である。

第四は、形式が同じなのに意味が異なる場合だ。DSCP値はどこでも構文上は有効だが、ドメインを越えて意味を維持するには事業者間の合意かゲートウェイでの写像が要る。二つの社内網を統合したとき、パケットがエラーを出さないまま誤った優先度を生む可能性がある。

したがって、ビットが通れるか、通してよいか、通した後も同じ意味かを別々に問わなければならない。その答えがトンネル、破棄、変換、版管理、試験になる。「管理された環境に対応」という製品説明だけでは、どの責任も決まらない。

メンバーシップが境界を実行可能にする

RFC 8799の中心的な指摘は、地図上の境界そのものには技術的な意味がないということだ。意味を持つのはノードの所属と役割である。境界ノードは内向きと外向きのインターフェースを区別する。送信側は宛先が内部かを知り、受信側は送信元が内部だったかを判断する必要があり得る。

文書は十一の機能要件を挙げる。ドメインには一意で検証可能な識別子、実質的には公開鍵が必要になる。ノードは参加資格を確認し、安全に登録して権限証明を得る。登録は取り消せなければならず、参加状態は一時的に離脱、復帰できる。ノード同士は相手の所属と役割を検証し、境界ノードを発見する。さらに、外へ出してはいけないパケットを止めるポリシーや設定を受け取る。

ドメインは入れ子にも重複にもなる。一台の装置がサービス用ドメインと観測用ドメインに同時参加し、インターフェースごとに別の所属を持ち得る。単一の「内側」フラグでは足りない。権限は、対象ドメイン、インターフェース、役割、有効期間に結び付かなければならない。

登録と同じ重さで失効を扱う必要がある。以前参加した事実だけを証明し、離脱を証明できない仕組みは、組織変更のたびに見えない例外を残す。秘密鍵の保有者はドメイン運用の信頼アンカーになるが、無制限の統治者ではない。鍵の保管、委任、ローテーション、復旧にも外側の統制が要る。

RFC 8799はこの機構を完成させていない。各パケットにドメイン標識を載せるべきか、個別に暗号認証すべきかは今後の研究として残す。要件一覧は監査に使えるが、導入可能な実装と同一視してはならない。

IOAMでは出口の仕事が目に見える

その後のRFC 9197は、限定ドメインの考え方を具体的なパケット処理に結び付けた例である。IOAMは利用者のパケットが網を通る間に運用情報を追加、更新する。その適用範囲をRFC 8799の限定ドメインと明記し、一つの領域内に複数の重なるIOAM名前空間が存在できるとする。

カプセル化の設計者はデータをIOAMドメイン内に留める仕組みを用意し、運用者も境界でフィルタリングなどを実施する。端の装置はIOAMフィールドを追加または除去する。境界は抽象的な外周ではなく、担当ノードによる検証可能なパケット変換になる。

RFC 9378では役割がさらに明確だ。カプセル化ノードがオプションを加え、トランジットノードが更新し、境界のデカプセル化ノードが全IOAMオプションと関連ヘッダーを取り除く。同じ装置でも名前空間ごとに役割が違う。装置名ではなく、範囲付きの役割が動作を決める。

外部への流出がないだけでは合格にならない。IOAMによるパケット長の増加は、ECMPの分配、経路MTU、ICMP処理に影響し得る。外向きキャプチャがきれいでも、内部の経路に副作用がないとは言えない。

IOAMはRFC 8799の概念が後の仕様で使われたことを示すが、一般的なメンバーシップ問題をすべて解決したわけではない。具体例と普遍的な完成を分けて読む必要がある。

未完成であることを隠さない

University of Aucklandは、Brian Carpenterをインターネットプロトコルとコンピューター史を専門とする名誉研究者として紹介する。CERNのネットワーク部門、IBMでの標準化業務を経て、IETF、IAB、Internet Societyの議長職も務めた。IETF DatatrackerにはRFC 8799を含む広い技術記録がある。

その経歴を根拠に、文書を機関の命令へ変えてはいけない。RFC 8799はBrian CarpenterとBing LiuによるInformationalのIndependent Submissionである。IETFでの議論と助言を経ているが、IETF合意でもインターネット標準でもない。後続のIETF文書が定義を参照しても、この地位は変わらない。

むしろ、答えを作ったふりをしない点に価値がある。二人は局所的な意味に必要な権限面を列挙し、設計者がまだ何を証明していないかを見えるようにした。要件、実装の選択、観測された結果を分離できる。

localは意図する範囲を表す言葉であり、安全の証明ではない。信頼できる限定ドメインは、誰が属し、誰が出口を担い、どの意味がそこで終わり、実際に終わったことをどう確認したかを説明できる。

情報源