5. SR ドメイン内の展開モデル

SID を SR ドメイン内でのみ、かつ SR ドメインのパケットに対してのみ使用することは、重要な展開モデルである。

これにより、SR ドメインは単一のルーティングシステムとして動作できる。

本節では、次を扱う。

外部からの SID 使用の試みに対する SR ドメインの保護
コンポーネント間の委任を伴う単一システムとしての SR ドメインの使用
SR ドメインのパケットの処理

5.1. SR ドメインの保護

SR ドメイン外のノードは信頼されず、ドメインの SID を直接使用できない。これは、2 段階のアクセス制御リストにより強制される。

SR ドメインに流入し、SR ドメイン内の SID 宛てであるすべてのパケットを破棄する。これは次のロジックで実現できる。同等の結果を得る他の方法も適合とみなされる。
- すべての SID をブロック S/s から割り当てる。
- ドメインの各エッジノードの各外部インターフェースに、宛先アドレスが S/s 内の受信パケットを破棄する、流入インフラストラクチャアクセスリスト（IACL）を設定する。
- この流入フィルタリング方式を実装しない場合、[RFC5095] で説明・参照される送信元ルーティング攻撃に SR ドメインがさらされる。
#1 の分散型保護は、SR ドメイン外の送信元アドレスから SID 宛てのパケットを破棄する、ノード単位の保護によって補完される。これは次のロジックで実現できる。同等の結果を得る他の方法も適合とみなされる。
- すべてのインターフェースアドレスをプレフィックス A/a から割り当てる。
- ノード k では、k にローカルなすべての SID をプレフィックス Sk/sk から割り当てる。
- SR ドメイン内の各 SR ノード k の各内部インターフェースに、送信元アドレスが A/a 内にない場合に宛先アドレスが Sk/sk 内の受信パケットを破棄する IACL を設定する。

5.2. コンポーネント間の委任を伴う単一システムとしての SR ドメイン

SR ドメイン内のすべてのパケットは SR ドメインのパケットである。IPv6 ヘッダは SR ドメインのノードが生成し、SR ドメインのノードを宛先とする。

ドメイン間パケットは、パケット経路のうち SR ドメイン内にある部分についてすべてカプセル化される。外側の IPv6 ヘッダは SR ドメインのノードが生成し、SR ドメインのノードを宛先とする。

結果として、SR ドメイン内のすべてのパケットは SR ドメインのパケットである。

SR ドメインは、オペレータが最外層ヘッダのさまざまな操作をシステム内の異なるノードに分配または委任できるシステムである。

SR ドメインのオペレータは、SRH の追加を SR ドメイン内のホストノードに委任し、任意の SRH の内容の検証を、そのホストに接続されたより信頼できるルータまたはスイッチに委任できる。インターフェース I を介してホスト H に接続されたトップオブラックスイッチ T を考える。H は、本書の範囲外の何らかの SDN 方式により、計算済み HMAC を含む SRH（SRH1）を受信する。H は生成するトラフィックを分類し、特定のサービスレベル契約（SLA）を必要とするトラフィックに SRH1 を追加する。T は、SR ドメインの SID ブロック（S/s）宛てのすべてのパケットで SRH の検証を要求する IACL を I に設定する。T は SRH1 が有効であり HMAC TLV を含むことを確認して検証し、その後 HMAC を検証する。

SR ドメインのオペレータは、SR ドメイン内のすべてのセグメントで HMAC を検証することを選択できる。この機構により、SRH Segment List が SR ドメインの通過中に変更されないことを検証できる。

5.3. MTU に関する考慮事項

SR ドメインの流入エッジノードは、SR ドメインを通過するパケットをカプセル化するため、SR ドメインの MTU を考慮する必要がある。SR ドメイン内では、流入エッジより大きい MTU 値を SR ドメイン内に設定するなど、よく知られた緩和技術を使用することが推奨される（RECOMMENDED）。

外側の IPv6 ヘッダおよび SRH によるカプセル化には、[RFC2473] で説明される IPv6 トンネルと同じ MTU およびフラグメンテーション上の考慮事項がある。IPv6 トンネルを含むさまざまなトンネリング方式の制限に関する詳しい検討は [INTAREA-TUNNELS] で議論されており、SR ドメイン内の MTU を検討するオペレータは考慮するべきである（SHOULD）。

5.4. ICMP エラー処理

SR ドメイン内で生成された ICMP エラーパケットは、SR ドメイン内の送信元ノードに送信される。ICMP エラーメッセージ内のトリガーパケットには SRH が含まれる場合がある。SRH を持つパケットの宛先アドレスは各セグメントの処理に伴って変わるため、トリガーパケットを生成したソケットまたはアプリケーションが使用した宛先とは異なる場合がある。

トリガーパケットの送信元が ICMP エラーメッセージを処理するには、IPv6 ヘッダの最終宛先アドレスが必要となる場合がある。プロトコルエラーハンドラが使用する宛先アドレスは、次のロジックで決定する。

トリガーとなった IPv6 パケットのすべての拡張ヘッダを、上位層ヘッダの前にあるルーティング拡張ヘッダまでたどる。
- ルーティングヘッダがタイプ 4 の Segment Routing Header（SRH）である場合
  
  o Segment List[0] の SID を、トリガーパケットの宛先アドレスとして使用してよい。

その後、ICMP エラーは [RFC4443] で定義されるとおり上位層トランスポートにより処理される。

外側の IPv6 ヘッダにカプセル化された IP パケットについて、ICMP エラー処理は [RFC2473] で定義されるとおりである。

5.5. ロードバランシングと ECMP

すべてのドメイン間パケットについて、SR 送信元ノードは内側のパケットに基づいて計算したフローラベルを設定しなければならない（MUST）。フローラベルの計算は、送信 Tunnel End Point に対して [RFC6438] で推奨されるとおりとする。

すべてのドメイン内パケットについて、SR 送信元ノードは、SRH を超えて 5 タプルを計算できない中継ノードにおける ECMP ロードバランシングを支援するため、[RFC6437] で説明されるとおりに計算したフローラベルを設定するべきである（SHOULD）。

SR ドメイン内のすべての中継ノードでは、宛先アドレスに向けた ECMP ハッシュの計算に [RFC6438] で定義されるとおりフローラベルを使用しなければならない（MUST）。フローラベルを使用しない場合、中継ノードは一対の SR エッジノード間のすべてのパケットを同一リンクへハッシュする可能性が高い。

SR セグメントエンドポイントノードでは、処理済みパケットを次のセグメントへ転送するために使用する ECMP ハッシュの計算に、[RFC6438] で定義されるとおりフローラベルを使用しなければならない（MUST）。

5.6. その他の展開

その他の展開モデル、およびセキュリティ、MTU、HMAC、ICMP エラー処理、他の拡張ヘッダとの相互作用に対するその影響は、本書の範囲外である。