要約

  • RFC 8008では、異なる配信範囲の制約を組み合わせると候補が累積的に絞り込まれる。IPv4とIPv6の条件を単に並べると、どの送信元アドレスも一致しなくなる。
  • RFC 9388の明示的な footprintunion は選択肢を表す。ただし、外側の制約を消したり、ある機能を統合した範囲全体で使えることにしたりはしない。
  • 配信対象としての適格性、コンテンツの必須条件、地図の版が持つ意味、容量の助言は別々の判断である。その区別が、中央の許可に依存しない連携を支える。

一つのアドレスに二つの条件を課す

あるCDNが、対応範囲の通知にIPv4のプレフィックスを載せている。IPv6にも対応することを伝えるため、IPv6のプレフィックスを表すオブジェクトをその隣に追加する。意図は分かりやすい。どちらのアドレス系統から来る要求も、配信先を選ぶ際の対象にしたい。

しかし、その並べ方が意図どおりの「または」を意味するとは限らない。RFC 8008の付録Bでは、異なる範囲の制約は下流CDNの候補資格を累積的に狭める。判断に使う送信元アドレスは、並んだ条件を同時に満たす必要がある。

一つのアドレスがIPv4のプレフィックスにもIPv6のプレフィックスにも属することはない。そのため、想定していた二つの利用者集団は一つに増えるどころか、対象が空になる。RFC 9388の図2は、この構成を使って該当するクライアントがなくなることを説明している。

これは、特定の事業者で障害が起きたという報告ではない。仕様が示す例である。また、端末が両方の系統を利用できないという話でもない。デュアルスタックの端末でも、ある判断で調べる送信元アドレスはIPv4かIPv6のいずれかである。

通知の項目数だけを見れば、対応範囲は広がったように見える。各系統の名前が正しく書かれているかを調べても、この問題は分からない。条件同士の関係を読まなければ、通知が誰を対象としているのかは判断できない。

この小さな関係が、参加者の約束を変える。「両方を満たす」を「どちらかを満たす」に読み替える側は、表示を便利にしただけではない。下流が示した条件よりも広い範囲に、上流が要求を振り向けられることにしてしまう。

使える機能と範囲は切り離せない

CDNIは、複数のコンテンツ配信ネットワークを相互接続し、要求の委任などを可能にする。問題の定義と利用例には、既存のネットワークが直接扱わない範囲へ配信を広げるといった協力がある。

協力しているからといって、各ネットワークが持つ資源や条件が同じになるわけではない。全体を一つの所有者の設備として扱ったり、参加者のサービスをどこでも交換可能と考えたりする根拠にはならない。

RFC 8008が選んだのは、機能に範囲の制限を付けるモデルである。下流CDNは一般にはHTTPS配信を行えても、一部の範囲では行えないことがある。保守中だったり、その範囲を担当する資源が機能を備えていなかったりする場合である。

ここで「この事業者はHTTPSに対応する」と「この事業者はこれらの地域を扱う」を独立した項目にすると、肝心な関係が失われる。二つの記述がそれぞれ真でも、調べている送信元にHTTPS配信が可能とは限らない。

取得と配信も異なる機能だ。上流やオリジンからコンテンツを取得する際のプロトコルへの対応は、要求者に必要なプロトコルで配信する能力と同じではない。片方の対応をもう片方の証拠として使うことはできない。

選んだ配信の仕組みが複数の機能を必要とするなら、それぞれが必要な範囲で成立しなければならない。機能Aを使える範囲と機能Bを使える範囲をまとめても、両方を必要とする要求に適した範囲が生まれるわけではない。

これは、すべてのコンテンツに同じ審査項目を課す提案ではない。必要な機能は配信の仕組みによって違う。省いてはならないのは、その仕組みで必要と定めた機能と、実際に使える範囲との結び付きである。

選択肢を増やす場所は明示する

RFC EditorのRFC 8008の現在の記録には、RFC 9388による更新が示されている。2016年の初期仕様を、現在も拡張できない閉じた表現として紹介するのは適切でない。

2023年7月のRFC 9388は、footprintunion を追加した。複数の範囲オブジェクトをその値として持ち、それらを選択肢にする。IPv4とIPv6の条件をこの明示的な和集合の中へ置けば、いずれかに一致する送信元を対象とする意図を表せる。

ただし、すべての範囲一覧が自動的に和集合になったわけではない。和集合の外にある条件は、引き続き候補を絞る。仕様の地理的な例では、国と国内区分を組み合わせた選択肢の外側にASNの条件を置いている。どの地理的な枝に一致しても、外側の条件は必要になる。

「指定したネットワークに属し、さらに、どちらかの地域に一致する」と「指定したネットワークに属するか、どちらかの地域に一致する」では、認める送信元が違う。図を一枚にまとめる途中でこの違いを失えば、提示されたサービスの境界を変えてしまう。

