要約

  • RFC 2373 の anycast はユニキャスト空間から割り当てられ、ビット列だけを見ても複数のインターフェースが共有しているのか、どれが受信するのかは判別できなかった。
  • 「最も近い」はルーティングプロトコルがその時点で用いる距離尺度の結果であり、地理、遅延、健全性、負荷、あるいは同一機械への継続を意味しなかった。

一つの表記に、勝者は埋め込まれていない

RFC 2373 の IPv6 アドレス体系はノードではなくインターフェースから始まる。ユニキャストは一つを識別する。マルチキャストは集合を識別して全員に届ける。anycast も集合を識別するが、配送先はそのうち「最も近い」一つだけだった。

重要なのは、専用の形式を作らなかったことである。Anycast アドレスはユニキャスト空間から割り当てられ、同じ形式を使うため、構文上は区別できない。同じユニキャスト形式のアドレスを複数のインターフェースに設定すると集合が成立し、参加ノードはそれが anycast であることを明示的に知らされなければならなかった。

したがって、ログに残った宛先文字列は台帳ではない。一つの所有者か集合か、どのメンバーが応答するか、なぜその経路が選ばれたかを説明しない。

「近い」の意味は経路が決めた

仕様が nearest を引用符で囲んだのには理由がある。距離とは、トポロジー、方針、その時点の広告を取り込んだルーティングプロトコルの尺度だった。地理的な近さでも、アプリケーション遅延の短さでも、プロセスの健康や機械の空き具合でもない。

この設計なら、新しいパケットフィールドを導入せず、通常の転送で集合の一員へ届けられる。しかし経路が変われば、選ばれる一員も変わり得る。同じ宛先でも観測地点が違えば別のインターフェースに届き、一つの観測地点からでも時間が変われば別の相手に届く。安定した文字列はサービスとの待ち合わせ場所であって、機械の恒久名ではなかった。

所属情報を運んだのはルーティングだった

RFC 2373 は、anycast 集合の全メンバーが存在するトポロジー領域を含む最長プレフィックス P を考えた。P の内側では各メンバーを個別のホスト経路として載せ、外側では anycast アドレスを P の経路に集約できた。

ここに拡張性の代価が現れる。共通のトポロジー領域がなければ P は空プレフィックスになり、個別経路をインターネット全体へ伝播しなければならない。文書はこれを深刻な制約と呼び、世界規模の集合は利用不能か厳しく制限されると見込んだ。

アドレス自身は、この所属台帳を一切持たない。運用者がインターフェース設定と経路広告で集合を作り、集約によって遠隔のルーティング表から個々のメンバーを隠すこともできた。

全ゼロが「どれか一台のルータ」を表すとき

必須の Subnet-Router anycast は、その曖昧さを具体化した。サブネットプレフィックスに全ゼロのインターフェース識別子を付ける。構文だけなら、番号ゼロのインターフェースを指すユニキャストと同じである。だが運用上はサブネット内の全ルータが認識し、そのうち一台にだけ配送された。

それ以外のアドレスについて、実装は明示的に anycast と構成されない限りユニキャストとみなす。つまり分類の一部は 128 ビットの外側、ノード設定と転送状態にあった。

初期制限は未解決部分を記録していた

RFC 2373 は、任意の anycast をインターネット規模で使った経験が少なく、複雑さと危険があると認めた。そこで送信元アドレスへの利用を一時的に禁じ、割り当て先をルータに限定した。後継の IPv6 アドレス仕様はこれらの制限を外したが、ユニキャスト形式、明示構成、経路による選択という核は残した。

後世の規則を過去へ投影してはいけない。1998 年の文書は、既知の形式と転送を再利用し、必須のルータ用途を設け、経験の乏しい範囲を狭く保つ最小初期仕様だった。後の緩和は、当初の懸念がすでに解決済みだったことも、現代的なサービス運用が当時存在したことも証明しない。

応答が証明できる範囲

一つの応答が示すのは、その時点、その観測地点から、ある経路が応答可能な一員へ届いたことまでである。全メンバー、経路の最適性、ヘルスチェックによる選択、次のパケットの配送先、アプリケーション処理の完了までは証明しない。

有効な証拠連鎖では、宛先アドレス、構成されたメンバー集合、各経路広告、観測地点ごとの選択経路、受信インターフェース、応答プロセス、セッション継続、最終的な業務結果を分けて記録する。

Lu Heng の running-code 優先原則に従えば、権威はアドレスのラベルではなく、実際に動く構成と転送にある。最小初期仕様は専用の自己記述型 anycast を発明しなかった理由を説明する。現実の層という考え方は、アドレス、経路、応答、完了した行為を隣接する別々の事実として扱うよう求める。

RFC 2373 は、一つのアドレスで集合の一員を見つけられるようにした。その達成は、アドレスが誰を見つけるか知っているふりをしなかったことに支えられている。