[要約] RFC 8754はIPv6セグメントルーティングヘッダ（SRH）に関する仕様であり、SRHの目的はパケットの経路制御とネットワークの柔軟性を向上させることです。SRHはパケットの経路情報をヘッダに含めることで、ネットワーク内での経路選択をより効率的に行うことができます。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8754 D. Dukes, Ed.
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 S. Previdi
Huawei
J. Leddy
Individual
S. Matsushima
SoftBank
D. Voyer
Bell Canada
March 2020
IPv6 Segment Routing Header (SRH)
IPv6セグメントルーティングヘッダー（SRH）
Abstract
概要
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.
セグメントルーティングは、セグメントルーティングヘッダー（SRH）と呼ばれる新しいタイプのルーティング拡張ヘッダーを使用してIPv6データプレーンに適用できます。このドキュメントでは、SRHと、セグメントルーティング（SR）対応のノードでSRHがどのように使用されるかについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8754.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8754で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. Segment Routing Header
2.1. SRH TLVs
2.1.1. Padding TLVs
2.1.2. HMAC TLV
3. SR Nodes
3.1. SR Source Node
3.2. Transit Node
3.3. SR Segment Endpoint Node
4. Packet Processing
4.1. SR Source Node
4.1.1. Reduced SRH
4.2. Transit Node
4.3. SR Segment Endpoint Node
4.3.1. FIB Entry Is a Locally Instantiated SRv6 SID
4.3.2. FIB Entry Is a Local Interface
4.3.3. FIB Entry Is a Nonlocal Route
4.3.4. FIB Entry Is a No Match
5. Intra-SR-Domain Deployment Model
5.1. Securing the SR Domain
5.2. SR Domain as a Single System with Delegation among
Components
5.3. MTU Considerations
5.4. ICMP Error Processing
5.5. Load Balancing and ECMP
5.6. Other Deployments
6. Illustrations
6.1. Abstract Representation of an SRH
6.2. Example Topology
6.3. SR Source Node
6.3.1. Intra-SR-Domain Packet
6.3.2. Inter-SR-Domain Packet -- Transit
6.3.3. Inter-SR-Domain Packet -- Internal to External
6.4. Transit Node
6.5. SR Segment Endpoint Node
6.6. Delegation of Function with HMAC Verification
6.6.1. SID List Verification
7. Security Considerations
7.1. SR Attacks
7.2. Service Theft
7.3. Topology Disclosure
7.4. ICMP Generation
7.5. Applicability of AH
8. IANA Considerations
8.1. Segment Routing Header Flags Registry
8.2. Segment Routing Header TLVs Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Segment Routing (SR) can be applied to the IPv6 data plane using a new type of routing header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are SR capable.
セグメントルーティング（SR）は、セグメントルーティングヘッダー（SRH）と呼ばれる新しいタイプのルーティングヘッダーを使用してIPv6データプレーンに適用できます。このドキュメントでは、SRHと、SR対応のノードでSRHがどのように使用されるかについて説明します。
"Segment Routing Architecture" [RFC8402] describes Segment Routing and its instantiation in two data planes: MPLS and IPv6.
「セグメントルーティングアーキテクチャ」[RFC8402]は、MPLSとIPv6の2つのデータプレーンでのセグメントルーティングとそのインスタンス化について説明しています。
The encoding of IPv6 segments in the SRH is defined in this document.
SRHでのIPv6セグメントのエンコーディングは、このドキュメントで定義されています。
This document uses the terms Segment Routing (SR), SR domain, SR over IPv6 (SRv6), Segment Identifier (SID), SRv6 SID, Active Segment, and SR Policy as defined in [RFC8402].
このドキュメントでは、[RFC8402]で定義されているように、セグメントルーティング（SR）、SRドメイン、IPv6上のSR（SRv6）、セグメント識別子（SID）、SRv6 SID、アクティブセグメント、およびSRポリシーという用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Routing headers are defined in [RFC8200]. The Segment Routing Header (SRH) has a new Routing Type (4).
ルーティングヘッダーは[RFC8200]で定義されています。セグメントルーティングヘッダー（SRH）に新しいルーティングタイプ（4）が追加されました。
The SRH is defined as follows:
SRHは次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Next Header: Defined in [RFC8200], Section 4.4.
次のヘッダー：[RFC8200]のセクション4.4で定義。
Hdr Ext Len: Defined in [RFC8200], Section 4.4.
Hdr Ext Len：[RFC8200]のセクション4.4で定義。
Routing Type: 4.
ルーティングタイプ：4。
Segments Left: Defined in [RFC8200], Section 4.4.
残りのセグメント：[RFC8200]、セクション4.4で定義。
Last Entry: contains the index (zero based), in the Segment List, of the last element of the Segment List.
最後のエントリ：セグメントリストの最後の要素の、セグメントリスト内のインデックス（ゼロベース）が含まれます。
Flags: 8 bits of flags. Section 8.1 creates an IANA registry for new flags to be defined. The following flags are defined:
フラグ：8ビットのフラグ。セクション8.1では、新しいフラグを定義するためのIANAレジストリを作成します。次のフラグが定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+
U: Unused and for future use. MUST be 0 on transmission and ignored on receipt.
U：未使用で、将来使用するため。送信時には0で、受信時には無視されなければなりません。
Tag: Tag a packet as part of a class or group of packets -- e.g., packets sharing the same set of properties. When Tag is not used at the source, it MUST be set to zero on transmission. When Tag is not used during SRH processing, it SHOULD be ignored. Tag is not used when processing the SID defined in Section 4.3.1. It may be used when processing other SIDs that are not defined in this document. The allocation and use of tag is outside the scope of this document.
タグ：クラスまたはパケットグループの一部としてパケットにタグを付けます-たとえば、同じプロパティセットを共有するパケット。ソースでタグが使用されていない場合、送信時にタグをゼロに設定する必要があります。 SRH処理中にタグが使用されない場合、それは無視されるべきです（SHOULD）。セクション4.3.1で定義されたSIDを処理する場合、タグは使用されません。このドキュメントで定義されていない他のSIDを処理するときに使用できます。タグの割り当てと使用は、このドキュメントの範囲外です。
Segment List[0..n]: 128-bit IPv6 addresses representing the nth segment in the Segment List. The Segment List is encoded starting from the last segment of the SR Policy. That is, the first element of the Segment List (Segment List[0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy, and so on.
セグメントリスト[0..n]：セグメントリストのn番目のセグメントを表す128ビットのIPv6アドレス。セグメントリストは、SRポリシーの最後のセグメントからエンコードされます。つまり、セグメントリストの最初の要素（セグメントリスト[0]）にはSRポリシーの最後のセグメントが含まれ、2番目の要素にはSRポリシーの最後から2番目のセグメントが含まれます。
TLV: Type Length Value (TLV) is described in Section 2.1.
TLV：Type Length Value（TLV）については、セクション2.1で説明します。
In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments Left fields are defined in Section 4.4 of [RFC8200]. Based on the constraints in that section, Next Header, Header Ext Len, and Routing Type are not mutable while Segments Left is mutable.
SRHでは、[Next Header]、[Hdr Ext Len]、[Routing Type]、および[Segments Left]フィールドは、[RFC8200]のセクション4.4で定義されています。そのセクションの制約に基づくと、Next Header、Header Ext Len、Routing Typeは変更できませんが、Segment Leftは変更可能です。
The mutability of the TLV value is defined by the most significant bit in the type, as specified in Section 2.1.
セクション2.1で指定されているように、TLV値の可変性は、タイプの最上位ビットによって定義されます。
Section 4.3 defines the mutability of the remaining fields in the SRH (Flags, Tag, Segment List) in the context of the SID defined in this document.
セクション4.3では、このドキュメントで定義されているSIDのコンテキストで、SRHの残りのフィールド（フラグ、タグ、セグメントリスト）の可変性を定義しています。
New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how the Hashed Message Authentication Code (HMAC) TLV (Section 2.1.2) verification works. Note that, in effect, these fields are mutable.
将来的に定義される新しいSIDは、フラグ、タグ、およびセグメントリストの可変性プロパティを指定し、ハッシュメッセージ認証コード（HMAC）TLV（セクション2.1.2）検証がどのように機能するかを示さなければなりません（MUST）。実際には、これらのフィールドは変更可能であることに注意してください。
Consistent with the SR model, the source of the SRH always knows how to set the Segment List, Flags, Tag, and TLVs of the SRH for use within the SR domain. How it achieves this is outside the scope of this document but may be based on topology, available SIDs and their mutability properties, the SRH mutability requirements of the destination, or any other information.
SRモデルと一致して、SRHのソースは、SRドメイン内で使用するためにSRHのセグメントリスト、フラグ、タグ、およびTLVを設定する方法を常に知っています。これを実現する方法はこのドキュメントの範囲外ですが、トポロジ、使用可能なSIDとその可変性プロパティ、宛先のSRH可変性要件、またはその他の情報に基づく場合があります。
This section defines TLVs of the Segment Routing Header.
このセクションでは、セグメントルーティングヘッダーのTLVを定義します。
A TLV provides metadata for segment processing. The only TLVs defined in this document are the HMAC (Section 2.1.2) and padding TLVs (Section 2.1.1). While processing the SID defined in Section 4.3.1, all TLVs are ignored unless local configuration indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support is optional for any implementation; however, an implementation adding or parsing TLVs MUST support PAD TLVs. Other documents may define additional TLVs and processing rules for them.
TLVは、セグメント処理のメタデータを提供します。このドキュメントで定義されている唯一のTLVは、HMAC（セクション2.1.2）とパディングTLV（セクション2.1.1）です。セクション4.3.1で定義されたSIDを処理している間、ローカル構成で別の指示がない限り（セクション4.3.1.1.1）、すべてのTLVは無視されます。したがって、TLVとHMACのサポートは、どの実装でもオプションです。ただし、TLVを追加または解析する実装は、PAD TLVをサポートする必要があります。その他のドキュメントでは、追加のTLVとそれらの処理ルールを定義している場合があります。
TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2.
Hdr Ext Lenが（Last Entry + 1）* 2より大きい場合、TLVが存在します。
While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len. Detection of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field of the SRH, and the packet being discarded.
セグメントエンドポイントでTLVを処理している間、TLVはHdr Ext Lenによって決定されたSRH内に完全に含まれている必要があります。 SRH Hdr Ext Lenの境界を超えるTLVが検出されると、ICMPパラメータ問題、コード0、ソースアドレスへのメッセージ、SRHのHdr Ext Lenフィールドを指し、パケットが破棄されます。
An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY limit:
実装は、ローカル構成に基づいて処理するTLVの数または長さ、あるいはその両方を制限する場合があります。それは制限するかもしれません：
* the number of consecutive Pad1 (Section 2.1.1.1) options to 1. If padding of more than one byte is required, then PadN (Section 2.1.1.2) should be used.
* 連続するPad1（セクション2.1.1.1）オプションの数を1に。1バイトを超えるパディングが必要な場合は、PadN（セクション2.1.1.2）を使用する必要があります。
* The length in PadN to 5.
* PadNの長さを5に。
* The maximum number of non-Pad TLVs to be processed.
* 処理される非パッドTLVの最大数。
* The maximum length of all TLVs to be processed.
* 処理されるすべてのTLVの最大長。
The implementation MAY stop processing additional TLVs in the SRH when these configured limits are exceeded.
これらの構成された制限を超えると、実装はSRHの追加のTLVの処理を停止する場合があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable-length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type: An 8-bit codepoint from the "Segment Routing Header TLVs" [IANA-SRHTLV]. Unrecognized Types MUST be ignored on receipt.
タイプ：「セグメントルーティングヘッダーTLV」[IANA-SRHTLV]からの8ビットコードポイント。認識されないタイプは、受信時に無視する必要があります。
Length: The length of the variable-length data field in bytes.
長さ：バイト単位の可変長データフィールドの長さ。
Variable-length data: data that is specific to the Type.
可変長データ：タイプに固有のデータ。
Type Length Value (TLV) entries contain OPTIONAL information that may be used by the node identified in the Destination Address (DA) of the packet.
タイプ長さ値（TLV）エントリには、パケットの宛先アドレス（DA）で識別されたノードが使用できるオプションの情報が含まれています。
Each TLV has its own length, format, and semantic. The codepoint allocated (by IANA) to each TLV Type defines both the format and the semantic of the information carried in the TLV. Multiple TLVs may be encoded in the same SRH.
各TLVには、独自の長さ、形式、およびセマンティックがあります。各TLVタイプに（IANAによって）割り当てられたコードポイントは、TLVで伝送される情報の形式と意味の両方を定義します。複数のTLVが同じSRHでエンコードされる場合があります。
The highest-order bit of the TLV type (bit 0) specifies whether or not the TLV data of that type can change en route to the packet's final destination:
TLVタイプの最上位ビット（ビット0）は、そのタイプのTLVデータがパケットの最終宛先への途中で変更できるかどうかを指定します。
0: TLV data does not change en route
0：TLVデータは途中で変更されません
1: TLV data does change en route
1：TLVデータは途中で変更されます
All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per [RFC8200]. The SR source nodes use the xn+y alignment requirements of TLVs and Padding TLVs when constructing an SRH.
すべてのTLVは、xn + y形式を使用してアライメント要件を指定します。 xn + y形式は[RFC8200]で定義されています。 SRソースノードは、SRHを構築するときに、TLVおよびパディングTLVのxn + yアライメント要件を使用します。
The Length field of the TLV is used to skip the TLV while inspecting the SRH in case the node doesn't support or recognize the Type. The Length defines the TLV length in octets, not including the Type and Length fields.
TLVの長さフィールドは、ノードがタイプをサポートまたは認識しない場合に、SRHの検査中にTLVをスキップするために使用されます。長さはTLVの長さをオクテットで定義します。タイプおよび長さフィールドは含まれません。
The following TLVs are defined in this document:
このドキュメントでは、次のTLVが定義されています。
Padding TLVs
TLVのパディング
HMAC TLV
HMAC TLV
Additional TLVs may be defined in the future.
今後、追加のTLVが定義される可能性があります。
There are two types of Padding TLVs, Pad1 and PadN, and the following applies to both:
パディングTLVには2つのタイプ、Pad1とPadNがあり、次の両方に適用されます。
Padding TLVs are used for meeting the alignment requirement of the subsequent TLVs.
パディングTLVは、後続のTLVのアライメント要件を満たすために使用されます。
Padding TLVs are used to pad the SRH to a multiple of 8 octets.
TLVのパディングは、SRHを8オクテットの倍数にパディングするために使用されます。
Padding TLVs are ignored by a node processing the SRH TLV.
TRHのパディングは、SRH TLVを処理するノードによって無視されます。
Multiple Padding TLVs MAY be used in one SRH.
1つのSRHで複数のパディングTLVを使用できます。
Alignment requirement: none
アライメント要件：なし
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
Type: 0
タイプ：0
A single Pad1 TLV MUST be used when a single byte of padding is required. A Pad1 TLV MUST NOT be used if more than one consecutive byte of padding is required.
1バイトのパディングが必要な場合は、1つのPad1 TLVを使用する必要があります。複数の連続するパディングバイトが必要な場合は、Pad1 TLVを使用してはなりません。
Alignment requirement: none
アライメント要件：なし
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Padding (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Padding (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4
タイプ：4
Length: 0 to 5. The length of the Padding field in bytes.
長さ：0から5。パディングフィールドの長さ（バイト単位）。
Padding: Padding bits have no semantic. They MUST be set to 0 on transmission and ignored on receipt.
パディング：パディングビットには意味がありません。送信時には0に設定し、受信時には無視する必要があります。
The PadN TLV MUST be used when more than one byte of padding is required.
1バイトを超えるパディングが必要な場合は、PadN TLVを使用する必要があります。
Alignment requirement: 8n
アライメント要件：8n
The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL and has the following format:
キー付きハッシュメッセージ認証コード（HMAC）TLVはオプションであり、次の形式になります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| //
| HMAC (variable) //
| //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 5.
タイプ：5。
Length: The length of the variable-length data in bytes.
長さ：バイト単位の可変長データの長さ。
D: 1 bit. 1 indicates that the Destination Address verification is disabled due to use of a reduced Segment List (see Section 4.1.1).
D：1ビット。 1は、削減されたセグメントリストを使用しているため、宛先アドレスの検証が無効であることを示します（セクション4.1.1を参照）。
RESERVED: 15 bits. MUST be 0 on transmission.
予約済み：15ビット。送信時には0でなければなりません。
HMAC Key ID: A 4-octet opaque number that uniquely identifies the pre-shared key and algorithm used to generate the HMAC.
HMACキーID：HMACの生成に使用される事前共有キーとアルゴリズムを一意に識別する4オクテットの不透明な番号。
HMAC: Keyed HMAC, in multiples of 8 octets, at most 32 octets.
HMAC：8オクテットの倍数、最大32オクテットのキー付きHMAC。
The HMAC TLV is used to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation. This also allows for verification that the current segment (by virtue of being in the authorized Segment List) is authorized for use. The SR domain ensures that the source node is permitted to use the source address in the packet via ingress filtering mechanisms as defined in BCP 84 [RFC3704] or other strategies as appropriate.
HMAC TLVは、パケットに適用されたSRHが許可された当事者によって選択されたことを確認し、セグメントリストが生成後に変更されないようにするために使用されます。これにより、現在のセグメント（許可されたセグメントリストに含まれているため）の使用が許可されていることを確認することもできます。 SRドメインは、BCP 84 [RFC3704]で定義されている入力フィルタリングメカニズムまたは必要に応じて他の戦略を使用して、送信元ノードがパケット内の送信元アドレスを使用できるようにします。
Local configuration determines when to check for an HMAC. This local configuration is outside the scope of this document. It may be based on the active segment at an SR Segment endpoint node, the result of an Access Control List (ACL) that considers incoming interface, HMAC Key ID, or other packet fields.
ローカル構成は、HMACをチェックするタイミングを決定します。このローカル構成は、このドキュメントの範囲外です。これは、SRセグメントエンドポイントノードのアクティブセグメント、着信インターフェイス、HMACキーID、またはその他のパケットフィールドを考慮したアクセス制御リスト（ACL）の結果に基づく場合があります。
An implementation that supports the generation and verification of the HMAC supports the following default behavior, as defined in the remainder of this section.
HMACの生成と検証をサポートする実装は、このセクションの残りの部分で定義されているように、次のデフォルトの動作をサポートします。
The HMAC verification begins by checking that the current segment is equal to the destination address of the IPv6 header. The check is successful when either:
HMAC検証は、現在のセグメントがIPv6ヘッダーの宛先アドレスと等しいことを確認することから始まります。次のいずれかの場合、チェックは成功です。
* HMAC D bit is 1 and Segments Left is greater than Last Entry, or
* HMAC Dビットが1で、残りのセグメントが最後のエントリより大きい、または
* HMAC Segments Left is less than or equal to Last Entry, and the destination address is equal to Segment List[Segments Left].
* 残りのHMACセグメントが最後のエントリ以下であり、宛先アドレスがセグメントリスト[セグメント残り]と等しい。
The HMAC field is the output of the HMAC computation as defined in [RFC2104], using:
HMACフィールドは、以下を使用して、[RFC2104]で定義されているHMAC計算の出力です。
* key: The pre-shared key identified by HMAC Key ID
* key：HMACキーIDで識別される事前共有キー
* HMAC algorithm: Identified by the HMAC Key ID
* HMACアルゴリズム：HMACキーIDで識別
* Text: A concatenation of the following fields from the IPv6 header and the SRH, as it would be received at the node verifying the HMAC:
* テキスト：IPv6ヘッダーとSRHからの次のフィールドの連結。これは、HMACを検証するノードで受信されるためです。
- IPv6 header: Source address (16 octets)
- IPv6ヘッダー：送信元アドレス（16オクテット）
- SRH: Last Entry (1 octet)
- SRH：最後のエントリー（1オクテット）
- SRH: Flags (1 octet)
- SRH：フラグ（1オクテット）
- SRH: HMAC 16 bits following Length
- SRH：HMAC 16ビット、長さ
- SRH: HMAC Key ID (4 octets)
- SRH：HMACキーID（4オクテット）
- SRH: All addresses in the Segment List (variable octets)
- SRH：セグメントリスト内のすべてのアドレス（可変オクテット）
The HMAC digest is truncated to 32 octets and placed in the HMAC field of the HMAC TLV.
HMACダイジェストは32オクテットに切り捨てられ、HMAC TLVのHMACフィールドに配置されます。
For HMAC algorithms producing digests less than 32 octets long, the digest is placed in the lowest-order octets of the HMAC field. Subsequent octets MUST be set to zero such that the HMAC length is a multiple of 8 octets.
32オクテット未満のダイジェストを生成するHMACアルゴリズムの場合、ダイジェストはHMACフィールドの最低次オクテットに配置されます。 HMACの長さが8オクテットの倍数になるように、後続のオクテットをゼロに設定する必要があります。
If HMAC verification is successful, processing proceeds as normal.
HMAC検証が成功した場合、処理は通常どおり続行されます。
If HMAC verification fails, an ICMP error message (parameter problem, error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate limited) and logged, and the packet SHOULD be discarded.
HMAC検証が失敗した場合、ICMPエラーメッセージ（パラメータの問題、エラーコード0、HMAC TLVをポイント）が生成され（レートが制限されます）、ログに記録され、パケットは破棄されるべきです（SHOULD）。
The HMAC Key ID field allows for the simultaneous existence of several hash algorithms (SHA-256, SHA3-256 ... or future ones) as well as pre-shared keys.
HMACキーIDフィールドでは、複数のハッシュアルゴリズム（SHA-256、SHA3-256 ...、または将来のアルゴリズム）と事前共有キーを同時に存在させることができます。
The HMAC Key ID field is opaque -- i.e., it has neither syntax nor semantic except as an identifier of the right combination of pre-shared key and hash algorithm.
HMACキーIDフィールドは不透明です。つまり、事前共有キーとハッシュアルゴリズムの正しい組み合わせの識別子として以外は、構文もセマンティックもありません。
At the HMAC TLV generating and verification nodes, the Key ID uniquely identifies the pre-shared key and HMAC algorithm.
HMAC TLV生成ノードと検証ノードでは、キーIDが事前共有キーとHMACアルゴリズムを一意に識別します。
At the HMAC TLV generating node, the Text for the HMAC computation is set to the IPv6 header fields and SRH fields as they would appear at the verification node(s), not necessarily the same as the source node sending a packet with the HMAC TLV.
HMAC TLV生成ノードでは、HMAC計算のテキストは、検証ノードに表示されるIPv6ヘッダーフィールドとSRHフィールドに設定されます。必ずしも、HMAC TLVでパケットを送信する送信元ノードと同じではありません。 。
Pre-Shared key rollover is supported by having two key IDs in use while the HMAC TLV generating node and verifying node converge to a new key.
事前共有キーのロールオーバーは、HMAC TLV生成ノードと検証ノードが新しいキーに収束する間に2つのキーIDを使用することでサポートされます。
The HMAC TLV generating node may need to revoke an SRH for which it previously generated an HMAC. Revocation is achieved by allocating a new key and key ID, then rolling over the key ID associated with the SRH to be revoked. The HMAC TLV verifying node drops packets with the revoked SRH.
HMAC TLV生成ノードは、以前にHMACを生成したSRHを取り消す必要がある場合があります。失効は、新しいキーとキーIDを割り当て、失効するSRHに関連付けられたキーIDをロールオーバーすることで実現されます。 HMAC TLV検証ノードは、取り消されたSRHでパケットをドロップします。
An implementation supporting HMAC can support multiple hash functions. An implementation supporting HMAC MUST implement SHA-2 [FIPS180-4] in its SHA-256 variant.
HMACをサポートする実装は、複数のハッシュ関数をサポートできます。 HMACをサポートする実装は、SHA-256バリアントでSHA-2 [FIPS180-4]を実装する必要があります。
The selection of pre-shared key and algorithm and their distribution is outside the scope of this document. Some options may include:
事前共有キーとアルゴリズムの選択およびそれらの配布は、このドキュメントの範囲外です。一部のオプションには次のものがあります。
* setting these items in the configuration of the HMAC generating or verifying nodes, either by static configuration or any SDN-oriented approach
* 静的構成またはSDN指向のアプローチのいずれかによって、HMAC生成ノードまたは検証ノードの構成でこれらの項目を設定する
* dynamically using a trusted key distribution protocol such as [RFC6407]
* [RFC6407]などの信頼できる鍵配布プロトコルを動的に使用
While key management is outside the scope of this document, the recommendations of BCP 107 [RFC4107] should be considered when choosing the key management system.
鍵管理はこのドキュメントの範囲外ですが、鍵管理システムを選択するときは、BCP 107 [RFC4107]の推奨事項を考慮する必要があります。
There are different types of nodes that may be involved in segment routing networks: SR source nodes that originate packets with a segment in the destination address of the IPv6 header, transit nodes that forward packets destined to a remote segment, and SR segment endpoint nodes that process a local segment in the destination address of an IPv6 header.
セグメントルーティングネットワークに関与する可能性のあるノードにはさまざまな種類があります。IPv6ヘッダーの宛先アドレスにセグメントを持つパケットを発信するSR送信元ノード、リモートセグメント宛てのパケットを転送する中継ノード、およびIPv6ヘッダーの宛先アドレスのローカルセグメントを処理します。
A SR source node is any node that originates an IPv6 packet with a segment (i.e., SRv6 SID) in the destination address of the IPv6 header. The packet leaving the SR source node may or may not contain an SRH. This includes either:
SRソースノードは、IPv6ヘッダーの宛先アドレスにセグメント（つまり、SRv6 SID）を持つIPv6パケットを発信するノードです。 SRソースノードを出るパケットには、SRHが含まれる場合と含まれない場合があります。これには次のいずれかが含まれます。
* A host originating an IPv6 packet, or
* IPv6パケットを発信するホスト、または
* An SR domain ingress router encapsulating a received packet in an outer IPv6 header, followed by an optional SRH.
* 受信したパケットを外部IPv6ヘッダーでカプセル化するSRドメイン入力ルーターの後に、オプションのSRHが続きます。
It is out of the scope of this document to describe the mechanism through which a segment in the destination address of the IPv6 header and the Segment List in the SRH are derived.
IPv6ヘッダーの宛先アドレスのセグメントとSRHのセグメントリストが生成されるメカニズムを説明することは、このドキュメントの範囲外です。
A transit node is any node forwarding an IPv6 packet where the destination address of that packet is not locally configured as a segment or a local interface. A transit node is not required to be capable of processing a segment or SRH.
トランジットノードは、IPv6パケットを転送するノードであり、そのパケットの宛先アドレスは、ローカルでセグメントまたはローカルインターフェイスとして構成されていません。中継ノードは、セグメントまたはSRHを処理できる必要はありません。
An SR segment endpoint node is any node receiving an IPv6 packet where the destination address of that packet is locally configured as a segment or local interface.
SRセグメントエンドポイントノードは、IPv6パケットを受信するノードであり、そのパケットの宛先アドレスがセグメントまたはローカルインターフェイスとしてローカルに構成されています。
This section describes SRv6 packet processing at the SR source, Transit, and SR segment endpoint nodes.
このセクションでは、SRソース、トランジット、およびSRセグメントエンドポイントノードでのSRv6パケット処理について説明します。
A source node steers a packet into an SR Policy. If the SR Policy results in a Segment List containing a single segment, and there is no need to add information to the SRH flag or add TLV; the DA is set to the single Segment List entry, and the SRH MAY be omitted.
ソースノードはパケットをSRポリシーに誘導します。 SRポリシーの結果、セグメントリストが1つのセグメントを含み、SRHフラグに情報を追加したり、TLVを追加したりする必要がない場合。 DAは単一のセグメントリストエントリに設定され、SRHは省略できます。
When needed, the SRH is created as follows:
必要に応じて、SRHは次のように作成されます。
The Next Header and Hdr Ext Len fields are set as specified in [RFC8200].
Next HeaderおよびHdr Ext Lenフィールドは、[RFC8200]で指定されているとおりに設定されます。
The Routing Type field is set to 4.
[ルーティングタイプ]フィールドは4に設定されています。
The DA of the packet is set with the value of the first segment.
パケットのDAには、最初のセグメントの値が設定されます。
The first element of the SRH Segment List is the ultimate segment. The second element is the penultimate segment, and so on.
SRHセグメントリストの最初の要素は、最終的なセグメントです。 2番目の要素は最後から2番目のセグメントです。
The Segments Left field is set to n-1, where n is the number of elements in the SR Policy.
左のセグメントフィールドはn-1に設定されています。nはSRポリシーの要素の数です。
The Last Entry field is set to n-1, where n is the number of elements in the SR Policy.
[Last Entry]フィールドはn-1に設定されます。nはSRポリシーの要素の数です。
TLVs (including HMAC) may be set according to their specification.
TLV（HMACを含む）は、それらの仕様に従って設定できます。
The packet is forwarded toward the packet's Destination Address (the first segment).
パケットは、パケットの宛先アドレス（最初のセグメント）に転送されます。
When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used.
ソースでSIDリスト全体をSRHに保存する必要がない場合は、削減されたSRHを使用できます。
A reduced SRH does not contain the first segment of the related SR Policy (the first segment is the one already in the DA of the IPv6 header), and the Last Entry field is set to n-2, where n is the number of elements in the SR Policy.
削減されたSRHには、関連するSRポリシーの最初のセグメントが含まれていません（最初のセグメントはIPv6ヘッダーのDAにすでにあるものです）。最後のエントリフィールドはn-2に設定されます（nは要素の数） SRポリシーで。
As specified in [RFC8200], the only node allowed to inspect the Routing Extension Header (and therefore the SRH) is the node corresponding to the DA of the packet. Any other transit node MUST NOT inspect the underneath routing header and MUST forward the packet toward the DA according to its IPv6 routing table.
[RFC8200]で指定されているように、ルーティング拡張ヘッダー（したがってSRH）を検査できる唯一のノードは、パケットのDAに対応するノードです。その他の中継ノードは、ルーティングヘッダーの下を検査してはならず（MUST NOT）、IPv6ルーティングテーブルに従ってパケットをDAに転送する必要があります。
When a SID is in the destination address of an IPv6 header of a packet, it's routed through an IPv6 network as an IPv6 address. SIDs, or the prefix(es) covering SIDs, and their reachability may be distributed by means outside the scope of this document. For example, [RFC5308] or [RFC5340] may be used to advertise a prefix covering the SIDs on a node.
SIDがパケットのIPv6ヘッダーの宛先アドレスにある場合、SIDはIPv6ネットワークを介してIPv6アドレスとしてルーティングされます。 SID、またはSIDをカバーするプレフィックス、およびそれらの到達可能性は、このドキュメントの範囲外の方法で配布される場合があります。たとえば、[RFC5308]または[RFC5340]を使用して、ノードのSIDをカバーするプレフィックスをアドバタイズできます。
Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs.
実装の詳細を制限することなく、SRセグメントエンドポイントノードは、ローカルSIDの転送情報ベース（FIB）エントリを作成します。
When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address. This lookup can return any of the following:
SRv6対応ノードは、IPv6パケットを受信すると、パケットの宛先アドレスに対して最長プレフィックス一致検索を実行します。このルックアップでは、次のいずれかが返されます。
* A FIB entry that represents a locally instantiated SRv6 SID
* ローカルにインスタンス化されたSRv6 SIDを表すFIBエントリ
* A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID
* SRv6 SIDとしてローカルにインスタンス化されていない、ローカルインターフェイスを表すFIBエントリ
* A FIB entry that represents a nonlocal route
* 非ローカルルートを表すFIBエントリ
* No Match
* 歯が立たない
This document and section define a single SRv6 SID. Future documents may define additional SRv6 SIDs. In such a case, the entire content of this section will be defined in that document.
このドキュメントとセクションでは、単一のSRv6 SIDを定義しています。今後のドキュメントでは、追加のSRv6 SIDが定義される可能性があります。そのような場合、このセクションの内容全体がそのドキュメントで定義されます。
If the FIB entry represents a locally instantiated SRv6 SID, process the next header chain of the IPv6 header as defined in Section 4 of [RFC8200]. Section 4.3.1.1 describes how to process an SRH; Section 4.3.1.2 describes how to process an upper-layer header or the absence of a Next Header.
FIBエントリがローカルにインスタンス化されたSRv6 SIDを表す場合は、[RFC8200]のセクション4で定義されているIPv6ヘッダーの次のヘッダーチェーンを処理します。セクション4.3.1.1は、SRHの処理方法について説明しています。 4.3.1.2項では、上位層ヘッダーの処理方法または次ヘッダーの欠如について説明します。
Processing this SID modifies the Segments Left and, if configured to process TLVs, it may modify the "variable-length data" of TLV types that change en route. Therefore, Segments Left is mutable, and TLVs that change en route are mutable. The remainder of the SRH (Flags, Tag, Segment List, and TLVs that do not change en route) are immutable while processing this SID.
このSIDを処理すると、残りのセグメントが変更され、TLVを処理するように構成されている場合、途中で変化するTLVタイプの「可変長データ」が変更される場合があります。したがって、左のセグメントは変更可能であり、途中で変更されるTLVは変更可能です。 SSIDの処理中、SRHの残りの部分（フラグ、タグ、セグメントリスト、および途中で変更されないTLV）は不変です。
S01. When an SRH is processed {
S02. If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in
the routing header.
S04. }
S05. Else {
S06. If local configuration requires TLV processing {
S07. Perform TLV processing (see TLV Processing)
S08. }
S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1
S10. If ((Last Entry > max_last_entry) or
S11. (Segments Left is greater than (Last Entry+1)) {
S12. Send an ICMP Parameter Problem, Code 0, message to
the Source Address, pointing to the Segments Left
field, and discard the packet.
S13. }
S14. Else {
S15. Decrement Segments Left by 1.
S16. Copy Segment List[Segments Left] from the SRH to the
destination address of the IPv6 header.
S17. If the IPv6 Hop Limit is less than or equal to 1 {
S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard
the packet.
S19. }
S20. Else {
S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission
to the new destination.
S23. }
S24. }
S25. }
S26. }
Local configuration determines how TLVs are to be processed when the Active Segment is a local SID defined in this document. The definition of local configuration is outside the scope of this document.
ローカル構成は、アクティブセグメントがこのドキュメントで定義されているローカルSIDである場合のTLVの処理方法を決定します。ローカル構成の定義は、このドキュメントの範囲外です。
For illustration purposes only, two example local configurations that may be associated with a SID are provided below.
説明のみを目的として、SIDに関連付けることができる2つのローカル構成の例を以下に示します。
Example 1: For any packet received from interface I2 Skip TLV processing
例1：インターフェイスI2から受信したパケットの場合TLV処理をスキップします
Example 2:
For any packet received from interface I1
If first TLV is HMAC {
Process the HMAC TLV
}
Else {
Discard the packet
}
When processing the upper-layer header of a packet matching a FIB entry locally instantiated as an SRv6 SID defined in this document:
このドキュメントで定義されているSRv6 SIDとしてローカルにインスタンス化されたFIBエントリに一致するパケットの上位層ヘッダーを処理する場合：
IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits {
Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module
}
ELSE {
Send an ICMP parameter problem message to the Source Address and
discard the packet. Error code (4) "SR Upper-layer
Header Error", pointer set to the offset of the upper-layer
header.
}
A unique error code allows an SR source node to recognize an error in SID processing at an endpoint.
一意のエラーコードにより、SRソースノードはエンドポイントでのSID処理のエラーを認識できます。
If the FIB entry represents a local interface and is not locally instantiated as an SRv6 SID, the SRH is processed as follows:
FIBエントリがローカルインターフェイスを表し、ローカルでSRv6 SIDとしてインスタンス化されていない場合、SRHは次のように処理されます。
If Segments Left is zero, the node must ignore the routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header.
Segments Leftがゼロの場合、ノードはルーティングヘッダーを無視し、パケットの次のヘッダーの処理に進む必要があります。パケットのタイプは、ルーティングヘッダーのNext Headerフィールドで識別されます。
If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type.
残りセグメントがゼロ以外の場合、ノードはパケットを破棄し、ICMPパラメータ問題、コード0、メッセージをパケットの送信元アドレスに送信して、認識されないルーティングタイプを指す必要があります。
Processing is not changed by this document.
このドキュメントによって処理は変更されません。
Processing is not changed by this document.
このドキュメントによって処理は変更されません。
The use of the SIDs exclusively within the SR domain and solely for packets of the SR domain is an important deployment model.
SRドメイン内のみでSRドメインのパケット専用にSIDを使用することは、重要な展開モデルです。
This enables the SR domain to act as a single routing system.
これにより、SRドメインは単一のルーティングシステムとして機能できます。
This section covers:
このセクションの内容は次のとおりです。
* securing the SR domain from external attempts to use its SIDs
* SRドメインをそのSIDを使用する外部の試みから保護する
* using the SR domain as a single system with delegation between components
* コンポーネント間の委任を伴う単一システムとしてSRドメインを使用する
* handling packets of the SR domain
* SRドメインのパケットの処理
Nodes outside the SR domain are not trusted: they cannot directly use the SIDs of the domain. This is enforced by two levels of access control lists:
SRドメイン外のノードは信頼されていません。ドメインのSIDを直接使用することはできません。これは、2つのレベルのアクセス制御リストによって実施されます。
1. Any packet entering the SR domain and destined to a SID within the SR domain is dropped. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:
1. SRドメインに入り、SRドメイン内のSID宛てのパケットはすべてドロップされます。これは、次のロジックで実現できます。同等の結果を持つ他のメソッドは準拠していると見なされます。
* Allocate all the SIDs from a block S/s
* ブロックS / sからすべてのSIDを割り当てる
* Configure each external interface of each edge node of the domain with an inbound infrastructure access list (IACL) that drops any incoming packet with a destination address in S/s
* ドメインの各エッジノードの各外部インターフェイスを、S / sの宛先アドレスを持つ着信パケットをドロップする受信インフラストラクチャアクセスリスト（IACL）で構成します。
* Failure to implement this method of ingress filtering exposes the SR domain to source-routing attacks, as described and referenced in [RFC5095]
* [RFC5095]で説明および参照されているように、この入力フィルタリングの方法を実装しないと、SRドメインがソースルーティング攻撃にさらされます。
2. The distributed protection in #1 is complemented with per-node protection, dropping packets to SIDs from source addresses outside the SR domain. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:
2. ＃1の分散保護はノードごとの保護で補完され、SRドメイン外の送信元アドレスからSIDへのパケットをドロップします。これは、次のロジックで実現できます。同等の結果を持つ他のメソッドは準拠していると見なされます。
* Assign all interface addresses from prefix A/a
* プレフィックスA / aからすべてのインターフェースアドレスを割り当てる
* At node k, all SIDs local to k are assigned from prefix Sk/sk
* ノードkでは、kにローカルなすべてのSIDがプレフィックスSk / skから割り当てられます
* Configure each internal interface of each SR node k in the SR domain with an inbound IACL that drops any incoming packet with a destination address in Sk/sk if the source address is not in A/a.
* ソースドメインがA / aにない場合、Sk / skの宛先アドレスを持つ着信パケットをドロップするインバウンドIACLを使用して、SRドメイン内の各SRノードkの各内部インターフェイスを構成します。
All intra-SR-domain packets are of the SR domain. The IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.
SRドメイン内のパケットはすべてSRドメインのものです。 IPv6ヘッダーは、SRドメインのノードから発信され、SRドメインのノードに送信されます。
All interdomain packets are encapsulated for the part of the packet journey that is within the SR domain. The outer IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.
すべてのドメイン間パケットは、SRドメイン内にあるパケットジャーニーの一部のためにカプセル化されます。外部IPv6ヘッダーは、SRドメインのノードから発信され、SRドメインのノードに送信されます。
As a consequence, any packet within the SR domain is of the SR domain.
結果として、SRドメイン内のすべてのパケットはSRドメインのものです。
The SR domain is a system in which the operator may want to distribute or delegate different operations of the outermost header to different nodes within the system.
SRドメインは、オペレーターが最も外側のヘッダーのさまざまな操作をシステム内のさまざまなノードに分散または委任することを望むシステムです。
An operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain and delegate validation of the contents of any SRH to a more trusted router or switch attached to the host. Consider a top-of-rack switch T connected to host H via interface I. H receives an SRH (SRH1) with a computed HMAC via some SDN method outside the scope of this document. H classifies traffic it sources and adds SRH1 to traffic requiring a specific Service Level Agreement (SLA). T is configured with an IACL on I requiring verification of the SRH for any packet destined to the SID block of the SR domain (S/s). T checks and verifies that SRH1 is valid and contains an HMAC TLV; T then verifies the HMAC.
SRドメインのオペレーターは、SRHの追加をSRドメイン内のホストノードに委任し、SRHの内容の検証をホストに接続されているより信頼できるルーターまたはスイッチに委任することを選択できます。インターフェイスIを介してホストHに接続されたトップオブラックスイッチTについて考えてみます。Hは、このドキュメントの範囲外にあるSDNメソッドを介して、計算されたHMACを備えたSRH（SRH1）を受信します。 Hは送信元のトラフィックを分類し、特定のサービスレベルアグリーメント（SLA）を必要とするトラフィックにSRH1を追加します。 TにはISRの検証を必要とするIACLがSRドメインのSIDブロックに宛てられたパケットに対して構成されています（S / s）。 Tは、SRH1が有効であり、HMAC TLVが含まれていることを確認します。次に、TはHMACを検証します。
An operator of the SR domain may choose to have all segments in the SR domain verify the HMAC. This mechanism would verify that the SRH Segment List is not modified while traversing the SR domain.
SRドメインのオペレーターは、SRドメインのすべてのセグメントにHMACを検証させることを選択できます。このメカニズムは、SRドメインのトラバース中にSRHセグメントリストが変更されていないことを確認します。
An SR domain ingress edge node encapsulates packets traversing the SR domain and needs to consider the MTU of the SR domain. Within the SR domain, well-known mitigation techniques are RECOMMENDED, such as deploying a greater MTU value within the SR domain than at the ingress edges.
SRドメインの入口エッジノードは、SRドメインを通過するパケットをカプセル化し、SRドメインのMTUを考慮する必要があります。 SRドメイン内では、入口エッジよりもSRドメイン内でより大きなMTU値を展開するなど、よく知られた緩和手法が推奨されます。
Encapsulation with an outer IPv6 header and SRH shares the same MTU and fragmentation considerations as IPv6 tunnels described in [RFC2473]. Further investigation on the limitation of various tunneling methods (including IPv6 tunnels) is discussed in [INTAREA-TUNNELS] and SHOULD be considered by operators when considering MTU within the SR domain.
外部IPv6ヘッダーとSRHによるカプセル化は、[RFC2473]で説明されているIPv6トンネルと同じMTUおよびフラグメンテーションの考慮事項を共有します。さまざまなトンネリング方式（IPv6トンネルを含む）の制限に関する詳細な調査は[INTAREA-TUNNELS]で説明されており、SRドメイン内のMTUを検討する場合は、オペレーターが検討する必要があります。
ICMP error packets generated within the SR domain are sent to source nodes within the SR domain. The invoking packet in the ICMP error message may contain an SRH. Since the destination address of a packet with an SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet.
SRドメイン内で生成されたICMPエラーパケットは、SRドメイン内の送信元ノードに送信されます。 ICMPエラーメッセージの呼び出しパケットには、SRHが含まれている場合があります。 SRHを含むパケットの宛先アドレスは、各セグメントが処理されるたびに変化するため、呼び出しパケットを生成したソケットまたはアプリケーションが使用する宛先ではない可能性があります。
For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol-error handlers.
呼び出しパケットのソースがICMPエラーメッセージを処理するために、IPv6ヘッダーの最終的な宛先アドレスが必要になる場合があります。次のロジックは、プロトコルエラーハンドラーが使用する宛先アドレスを決定するために使用されます。
* Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper-layer header.
* 呼び出し側IPv6パケットのすべての拡張ヘッダーを、上位層ヘッダーの前のルーティング拡張ヘッダーに移動します。
- If routing header is type 4 Segment Routing Header (SRH)
- ルーティングヘッダーがタイプ4セグメントルーティングヘッダー（SRH）の場合
o The SID at Segment List[0] may be used as the destination address of the invoking packet.
o Segment List [0]のSIDは、呼び出しパケットの宛先アドレスとして使用できます。
ICMP errors are then processed by upper-layer transports as defined in [RFC4443].
ICMPエラーは、[RFC4443]で定義されているように、上位層のトランスポートによって処理されます。
For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in [RFC2473].
外部IPv6ヘッダーにカプセル化されたIPパケットの場合、ICMPエラー処理は[RFC2473]で定義されています。
For any interdomain packet, the SR source node MUST impose a flow label computed based on the inner packet. The computation of the flow label is as recommended in [RFC6438] for the sending Tunnel End Point.
ドメイン間パケットの場合、SR送信元ノードは、内部パケットに基づいて計算されたフローラベルを課さなければなりません（MUST）。フローラベルの計算は、[RFC6438]で送信トンネルエンドポイントに対して推奨されているとおりです。
For any intradomain packet, the SR source node SHOULD impose a flow label computed as described in [RFC6437] to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH.
ドメイン内パケットの場合、SRソースノードは、[RFC6437]で説明されているように計算されたフローラベルを課して、SRHを超える5タプルを計算できないトランジットノードでのECMPロードバランシングを支援する必要があります。
At any transit node within an SR domain, the flow label MUST be used as defined in [RFC6438] to calculate the ECMP hash toward the destination address. If a flow label is not used, the transit node would likely hash all packets between a pair of SR Edge nodes to the same link.
SRドメイン内のトランジットノードでは、[RFC6438]の定義に従ってフローラベルを使用して、宛先アドレスへのECMPハッシュを計算する必要があります。フローラベルを使用しない場合、トランジットノードは、同じリンクへのSRエッジノードのペア間のすべてのパケットをハッシュする可能性があります。
At an SR segment endpoint node, the flow label MUST be used as defined in [RFC6438] to calculate any ECMP hash used to forward the processed packet to the next segment.
SRセグメントエンドポイントノードでは、[RFC6438]で定義されているようにフローラベルを使用して、処理されたパケットを次のセグメントに転送するために使用されるECMPハッシュを計算する必要があります。
Other deployment models and their implications on security, MTU, HMAC, ICMP error processing, and interaction with other extension headers are outside the scope of this document.
他の展開モデルと、セキュリティ、MTU、HMAC、ICMPエラー処理、および他の拡張ヘッダーとの相互作用への影響は、このドキュメントの範囲外です。
This section provides illustrations of SRv6 packet processing at SR source, transit, and SR segment endpoint nodes.
このセクションでは、SRソース、トランジット、およびSRセグメントエンドポイントノードでのSRv6パケット処理の図を示します。
For a node k, its IPv6 address is represented as Ak, and its SRv6 SID is represented as Sk.
ノードkの場合、そのIPv6アドレスはAkとして表され、そのSRv6 SIDはSkとして表されます。
IPv6 headers are represented as the tuple of (source,destination). For example, a packet with source address A1 and destination address A2 is represented as (A1,A2). The payload of the packet is omitted.
IPv6ヘッダーは、（source、destination）のタプルとして表されます。たとえば、送信元アドレスがA1で宛先アドレスがA2のパケットは、（A1、A2）と表されます。パケットのペイロードは省略されます。
An SR Policy is a list of segments. A list of segments is represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit.
SRポリシーは、セグメントのリストです。セグメントのリストは<S1、S2、S3>として表されます。S1は最初にアクセスするSID、S2は2番目にアクセスするSID、S3は最後にアクセスするSIDです。
(SA,DA) (S3,S2,S1; SL) represents an IPv6 packet with:
（SA、DA）（S3、S2、S1; SL）は、次のIPv6パケットを表します。
* Source Address SA, Destination Addresses DA, and next header SRH.
* 送信元アドレスSA、宛先アドレスDA、および次のヘッダーSRH。
* SRH with SID list <S1,S2,S3> with SegmentsLeft = SL.
* SRHとSIDリスト<S1、S2、S3>、SegmentsLeft = SL。
* Note the difference between the <> and () symbols. <S1,S2,S3> represents a SID list where the leftmost segment is the first segment. In contrast, (S3,S2,S1; SL) represents the same SID list but encoded in the SRH Segment List format where the leftmost segment is the last segment. When referring to an SR Policy in a high-level use case, it is simpler to use the <S1,S2,S3> notation. When referring to an illustration of detailed behavior, the (S3,S2,S1; SL) notation is more convenient.
* <>記号と()記号の違いに注意してください。 <S1、S2、S3>は、左端のセグメントが最初のセグメントであるSIDリストを表します。対照的に、（S3、S2、S1; SL）は同じSIDリストを表しますが、左端のセグメントが最後のセグメントであるSRHセグメントリスト形式でエンコードされます。高レベルのユースケースでSRポリシーを参照する場合、<S1、S2、S3>表記を使用する方が簡単です。詳細な動作の図を参照するときは、（S3、S2、S1; SL）表記の方が便利です。
At its SR Policy headend, the Segment List <S1,S2,S3> results in SRH (S3,S2,S1; SL=2) represented fully as:
SRポリシーヘッドエンドでは、セグメントリスト<S1、S2、S3>はSRH（S3、S2、S1; SL = 2）となり、次のように完全に表現されます。
Segments Left=2 Last Entry=2 Flags=0 Tag=0 Segment List[0]=S3 Segment List[1]=S2 Segment List[2]=S1
左のセグメント= 2最後のエントリ= 2フラグ= 0タグ= 0セグメントリスト[0] = S3セグメントリスト[1] = S2セグメントリスト[2] = S1
The following topology is used in examples below:
次のトポロジは、以下の例で使用されています。
+ * * * * * * * * * * * * * * * * * * * * +
* [8] [9] *
| |
* | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
+ * * * * * * * SR domain * * * * * * * +
Figure 1
図1
* 3 and 4 are SR domain edge routers
* 3と4はSRドメインエッジルーターです
* 5, 6, and 7 are all SR domain routers
* 5、6、7はすべてSRドメインルーターです
* 8 and 9 are hosts within the SR domain
* 8と9はSRドメイン内のホストです
* 1 and 2 are hosts outside the SR domain
* 1と2はSRドメイン外のホストです
* The SR domain implements ingress filtering as per Section 5.1 and no external packet can enter the domain with a destination address equal to a segment of the domain.
* SRドメインはセクション5.1に従って入力フィルタリングを実装し、外部パケットはドメインのセグメントに等しい宛先アドレスでドメインに入ることができません。
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the packet is
ホスト8がSRポリシー<S7、A9>を介してホスト9にパケットを送信すると、パケットは
P1: (A8,S7)(A9,S7; SL=1)
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it wants to use a reduced SRH, the packet is
ホスト8がSRポリシー<S7、A9>を介してホスト9にパケットを送信し、削減されたSRHを使用したい場合、パケットは
P2: (A8,S7)(A9; SL=1)
When host 1 sends a packet to host 2, the packet is
ホスト1がホスト2にパケットを送信すると、パケットは
P3: (A1,A2)
P3：（A1、A2）
The SR domain ingress router 3 receives P3 and steers it to SR domain egress router 4 via an SR Policy <S7,S4>. Router 3 encapsulates the received packet P3 in an outer header with an SRH. The packet is
SRドメイン入口ルーター3はP3を受信し、SRポリシー<S7、S4>を介してSRドメイン出口ルーター4に誘導します。ルータ3は、SRHを使用して、受信したパケットP3を外部ヘッダーにカプセル化します。パケットは
P4: (A3,S7)(S4,S7; SL=1)(A1,A2)
If the SR Policy contains only one segment (the egress router 4), the ingress router 3 encapsulates P3 into an outer header (A3,S4) without SRH. The packet is
SRポリシーに1つのセグメントのみが含まれている場合（出力ルーター4）、入力ルーター3はP3をSRHなしの外部ヘッダー（A3、S4）にカプセル化します。パケットは
P5: (A3,S4)(A1,A2)
P5：（Az、Mn）（A1、A2）
The SR domain ingress router 3 receives P3 and steers it to SR domain egress router 4 via an SR Policy <S7,S4>. If router 3 wants to use a reduced SRH, it encapsulates the received packet P3 in an outer header with a reduced SRH. The packet is
SRドメイン入口ルーター3はP3を受信し、SRポリシー<S7、S4>を介してSRドメイン出口ルーター4に誘導します。ルーター3が削減されたSRHを使用したい場合、ルーター3は受信パケットP3を削減されたSRHの外部ヘッダーにカプセル化します。パケットは
P6: (A3,S7)(S4; SL=1)(A1,A2)
When host 8 sends a packet to host 1, the packet is encapsulated for the portion of its journey within the SR domain. From 8 to 3 the packet is
ホスト8がホスト1にパケットを送信すると、パケットはSRドメイン内のその経路の一部に対してカプセル化されます。 8から3までのパケットは
P7: (A8,S3)(A8,A1)
P7：（A8、Cs）（A8、A1）
In the opposite direction, the packet generated from 1 to 8 is
反対方向では、1から8に生成されるパケットは
P8: (A1,A8)
文字8：（クラス1、クラス8）
At node 3, P8 is encapsulated for the portion of its journey within the SR domain, with the outer header destined to segment S8. This results in
ノード3では、SRドメイン内のその経路の一部についてP8がカプセル化され、外部ヘッダーはセグメントS8に送信されます。これは
P9: (A3,S8)(A1,A8)
P9：（Az、C8）（A1、A8）
At node 8, the outer IPv6 header is removed by S8 processing, then processed again when received by A8.
ノード8では、外部IPv6ヘッダーがS8処理によって削除され、A8によって受信されたときに再び処理されます。
Node 5 acts as transit node for packet P1 and sends packet
ノード5はパケットP1の中継ノードとして機能し、パケットを送信します
P1: (A8,S7)(A9,S7;SL=1)
on the interface toward node 7.
ノード7へのインターフェイス上。
Node 7 receives packet P1 and, using the logic in Section 4.3.1, sends packet
ノード7はパケットP1を受信し、セクション4.3.1のロジックを使用してパケットを送信します。
P7: (A8,A9)(A9,S7; SL=0)
on the interface toward router 6.
ルータ6へのインターフェイス上。
This section describes how a function may be delegated within the SR domain. In the following sections, consider a host 8 connected to a top of rack 5.
このセクションでは、SRドメイン内で関数を委任する方法について説明します。次のセクションでは、ラック5の上部に接続されたホスト8について考えます。
An operator may prefer to apply the SRH at source 8, while 5 verifies that the SID list is valid.
オペレーターはソース8でSRHを適用することを好むかもしれませんが、5はSIDリストが有効であることを確認します。
For illustration purposes, an SDN controller provides 8 an SRH terminating at node 9, with Segment List <S5,S7,S6,A9>, and HMAC TLV computed for the SRH. The HMAC key ID and key associated with the HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is configured with an IACL applied to the interface connected to 8, requiring HMAC verification for any packet destined to S/s.
説明のために、SDNコントローラーは、ノード9で終了するSRH 8と、セグメントリスト<S5、S7、S6、A9>、およびSRHに対して計算されたHMAC TLVを提供します。 HMAC TLVに関連付けられたHMACキーIDとキーは5と共有されます。ノード8はキーを知りません。ノード5は、8に接続されたインターフェイスに適用されたIACLで構成され、S / S宛てのすべてのパケットに対してHMAC検証を要求します。
Node 8 originates packets with the received SRH, including HMAC TLV.
ノード8は、HMAC TLVを含む、受信したSRHでパケットを発信します。
P15: (A8,S5)(A9,S6,S7,S5;SL=3;HMAC)
Node 5 receives and verifies the HMAC for the SRH, then forwards the packet to the next segment
ノード5はSRHのHMACを受信して検証し、パケットを次のセグメントに転送します
P16: (A8,S7)(A9,S6,S7,S5;SL=2;HMAC)
Node 6 receives
ノード6が受信する
P17: (A8,S6)(A9,S6,S7,S5;SL=1;HMAC)
Node 9 receives
ノード9が受信する
P18: (A8,A9)(A9,S6,S7,S5;SL=0;HMAC)
This use of an HMAC is particularly valuable within an enterprise-based SR domain [SRN].
このHMACの使用は、企業ベースのSRドメイン[SRN]内で特に価値があります。
This section reviews security considerations related to the SRH, given the SRH processing and deployment models discussed in this document.
このセクションでは、このドキュメントで説明されているSRH処理および展開モデルを前提として、SRHに関連するセキュリティの考慮事項を確認します。
As described in Section 5, it is necessary to filter packets' ingress to the SR domain, destined to SIDs within the SR domain (i.e., bearing a SID in the destination address). This ingress filtering is via an IACL at SR domain ingress border nodes. Additional protection is applied via an IACL at each SR Segment Endpoint node, filtering packets not from within the SR domain, destined to SIDs in the SR domain. ACLs are easily supported for small numbers of seldom changing prefixes, making summarization important.
セクション5で説明したように、SRドメイン内のSID宛ての（つまり、宛先アドレスにSIDが含まれている）SRドメインへのパケットの進入をフィルタリングする必要があります。この入力フィルタリングは、SRドメインの入力境界ノードのIACLを介して行われます。各SRセグメントエンドポイントノードのIACLを介して追加の保護が適用され、SRドメイン内からではなく、SRドメイン内のSID宛てのパケットをフィルタリングします。 ACLは、めったに変更されない少数のプレフィックスに対して簡単にサポートされるため、要約が重要になります。
Additionally, ingress filtering of IPv6 source addresses as recommended in BCP 38 [RFC2827] SHOULD be used.
さらに、BCP 38 [RFC2827]で推奨されているIPv6送信元アドレスの入力フィルタリングを使用する必要があります（SHOULD）。
An SR domain implements distributed and per-node protection as described in Section 5.1. Additionally, domains deny traffic with spoofed addresses by implementing the recommendations in BCP 84 [RFC3704].
セクション5.1で説明されているように、SRドメインはノードごとの分散保護を実装しています。さらに、ドメインはBCP 84 [RFC3704]の推奨事項を実装することにより、アドレスが偽装されたトラフィックを拒否します。
Full implementation of the recommended protection blocks the attacks documented in [RFC5095] from outside the SR domain, including bypassing filtering devices, reaching otherwise-unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.
推奨される保護を完全に実装すると、[RFC5095]に記載されているSRドメイン外からの攻撃をブロックできます。これには、フィルタリングデバイスのバイパス、他の方法では到達できないインターネットシステムへの到達、ネットワークトポロジの検出、帯域幅の枯渇、エニーキャストの無効化が含まれます。
Failure to implement distributed and per-node protection allows attackers to bypass filtering devices and exposes the SR domain to these attacks.
分散およびノードごとの保護の実装に失敗すると、攻撃者はフィルタリングデバイスをバイパスし、SRドメインをこれらの攻撃にさらすことができます。
Compromised nodes within the SR domain may mount the attacks listed above along with other known attacks on IP networks (e.g., DoS/DDoS, topology discovery, man-in-the-middle, traffic interception/ siphoning).
SRドメイン内の侵害されたノードは、IPネットワークに対する他の既知の攻撃（DoS / DDoS、トポロジー検出、中間者、トラフィックの傍受/サイフォンなど）とともに上記の攻撃を開始する可能性があります。
Service theft is defined as the use of a service offered by the SR domain by a node not authorized to use the service.
サービスの盗難は、サービスの使用を許可されていないノードがSRドメインによって提供されるサービスを使用することとして定義されます。
Service theft is not a concern within the SR domain, as all SR source nodes and SR segment endpoint nodes within the domain are able to utilize the services of the domain. If a node outside the SR domain learns of segments or a topological service within the SR domain, IACL filtering denies access to those segments.
ドメイン内のすべてのSRソースノードとSRセグメントエンドポイントノードはドメインのサービスを利用できるため、サービスの盗難はSRドメイン内の問題ではありません。 SRドメイン外のノードがSRドメイン内のセグメントまたはトポロジサービスを学習すると、IACフィルタリングはそれらのセグメントへのアクセスを拒否します。
The SRH is unencrypted and may contain SIDs of some intermediate SR nodes in the path towards the destination within the SR domain. If packets can be snooped within the SR domain, the SRH may reveal topology, traffic flows, and service usage.
SRHは暗号化されておらず、SRドメイン内の宛先へのパスにいくつかの中間SRノードのSIDが含まれている場合があります。パケットがSRドメイン内でスヌーピングできる場合、SRHはトポロジ、トラフィックフロー、およびサービスの使用状況を明らかにする可能性があります。
This is applicable within an SR domain, but the disclosure is less relevant as an attacker has other means of learning topology, flows, and service usage.
これはSRドメイン内で適用できますが、攻撃者がトポロジ、フロー、およびサービスの使用状況を学習する他の手段を持っているため、この開示はあまり重要ではありません。
The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing destination address or SRH in back-to-back packets. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism.
ICMPv6エラーメッセージの生成は、エラーを引き起こす宛先アドレスまたはSRHをバックツーバックパケットで送信することにより、サービス拒否攻撃を試みるために使用される場合があります。 [RFC4443]のセクション2.4に正しく従う実装は、ICMPv6レート制限メカニズムによって保護されます。
The SR domain is a trusted domain, as defined in [RFC8402], Sections 2 and 8.2. The SR source is trusted to add an SRH (optionally verified as having been generated by a trusted source via the HMAC TLV in this document), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane. As such, the SR domain does not rely on the Authentication Header (AH) as defined in [RFC4302] to secure the SRH.
[RFC8402]、セクション2および8.2で定義されているように、SRドメインは信頼できるドメインです。 SRソースはSRHを追加することが信頼され（オプションで、このドキュメントのHMAC TLVを介して信頼できるソースによって生成されたものとして検証されます）、ドメイン内でアドバタイズされるセグメントは正確であることが信頼され、安全なコントロールプレーンを介して信頼できるソースによってアドバタイズされます。そのため、SRドメインは、[RFC4302]で定義されている認証ヘッダー（AH）に依存せずにSRHを保護します。
The use of SRH with AH by an SR source node and its processing at an SR segment endpoint node are not defined in this document. Future documents may define use of SRH with AH and its processing.
SRソースノードによるAHでのSRHの使用とSRセグメントエンドポイントノードでのその処理は、このドキュメントでは定義されていません。将来の文書では、AHでのSRHの使用とその処理を定義する可能性があります。
This document makes the following registrations in the "Internet Protocol Version 6 (IPv6) Parameters" "Routing Types" subregistry maintained by IANA:
このドキュメントは、IANAによって維持される「インターネットプロトコルバージョン6（IPv6）パラメータ」「ルーティングタイプ」サブレジストリに次の登録を行います。
+-------+------------------------------+---------------+
| Value | Description | Reference |
+=======+==============================+===============+
| 4 | Segment Routing Header (SRH) | This document |
+-------+------------------------------+---------------+
Table 1: SRH Registration
表1：SRH登録
This document makes the following registrations in the "Type 4 - Parameter Problem" message of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained by IANA:
このドキュメントでは、IANAが管理する「インターネット制御メッセージプロトコルバージョン6（ICMPv6）パラメータ」レジストリの「タイプ4-パラメータの問題」メッセージに次の登録を行います。
+------+-----------------------------+
| Code | Name |
+======+=============================+
| 4 | SR Upper-layer Header Error |
+------+-----------------------------+
Table 2: SR Upper-layer Header Error Registration
表2：SR上位層ヘッダーのエラー登録
This document describes a new IANA-managed registry to identify SRH Flags Bits. The registration procedure is "IETF Review" [RFC8126]. The registry name is "Segment Routing Header Flags". Flags are 8 bits.
このドキュメントでは、SRHフラグビットを識別するための新しいIANA管理レジストリについて説明します。登録手順は「IETFレビュー」[RFC8126]です。レジストリ名は「セグメントルーティングヘッダーフラグ」です。フラグは8ビットです。
This document describes a new IANA-managed registry to identify SRH TLVs. The registration procedure is "IETF Review". The registry name is "Segment Routing Header TLVs". A TLV is identified through an unsigned 8-bit codepoint value, with assigned values 0-127 for TLVs that do not change en route and 128-255 for TLVs that may change en route. The following codepoints are defined in this document:
このドキュメントでは、SRH TLVを識別するための新しいIANA管理レジストリについて説明します。登録手続きは「IETFレビュー」です。レジストリ名は「セグメントルーティングヘッダーTLV」です。 TLVは、符号なしの8ビットコードポイント値によって識別されます。割り当てられた値は、途中で変化しないTLVの場合は0〜127、途中で変化する可能性のあるTLVの場合は128〜255です。このドキュメントでは、次のコードポイントが定義されています。
+---------+--------------------------+---------------+
| Value | Description | Reference |
+=========+==========================+===============+
| 0 | Pad1 TLV | This document |
+---------+--------------------------+---------------+
| 1 | Reserved | This document |
+---------+--------------------------+---------------+
| 2 | Reserved | This document |
+---------+--------------------------+---------------+
| 3 | Reserved | This document |
+---------+--------------------------+---------------+
| 4 | PadN TLV | This document |
+---------+--------------------------+---------------+
| 5 | HMAC TLV | This document |
+---------+--------------------------+---------------+
| 6 | Reserved | This document |
+---------+--------------------------+---------------+
| 124-126 | Experimentation and Test | This document |
+---------+--------------------------+---------------+
| 127 | Reserved | This document |
+---------+--------------------------+---------------+
| 252-254 | Experimentation and Test | This document |
+---------+--------------------------+---------------+
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
Table 3: Segment Routing Header TLVs Registry
表3：セグメントルーティングヘッダーTLVレジストリ
Values 1, 2, 3, and 6 were defined in draft versions of this specification and are Reserved for backwards compatibility with early implementations and should not be reassigned. Values 127 and 255 are Reserved to allow for expansion of the Type field in future specifications, if needed.
値1、2、3、および6は、この仕様のドラフトバージョンで定義されており、初期の実装との下位互換性のために予約されているため、再割り当てしないでください。値127と255は、将来の仕様で必要に応じてTypeフィールドを拡張できるように予約されています。
[FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/ NIST.FIPS.180-4, August 2015, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.
[FIPS180-4]米国国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http：// csrc .nist.gov / publications / fips / fips180-4 / fips-180-4.pdf>。
[IANA-SRHTLV] IANA, "Segment Routing Header TLVs", <https://www.iana.org/assignments/ipv6-parameters/>.
[IANA-SRHTLV] IANA、「セグメントルーティングヘッダーTLV」、<https://www.iana.org/assignments/ipv6-parameters/>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、DOI 10.17487 / RFC2473、1998年12月、<https://www.rfc-editor.org/info/rfc2473>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704 >。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107 >。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、DOI 10.17487 / RFC5095、2007年12月、<https：//www.rfc -editor.org/info/rfc5095>。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6407] Weis、B.、Rowles、S.、T。Hardjono、「The Group Domain of Interpretation」、RFC 6407、DOI 10.17487 / RFC6407、2011年10月、<https://www.rfc-editor.org/ info / rfc6407>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc- editor.org/info/rfc6437>。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B。およびS. Amante、「IPv6フローラベルを使用したトンネルでの等コストマルチパスルーティングおよびリンク集約」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<https：//www.rfc- editor.org/info/rfc6438>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[INTAREA-TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.
[INTAREA-TUNNELS] Touch、J。およびM.タウンズリー、「インターネットアーキテクチャのIPトンネル」、作業中、インターネットドラフト、draft-ietf-intarea-tunnels-10、2019年9月12日、<https：// tools.ietf.org/html/draft-ietf-intarea-tunnels-10>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>.
[RFC5308] Hopps、C。、「Routing IPv6 with IS-IS」、RFC 5308、DOI 10.17487 / RFC5308、2008年10月、<https://www.rfc-editor.org/info/rfc5308>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：//www.rfc-editor .org / info / rfc5340>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. Bonaventure, "Software Resolved Networks: Rethinking Enterprise Networks with IPv6 Segment Routing", 2018, <https://inl.info.ucl.ac.be/system/files/ sosr18-final15-embedfonts.pdf>.
[SRN] Lebrun、D.、Jadin、M.、Clad、F.、Filsfils、C。、およびO. Bonaventure、「Software Resolved Networks：Rethinking Enterprise Networks with IPv6 Segment Routing」、2018、<https：// inl .info.ucl.ac.be / system / files / sosr18-final15-embedfonts.pdf>。
Acknowledgements
謝辞
The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kühlewind, Roman Danyliw, Joe Touch, and Magnus Westerlund for their comments to this document.
著者は、Ole Troan、Bob Hinden、Ron Bonica、Fred Baker、Brian Carpenter、Alexandru Petrescu、Punit Kumar Jaiswal、David Lebrun、Benjamin Kaduk、Frank Xialiang、MirjaKühlewind、Roman Danyliw、Joe Touch、およびMagnus Westerlundに感謝します。このドキュメントへのコメント。
Contributors
貢献者
Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen Linkova, Ebben Aries, Tomoya Kosugi, Éric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James Connolly, and Aloys Augustin contributed to the content of this document.
カムラン・ラザ、ザファール・アリ、ブライアン・フィールド、ダニエル・バーニア、アイダ・レオン、ジェン・リンコワ、エベン・アリエス、小杉知也、エリック・ヴィンケ、デビッド・レブルン、ダーク・スタインバーグ、ロバート・ラズク、デイブ・バラチ、ジョン・ブロゾウスキ、ピエール・フランソワ、ナジェンドラ・クマー、マーク・タウンズリー、Christian Martin、Roberta Maglione、James Connolly、Aloys Augustinがこのドキュメントの内容に貢献しました。
Authors' Addresses
著者のアドレス
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Darren Dukes (editor) Cisco Systems, Inc. Ottawa Canada
ダレンデュークス（編集者）Cisco Systems、Inc.オタワカナダ
Email: ddukes@cisco.com
Stefano Previdi Huawei Italy
Stefano Previdi Huaweiイタリア
Email: stefano@previdi.net
John Leddy Individual United States of America
ジョン・レディ個人アメリカ合衆国
Email: john@leddy.net
Satoru Matsushima SoftBank
さとる まつしま そｆｔばんｋ
Email: satoru.matsushima@g.softbank.co.jp
Daniel Voyer Bell Canada
ダニエルボイヤーベルカナダ
Email: daniel.voyer@bell.ca