要約

  • RFC 1546 は、一つのアドレスでサービス提供者のどれかに到達する実験を定義したが、そのアドレスを特定サーバーの識別子とはしなかった。
  • 最初のデータグラムと次のデータグラムは別のサーバーに届き得るため、状態の継続、重複防止、レプリカ整合性には追加の仕組みが必要だった。
  • 後続 RFC は Service Address、Anycast Node、NSID などを整備したが、経路選択と応答者の権限を同一視しなかった。

接続開始が発見になる

1993年11月、Craig Partridge、Trevor Mendez、Walter Milliken は RFC 1546 を公表した。IRTF による Informational 文書であり、インターネット標準ではなく実験的サービスの説明だった。したがって、ここから特定組織の導入や普及率、実装品質を導くことはできない。

出発点は、利用者が機械そのものではなく機能を求める場面だった。同じサービスを複数のサーバーが提供し、どれが選ばれてもよいなら、ネットワークが一台を選べる。そのための anycast アドレスに対し、インターネットは少なくとも一台、できれば一台だけへデータグラムを届ける。

「できれば」という表現が境界を示す。通常の IP はデータグラムを複製したり誤配送したりし得る。一件の送信は、厳密に一台が一度だけ処理した証明ではない。RFC が共有したのはサービス到達の最小意味であり、結果の一意性ではなかった。

二通目が別の現実へ行く

文書の例では、最初のデータグラムがサーバー X に届く。同じ宛先へ送った二通目は X に戻るかもしれず、Y に届くかもしれない。IP 層は前回の選択を覚えていない。

ここで一つのアドレス表示の裏に、異なる事実が現れる。ある時刻の送信元に対して選ばれた経路、到達したノード、応答したプロセス、保持していたデータ、アプリケーション上の効果は、それぞれ変化し得る。共有ロケーターの継続は、関係の継続ではない。

一回で完結する冪等な問い合わせなら、選択が変わっても問題になりにくい。だが X が保存したチャレンジを Y は知らない。X で始めた処理が Y に複製済みとも限らない。応答が見えず再試行した書き込みは、最初の効果が無かったとは限らない。さらに一つのデータグラムが複数サーバーへ届く余地まであれば、トランザクションの受領証が不可欠になる。

anycast から unicast への参照変更

RFC 1546 は TCP に特別な手順を提案した。ACK のない最初の SYN だけが anycast アドレスを遠隔宛先に使う。選ばれたサーバーは自身の unicast アドレスから SYN-ACK を返す。開始側は相手のアドレスをその unicast 値へ置き換え、以降は一台との接続として扱う。

これは共有アドレスが個体識別子に変身する仕組みではない。発見に使った参照を、応答によって得た具体的な参照へ切り替える仕組みである。史料は提案を裏付けるが、それが全 TCP 実装に普及したことは示さない。

RFC 7094 は、経路変更が進行中のトランザクションを状態のない別インスタンスへ移せば、セッションがリセットされると説明した。固定的な試験網で動作したことは、異なる世界規模の経路特性でも状態が続く証拠ではない。

UDP や複数 TCP 接続をまたぐアプリケーションにも同じ制約がある。継続して同じ相手が必要なら、最初の交換で unicast アドレスを学び、次からそれを使う。親和性はアプリケーションが明示的に取得する性質となる。

アドレス、ノード、インスタンス

RFC 2101 は識別子とロケーターを区別した。anycast アドレスは同等の機能を持つ集合の一員を見つけられるが、一意のホストを識別できない。その時間的な一意性は TCP 接続確立より短い場合さえある。

RFC 4786 は運用上の対象をさらに分けた。Service Address はサービスに関連付けた IP アドレス、Anycast Node は離散的な場所でそこへの経路を提示するホストとルーター、catchment は特定の経路状態でそのノードへ導かれる送信元の集合である。選択はトポロジーと送信元に依存し、地理的な近さ、最低遅延、最高品質を保証しない。

等コスト経路の扱いも重要だ。パケット単位で異なるノードへ振り分ければ、一つのトランザクションが分断される。宛先欄が同じでも、状態が置かれた場所は同じでない。

経路広告とサービス正常性も別物である。RFC 4786 は可能なら健康状態と広告を密接に結ぶことを望ましいとした。一方、共有 unicast DNS を扱う RFC 3258 は、ゾーン配布と切替の協調、誤ったデータを受けたサーバーの応答停止を求めつつ、DNS プロセス障害ごとの経路撤回を一般には推奨しなかった。確実な連携には複雑さがあり、DNS は別アドレスへフェイルオーバーできたからだ。

後からの ping は当時の回答者ではない

RFC 4892 は観測の落とし穴を指摘した。ping、TCP 接続、traceroute、追加の DNS 問い合わせは、調査対象の回答を返したサーバーとは別のサーバーに届き得る。後刻の観測は後刻の経路選択を示すだけで、過去の回答者を復元しない。

RFC 5001 の EDNS NSID は、インスタンス手掛かりを対象の応答に入れる。リゾルバーが不透明な識別値を要求し、ネームサーバーが同じ DNS 応答に含める。後追い試験より帰属は強いが、値はサーバー定義で非推移的だ。運用者や場所を認証せず、データの正しさや最終効果も保証しない。

したがって証拠は、時刻、Service Address、観測経路または catchment、応答内のインスタンス情報、伝送結果、データ検証、認証、アプリケーションの判断を別々に保持すべきである。一つの層の記録に他の層の権限を背負わせてはいけない。

経路選択は資格審査ではない

RFC 1546 は当初から、悪意あるホストがそのアドレスの提供者を名乗ってトラフィックを奪えること、盗聴者が不正確な情報で応答し得ることを警告した。anycast 集合の一員であるという主張は、それ自体では検証できなかった。

経路はパケットの行き先を選べるが、応答者を承認し、レプリカの状態を証明し、アプリケーション成功を宣言することはできない。認証プロトコル、署名データ、整合性検査、取引ログがそれぞれ別の受領証を出す必要がある。

RFC 7094 が示した安全側の設計は、この限界を前提にする。同じ宛先へのパケットが異なるインスタンスへ届くと想定し、一パケットで自己完結する要求、状態を持たない伝送、unicast 送信元への応答、要求間の固定状態なし、冪等な再試行を好む。複数パケットが必要なら、anycast 交換で unicast インスタンスを発見できる。

変わらない文字列が隠すもの

RFC 7094 は RFC 1546 を anycast の最初の正式仕様と位置付け、そこで大半の論点が既に捉えられていたと評価した。1993年の成果は「最寄りで最良のサーバー」を約束したことではない。サービス単位の選択だけを共通化し、状態と権限を各層の責任として残したことにある。

本稿の資料が証明するのは、その公刊された設計記録である。特定の導入、障害、脆弱性、採用率、TCP 提案の一般実装、定量的影響は証明しない。ただし、同じアドレスと同じサーバーが別の命題であることは明確だ。過去のログに前者しかなければ、経路が動いた後に後者を取り戻すことはできない。

出典