Stateless Ingress: IPv6セグメントルーティング（SRv6）によるローカルからクラウドへのトンネル制御

Stateful edge proxies are the primary bottleneck for high-throughput tunneling. IPv6 Segment Routing (SRv6) embeds routing logic directly into the packet header, eliminating the edge-state bottleneck entirely.

---

エッジコンピューティングのボトルネック

現代の分散アーキテクチャでは、ネットワークのエッジは非常に複雑になっています。リバースプロキシ、ロードバランサー、NATゲートウェイ、ステートフルファイアウォールなどが負荷をかけています。クラウド境界に到達したパケットがローカル開発環境やマイクロサービス、オンプレミスのデバイスに向かう場合、中央集権的なingressコントローラーがそれを捕捉し、接続を終了させ、ルーティングステートデータベースやインメモリテーブルを参照し、ペイロードをトンネルに再カプセル化します。

このステートフルな処理は、10年以上にわたりWebトラフィックの配信の基盤でしたが、高スループット・超低遅延の要件下では致命的なボトルネックとなります。ステートテーブルの維持コストはスケーラビリティを制限し、パケットあたりの遅延を増大させます。

SRv6はこのパラダイムを根本的に破壊します。IETFによってRFC 8986として2021年2月に標準化されたSRv6ネットワークプログラミングフレームワークは、IPv6パケットヘッダーに直接命令列をエンコードすることで、ネットワークオペレーターやアプリケーションがパケット処理プログラムを指定できる仕組みです。各命令はSRv6セグメント識別子（SID）で識別され、ネットワーク内の複数ノードで実行されます。中央のステートマシンは不要です。

従来のモノリシックなミドルウェア装置に頼ることなく、SRヘッドエンドノードは明示的なルーティング命令（*セグメント*と呼ばれる）をIPv6パケットヘッダーに直接埋め込みます。トランジットルーターはトンネルを知る必要はなく、ハードウェアレートでヘッダー命令を順次実行します。状態を装置からパケット自体に移すことで、真のステートレスネットワーク ingressを実現します。

---

高スループット環境におけるステートフルプロキシのボトルネック

SRv6の価値を理解するには、スケール時のステートフルなingressのコストを考える必要があります。Nginx、HAProxy、Envoy、またはハードウェアのApplication Delivery Controller（ADC）はクラウドの境界に位置します。受信したパケットに対し、proxyは5つの値（ソースIP、宛先IP、ソースポート、宛先ポート、プロトコル）を用いてコネクションステートテーブルをルックアップし、そのパケットが属するトンネルを特定します。

このステートの維持は高コストです。並行するトンネル数が数万、数十万に達すると、ステートテーブルもそれに比例して増大します。proxyはTCPコネクションの状態（SYN、ESTABLISHED、FIN、WAIT）を追跡し続け、切断されたコネクションのメモリ解放や、異なるMTUサイズに対応したバッファ割り当ても管理します。

また、ハブ・スポークアーキテクチャはトラフィックを中央の検査ポイントに迂回させるため、最適な最短経路ルーティングを妨げます。すべてのパケットはロードバランサーを経由して目的地に到達し、これを*トロンボーニング*と呼びます。これにより遅延やスループットの制限が生じ、リアルタイムデータパイプラインには特に悪影響です。

---

SRv6ネットワークプログラミングの仕組み

解決策はIPv6のネイティブプログラマビリティにあります。SRv6はIPv6の128ビットアドレス空間を利用し、ネットワークエンドポイントだけでなく、特定のフォワーディング操作もエンコードします。

SRv6対応ネットワークでは、IPv6アドレスはセグメント識別子（SID）として再利用されます。RFC 8986（セクション3.1）で定義される標準の128ビットSRv6 SIDは、以下の3つの論理コンポーネントに構成されます：

