要約

  • PvDは、送信元アドレス、DNS、最初のルータなどを混ぜずに使うための整合性境界である。FQDN、H/L/Rフラグ、シーケンス番号は境界の識別や更新に使われるが、いずれも経路の優先順位ではない。
  • 信頼は一度に成立しない。追加情報を同じPvDの中で取得し、証明書、識別子、有効期限、プレフィックスを検証した後、ホストやアプリケーションが用途に応じて選ぶ。実際の選択は送信元、リゾルバ、ネクストホップ、接続結果で立証する。

「新しい方」が選ばれなかった理由

一台の端末が、同じリンク上で二つの明示的なPvDを受け取ったとする。一方はよく知られた事業者のFQDNを持ち、追加情報があることを示すHフラグも立っている。シーケンス番号は前回の観測から増えていた。監視画面はそれを新しい状態と認識し、そのまま「選択済み」と表示した。

ところが、HTTPSで認証した追加情報にはnoInternet: trueが入っていた。そのPvDは障害中ではなく、ローカルサービスに限定された正当なネットワークである。一般のウェブ接続には、もう一方のPvDを使うというホスト方針が適用された。

この例で食い違っているのはネットワークではない。画面が、名前、鮮度、用途への適合性、実行された選択を一つの状態に畳み込んだことが問題である。

マルチホーム環境では、個々に正しい設定を誤って組み合わせるだけで通信が壊れる。あるネットワークの送信元アドレスに、別のネットワークのDNSとデフォルトルータを組み合わせれば、応答経路や名前解決の見え方がずれる。RFC 7556がPvDを導入した中心的な理由は、この出所の関係を保つことにある。

PvDは物理インターフェースではない

RFC 7556はPvDを「一貫したネットワーク設定情報の集合」と定義する。送信元プレフィックス、DNSサーバ、検索サフィックス、プロキシ、デフォルトゲートウェイなどがその要素になり得る。

同じリンクに複数のPvDが存在することも、一つのPvDが複数リンクにまたがることもある。したがって、インターフェース名をPvD名に置き換えただけでは設計要件を満たさない。境界は物理ポートではなく、どの設定が整合して使えるかで決まる。

アーキテクチャは、設定の取得元から推定する暗黙のPvDと、明示的な識別子を持つPvDを区別する。どちらでも、PvD対応ホストは設定と出所の関連を保持する。接続時にはOS、利用者、またはアプリケーションの方針が用途に合うPvDを選び、その内部からアドレス、DNS、ルータを使う。

標準が万能のランキングを定めていない点は重要である。セキュリティ、料金、到達性、アプリケーションの範囲、利用者の意図は一致しないことがある。社内アプリは制限付きPvDを選び、ブラウザはインターネット接続用PvDを選べる。一台のホストに一人の「勝者」を決める必要はない。

RAは文脈を提示する

RFC 8801はIPv6 Router Advertisementのタイプ21としてPvD Optionを定義した。そこにはFQDN形式のPvD ID、H/L/Rフラグ、16ビットのシーケンス番号、Delay、必要に応じて内包されたRA情報が入る。

広告する運用者はPvD IDのFQDNを所有・管理すべきであり、最終的なサービスが同一である場合だけ同じIDを使う。異なるサービスを一つの親しみやすい名前にまとめれば、ホストが守るべき境界の意味が失われる。

ただし、名前の所有とローカルRAの正当性は同じではない。リンク上の攻撃者が有名なFQDNを書いたRAを送ることはできる。そこでRFC 8801は、追加情報のHTTPS認証とプレフィックス検証を別の面として要求する。

Hは追加情報をHTTPSで取得できること、Lは従来のDHCPv4情報との関連、RはPvD対応ホスト向けの内側のRAヘッダとオプションを示す。Hが立っていても取得成功を意味せず、Rは優先指定ではない。シーケンス番号も更新の世代であって順位ではない。別々のPvDの42と7を比較しても意味はない。

