要約

  • RFC 7067とRFC 8171は、unknown unicast、ARP、NDの一部をPushまたはPullによるアドレスと到達位置の対応情報に置き換える。効果を安全に得るには、不完全な情報における「不明」と、完全な情報における「存在しない」を分けなければならない。
  • RFC 8302とRFC 8380では、その対応情報がキャッシュ、代理応答、事前カプセル化に使われる。情報が転送の早い段階で作用するほど、古い対応や偽の対応による損害は大きくなる。

分析

古い答えは正常な形で届く

仮想マシンが別のラックへ移動しても、IPアドレスとMACアドレスは同じままかもしれない。変わるのは、その端末へ到達するegress RBridgeである。移動前の対応情報を保持するクライアントにとって、答えは壊れていない。形式も認証も正しく、示している場所だけが古い。

フラッディングは非効率だが、未知を未知のまま扱う。宛先を知らないエッジは、周囲へ問いを広げる。ディレクトリ支援はこの繰り返しを減らす。Pushなら情報を前もって配り、Pullなら必要な時点で問い合わせ、結果をキャッシュできる。データセンターの規模が大きくなり、仮想マシンの作成、削除、移動が増えるほど、unknown unicast、ARP、IPv6 Neighbor Discoveryを減らす利点は大きい。

RFC 7067は、2013年11月に問題設定と高位設計を提示したInformational文書であり、Internet Standards Track仕様ではない。著者はLinda Dunbar、Donald Eastlake、Radia Perlman、Igor Gashinskyである。RFC 8171は、Donald Eastlake 3rd、Linda Dunbar、Radia Perlman、Yizhou Liによる2017年6月のStandards Track文書で、具体的なディレクトリ機構を定める。

続くRFC 8302はYizhou Li、Donald Eastlake 3rd、Linda Dunbar、Radia Perlman、Muhammad Umairの共同執筆、RFC 8380はLinda Dunbar、Donald Eastlake 3rd、Radia Perlmanの共同執筆である。いずれも2018年のStandards Track文書だ。IETF Datatrackerの人物記録はLinda Dunbarの参加を裏付けるが、単独発明や特定ネットワークでの導入成果までは示さない。

完全性は受信側の行動を変える

RFC 8171では、Push Directory serverがData Labelごとに完全な情報を持つかどうかを表明できる。完全な対応表が実際に配布済みなら、ingress RBridgeは表にないunicast宛先をフラッディングせず、フレームを捨てることができる。完全という前提が誤っていれば、到達可能な宛先への通信を同じ処理が失わせる。

ここで「完全」は運用上の権限になる。不完全な集合に見当たらないことは、その情報源が知らないというだけである。検証済みの完全な集合にないことは、指定された範囲で存在しないという、より強い否定を支えうる。両方を一つのnot foundに押し込めると、部分的な台帳が探索を止める権限を得る。

さらに、RFC 8171は情報の配送と生成を分離している。Primary serverは、鮮度を確保するよう設計された信頼できる仕組みから情報を得るものと定義されるが、その仕組み自体は仕様の範囲外だ。Secondary serverはprimaryから受け取れる。プロトコルが正しく複製できても、元のオーケストレーション情報が移動を見落としていれば、誤りも正確に複製される。

認証は話者を確かめる。暗号化は経路上の改変や漏えいを抑える。しかし、認証された話者が現在の場所を知っているかどうかは別問題である。正規のセッションで届いた古い対応情報は、正規の古い対応情報にすぎない。

サーバーはクライアントの記憶を管理する

Pull応答にゼロ以外のLifetimeを付けると、クライアントはその期間、結果を再利用する。正の応答は端末の移動後に古くなる。負の応答は、その後に新しい端末が追加された時に古くなる。後者は誤配送を起こさない代わりに、新しい宛先を見えないままにする。

RFC 8171は、そうしたサーバーにUpdate messageによる訂正を求め、キャッシュ整合性のため三段階の記録方法を示す。最も粗い方法はData Label単位の失効時刻を記録し、変更時に広い範囲をフラッシュする。最も細かい方法は、どのクライアントがどの正または負の応答をいつまで保持しうるかを追跡する。後者は不要な無効化を減らすが、サーバー側の状態を増やす。