Locator（B:N）: SRv6対応ノードのネットワークアドレスを表す最重要ビット。これは標準のInterior Gateway Protocol（IS-ISやOSPFv3）をSRv6拡張とともにネイティブにルーティングします。locatorはB:Nとして表され、Bは運用者が割り当てたSIDブロック、Nは特定ノードを識別します。

Function: パケット到達時に対象ノードが実行する操作の一意識別子。

Argument（ARG）: 追加のメタデータで、宛先での動作を変化させるために関数に渡されます。

パケットがネットワークエッジに到達すると、SRヘッドエンドノードはこれをSegment Routing Header（SRH）と呼ばれるIPv6拡張ヘッダーでカプセル化します。これはRFC 8754（2020年3月）で標準化されており、順序付けられたSegment Listを持ちます。パケットがネットワークを通過する際、各SRv6対応ノードはアクティブなSIDを検査します。Locatorが自身の設定したlocatorブロックと一致すれば、対応するFunctionを実行します。

RFC 8986は標準化されたエンドポイント動作の基本セットを定義しています。最も実用的なものは:

• End: 基本的なトランジット機能。ノードはSegments Leftカウンターをデクリメントし、次のSIDにIPv6宛先アドレスを更新し、IGP FIBルックアップにより転送します。
• End.X: アクティブなセグメントを更新し、特定のLayer 3隣接点からパケットをクロスコネクトします。トラフィックエンジニアリングやパス制約に有効です。
• End.DX4 / End.DX6: 外側のIPv6ヘッダーをデカプセル化し、内側のIPv4またはIPv6ペイロードを次のホップに転送します。トンネルされたトラフィックを直接ローカルエンドポイントに届けるための重要な機能です。
• H.Encaps (Headend Encapsulation): ingress動作で、受信したIPパケットを外側のIPv6ヘッダーとSRHでラップし、完全なセグメントリストを含む。これはステートレスなingressエッジで適用される機能です。

---

ステートレスIngressの実現：ミドルウェア排除

これらの動作を連鎖させることで、ネットワークエッジからのフローごとのステートを不要にしたingressモデルを展開できます。

SRヘッドエンドはインターネットやピアリングパートナーからのパケットを受信します。TCPコネクションの終了やステートテーブルの参照を行わず、単一のハードウェアアクセラレーションされたポリシーマッチを行い、H.Encapsを即座に適用します。ペイロードは、ターゲットエンドポイントに到達するために必要なSIDリストを持つIPv6ヘッダーでラップされます。

コアのトランジットルーターはトンネルの知識もコネクションステートも持たず、アクティブなIPv6宛先アドレスに基づき、IGPの最短経路でフォワードします。フローごとのステートはコアから完全に排除されます。

最終ノード（Provider Edgeルーター、オンプレミスゲートウェイ、SRv6対応ネットワークスタックを持つ開発者ワークステーション）では、End.DX4やEnd.DX6が外側のIPv6とSRHを除去し、元のペイロードを直接ローカルアプリケーションソケットに届けます。

オープンソース実装例

SRv6を利用した実運用のオープンソーススタックには以下があります：

Linuxカーネル: SRv6サポートはカーネル4.10で導入され（カプセル化）、4.14でseg6localエンドポイント動作（End.DX4などに必要）が追加されました。iproute2ツールチェーンはencap seg6（ソースルーティング）とencap seg6local（エンドポイント機能）を提供します。LinuxカーネルはRFC 8986のほとんどの動作をサポートし、eBPF、Netfilter、FRRouting、Cilium、SONiCと連携しています。

FD.io VPP (Vector Packet Processing): VPPのSRv6実装はRFC 8986のLocalSID動作（End、End.X、End.DX4、End.DX6、End.DT4、End.DT6、End.DX2など）を完全サポートし、T.InsertやT.EncapsによるSR Policyステアリングも可能です。VPPはDPDKバックのデータプレーンでパケットをベクトル処理し、ハードウェア並みのフォワーディング速度をソフトウェアで実現します。

---

トラフィックエンジニアリング、Flex-Algo、uSID圧縮

