SRv6 とは何か – ネットワークの複雑性はどこへ移動するのか

SRv6 は、Segment Routing over IPv6 の略です。IPv6 データプレーン上で Segment Routing を実現し、パケットに「どの経路を通るか」「どの処理を受けるか」という意図を持たせる技術です。

ただし、SRv6 を単に「新しいルーティング技術」と見ると、少し狭くなります。SRv6 を理解するうえで重要なのは、ネットワークの複雑性をどこに置くのか、という視点です。

従来のネットワークでは、経路制御、VPN、トラフィックエンジニアリング、サービスチェイニング、NFV などを実現するために、MPLS、VRF、PBR、トンネル、VLAN、Firewall、DPI、NAT、CGN、Load Balancer、仮想ネットワークなどを組み合わせてきました。

それぞれの技術には役割があり、実際に機能してきました。しかし規模が大きくなり、サービスが複雑になり、制御したい単位が細かくなるほど、ネットワーク全体の意図は見えにくくなります。

どのトラフィックが、どの経路を通り、どの装置で処理され、どの VRF で lookup され、どこで decap され、どこで NAT されているのか。その意図が、複数の装置、複数の設定、複数の制御機構に分散していきます。

SRv6 は、この分散した複雑性を、IPv6 SID と Segment List という形で再配置しようとする技術です。複雑性を消すのではなく、置き場所を変える技術だと見た方が分かりやすいと思います。

通常の IP ルーティングでは何が足りないのか

通常の IP ルーティングは、非常によくできた仕組みです。パケットには宛先 IP アドレスがあり、各ルーターはその宛先を見て次ホップを決めます。この単純さによって、IP ネットワークは大規模に拡張できました。

しかし、通信事業者や大規模ネットワークでは、単に宛先へ届けるだけでは足りない場面があります。

• 特定の顧客トラフィックだけ低遅延経路に通したい
• 帯域に余裕がある経路へ流したい
• 障害時に特定の迂回経路へ即座に逃がしたい
• 特定の拠点や装置を必ず経由させたい
• Firewall、DPI、NAT、CGN、Load Balancer などを順番に通したい
• VPN や VRF ごとに異なる処理をしたい
• モバイル網の User Plane を柔軟に制御したい

宛先 IP アドレスは、「どこへ届けるか」は表せます。しかし、「どこを通るべきか」「どの処理を受けるべきか」「どのサービス文脈で転送されるべきか」までは表現しにくい。

そのため従来は、複数の仕組みを組み合わせて対応してきました。VRF で論理的に経路表を分け、PBR で特定条件のパケットを別経路へ曲げ、MPLS でラベルに基づいた転送を行い、トンネルで経路を隠蔽し、VLAN や仮想ネットワークでサービス経路を構成する、という具合です。

これらは現実的な解であり、現在も使われています。問題は、個々の技術が悪いことではありません。経路、サービス、VPN、処理順序、トラフィック制御が、それぞれ別の場所に記述されることです。

SRv6 は、この散らばった意図を Segment List として表現しようとします。

Segment とは何か

SRv6 の Segment は、単なる経由地点ではありません。パケットに対する「次に実行すべき命令」のようなものとして扱われます。

• 特定のノードへ到達せよ
• 特定のリンクを使え
• 特定の VRF で lookup せよ
• パケットを decap せよ
• 特定のインターフェースへ転送せよ
• Firewall や DPI などのサービス機能を通せ

SRv6 では、この Segment を IPv6 アドレスとして表現します。ここが重要です。SRv6 における IPv6 アドレスは、単なる宛先アドレスではありません。場合によっては、ネットワーク上の機能や処理を表す識別子になります。

この識別子を SID、Segment Identifier と呼びます。パケットは、SID の列である Segment List に従って転送されます。

通常の IP 転送では、パケットは基本的に宛先へ向かいます。SRv6 では、パケットは Segment List に従い、経路や処理を順番に受けます。この点で、SRv6 は単なる経路制御ではなく、ネットワーク上の処理を組み合わせる仕組みに近いものです。

SID は場所と処理を含む

SRv6 を説明するときに、「関数呼び出しに近い」と表現されることがあります。この比喩は直感的には分かりやすいのですが、比喩だけで終わらせると危険です。