追加情報は同じPvDを通って検証する

Hが立っている場合、ホストはhttps://<PvD-ID>/.well-known/pvdへアクセスできる。Hが立っていなければ、この仕組みによる取得を行ってはならない。応答のメディアタイプはapplication/pvd+jsonである。

取得経路には厳しい一貫性条件がある。PvD IDの名前解決、証明書状態の確認、HTTPS接続、送信元アドレス、ネクストホップは、すべて評価中のPvDに属する設定だけを使う。別のPvDのDNSで名前を引き、第三の経路で取得しては、対象ドメインを検証したことにならない。

この条件は実装上の美しさだけを狙ったものではない。Split DNSは文脈ごとに違う答えを返し得る。送信元プレフィックスは正しい最初のルータを左右する。特定事業者のPvD名を別ネットワークのDNSへ漏らせば、接続履歴の手掛かりにもなる。URLだけを記録する監査では、この境界を再現できない。

TLS証明書のDNS-IDはPvD IDと等しくなければならない。失敗した場合、ホストは接続を閉じ、そのPvDには追加情報がないものとして扱う。これはFQDN所有者が情報サービスを認めている証拠であるが、ローカルRAや全プレフィックスを単独で保証するものではない。

JSONはプレフィックスまで結ぶ

有効なJSONにはidentifier、expires、prefixesが必要である。識別子はRAのPvD IDと一致し、有効期限は未来でなければならない。さらに、関連するRAのすべてのPrefix Information OptionがJSONのプレフィックスで覆われる必要がある。欠落や不一致があれば、その情報は利用できない。

つまり、ローカルルータの「この設定はこの名前に属する」という主張と、認証済みサービスの「この名前はこれらのプレフィックスを認める」という主張を照合する。一方しか支配していない主体に、完全な権威を与えない設計である。

任意のdnsZonesはPvD内で使えるDNS領域を示す。noInternet: trueはインターネット全体ではなく限定サービスを提供するという意味で、誤設定ではない。工場、病院、企業の閉域サービスには、それが正しい製品仕様になり得る。

未知のキーは無視される。共通キーはIANAの登録簿で管理され、私的な拡張は組織名空間またはvendor-*のサブ辞書に収める。登録は相互運用できる意味を与えるが、広告値の真実性や実装率を証明しない。

鮮度と取得には停止条件がある

シーケンス番号が変わるかJSONが期限切れになれば、保持していた追加情報を非推奨にする。Delayとランダム化した更新時刻は、多数のホストが同時に取得するのを避けるための負荷制御であり、緊急度ではない。

絶対時刻はホストの時計ずれに影響されるため、期限だけをセキュリティ判断に使ってはならない。TLS、HTTP、JSONの失敗後は、そのネットワーク接続中に同じPvD IDを再取得しない。失敗が十回以上続けば、その接続中はすべてのPvD追加情報取得を停止する。悪意あるRAがホストを外部サーバへの増幅装置にすることを防ぐ境界である。

運用者がHを立てるなら、captive portalのログイン前でも必要なDNS、証明書確認、HTTPSを通す責任が生じる。ホスト側はPvD内で一時IPv6アドレスを使い、Cookieや識別性の高いヘッダを送らない方がよい。任意の情報取得が最初の追跡イベントになり得るからだ。

最終的な選択はホストの実行に現れる

検証済みのPvDが揃っても、具体的な接続には方針が必要である。運用者は整合した選択肢を提示し、FQDN所有者は情報サービスを認証し、JSONは用途と範囲を説明する。どれが現在のアプリケーションに合うかはホストが決める。

そして、決定を証明するのはRAのラベルではない。採用した送信元アドレス、問い合わせたDNS、選んだネクストホップ、到達先と接続結果である。Running-Code Primacyとは標準を軽視することではなく、共通仕様が守る関連を、実行されたコードと観測で確かめることである。

出典