RSVP-TEの置き換え：ソースルーティング

従来のトラフィックエンジニアリングはRSVP-TE（Resource Reservation Protocol — Traffic Engineering、RFC 3209）に依存していました。これはステートフルなシグナリングプロトコルで、経路上の各ルーターが帯域予約とトンネルステートを保持します。大規模になると、制御プレーンのオーバーヘッドがコアルーターのCPU負荷を増大させます。

SRv6は、ソースルーティングを用いて同じ粒度のトラフィックエンジニアリングをステートレスに実現します。SRヘッドエンドは、SRH内にSIDを積み重ねてフォワーディング経路を指定します。コアルーターはシグナリングステートを持ちません。さらに、RFC 9350（2023年2月、スタンダードトラック）で標準化されたFlex-Algoを利用することで、複数の論理ルーティングトポロジーを同一物理インフラ上に構築可能です。

Flex-Algoは、制約ベースのアルゴリズムを定義し、複数の論理経路を計算します。RFC 9350では、SRv6では*locator*がアルゴリズムにバインドされると規定しています（RFC 9350セクション2）。

例:

• アルゴリズム128は最小の伝播遅延を最優先した経路を計算
• アルゴリズム129は特定の管理グループカラーに一致しないリンクを除外した経路を計算

ステートレスのingressノードは、パケットをカプセル化する際に、目的のFlex-Algoに対応するlocatorブロックを選択します。これにより、重要なトラフィックが制約に適合した経路を通ることが保証され、ネットワーク全体の再シグナリングを必要としません。

RFC 9800（uSID）によるヘッダーオーバーヘッドの解消

SRv6の早期導入時の課題の一つは、カプセル化のオーバーヘッドでした。各SIDは128ビットのIPv6アドレスです。HuaweiのSRH構造のドキュメントによると、SRHの長さは(n × 16) + 8バイトです。例えば6ホップの経路では104バイトのSRHが必要となり、これは標準の40バイトのIPv6外側ヘッダーに追加されます。hop-by-hop制約を指定する場合、パケットのMTUフラグメンテーションやASICのスループット低下を引き起こす可能性があります。

この問題を解決するのが圧縮SRv6セグメントリストエンコーディングです。RFC 9800（2025年6月、スタンダードトラック）として正式に公開されており、RFC 8754を更新します。RFC 9800は、NEXT-CSIDとREPLACE-CSIDのエンドポイント動作を定義し、一般的にmicro-SID (uSID)アーキテクチャとして展開されます。

128ビットのSIDをホップごとに分割する代わりに、複数の圧縮されたC-SIDを1つの128ビットコンテナにパックします。32ビットのlocatorブロック（GIB）と16ビットのC-SIDを用い、最大6つのフォワーディング命令を格納可能です。処理は「シフト＆ルックアップ」方式で、ノードは自身のC-SIDを処理する際に残りのC-SIDをシフトし、次のFIBルックアップを行います。これにより、Segments Leftのデクリメントが不要となります。

uSID圧縮は、非SRv6対応のトランジットノードには透過的です。これらは従来のIPv6宛先アドレスとして認識し、標準のIPv6フォワーディングを行います。したがって、段階的な展開が可能です。

2023年に欧州先進ネットワークテストセンター（EANTC）による多ベンダーの相互運用性テストで、Arista、Arrcus、Cisco、Huawei、Juniper、Nokia、Keysight、SpirentがuSIDの検証を行いました。2024年のテストでは、uSID Micro-SIDシナリオに焦点を当てています。

---

移行戦略と混在環境

従来のレガシーingressアーキテクチャからSRv6への移行には計画的な設計が必要です。特に、SRv6非対応のエンドポイントが存在する場合です。

これらのエンドポイントは、ローカルのプロキシが担います。プロキシはセグメントリストを終了させ、IPv6とSRHを除去し、標準のIPトラフィックをアプリケーションに送ります。これにより、ステートはエッジに限定され、クラウドの中央ステートテーブルは引き続き排除されます。

