要約

  • RFC 9084は、プレフィックスを起点としたOSPF Router IDと、到達可能なRouter Addressを広告へ追加する。ABRが別エリア向けのLSAを作っても由来を残せるが、SPF計算は変えず、広告の正当性も保証しない。
  • Ketan Talaulikarは5人の著者の一人であり編集者である。ABRは現在のECMP計算へ寄与する起点だけを伝え、特定できない場合は二つの属性を付けてはならない。推測より欠落を選ぶ規則が記録の信頼性を支える。

エリア境界で変わるのは到達性ではなく見える名前

エリア内プレフィックスでは、LSAのAdvertising Routerから広告元を識別できる。ABRがエリア間プレフィックスを別のエリアへ伝えると、新しいLSAのAdvertising RouterはABR自身になる。受信側が読んでいるLSAの作成者としては正しい一方、その前段でプレフィックスを起点としたルーターは通常のフィールドから消える。

これはOSPF階層の破綻ではなく、抽象化の結果である。ただし解析には損失が生じる。複数のプレフィックスが実際の起点ではなくABRへまとめて関連付けられる。同一プレフィックスを起点とする複数のECMPノードが見えなくなる。障害対応者が中継地点を原因地点だと誤解することもある。

2021年8月のRFC 9084は、プレフィックス属性として二つの任意sub-TLVを定義した。著者はA. Wang、Acee Lindem、J. Dong、Peter Psenak、Ketan Talaulikarで、Talaulikarは編集者として記録される。IETF Datatrackerの人物記録は、この署名を公開されたルーティング標準活動へ結び付ける。

編集者であることは、単独発明や運用支配を意味しない。文書は5人の著者とIETFの審査過程による共同成果であり、実装、設定、採用、実ネットワークの結果は別の主体が担う。人物への正確な帰属は、その境界を消さない。

広告者と起点は別々に保持する

Advertising Routerは、現在のLSAを誰が生成したかを示す。Prefix Sourceは、伝播の前段で誰がプレフィックス広告を起点としたかを示す。ABRを越えた場合、この二つが違うことは正常である。

RFC 9084は既存フィールドの意味を広げず、追加属性に由来を置いた。そのため受信側は「このABRがLSAを作成した」と「この別のルーターがプレフィックスを起点とした」を同時に記録できる。

由来は責任追跡の入口であって、所有証明ではない。起点と記録されたルーターがアドレス資源を所有するとは限らず、現在も動作しているとも、実際のパケットがそこを通るとも限らない。名前が示す範囲を越えて意味を足してはならない。

Router IDとRouter Addressは同じものではない

Prefix Source OSPF Router-IDは、OSPFドメイン内で一意な32ビット値を運ぶ。IPv4のloopback addressを使う慣行はあるが、Router IDが到達可能である保証はない。OSPFv3とIPv6では、その値をIPv6の運用アドレスとして扱うこともできない。

Prefix Source Router Addressは、起点ルーターの到達可能なIPv4またはIPv6アドレスを運ぶ。長さはプレフィックスのアドレスファミリーに応じて4または16オクテットである。起点が既に適切なOSPF Router Addressを広告している場合、同じアドレスを使わなければならない。それがない場合、実装は一意で到達可能なローカルアドレスを選べる。

Router IDはプロトコル上の同一性、Router Addressは運用上の到達性を担う。片方をもう片方の代用にすると、正しいIDなのに接続先がなくなったり、到達できる別ノードを起点だと誤認したりする。監視は両方と、そのLSA文脈を残す必要がある。

RFC 7684はOSPFv2の拡張プレフィックス属性を、RFC 8362はOSPFv3の拡張可能なLSA形式を提供する。属性を運ぶ共通形式であって、資源所有者の認証や広告許可を行う仕組みではない。

ECMPでは起点が複数になる

同じプレフィックスを複数の等コストノードが起点とすることがある。そのため親TLVには、ECMP起点ごとに複数のPrefix Source Router-IDとRouter Addressを含められる。

表示を簡単にするため一つの「代表」を選ぶと、仕様が保持した分散性をアプリケーションが再び失う。コントローラーは値の集合、追加と削除の時刻、それぞれを支えた広告を保持しなければならない。

一つの起点が集合から外れても、プレフィックス全体が消えるとは限らない。逆にプレフィックスが残っていても、起点集合が同じとは限らない。状態変化を一つの緑色表示へ圧縮すると、原因解析に必要な差分がなくなる。

ECMP集合は転送結果そのものでもない。フローハッシュ、各next hopの利用率、ブラックホール、個別パケットの通過経路は、FIB、カウンター、プローブなど別の観測で確かめる。

分からない起点は広告しない