RFC 9388は、footprintunion の値に別の footprintunion を含めることを禁止する。和集合をさらに和集合にしても、一つの和集合に展開できるため、この制限で選択肢を表す意味が失われるわけではない。

一方、和集合を囲む別の制約は、同じ意味で展開できるものではない。和集合の入れ子を減らせることを理由に、外の制限まで取り去ることはできない。

簡略化が役立つのは、同じ送信元に対して同じ結果になるときである。項目が減ったことや表示が見やすくなったことは、その証明ではない。対象となる送信元が変わったなら、説明を短くしただけではなく、別の条件を表している。

地図は施設の所在地を証明しない

配信範囲という言葉から、サーバーの設置場所を連想しやすい。しかしRFC 8008の範囲は、どこからの要求に対して配信する意思があるかを表すものであり、設備の所在地だけで決まるものではない。

接続事業者が自社の加入者向けにCDNを構築すれば、加入者が集中する場所の近くに資源を置くことがある。その資源が他のネットワークから到達可能でも、あらゆる外部要求を引き受ける意思があることにはならない。通信上の到達性と、サービスを提供する条件は別である。

範囲の記述方法にも、それぞれ判断が残る。ASNから具体的なアドレス範囲をどう求めるかについて、CDNIは全上流に共通の権威ある方法を定めていない。送信元がどの国にあるかについても、統一の判定方法を提供してはいない。

RFC 9388の subdivisioncode は、ISO 3166-2の国の下位区分を使い、国より細かな地域を記述できるようにする。記述が細かいことと、位置判定が正確であることは違う。区分を表すコードがあっても、送信元をそこへ正しく割り当てたことまでは証明しない。

また、要求の対象範囲を示すコードは、処理の全工程やコンテンツの全コピーがその法域に置かれることの証拠ではない。要求を受け入れる範囲と、資源やコピーの位置は同じ問いではない。

IANAのCDNIパラメーター登録簿は、型の名前と定義を共有する基盤になる。個々の要求の地理的な所属を認定する場所ではない。

通知の意味は共有されていても、その通知に送信元を当てはめる根拠には不確実性が残り得る。その二つを分けることが重要である。共通のコードを使うだけで、ある参加者の位置推定が全参加者の確定した事実に変わるわけではない。

下流の先にある依存関係

CDNIの枠組みは、範囲・機能の通知、リダイレクト、メタデータ、制御、ログを、関連するが異なる役割に分けている。候補を選ぶための通知は、将来のコンテンツ配信が完了したという報告ではない。

候補の下流CDNは、さらに下流のネットワークを使って一部の範囲を扱うこともある。RFC 8008の付録Aは、最初の下流が自力では提供できないプロトコルを、次の下流が一部の範囲で提供する例を示している。

その機能が失われたとき、変わるのは特定の機能と特定の範囲の組み合わせである。最初の下流全体が、あらゆる地域であらゆる要求を扱えなくなったとは限らない。

反対に、参加者の名前だけが残る統合地図では、失われた依存関係が見えないことがある。同じ相手を選べるように見えても、以前の選択を支えていた一部分の機能がもうない。

必要な対応は、必ずしも全内部構造の公開ではない。RFC 8008は、資源を基にした範囲の記述が内部構造を露出させる可能性を認め、そのような開示を一律に必須としていない。

上流にとって重要なのは、どの送信元に対して、どの機能の通知が今も有効かである。限定された変更を限定された範囲で示せば、失われた機能を誤って選ばず、影響のない機能や範囲は使い続けられる。小さな通知が、広い地図より実際の判断に役立つ場合がある。

メタデータの読解と条件の履行は別だ

範囲に一致した送信元の要求でも、コンテンツに付く必須条件を下流が満たせない場合がある。RFC 8006は、メタデータを理解・転送することと、その条件を実行することを分けている。

必ず履行しなければならない属性を理解できない、または必要な機能を実行できないなら、対応するコンテンツを提供してはならない。機能通知から好ましい候補に見えたとしても、その義務はなくならない。

事前に機能を確認していても、この区別は必要だ。利用できる機能が変わったり、認識に食い違いがあったりする可能性がある。下流は要求に関連するメタデータを評価し、必須条件を実行できない要求を拒否する必要がある。

メタデータの再配布規則が許す場合には、自分ではコンテンツを提供できなくても、別のCDNへ安全に情報を渡せることがある。中継する権限と、自ら配信する能力は同じではない。転送できることを、ローカルで義務を履行できることへ読み替えてはいけない。

RFC 8008は、具体的なプロトコルが定める取り扱いに従って、理解しない任意の範囲型や機能型を無視できるとしている。任意の型の交渉や未対応の場合の処理は、そのプロトコルが定義しなければならない。

この許容は、要求が必要とする未知の条件が満たされた証明ではない。理解した情報だけで選ぶことと、コンテンツが求める全条件を履行できることは違う。CDNIの要件文書を背景として読んでも、各インターフェースの役割が一つの包括的保証になるわけではない。