なぜ SRv6 が関数呼び出しのように見えるのか。それは、SRv6 SID が単なる場所ではなく、Locator、Function、Arguments を含む構造として設計されるためです。

要素	意味
Locator	どのノード、どの領域、どの場所へ届けるかを表す
Function	その場所に到達したあと、どの処理を実行するかを表す
Arguments	必要に応じて Function に渡す追加情報を表す

つまり、ある SID に到達したノードは、単に「このアドレス宛のパケットを受け取った」と見るだけではありません。「この SID に対応する処理を実行する」と解釈します。

• End: その SID の処理を終えて次の Segment へ進める
• End.X: 特定の隣接先へ転送する
• End.DT4: IPv4 テーブルで lookup する
• End.DT6: IPv6 テーブルで lookup する
• End.DT46: IPv4 / IPv6 両方のテーブルで lookup する
• End.DX4 / End.DX6: 特定の L3 隣接へ decap して転送する

このように、SID は「どこへ行くか」だけでなく、「そこで何をするか」を含みます。ここで初めて、「SRv6 は関数呼び出しに近い」という比喩に意味が出てきます。

もちろん、実際の SRv6 はプログラミング言語そのものではありません。しかし、SID が Locator と Function を含み、Segment List が処理の順序を表すという点で、SRv6 は Network Programming と呼べる構造を持っています。

MPLS-TE や RSVP-TE への不満

SRv6 が登場した背景には、MPLS-TE や RSVP-TE に対する不満もあります。

MPLS-TE は、明示的な経路を作り、トラフィックをその経路に流すことができます。これは強力です。しかし RSVP-TE では、経路上の中間ノードにも LSP の状態を持たせる必要があります。

つまり、入口ルーターだけでなく、中間ルーターも「この LSP は次にどこへ送る」という状態を保持します。小規模であれば問題になりにくいものの、LSP の数が増え、ネットワークが大規模になり、障害や経路変更が頻繁になると、状態管理は重くなります。

• LSP ごとの状態管理
• RSVP によるシグナリング
• 経路変更時の再計算
• 障害時の再収束
• 中間ノードの状態確認
• 運用上の見通しの悪さ

Segment Routing は、この問題に対して別の設計を取ります。経路全体の意図を中間ノードへ個別状態として持たせるのではなく、入口ノードが Segment List を付与します。中間ノードは、自分に対応する Segment を処理し、次の Segment へ進めます。

この考え方により、パスごとの状態をネットワーク全体にばら撒く必要を減らします。ここに、Segment Routing の大きな狙いがあります。SRv6 は、その Segment Routing を IPv6 データプレーンで実現する方式です。

SRv6 は IPv6 版 MPLS なのか

SRv6 は、MPLS の代替として語られることがあります。確かに、MPLS で実現していた VPN や Traffic Engineering に近いことを SRv6 で実現できます。その意味では、SRv6 は MPLS の後継的な文脈で語られることもあります。

しかし、SRv6 を単に「IPv6 版 MPLS」と見ると、本質を見落とします。MPLS では Label によって転送動作を表現します。SRv6 では、IPv6 SID によって経路や機能を表現します。

SR-MPLS では、Segment は MPLS Label として表現されます。SRv6 では、Segment は IPv6 アドレスとして表現されます。この違いは大きいです。

そのため SRv6 は、IPv6 ネットワーク上で、経路制御だけでなく、サービス処理や VPN 文脈まで含めて表現しやすい。一方で、MPLS を使わないから簡単になる、という話でもありません。

MPLS の複雑性が消える代わりに、SRv6 SID 設計、SRH 処理、Policy 設計、装置対応、可視化の問題が出てきます。つまり、MPLS の複雑性から自由になるというより、別の抽象化へ移ると考えた方がよいと思います。

サービスチェイニングとの関係

SRv6 が分かりやすく効く領域の一つが、サービスチェイニングです。

例えば、ある通信を User traffic、Firewall、DPI、NAT、Internet の順番で通したいとします。

従来のネットワークでは、このような経路を実現するために、VLAN、VRF、PBR、トンネル、仮想スイッチ、NFV 基盤側のネットワーク設定などを組み合わせることが多いです。実現はできます。しかし、構成は複雑になりやすい。