ABRがbackboneから得たエリア間プレフィックスを別のnon-backbone areaへ生成する際、現在のECMP経路へ寄与するノード集合を計算する。起点情報として使えるのは、その集合に含まれるノードだけである。

寄与する起点を特定できなければ、ABRは二つのPrefix Source属性をどちらも含めてはならない。「不明」は正確な状態であり、ABR自身、最後に見た値、推測したノードで埋めることは誤った証拠の生成になる。

過去の属性をそのままコピーすることも許されない。昨日はECMPに参加していたノードが今日の計算から外れたなら、現在の由来集合からも外れるべきだ。由来は静的な名札ではなく、計算結果と同期する状態である。

エリア内広告なら、source Router IDとLSAのAdvertising Routerを比較できる。不一致は無効として無視する。エリア間や外部広告では同じ検証を確実に行えない。中継者と起点が異なること自体が機構の目的だからだ。

NSSAからAS-externalへの変換も同じ考え方に従う。変換の都合で由来を無条件に消しても、現在の寄与集合から外れた由来を残してもいけない。

正しい長さは正しい主張を保証しない

Router IDが0なら無効であり、受信側は無視する。アドレスファミリーと一致しない長さのRouter Addressも無効である。どちらもrate limitを掛けてエラー記録することが推奨される。明白な異常を解析へ入れず、ログ自体が攻撃対象になることも抑える。

しかし、形式が正しい偽情報は残り得る。RFCは、プレフィックス広告を注入できるrogue nodeが偽の起点情報も広告できると明記する。OSPFの認証や参加制御は伝送の境界を守るが、侵害された正規ノードの内容まで真実にしない。

消費側は信頼度を段階化する必要がある。エリア内でAdvertising Routerと一致した値、複数ABRを経た値、外部再配送から来た値は同じ強さではない。到達可能性やLSDBとの整合は補助証拠であり、単独の判定ではない。

再配送では「誰のアドレスか」を決める主体が要る

別のルーティングドメインから入ったプレフィックスでは、OSPFから見える入口はASBRである一方、実際にプレフィックスを持つノードは外部にあり得る。RFC 9084は、Router AddressへASBRを入れるか外部ノードを入れるかを実装が制御できるとしている。

ASBRはローカルチームが操作できる引き渡し点を示す。外部ノードはより長い由来を示すが、別の信頼領域に属し、到達できない場合や内部構造を余分に公開する場合がある。どちらも用途が違い、一律の正解ではない。

sub-TLVだけでは選択された意味が分からない。運用記録に、方針の所有者、対象プレフィックス、変更履歴、消費側の解釈を残さなければ、同じバイト列から二つの組織が異なる責任者を導く。

情報量と公開範囲には費用がある

多くのプレフィックスへ一つ以上の起点を追加すれば、LSDB容量、flooding、解析負荷が増える。RFCは影響を考慮し、必要なプレフィックスだけを対象にできるとしている。観測可能性は無償ではない。

重要サービス、再配送境界、TEコントローラーが使う対象には価値があるかもしれない。一方、全プレフィックスへ測定なしで広げれば、状態とchurnが制御プレーンを圧迫する可能性がある。

もう一つの費用は開示である。エリア境界が隠していた内部ノードを遠隔側へ伝えると、サービスの起点や冗長構成が見える。障害対応には役立つが、必要のない利用者へ運用地図を渡すことにもなる。

誰が、どのプレフィックスを、どの期間受け取り、いつ撤回できるかを定める必要がある。説明責任は無制限な公開と同義ではない。

起点属性は経路を命令しない

RFC 9084は、拡張がOSPFの基本経路計算を変更しないと明記する。起点属性が正しくても、metricは変わらず、プレフィックスは自動でインストールされず、広告権限も生まれない。用途はトポロジー解析、障害調査、TEなどの説明である。

コントローラーが情報から経路を変えるなら、その決定と結果はコントローラー運用者に属する。現在のLSDB、ABR計算、ローカルポリシー、インストール済みnext hop、実際の転送を突き合わせる必要がある。

Lu HengのMinimum Initial Specification, Localized Future Decision, and Voluntary AdoptionをSofia Renの分析枠として使うと、共通仕様は二つの由来フィールドと厳格な省略規則に留まる。対象、外部アドレスの意味、消費者の行動はローカルで決める。

Running-Code Primacyは、その記録を稼働中のLSDB、ECMP集合、到達可能なノード、コントローラー状態、転送結果で検証する。この二つの文章は2026年の編集上の視点であり、Talaulikarらの私的意図を示す資料ではない。

この拡張は、階層が隠した事実を戻しながら、その事実へ経路支配権を与えない。プレフィックスは最初のルーター名を保てる。信じて使う責任は、受信した組織に残る。

出典