要約

  • RFC 5308 の TLV 236 は IPv6 プレフィックス到達性、TLV 232 は IPv6 インターフェースアドレス、NLPID 142 は IPv6 対応を表す。三つは役割の異なる主張であり、一体化した転送完了証明ではない。
  • 標準トポロジーを IPv4 と共有する構成では、IPv6 の SPF が成立しても各中継ノードの能力、RIB、FIB、実パケットの結果を照合する必要がある。RFC 5120 のマルチトポロジーは参加資格を明示できるが、配送結果そのものは保証しない。

「到達可能」の範囲を一段ずつ分解する

運用画面には目的プレフィックスがある。メトリックは許容範囲にあり、SPF の木にも不自然な枝はない。送信側と宛先側は IPv6 を扱う。それでもパケットは、中間の一台が共通 IS-IS グラフには属しながら IPv6 の転送条件を満たしていなければ、そこで終わる。

ここで重要なのは、単独の記録を誤りと決めつけないことである。プレフィックス広告は正しいかもしれない。隣接も本物で、SPF の実装も仕様どおりかもしれない。誤りは、それらの記録が持つ権限の範囲を越えて「全ホップで IPv6 を運べる」という結論を作った瞬間に生じる。

RFC 5308 は IPv6 情報を従来の IS-IS LSP に載せる。RFC 5120 は必要ならトポロジーを分ける仕組みを定義する。この二つを重ねると、標準トポロジーの隣接は IS-IS の接続性を示すだけで、そこを通る全ネットワーク層プロトコルの実装状態まで宣誓していないことが見える。

TLV 236 は経路材料であって配送票ではない

IPv6 Reachability の TLV 236 には、プレフィックス、32 ビットのメトリック、U・X・S の各ビット、必要に応じてサブ TLV が入る。U は階層を下向きに伝わったこと、X は別のルーティングプロトコル由来であること、S はサブ TLV 部分が続くことを示す。どのビットも、パケットが転送されたことを示さない。

同じ TLV は一つの LSP にゼロ回でも複数回でも現れ得る。リンクローカルプレフィックスを載せてはならない。プレフィックス本体は長さに応じた最少バイトだけで符号化されるため、観測基盤は表示済み文字列だけでなく、長さと有効バイトを保持しなければならない。

さらに、MAX_V6_PATH_METRIC は 0xFE000000 である。これを超えるメトリックを持つ広告は、通常の SPF 計算では考慮してはならない。データベースには存在し得るが、通常の IPv6 ルート候補ではない。したがって「LSP に見えた」と「選路に使えた」を同じ状態名で保存する設計は、仕様上の区別を壊す。

TLV 232 は PDU を失うと意味を変える

IPv6 Interface Address の TLV 232 は、入っている PDU によって作用域が変わる。Hello では送信インターフェースに割り当てられたリンクローカルアドレスだけを含める。LSP では広告元の中間システムに割り当てられた非リンクローカルアドレスだけを含める。

アドレス値だけを抽出して Hello か LSP かを捨てると、近隣リンクだけで有効な識別子をドメイン全体の識別子のように扱う危険がある。逆に、システムの非リンクローカルアドレスを、どこで主張されたか分からない断片へ変えてしまう。正しいテレメトリーは値だけでなく、送信者、インターフェース、PDU 種別、受信時刻を一組として保存する。

NLPID 142 は能力宣言の入口にすぎない

IS-IS で IPv6 ルーティングを支えるシステムは、Protocols Supported TLV に IPv6 の NLPID 142 を入れなければならない。これは TLV 236 が一つ見えたという事実より、ノードの能力に近い証拠である。それでも宣言者はルーティングプロセスである。

特定のポートが稼働しているか、隣接ノードのリンクローカルアドレスを解決できたか、該当 VRF に正しい RIB が選ばれたか、最新の FIB が全ラインカードに投入されたかまでは示さない。署名や認証で LSP の真正性を高めても、この範囲は広がらない。真正な制御プレーン情報と、完全な転送経路は別の性質である。

ECMP では証拠の対象がさらに広がる。一度の疎通確認は、実際に選ばれた一つのメンバーについての観測にすぎない。同じハッシュ空間に残る他の次ホップが IPv6 を捨てるなら、経路全体を「正常」とすることはできない。

RFC 5120 はグラフへの参加をアドレスファミリーに結び付ける

マルチトポロジー IS-IS は、IIH でトポロジー参加を伝える。ポイントツーポイントリンクでは、相手があるトポロジー ID を広告していなければ、その相手を当該トポロジーの LSP に含めてはならない。共通トポロジーが一つもない二者は、隣接を形成すべきではない。MT ID 2 は IPv6 routing 用に予約され、TLV 237 は TLV 236 由来の IPv6 到達性にトポロジー識別を加える。

ただしブロードキャスト LAN では、共通マルチトポロジーがなくても同じ DIS を選ぶために隣接を形成する。この例外は設計上の注意点を鮮明にする。基礎隣接が存在することは、あらゆるトポロジーでその隣接を経路に使ってよいという許可ではない。実際の共通メンバーシップを別に評価しなければならない。

IPv4 と IPv6 を別グラフにすれば、非対応ノードが IPv6 の中継に入る問題を減らせる。その代わりに、トポロジーごとの参加状態、overload、TLV 237、SPF、RIB、回復手順が増える。同じアドレスファミリーの複数トポロジーでアドレスが重なる場合、受信パケットにどの RIB を使うかは別のローカル機構で決める必要がある。分離は曖昧さを消すが、自動的な配送保証を作るわけではない。

RFC 7775 が修正した優先順位も監査対象になる

RFC 5308 の元の記述は、IPv6 の優先順位に Level 1 up、Level 2 up、Level 2 down、Level 1 down を並べた。後の RFC 7775 は、基礎となる二階層モデルに Level 2 inter-area という経路種別がないため、その形の「Level 2 down」は不適切だと説明し、TLV 236 と TLV 237 の実際の経路種別に合わせて規則を置き換えた。

実装監査では 2008 年の列挙を最終仕様として固定せず、RFC 7775 を含めて判断する必要がある。保存する証拠も単一の勝敗ではなく、TLV、トポロジー、レベル、U/X ビット、元プロトコル、メトリック、優先クラス、SPF 世代を含むべきだ。そうすれば規格の訂正後にも、当時の入力と決定を再現できる。

パケットと同じ住所体系で追跡する

機密情報を含めずに有用な運用レシートを作ることはできる。ノード ID、隣接、PDU 種別、トポロジー ID、Protocols Supported TLV と IPv6 NLPID、TLV 232 のアドレスと作用域、TLV 236 または 237 のプレフィックス・各ビット・メトリック・サブ TLV、SPF 世代、前駆ノード、次ホップ、全 ECMP メンバー、各中継ノードの IPv6 能力、RIB 選択、FIB 世代と投入結果、リンクローカル解決、プローブ経路、配送結果、ロールバック判断を一つの鎖にする。

この鎖が守るのは、到達性を記述する権限と、実際にパケットを動かす責任の境界である。グラフの計算は正しくてもよい。それだけでは「IPv6 がこの経路を通った」という主張に必要な証拠は完成しない。

Sources