要約

  • 複数のIPv6プレフィックスを受け取るだけではマルチホームは成立しない。送信元、第一ホップ、DNS文脈の組み合わせが一貫している必要がある。
  • 運用上の証跡は三つの選択を一回の接続試行に結び付ける一方、受信した設定、端末の採用、上流の受理、アプリの結果を別々の事実として残すべきだ。

障害会議には、しばしば三枚の正しい画面が並ぶ。DNSには回答がある。端末には有効なIPv6アドレスがある。ルーターには到達できる。それなのにアプリケーションはタイムアウトする。各画面が間違っているのではない。DNS回答はVPN、送信元は固定回線、出口はモバイル回線という、成立しない組み合わせを見ているのである。

RFC 7157 IPv6 Multihoming without Network Address Translation は、この組み合わせの問題を分析した。2014年3月にIETFの合意を反映するInformational RFCとして公開され、O. Troanが編集者、David Miles、Satoru Matsushima、Takashi Okimoto、Dan Wingが共著者として記載されている。IETFのOle Trøan公式プロフィールもこのRFCを掲載する。これは共同文書への編集上の貢献を示す記録であり、単独発明、導入先の支配、後続RFCの著者資格を意味しない。

文書の出発点は、IPv4のNAPT装置が実際には三つの機能をまとめていたという観察だ。境界装置は外向きの送信元アドレスを決め、次の転送先を選び、構成によってはDNSも仲介する。内側の端末から見えるのは一つのプライベートアドレスと一つのゲートウェイである。どの事業者のアドレス、経路、名前空間を使ったかは箱の内側に隠れる。

IPv6では、小規模拠点も二つの事業者から別々のグローバルプレフィックスを受け取れる。ノートPCはWi‑Fiと携帯回線を同時に維持し、その上に社内VPNを重ねることもできる。見えない変換器を経ずにエンドツーエンドで到達できる余地は広がる。しかし、アドレスの豊富さは設定情報の所属関係まで決めない。

RFC 7157は、最初のパケットより前にそろえる三項目を示す。宛先に適した送信元アドレス、その送信元を扱える次ホップ、目的の名前空間を知るDNS再帰サーバーである。上流事業者は送信元の偽装を防ぐフィルタを設けることがある。事業者Aの正当なプレフィックスを持つパケットでも、事業者Bの出口へ渡せば破棄され得る。個々の有効性は組の有効性ではない。

第一の判断は送信元だ。RFC 6724はIPv6の送信元・宛先アドレス選択の既定アルゴリズムと、管理者が調整できるポリシーテーブルを定める。RFC 7157は、複数事業者の同一スコープのアドレスがあると、既定規則だけでは適切な送信元を決定できない場合があると述べる。RFC 7078は、その選択ポリシーをDHCPv6で配布する選択肢を定義した。だが、オプションを受信した事実は、端末が採用したこと、期限内であること、このパケットに適用したことを証明しない。

第二は第一ホップだ。複数のRouter Advertisementにより、複数のデフォルトルーターが同時に有効になり得る。単に到達できるルーターを選ぶだけでは、送信元プレフィックスを受け入れない上流へ出してしまう。後のRFC 8028は、送信元を先に選び、そのプレフィックスを広告したルーターへパケットを渡すというホスト動作をStandards Trackで明確にした。著者はFred BakerとBrian Carpenterである。Ole Troanは重要な文言への貢献で謝辞に載るが、謝辞は著者欄ではない。

第三はDNSの文脈である。企業VPNだけが知る内部名もあれば、問い合わせ元によって別の答えを返すアクセス網もある。複数リゾルバーに同時に聞き、最速の回答を採用する方式は、選んだ出口から使えないアドレスを返す可能性がある。RFC 7157はドメイン空間に応じた選択を論じ、RFC 6731のDHCPv6によるDNS選択情報を参照する。回答には、どのインターフェース、送信元、リゾルバー、供給文脈から得たかという来歴が必要になる。

三つの判断は連続するが、責任主体は一つではない。アプリケーションが名前と用途を示す。名前解決ポリシーが文脈を選び、宛先候補を得る。ホストが送信元を選ぶ。経路処理が出口を決める。ゲートウェイと上流フィルタが受理を判断し、最後に遠端が応答する。「IPv6成功」という一行だけを残せば、次の失敗時には各担当が互いに接続できない証跡を持ち寄ることになる。

代替策にも正確な境界がある。RFC 7157はエンドツーエンド透過性のため、可能ならNATとNPTv6を避けるべきだとする。同時に、検討した問題にはDHCPv6ベースの解決が適し、移行段階ではNPTv6が必要になり得ると結論付ける。望ましい設計と現実の移行経路を両方記したのであって、変換を全面禁止も全面推奨もしていない。RFC 6296のプレフィックス変換仕様も、普遍的な採用命令ではない。

後続のRFCは、設定を所属ごとに束ねる考えを発展させた。RFC 7556はProvisioning Domain（PvD）を、送信元プレフィックス、DNSサーバー、DNSサフィックス、デフォルトゲートウェイなどの一貫した設定集合と定義する。異なるPvDの情報を不用意に混ぜないための参照モデルである。RFC 8801はRouter AdvertisementでFQDN形式のPvD IDを知らせ、任意のJSON追加情報を取得できるようにした。IDやJSONは関連付けの材料であり、信頼性や現在の到達性を保証しない。

監査すべき対象は、接続アイコンではなく一回の試行だ。一つの試行IDに、要求した名前と用途、DNSのPvD、リゾルバーと問い合わせ元、回答集合とTTL、選んだ宛先、送信元候補と選択結果、ポリシー版、ルーター候補と第一ホップ、広告プレフィックスと寿命、経路・近隣状態、フィルタ判定、再試行で変えた要素、可能なら上流・遠端の観測を結ぶ。単調時計を使えば時刻補正が因果順序を壊さない。

記録ごとの意味は限定される。設定済みアドレスは選択の証拠ではない。選択済み送信元は上流受理の証拠ではない。ルーター広告は転送実績ではない。DNS回答は配送結果ではない。アプリの応答でさえ、その時点の一経路が成功した証拠にすぎず、未使用の代替経路まで正しいとは言えない。

Trøanの編集記録を人物記事として読む価値はここにある。RFC 7157は、古い箱が吸収していた判断を分解した。透過性とは制御がない状態ではなく、どの入力から誰が選び、いつ失効し、どう取り消せるかが読める状態である。

情報源