これは、正確さの費用を誰が負担するかという設計でもある。サーバーが詳細を持たなければ、ネットワーク全体がより多くの再問い合わせと広域無効化を負う。詳細を持てば、サーバーは他者のキャッシュについても記憶しなければならない。どちらを選んでも、サーバーの変更がクライアントへ届くまでの短い古さの窓は残りうる。

Lifetimeは正しさの保証期間ではない。再利用を許す最大時間である。移動が多い環境で長いLifetimeを選べば、問い合わせ数は減っても旧位置を信じ続ける時間が増える。値はキャッシュ効率だけでなく、現実の変化率と誤りの影響から決める必要がある。

Confidence Levelは情報源の順位表である

RFC 8302は、IP、MAC、Data Labelの対応をARP/ND最適化に使う。情報源は管理系、ディレクトリや制御プレーン、データプレーンの観測に分かれる。SENDを使わないARP/NDは偽造されやすい。一方、保護された管理情報にも設定誤りや更新遅延がありうる。

Confidence Levelは、それらの相対的な信頼性を実装が設定するための仕組みである。完全で信頼できるディレクトリ情報なら、偽造ARP/NDがローカルリンクへ与える損害を限定できる。不完全または不確かなディレクトリなら、データプレーン学習と併用し、どちらを採るかをconfidenceで仲裁できる。

重要なのは、IETFが普遍的な順位を定めていないことだ。数値は事実を測定するのではなく、情報源についての判断を表す。その判断を監査するには、なぜ一方が優先されるのか、どの観測なら覆せるのか、優先が何時間続くのかを説明できなければならない。

移動はその説明を試す。RFC 8302は、ローカルに学習した動的エントリーをリンク障害時に削除し、更新されない対応をage outさせるよう求める。端末がRB1からRB2へ移ったなら、旧位置は新位置に置き換わり、他のエッジも更新されるべきだ。中央にあることではなく、観測された変化に追随できることが信頼の根拠になる。

早い判断は誤りの到達範囲も広げる

RFC 8380は、信頼された非RBridgeノードがディレクトリの助けを借りてTRILLパケットを事前にカプセル化する仕組みを扱う。宛先のegress RBridgeをあらかじめ知ることで、通常の入口での探索やフラッディングを減らせる。

同時に、セキュリティ上の境界は厳しくなる。信頼できない支援ノードはingress／egress nicknameや内外のMACアドレスを偽装でき、TRILLドメインのトポロジーも相当程度知りうる。ディレクトリとの経路が攻撃されれば、偽の対応情報によってパケットが誤った宛先へ送られ、受信者を制限するポリシーに違反する可能性がある。そのためRFCは相互認証と暗号化、パッチ維持、適切な設定、最小アクセスを推奨する。

ただし、保護された経路は内容の鮮度を保証しない。話者、範囲、相対信頼度、保持期限、更新成功、実際の転送は別々の証拠面である。前段で情報を使うほど、一つの誤りが通常のエッジ検査を通る前に作用しうる。

ネットワークが台帳を反証できること

Lu Hengが後に示した最小初期仕様、将来判断のローカル化、自発的採用は、Sofia Renがこの仕組みを読むための視点になる。相互運用に必要な対応形式と更新意味は共有し、confidence、キャッシュ、フォールバック、リスク受容は結果を負う側に残す。これは後年の編集上の比較であり、RFC著者の思想を推定するものではない。

Running-Code Primacyから得られる試験はさらに厳しい。ディレクトリが価値を持つのは、実際の転送系がそれを使うからだ。リンク状態、移動イベント、パケット経路が記録と食い違えば、記録は失効し、訂正され、順位を下げられ、または迂回されなければならない。

四つのRFCは、現在の実装率、導入規模、フラッディング削減率、損失、収束時間、事故防止を実証していない。代わりに、記録を転送判断へ変える前に必要な問いを残した。誰が元情報を作ったか。どこまで完全か。誰が古い応答を持つか。何がそれを覆せるか。移動してから訂正まで何秒かかったか。

優れたディレクトリは速く答える。信頼できるディレクトリは、自分の答えが効力を失う条件も明示する。

情報源