SR-MPLSとSRv6の共存では、ドメインゲートウェイにバインディングSIDを設定し、SRv6 SR Policy全体を単一のMPLSラベルにマッピングします。これにより、ドメインA（SR-MPLS）はゲートウェイで終了し、その後SRv6ドメインに再カプセル化されて配送されます。BGPは同じVPNプレフィックスに対してSR-MPLSとSRv6 SIDを同時にシグナリング可能です。

制御プレーンでは、SRv6は通常、IS-ISやOSPFv3とともに動作し、BGP-LSを用いてトポロジ情報をPCEに提供します。PCEは最適なセグメントリストを計算し、必要に応じてPCEPやBGP SR-Policyを通じてSRヘッドエンドに配布します。

セキュリティ上の考慮点

SRv6のセキュリティモデルはMPLSと根本的に異なります。MPLSラベルはローカルに重要であり、ルーティング可能ではありません。一方、SRv6 SIDはグローバルにルーティング可能なIPv6アドレスです。これにより、SIDプレフィックスが適切にフィルタリングされないと、ドメイン外からの攻撃者にドメインのトポロジーが見える可能性があります。RFC 8754のセクション5では、SRH Routing Type 4を持つパケットをドメイン境界でドロップするiACLフィルタリングや、偽装された送信元アドレスを拒否するuRPFの重要性を規定しています。

RFC 9602（2024年10月）は、SRv6 SID用に専用のIPv6プレフィックスを割り当てており、これを使用しない展開では追加の注意が必要です。draft-ietf-spring-srv6-security（2026年初旬現在進行中）では、脅威の分類と対策ガイドラインを詳細に示しています。

---

エコシステムの成熟度と実運用

SRv6は初期導入段階を超え、実運用に広く展開されています。複数の国とユースケースで採用例があります:

通信事業者: SoftBank（日本）は5GネットワークスライシングにSRv6を採用し、特定サービス層向けの隔離された制約付きネットワークパスを作成しています。Bell CanadaはSRv6とuSIDをバックボーンに展開し、Cisco、Nokia、Juniperのハードウェア間のマルチベンダー相互運用性を2023年に公開しました。中国聯通と中国電信も全国的にSRv6を大規模展開しています。

ハイパースケーラー: Microsoftは2025年のOpen Compute Project（OCP）グローバルサミットで、AzureのFairwater DC展開においてSRv6を重要技術として紹介しました。AlibabaとMicrosoftは、SRv6 uSIDの拡張をSONiCネットワークOSに寄与し、SDN制御のファブリックにSRv6を統合しています。Reliance JioはCiscoと協力し、1億世帯と6億のモバイル・エンタープライズ顧客を対象にSRv6を展開中です。

ハードウェアサポート: CiscoのASR 9000/NCS 5500/NCS 540シリーズ（IOS XR）、Nexus（NX-OS）、Huawei NE40E/NE5000E/NE8000（VRP）、Juniper MX/PTXシリーズ、Nokia 7750 SRシリーズ、Arista 7280R3シリーズ、Arrcus ArcOSプラットフォームなどでSRv6の実装が進んでいます。FRRouting（FRR）10.5は、マルチロケータサポートやC-SIDサポートなどの重要なuSID拡張を追加しています。

---

結論

ステートフルミドルウェアからステートレス・パケット駆動のルーティングへの移行は、ネットワークエンジニアリングの根本的な成熟を示しています。分散アーキテクチャの複雑化とローカルからクラウドへのテレメトリ増加に伴い、ネットワークエッジは大規模な中央ステートマシンとして機能できなくなっています。

RFC 8754、8986、9350、9800を通じて標準化されたSRv6は、完全なツールセットを提供します。ステートレスなヘッドエンドカプセル化、制約認識のフォワーディング（Flex-Algo）、uSID圧縮によるヘッダー効率化です。制御プレーンは、IS-ISやOSPFv3とともにBGP-LSを用いたPCEによる経路最適化も可能です。

