要約

  • RFC 9983 の 0x10 AC-Flag は、Extended Prefix TLV のプレフィックスが複数ノードから広告される意図を示す、限定された属性である。
  • 設定、LSA の到達、経路計算、FIB、ECMP による選択、レプリカ健全性、アプリケーション結果は、それぞれ別途確認すべき証拠である。

運用画面では、同じプレフィックスの複数広告と AC-Flag を見つけると「Anycast 正常」と表示したくなる。BGP-LS のコレクターも同じビットを示していれば、結論はなおもっともらしく見える。しかし、その画面は一つの宣言を複数回見ているにすぎず、パケットの選択やサービス結果を観測したわけではない。

RFC 9983 は、2026 年 5 月に IETF Standards Track として公開された OSPFv2 Anycast Property Advertisement である。Extended Prefix TLV Flags の 0x10 を Anycast Flag とし、意味を「当該プレフィックスは複数ノードから広告される意図がある」と定める。anycast として設定されたプレフィックスはこのフラグを設定し、そうでないものはクリアしなければならない。

これは重複広告の意味を明示するための有効な共通語である。複数広告だけでは、意図された anycast なのか、移行中の重なりなのか、設定誤りなのか分からない。Extended Prefix Opaque LSA が他エリアへ再広告される際にもフラグを保存しなければならないため、意図はエリア境界で失われない。

ただし、保存された意図は稼働確認ではない。

一つのビットから飛び越えてはいけない段階

最初に、誰がどの権限で anycast を設定したかという管理面の事実がある。次に、どのルーターがどの LSA を受信したかという制御面の事実がある。さらに各 ingress が、その時点の SPF、ポリシー、フィルター、再帰解決を用いてどの経路を採用し、FIB へ入れたかという局所的事実が続く。データ面では ECMP ハッシュ、戻り経路、隣接状態が特定のレプリカを選ぶ。最後に、そのレプリカが健全で権限を持ち、期待するアプリケーション操作を完遂したかがある。

一段が正しくても次段は保証されない。AC-Flag 付き LSA があっても、必要なエリアへ届かないことはある。経路が RIB にあってもローカルポリシーにより FIB へ入らないことがある。FIB が正しくても、あるフローは drain 中や過負荷のレプリカを選ぶことがある。TCP の応答があっても、認証された要求が失敗したり、古いサービス状態を返したりすることがある。

RFC 9983 はこの後半を約束しない。そこで Heng Lu の最小初期仕様という読み方が役立つ。共同層には共同で必要なものだけを置く。ここでは「複数ノード向けのプレフィックス」という意図で十分である。健全性判定、負荷分散、サービス責任、業務上の成功条件はローカルな判断であり、ローカルな証拠を必要とする。共通フラグにそれらを押し込むと、説明可能性が失われる。

AC と N の矛盾は消してはならない

RFC 9983 は RFC 7684 の N-flag と AC-Flag を同時に設定してはならないとする。両方を受け取ったルーターは設定異常として扱い、N-flag を無視し、レート制限を考慮して記録すべきである。

これは単なるパーサー上の例外ではない。監視パイプラインが全フラグを「有効なプレフィックス属性」という一つの真偽値に畳み込めば、規格が異常として残すよう求めた矛盾を消す。逆に、その矛盾だけでサービス停止を宣言することもできない。規格はその因果を定めていない。矛盾を肯定的な能力証拠から除外し、設定と広告の起点を追跡し、別のデータ面・サービス面の観測で影響を判断するのが適切である。

可視化の拡大は操作権限の拡大ではない

複数ルーターが広告するプレフィックスについて、少なくとも一つに AC-Flag があれば RFC 9983 は anycast とみなす。単一広告かつフラグなしならノード固有である。古い設定を厳格に監視し、一貫して管理することも求める。属性識別ではフラグが優先するからである。

RFC 9085 の BGP-LS Prefix Attribute Flags TLV は対応する属性を運べる。トポロジー分析には価値があるが、コレクターが ingress の FIB、実際の ECMP 選択、レプリカの稼働、トランザクションの完了を認定できるようにはならない。同じ宣言が OSPF、BGP-LS、資産台帳で一致しても、独立した三つの証人ではない。

RFC 9983 は RFC 9129 と RFC 8349 の YANG モデルに書込み可能な anycast-flag を追加する。管理面の書込みが、下流の判断を変え得る。だから安全な管理トランスポート、相互認証、NACM によるアクセス制限が必要となる。フラグを転送や安全保障の判断へ使うなら、誰が何をいつ書いたか、どの実装が解釈したか、矛盾時の規則が何かを監査可能にすべきである。

事実を層ごとに記録する

重要なプレフィックスには、承認済み設定と管理主体、エリア別 LSA と AC/N 矛盾、関連 ingress の経路計算と FIB、実データ面の選択、各レプリカの健全性・容量、アプリケーション結果を結び付ける。すべてのアラート前に全項目を集めるという意味ではない。観測した層に見合う名前を結論へ付けるという意味である。

「AC-Flag を観測した」は強い主張である。「anycast サービスは健全」は、その主張だけからは導けない。この区別を守れば、障害後にフラグやダッシュボードだけを直し、真に失敗した局所的選択、ヘルス受入れ、アイデンティティ、アプリケーション状態を見逃すことを防げる。