どの装置で経路を曲げているのか、どの VRF で lookup されているのか、どの仮想ネットワークを通っているのか、どこで NAT されているのか、どこで decap されているのか。処理の流れが、ネットワーク内のあちこちに分散してしまいます。

SRv6 では、こうした処理の流れを Segment List として表現できます。Firewall Function、DPI Function、NAT Function、Internet 向け Egress を Segment として並べる、という見方です。

これは、NFV やサービスチェイニングとの相性がよい考え方です。通信事業者のネットワークでは、Firewall、DPI、CGN、UPF、Load Balancer など、パケットが通過すべき機能が多くあります。それらを個別のネットワーク構成で無理につなぐのではなく、Segment として表現するところに SRv6 の強みがあります。

ただし、これも「簡単になる」という意味ではありません。サービスチェインの意図を Segment List として表現できるようになる一方で、その SID を誰が設計し、誰が配布し、誰が Policy として適用し、誰が障害時に追跡するのかという問題は残ります。

課題はどこに移るのか

SRv6 の価値は、ネットワーク制御の意図を Segment List として表現できる点にあります。しかし、そのためには新しい設計領域が発生します。

課題	見るべき点
SID 設計	Locator をどの単位で割り当てるか、Function をどの範囲で定義するか、サービスやノードごとの整理をどう行うか
Headend Policy	どの条件のトラフィックを、どの SR Policy へ steer するか
装置実装	SRH 処理、SID lookup、End behavior、decap、VRF 連携を ASIC で処理できるか
ヘッダーオーバーヘッド	SID 数が増えたときの SRH サイズ、MTU、uSID や圧縮 SID の必要性
可視化と障害解析	どの Segment List が付与され、どの SID が処理され、どこで decap されたかを追えるか

IPv6 に対応していることと、SRv6 を高性能に処理できることは同じではありません。どの End behavior に対応しているのか、どの程度の SID depth まで性能が出るのか、uSID や圧縮 SID に対応するのか、といった確認が必要です。

また、SRv6 の SID は IPv6 アドレスです。IPv6 アドレスは 128 bit、つまり 16 byte です。Segment が増えるほど、SRH に含まれる SID も増えます。サービスチェインが長くなるほど、ヘッダーサイズや MTU への影響を考える必要があります。

さらに、SRv6 では単にルーティングテーブルを見るだけでは不十分になります。どの SR Policy が適用されたのか、どの Segment List が付与されたのか、どの SID が処理されたのか、どの End behavior で想定外の動作をしたのか、どこで decap されたのか、どの VRF で lookup されたのか。これらを追える仕組みが必要です。

つまり、SRv6 の導入では、転送面だけではなく、設計、制御、監視、障害解析まで含めた運用モデルが必要になります。

まとめ

SRv6 は、IPv6 上で Segment Routing を実現する技術です。しかし、それだけでは本質は見えにくい。

SRv6 を評価するときに見るべき点は、「新しいか」「MPLS を置き換えるか」だけではありません。より重要なのは、SRv6 によって移動した複雑性を、自分たちの設計力や運用体制で扱えるかどうかです。

SRv6 では、ネットワークの制御意図を IPv6 SID として表現し、その SID の列である Segment List によって、経路や処理順序を制御します。通常の IP ルーティングでは、パケットは基本的に宛先へ向かいます。SRv6 では、パケットは Segment List に従い、必要な経路や処理を順番に受けます。

この仕組みによって、VPN、Traffic Engineering、サービスチェイニング、NFV などを、より統一的に扱える可能性があります。ただし、SRv6 は「導入すればネットワークが簡単になる技術」ではありません。

むしろ、ネットワーク制御の抽象度を上げることで、SID 設計、Headend Policy、SRH 処理、装置実装、可視化、運用設計といった領域に、設計責任を明示的に集める技術です。

正しく設計できれば、SRv6 は強力です。しかし、SID 設計や Policy 設計を曖昧にしたまま導入すると、従来よりも見えにくいネットワークになる可能性もあります。

その意味で、SRv6 を検討するときに最初に見るべきものは、対応機能の一覧だけではありません。自分たちが、その複雑性をどこで引き受け、どのように設計し、どのように観測し、どのように運用するのか。そこまで含めて考えなければ、SRv6 は単なる新しい転送技術ではなく、新しい見えにくさを持ち込むだけになります。