現実的な制約も存在します。SRv6はIPv6インフラを必要とし、uSID未対応プラットフォームではヘッダーオーバーヘッドが問題となる場合があります。ドメイン境界のセキュリティにはACLやuRPFの適切な設定が求められます。しかし、エコシステムは進展しています。主要ベンダーからラインレート対応のハードウェアが出荷され、ハイパースケーラーもAIトレーニング規模で展開しています。IETFの標準スタックも完成しています。今日、ローカルからクラウドへのトンネルインフラを構築するエンジニアにとって、SRv6は未来の技術ではなく、実運用のアーキテクチャ選択肢となっています。

---

参考マップ

RFC	タイトル	ステータス	発行日
RFC 8402	Segment Routing Architecture	Standards Track	2018年7月
RFC 8754	IPv6 Segment Routing Header (SRH)	Standards Track	2020年3月
RFC 8986	SRv6 Network Programming	Standards Track	2021年2月
RFC 9256	Segment Routing Policy Architecture	Standards Track	2022年7月
RFC 9259	SRv6におけるOAM	Standards Track	2022年6月
RFC 9350	IGP Flexible Algorithm	Standards Track	2023年2月
RFC 9602	IPv6アドレッシングにおけるSRv6 SID	Informational	2024年10月
RFC 9800	圧縮SRv6セグメントリストエンコーディング	Standards Track	2025年6月

---

変更履歴

2026年6月の最新情報に基づく事実確認:

• RFC 8986の日付修正: 記事には日付未記載とあったが、2021年2月（スタンダードトラック、IETF）と確認済み。
• RFC 8754追加: SRH仕様（RFC 8754、2020年3月）が抜けていたため追加。アーキテクチャの基盤です。
• SRHオーバーヘッド式修正: 元記事では「8ホップなら128バイト追加」とあったが、正しくは(n × 16) + 8バイトです。6ホップの場合は136バイトのSRHと40バイトのIPv6外側ヘッダーとなる。Huaweiの設計資料に基づき正確に修正。
• uSIDのRFC番号修正と更新: 元記事では非公式に説明され、RFC 8986に既に標準化済みと誤解されていたが、RFC 9800（2025年6月）として正式公開。RFC番号と圧縮率（最大6 C-SID、32ビットGIB、16ビットC-SID）を明示。トランジットノードには透過的です。
• Flex-AlgoのRFC番号追加: RFC 9350（2023年2月）で標準化。SRv6では*locator*がアルゴリズムにバインドされると規定（セクション2）。
• Linuxカーネルバージョン修正: v4.10はSRv6のカプセル化を導入したが、End.DX4などのエンドポイント動作はv4.14から。正確に修正。
• VPPのサポート確認: fd.ioのドキュメントに基づき、End、End.X、End.DX4、End.DX6、End.DT4、End.DT6、End.DX2、End.B6.Encapsのサポートを明記。
• NVIDIA Omniverseの記述削除: 具体的な製品連携の未検証情報を除去。SRv6の工業用テレメトリ利用の概念は維持。
• 実運用展開例追加: SoftBank、Bell Canada、中国聯通・電信、Microsoft Azure、Alibaba、Reliance Jio、SONiCエコシステムの展開例を追加。
• セキュリティ考慮点追加: SRv6 SIDはグローバルルーティング可能であり、ドメイン境界のフィルタリング（RFC 8754 Sec.5、RFC 9602）やuRPFの重要性を解説。
• RFC 9602追加: 2024年10月発行。SRv6 SID用のIPv6プレフィックス割り当てとセキュリティに関する情報。
• 参考RFC一覧表追加: 全RFCのタイトル、ステータス、発行日を整理。
• フロントマター/メタデータ削除: タイトルタグやメタ情報は除外し、規定の構造に準拠。