要約

  • draft-ietf-spring-sid-as-source-address-00は2026年9月7日に公開され、SPRINGのワーキンググループ文書になった。作業対象になったのであり、RFCとして承認されたわけではない。
  • 入口PEのループバックアドレスに代えて対応するサービスSIDを外側の送信元に使えば、往復のアドレス関係をファイアウォールが同じセッションとして照合しやすくなる。
  • その送信元はサービス文脈を表す。装置、顧客、利用権限まで一意に示すものではなく、草案自身が追跡性低下、SIDの偽装、状態表の消費を警告している。

問題は、往路だけを見れば不自然ではない構成から生じる。SRv6の入口PEは顧客パケットを外側IPv6ヘッダーで包み、送信元に自分のループバック、最終宛先に対向側のVPNサービスSIDを使うことが多い。SR Policyなら最終宛先はSRHの末尾にあり、ベストエフォートならIPv6宛先そのものになる。SRv6を解釈できるファイアウォールは、末尾の宛先を取り出して状態を作る。

復路では別のPEループバックが送信元になり、最初のPE側のサービスSIDが最終宛先になる。外側の二つのアドレスは単純に入れ替わらない。戻り側の送信元が往路の宛先と等しいことを期待する装置には、同じ顧客通信が二つの無関係なフローに見える。その結果、正常な応答やICMPエラーまで捨てられうる。

新草案の発想は、位置ではなくサービスの意味を対称にすることだ。入口PEがL3 VPNを特定した後、対向PEがその通信で受け取るはずのサービスSIDを選び、外側の送信元に置く。逆向きでも同じ処理をする。サービスSIDが送信元と最終宛先の間で反転し、状態キーが整う。送信元欄のSIDは通常のIPv6アドレスとして扱われ、その場所でエンドポイント動作を実行しない。

ここで「送信元」という言葉の中身が変わる。以前は入口PEを指すアドレスだったものが、入口PEの選んだサービス分類子になる。ファイアウォールのヒットは、現在の解析と規則の下で既存セッションに結び付いたことを示す。しかし、どの筐体が送ったか、どの顧客が原因か、そのノードにSIDを使う権限があったか、値が偽装されていないかまでは証明しない。

草案は三段階の粒度を示す。VRF単位なら追加検索が不要で扱いやすいが、同じVRFの複数CEが一つの送信元SIDに畳み込まれる。AC単位は追加検索なしで接続回線まで分けられる。プレフィックス単位はさらに細かいが、顧客パケットの送信元をVRF内で再検索するため、転送コストが増える。利用可能な最細粒度を選び、プレフィックス、AC、VRFの順にフォールバックする規則は、精度と費用の接点を明示している。

対称性は信頼の代用品ではない。ロケータープレフィックスがドメイン内で到達可能なら、内部ノードが正規のサービスSIDに見える送信元を偽装できる可能性がある。さらに、動的なSIDが短時間に増減すれば、ファイアウォールのセッション作成、エージング、容量に負荷がかかり、表があふれる恐れもある。草案が利用可能なサービスフローを厳しく制御するよう求めるのは、そのためだ。送信元許可、なりすまし防止、SIDの世代管理、状態予算は別の統制である。

ICMPでは、同じアドレスに診断上の役割が加わる。SRv6 PingはEnd SIDを外側の送信元にして復路到達性を試せる。中継ノードがエラーを返すとき、処理に失敗したSIDを送信元にすれば、ヘッドエンドは関連するノードとセグメントを特定しやすい。VPN由来のエラーでは、入口PEが埋め込まれた上位ヘッダーをRFC 8986どおり処理し、内側ICMPをCEへ渡す必要がある。ただし、障害位置を示す値は報告者の認証でも根本原因の確定でもない。

圧縮形式との組み合わせも条件になる。RFC 9800では、ルーティングヘッダー末尾と最終ノードが受け取る宛先が異なる場合があり、SRHを使わず宛先欄に圧縮セグメントを収めることもできる。草案は最終宛先を圧縮せず、SRH末尾に残すことを推奨する。ファイアウォールが両方向で同じ最終宛先を復元できなければ、PEの送信元選択が正しくても状態照合は崩れる。

実装欄にも境界がある。New H3CのCR16000とCR19000、ソフトウェア7.1.119以降が全節を実装し、成熟度はProductionと記されている。一方、対象版は前身のDraft-13で、具体的な実装経験は「特になし」とされる。RFC 7942の扱いに従い、IETFが寄稿者の申告を検証したわけではなく、推奨でもないと本文自身が断っている。動くコードの手掛かりではあるが、第三者適合試験、相互接続結果、導入規模の証明ではない。

Heng Luの現実層の考え方を当てると、混同すべき境目が見える。ワーキンググループ採用は調整の事実、PEの設定は意図した状態、パケットと状態表は観測、顧客への配送と追跡可能性は結果だ。一つが成立しても、次の層まで自動的に成立しない。

今回のニュースの価値は、SRv6の機能が一つ増えたことではない。誤廃棄を減らすために、送信元アドレスをサービスの記号へ読み替える作業が、共通仕様の検討対象になったことにある。運用記録はSID割当、許可された発信PE、選択粒度、ファイアウォールの解析版、状態ヒット、実パケット、CEでの結果を一つの世代で結ぶ必要がある。「戻り通信が一致した」を「誰が送ったか確認できた」に膨らませないためである。

出典

  1. IETF Datatracker：SID as source address in SRv6
  2. ワーキンググループ草案00
  3. Datatracker：前身草案
  4. 前身草案リビジョン13
  5. SRv6 Security Considerations リビジョン16
  6. RFC 8402：Segment Routing Architecture
  7. RFC 8754：IPv6 Segment Routing Header
  8. RFC 8986：SRv6 Network Programming
  9. RFC 9252：BGP Overlay Services over SRv6
  10. RFC 9259：OAM in SRv6
  11. RFC 9800：Compressed SRv6 Segment Lists
  12. RFC 7942：Implementation Status Sections
  13. Heng Lu：Running-Code Primacy
  14. Heng Lu：Minimum Initial Specification
  15. Heng Lu：Reality Layers