容量については現在の拡張を読む

RFC 8008の初期設計が扱う情報は限定されていた。しかし、そのことから、現在のFCIは負荷を一切通知できないと結論するのは誤りである。

2025年7月の RFC 9808は、FCI.Telemetry と FCI.CapacityLimits を追加した。使用状況や利用上限を伝え、上流が委任するトラフィック量を判断する助けにする。

同時に、その情報は助言であり、容量の保証、確約、予約ではないと明記している。上限は、その通知に結び付く範囲を持つ。適用する上限は最も具体的に見えるもの一つを選ぶのではなく、すべてを併せて考慮する。

この拡張があっても、対象としての適格性とは別の判断が残る。余裕があるように見える数値は、範囲の外の送信元を内側へ移さない。コンテンツ条件を実行する機能がないなら、その機能を数値が補うこともない。

使用状況の指標にも範囲や意味がある。上限と比べる観測が別の情報源、別の範囲、別の集計期間を指していれば、同じ利用率という名前でも意図した比較にはならない。観測の遅れも、調整の効果を読む際に関係する。

情報が増えれば判断の材料は増えるが、次の要求の成功が確定するわけではない。下流は助言を示し、上流は委任を選ぶ。助言を受け取った側が、見えている容量の所有権や予約済みの枠を取得するわけではない。

同じ地名のように見えても版が違えば意味が違う

RFC 9241は、ALTOを使ったCDNIの機能・範囲通知を具体化する。RFC Editorの記録でも、基本の意味を定める文書とは別に確認できる。転送方式が具体化されても、RFC 8008の機能ごとの意味が置き換わるわけではない。

範囲をALTO PIDで表す場合、対応するネットワーク地図に依存することがある。ALTOプロトコルは、こうした情報資源の枠組みを提供する。通知は依存する資源とその版を示し、どの地図を使った表現か分かるようにする。

同じ識別子が使われ続けていても、そこに含まれるアドレス群が同じとは限らない。通知が前提とした版とは異なる地図を結び付ければ、同じ名前に別の範囲を与えてしまう。

求めるのは参照の意味の整合性であって、全CDNの時計を世界規模で同期させることではない。版のタグは、どの記述かを示す。配信遅延や品質を測る指標でも、将来のトラフィック受け入れを保証するものでもない。

空の値についても、どこが空かを見なければならない。RFC 9241では、通知する機能の配列が空なら、どの範囲にも必須実装のCDNI機能を提供しない意味になる。一方、一つの機能オブジェクトの範囲が省略、null、空であれば、その機能の範囲は全域と解釈される。

この二つを「空なら使えない」と一律に扱えば、片方を反対に読んでしまう。逆に「空なら広く継承する」と決めても、通知全体の機能がないという意味を失う。値の形だけでなく、その位置が意思決定に関係する。

絞り込んだ通知の版タグは、元となる完全な通知の版に対応する。必要な部分だけを得ることは有用だが、要求しなかった範囲の機能について包括的な結論を得たことにはならない。

ALTOのエンティティ属性地図は、階層と継承をドメインごとに定める。RFC 9388の国内区分コードには、属性の階層も継承もない。アドレスプレフィックスのルールを地理的なコードへ移し、国の属性が各区分へ自動的に適用されると推定してはいけない。

ALTOの増分更新は、変更を効率的に伝える。情報を速く受け取ることは大切でも、間違った条件の組み合わせは速さでは直らない。意味を正しく残すことが、更新の利点を生かす前提になる。

共通の意味と中央の許可は違う

RFC 8008は、通知を運ぶ具体的なプロトコルに認証と完全性を求める。偽の「範囲なし」「機能なし」という通知によって、委任を妨げられるからである。

ただし、誰が送ったかを確かめることは、地域の判定やサービス品質を証明することとは違う。容量が予約されたことにもならない。既存の関係、商業上の取り決め、必要な事後確認は、意味の共有とは別に残る。

Lu Hengの 最小限の初期仕様、ローカルな将来判断、自発的な採用についての議論は、この境界を考える手掛かりになる。最初の連携に必要な意味を共有し、その後の判断は参加者の手元に残す。拡張は理解して役立てられる場合に採用できる。

自発的な採用は、すでに引き受けた条件を無視する自由ではない。明示的な和集合を使って選択肢を増やしても、外側の制約は残る。任意の型を理解しないことは、コンテンツの必須条件が満たされたことを意味しない。

The Policy Mirrorが注目する、方針が実際の判断になる接点は、ここでは通知の読み方にある。対象範囲、条件の組み合わせ、参照する版をどう扱うかによって、見た目は単なる表示でも要求の資格を定義する。

広い地図が悪いのではない。正しく表した広い選択肢には価値がある。問題は、条件を消して広く見せた地図が、誰も明示的に約束していないサービスの根拠として使われることである。