Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 9631 Juniper Networks
Category: Experimental Y. Kamite
ISSN: 2070-1721 NTT Communications Corporation
A. Alston
Alston Networks
D. Henriques
Liquid Telecom
L. Jalil
Verizon
August 2024
This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Header (CRH). Individually, they are called CRH-16 and CRH-32.
このドキュメントでは、2つの新しいIPv6ルーティングヘッダーが実装および展開される実験について説明します。まとめて、それらはコンパクトルーティングヘッダー（CRH）と呼ばれます。個別に、それらはCRH-16およびCRH-32と呼ばれます。
One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations described in this document can be addressed with Access Control Lists (ACLs). Finally, this document encourages replication of the experiment.
この実験の1つの目的は、CRHを実装ネットワークに実装および展開できることを実証することです。もう1つの目的は、このドキュメントで説明されているセキュリティに関する考慮事項に、アクセス制御リスト（ACL）で対処できることを実証することです。最後に、この文書は実験の複製を奨励しています。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9631.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9631で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. The Compact Routing Header (CRH)
4. The CRH Forwarding Information Base (CRH-FIB)
5. Processing Rules
5.1. Computing Minimum CRH Length
6. Mutability
7. Applications and CRH SIDs
8. Operational Considerations
9. Textual Representations
10. Security Considerations
11. Experimental Results
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Appendix A. CRH Processing Examples
A.1. The CRH SID list contains one entry for each segment in the
path.
A.2. The CRH SID list omits the first entry in the path.
Acknowledgements
Contributors
Authors' Addresses
IPv6 [RFC8200] source nodes use Routing headers to specify the path that a packet takes to its destination(s). The IETF has defined several Routing Types; see [IANA-RT]. This document defines two new Routing Types. Collectively, they are called the Compact Routing Header (CRH). Individually, they are called CRH-16 and CRH-32.
IPv6 [RFC8200]ソースノードは、ルーティングヘッダーを使用して、パケットが宛先にとるパスを指定します。IETFは、いくつかのルーティングタイプを定義しています。[iana-rt]を参照してください。このドキュメントでは、2つの新しいルーティングタイプを定義します。まとめて、それらはコンパクトルーティングヘッダー（CRH）と呼ばれます。個別に、それらはCRH-16およびCRH-32と呼ばれます。
The CRH allows IPv6 source nodes to specify the path that a packet takes to its destination. The CRH can be encoded in relatively few bytes. The following are reasons for encoding the CRH in as few bytes as possible:
CRHを使用すると、IPv6ソースノードがパケットが宛先にとるパスを指定できます。CRHは、比較的少ないバイトでエンコードできます。以下は、CRHをできるだけ少ないバイトでエンコードする理由です。
* Many forwarders based on Application-Specific Integrated Circuits (ASICs) copy headers from buffer memory to on-chip memory. As header sizes increase, so does the cost of this copy.
* アプリケーション固有の統合回路（ASIC）に基づく多くのフォワーダーは、バッファメモリからオンチップメモリにヘッダーをコピーします。ヘッダーサイズが増加すると、このコピーのコストも増加します。
* Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely reliable, many IPv6 hosts refrain from sending packets larger than the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are small, the overhead imposed by large Routing headers is excessive.
* Path MTU Discovery（PMTUD）[RFC8201]は完全に信頼性が高いため、多くのIPv6ホストはIPv6最小リンクMTU（つまり、1280バイト）よりも大きいパケットの送信を控えます。パケットが小さい場合、大きなルーティングヘッダーによって課されるオーバーヘッドは過剰です。
This document describes an experiment with the following purposes:
このドキュメントでは、次の目的の実験について説明します。
* To demonstrate that the CRH can be implemented and deployed
* CRHを実装および展開できることを実証する
* To demonstrate that the security considerations described in this document can be addressed with ACLs
* このドキュメントで説明されているセキュリティ上の考慮事項にACLSで対処できることを実証するために
* To encourage replication of the experiment
* 実験の複製を促進する
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Both CRH versions (i.e., CRH-16 and CRH-32) contain the following fields:
両方のCRHバージョン（つまり、CRH-16およびCRH-32）には、次のフィールドが含まれています。
* Next Header, as defined in [RFC8200]
* [RFC8200]で定義されている次のヘッダー
* Hdr Ext Len, as defined in [RFC8200]
* [RFC8200]で定義されているHDR ext Len
* Routing Type, as defined in [RFC8200] (CRH-16 value is 5, and CRH-32 value is 6.)
* [RFC8200]で定義されているルーティングタイプ（CRH-16値は5、CRH-32値は6です。）
* Segments Left, as defined in [RFC8200]
* [RFC8200]で定義されているように、残りのセグメント
* type-specific data, as described in [RFC8200]
* [RFC8200]で説明されているタイプ固有のデータ
In the CRH, the type-specific data field contains a list of CRH Segment Identifiers (CRH SIDs). Each CRH SID identifies an entry in the CRH Forwarding Information Base (CRH-FIB) (Section 4). Each CRH-FIB entry identifies an interface on the path that the packet takes to its destination.
CRHでは、型固有のデータフィールドには、CRHセグメント識別子（CRH SIDS）のリストが含まれています。各CRH SIDは、CRH転送情報ベース（CRH-FIB）のエントリを識別します（セクション4）。各CRH-FIBエントリは、パケットが宛先にとるパス上のインターフェイスを識別します。
CRH SIDs are listed in reverse order. So, the first CRH SID in the list represents the final interface in the path. Because CRH SIDs are listed in reverse order, the Segments Left field can be used as an index into the CRH SID list. In this document, the "current CRH SID" is the CRH SID list entry referenced by the Segments Left field.
CRH SIDは逆順序でリストされています。したがって、リスト内の最初のCRH SIDは、パス内の最終インターフェイスを表します。CRH SIDは逆の順序でリストされているため、セグメントの左フィールドはCRH SIDリストへのインデックスとして使用できます。このドキュメントでは、「現在のCRH SID」は、セグメントの左フィールドで参照されるCRH SIDリストエントリです。
The first CRH SID in the path is omitted from the list unless there is some reason to preserve it. See Appendix A for an example.
パスでの最初のCRH SIDは、それを保存する理由がない限り、リストから省略されます。例については、付録Aを参照してください。
In the CRH-16 (Figure 1), each CRH SID is encoded in 16 bits. In the CRH-32 (Figure 2), each CRH SID is encoded in 32 bits.
CRH-16（図1）では、各CRH SIDは16ビットでエンコードされています。CRH-32（図2）では、各CRH SIDは32ビットでエンコードされています。
In all cases, the CRH MUST end on a 64-bit boundary. So, the type-specific data field MUST be padded with zeros if the CRH would otherwise not end on a 64-bit boundary.
すべての場合において、CRHは64ビットの境界で終了する必要があります。したがって、CRHが64ビットの境界で終了しない場合、型固有のデータフィールドにゼロをパッドで入れる必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID[0] | SID[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: CRH-16
図1：CRH-16
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[0] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[1] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: CRH-32
図2：CRH-32
Each CRH SID identifies a CRH-FIB entry.
各CRH SIDは、CRH-FIBエントリを識別します。
Each CRH-FIB entry contains:
各CRH-FIBエントリには次のものが含まれます。
* An IPv6 address
* IPv6アドレス
* A topological function
* トポロジー機能
* Arguments for the topological function (optional)
* トポロジー機能の引数（オプション）
The IPv6 address can be a Global Unicast Address (GUA), a Link-Local Unicast (LLU) address, or a Unique Local Address (ULA). When the IPv6 address is the final address in a path, it can also be a multicast address.
IPv6アドレスは、グローバルユニキャストアドレス（GUA）、Link-Local Unicast（LLU）アドレス、または一意のローカルアドレス（ULA）です。IPv6アドレスがパス内の最終アドレスである場合、マルチキャストアドレスになることもあります。
The topological function specifies how the processing node forwards the packet to the interface identified by the IPv6 address. The following are examples:
トポロジー関数は、処理ノードがIPv6アドレスによって識別されたインターフェイスにパケットを転送する方法を指定します。以下は例です。
* Forward the packet through the least-cost path to the interface identified by the IPv6 address (i.e., loose source routing).
* IPv6アドレス（つまり、ルーズソースルーティング）で識別されたインターフェイスへの最小コストパスを介してパケットを転送します。
* Forward the packet through a specified interface to the interface identified by the IPv6 address (i.e., strict source routing).
* 指定されたインターフェイスを介して、IPv6アドレス（つまり、厳密なソースルーティング）で識別されたインターフェイスにパケットを転送します。
Some topological functions require parameters. For example, a topological function might require a parameter that identifies the interface through which the packet is forwarded.
一部のトポロジー機能にはパラメーターが必要です。たとえば、トポロジー機能には、パケットが転送されるインターフェイスを識別するパラメーターが必要になる場合があります。
The CRH-FIB can be populated by:
CRH-FIBには次のように入力できます。
* An operator, using a Command Line Interface (CLI)
* コマンドラインインターフェイス（CLI）を使用するオペレーター
* A controller, using the Path Computation Element Communication Protocol (PCEP) [RFC5440] or the Network Configuration Protocol (NETCONF) [RFC6241]
* パス計算要素通信プロトコル（PCEP）[RFC5440]またはネットワーク構成プロトコル（NetConf）[RFC6241]を使用したコントローラー
* A distributed routing protocol, such as those defined in [ISO10589-Second-Edition], [RFC5340], and [RFC4271]
* [ISO10589-Second-Edition]、[RFC5340]、および[RFC4271]で定義されているものなどの分散ルーティングプロトコル。
The above-mentioned mechanisms are not defined here and are beyond the scope of this document.
上記のメカニズムはここでは定義されておらず、このドキュメントの範囲を超えています。
The following rules describe CRH processing:
以下のルールは、CRH処理について説明します。
* If Hdr Ext Len indicates that the CRH is larger than the implementation can process, discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field.
* HDR ext LenがCRHが実装よりも大きいことを示している場合、パケットを破棄し、ICMPv6 [RFC4443]パラメーター問題、コード0、ソースアドレスへのメッセージを送信し、HDR Ext Lenフィールドを指します。
* Compute L, the minimum CRH length (Section 5.1).
* L、最小CRHの長さを計算します（セクション5.1）。
* If L is greater than Hdr Ext Len, discard the packet and send an ICMPv6 Parameter Problem, Code 6, message to the Source Address, pointing to the Segments Left field.
* LがHDR ext Lenよりも大きい場合は、パケットを破棄し、ICMPV6パラメーター問題、コード6、ソースアドレスへのメッセージを送信し、セグメントの左フィールドを指します。
* Decrement Segments Left.
* 減少セグメントが残っています。
* Search for the current CRH SID in the CRH-FIB. In this document, the "current CRH SID" is the CRH SID list entry referenced by the Segments Left field.
* CRH-FIBで現在のCRH SIDを検索します。このドキュメントでは、「現在のCRH SID」は、セグメントの左フィールドで参照されるCRH SIDリストエントリです。
* If the search does not return a CRH-FIB entry, discard the packet and send an ICMPv6 Parameter Problem, Code 0, message to the Source Address, pointing to the current SID.
* 検索がCRH-FIBエントリを返さない場合は、パケットを破棄し、ICMPV6パラメーター問題、コード0、ソースアドレスへのメッセージを送信し、現在のSIDを指しています。
* If Segments Left is greater than 0 and the CRH-FIB entry contains a multicast address, discard the packet and send an ICMPv6 Parameter Problem, Code 0, message to the Source Address, pointing to the current SID. (This prevents packet storms.)
* 残ったセグメントが0より大きく、CRH-FIBエントリにマルチキャストアドレスが含まれている場合、パケットを破棄し、ICMPV6パラメーター問題、コード0、ソースアドレスへのメッセージを送信し、現在のSIDを指します。（これにより、パケットストームが防止されます。）
* Copy the IPv6 address from the CRH-FIB entry to the Destination Address field in the IPv6 header.
* CRH-FIBエントリからIPv6アドレスをIPv6ヘッダーの宛先アドレスフィールドにコピーします。
* Submit the packet, its topological function, and its parameters to the IPv6 module.
* パケット、そのトポロジ機能、およびそのパラメーターをIPv6モジュールに送信します。
NOTE: By default, the IPv6 module determines the next hop and forwards the packet. However, the topological function may elicit another behavior. For example, the IPv6 module may forward the packet through a specified interface.
注：デフォルトでは、IPv6モジュールは次のホップを決定し、パケットを転送します。ただし、トポロジー機能は別の動作を引き出す可能性があります。たとえば、IPv6モジュールは、指定されたインターフェイスを介してパケットを転送できます。
The algorithm described in this section accepts the following CRH fields as its input parameters:
このセクションで説明したアルゴリズムは、次のCRHフィールドを入力パラメーターとして受け入れます。
* Routing Type (i.e., CRH-16 or CRH-32)
* ルーティングタイプ（つまり、CRH-16またはCRH-32）
* Segments Left
* セグメントが残っています
It yields L, the minimum CRH length. The minimum CRH length is measured in 8-octet units, not including the first 8 octets.
L、最小CRHの長さを生成します。最小CRHの長さは、最初の8オクテットを含まない8オクテット単位で測定されます。
switch(Routing Type) {
case CRH-16:
if (Segments Left <= 2)
return(0)
sidsBeyondFirstWord = Segments Left - 2;
sidPerWord = 4;
case CRH-32:
if (Segments Left <= 1)
return(0)
sidsBeyondFirstWord = Segments Left - 1;
sidsPerWord = 2;
case default:
return(0xFF);
}
words = sidsBeyondFirstWord div sidsPerWord;
if (sidsBeyondFirstWord mod sidsPerWord)
words++;
return(words)
In the CRH, the Segments Left field is mutable. All remaining fields are immutable.
CRHでは、セグメントの左フィールドは可変です。残りのすべてのフィールドは不変です。
A CRH contains one or more CRH SIDs. Each CRH SID is processed by exactly one CRH-configured router whose one address matches the packet Destination Address.
CRHには1つ以上のCRH SIDが含まれています。各CRH SIDは、1つのアドレスがパケット宛先アドレスと一致する1つのCRH構成ルーターで処理されます。
Therefore, a CRH SID is not required to have domain-wide significance. Applications can allocate CRH SIDs so that they have either domain-wide or node-local significance.
したがって、CRH SIDはドメイン全体の重要性を持つ必要はありません。アプリケーションは、CRH SIDを割り当てることができ、ドメイン全体またはノードローカルの有意性を持つようにします。
PING and Traceroute [RFC2151] both operate correctly in the presence of the CRH. TCPDUMP and Wireshark have been extended to support the CRH.
pingとtraceroute [RFC2151]はどちらもCRHの存在下で正しく動作します。TCPDUMPとWiresharkは、CRHをサポートするために拡張されています。
PING and Traceroute report 16-bit CRH SIDs for CRH-16 and 32-bit CRH SIDs for CRH-32. It is recommended that the experimental versions of PING use the textual representations described in Section 9.
PingおよびTracerouteは、CRH-16およびCRH-32の32ビットCRH SIDの16ビットCRH SIDをレポートします。Pingの実験バージョンは、セクション9で説明したテキスト表現を使用することをお勧めします。
A 16-bit CRH SID can be represented by four lowercase hexadecimal digits. Leading zeros SHOULD be omitted. However, the all-zeros CRH SID MUST be represented by a single 0. The following are examples:
16ビットのCRH SIDは、4つの小文字六量体数字で表すことができます。主要なゼロは省略する必要があります。ただし、All-Zeros CRH SIDは単一の0で表現する必要があります。次の例は次のとおりです。
* beef
* 牛肉ビーフ怨声
* eef
* eef
* 0
* 0
A 16-bit CRH SID also can be represented in dotted-decimal notation. The following are examples:
16ビットのCRH SIDは、点線程度の表記で表現することもできます。以下は例です。
* 192.0
* 192.0
* 192.51
* 192.51
A 32-bit CRH SID can be represented by four lowercase hexadecimal digits, a colon (:), and another four lowercase hexadecimal digits. Leading zeros MUST be omitted. The following are examples:
32ビットのCRH SIDは、4つの小文字六足数字、コロン（:)、さらに4つの小文字六量体数字で表すことができます。主要なゼロを省略する必要があります。以下は例です。
* dead:beef
* 死：牛肉
* ead:eef
* EAD：EEF
* :beef
* ：牛肉
* beef:
* 牛肉：
* :
* ：
A 32-bit CRH SID can also be represented in dotted-decimal notation. The following are examples:
32ビットのCRH SIDは、点線式表記で表現することもできます。以下は例です。
* 192.0.2.1
* 192.0.2.1
* 192.0.2.2
* 192.0.2.2
* 192.0.2.3
* 192.0.2.3
In this document, one node trusts another only if both nodes are operated by the same party. A node determines whether it trusts another node by examining its IP address. In many networks, operators number their nodes using a small number of prefixes. This facilitates identification of trusted nodes.
このドキュメントでは、両方のノードが同じパーティによって操作されている場合にのみ、1つのノードが別のノードを信頼します。ノードは、IPアドレスを調べて別のノードを信頼するかどうかを判断します。多くのネットワークでは、オペレーターは少数のプレフィックスを使用してノードを番号にします。これにより、信頼できるノードの識別が容易になります。
A node can encounter security vulnerabilities when it processes a Routing header that originated on an untrusted node [RFC5095]. Therefore, nodes MUST deploy ACLs that discard packets containing the CRH when both of the following conditions are true:
ノードは、信頼されていないノード[RFC5095]で発生するルーティングヘッダーを処理すると、セキュリティの脆弱性に遭遇する可能性があります。したがって、次の両方の条件が真である場合、ノードはCRHを含むパケットを破棄するACLを展開する必要があります。
* The Source Address does not identify an interface on a trusted node.
* ソースアドレスは、信頼できるノード上のインターフェイスを識別しません。
* The Destination Address identifies an interface on the local node.
* 宛先アドレスは、ローカルノードのインターフェイスを識別します。
The above-mentioned ACLs do not protect the node from attack packets that contain a forged (i.e., spoofed) Source Address. In order to mitigate this risk, nodes MAY also discard packets containing the CRH when all of the following conditions are true:
上記のACLは、偽造された（つまり、スプーフィングされた）ソースアドレスを含む攻撃パケットからノードを保護しません。このリスクを軽減するために、次のすべての条件が真である場合、ノードはCRHを含むパケットを破棄する場合があります。
* The Source Address identifies an interface on a trusted node.
* ソースアドレスは、信頼できるノード上のインターフェイスを識別します。
* The Destination Address identifies an interface on the local node.
* 宛先アドレスは、ローカルノードのインターフェイスを識別します。
* The packet does not pass an Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704] check.
* このパケットは、強化された実行可能パスユニキャスト逆パス転送（EFP-URPF）[RFC8704]チェックを通過しません。
The EFP-uRPF check eliminates some, but not all, packets with forged Source Addresses. Therefore, a network operator that deploys CRH MUST implement ACLs on each of its edge nodes. The ACL discards packets whose Source Address identifies an interface on a trusted node.
EFP-URPFチェックは、すべてではないが、鍛造ソースアドレスを備えたパケットを排除します。したがって、CRHを展開するネットワークオペレーターは、各エッジノードにACLSを実装する必要があります。ACLは、ソースアドレスが信頼できるノード上のインターフェイスを識別するパケットを破棄します。
The CRH is compatible with end-to-end IPv6 Authentication Header (AH) [RFC4302] processing. This is because the source node calculates the Integrity Check Value (ICV) over the packet as it arrives at the destination node.
CRHは、エンドツーエンドのIPv6認証ヘッダー（AH）[RFC4302]処理と互換性があります。これは、ソースノードが宛先ノードに到着するときにパケットを介して整合性チェック値（ICV）を計算するためです。
Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:
この実験に参加している当事者は、この文書の公開から1年以内に実験結果を公開する必要があります。実験結果は次のとおりです。
* Effort required to deploy
* 展開するために必要な努力
- Was deployment incremental or network-wide?
- 展開は増加しましたか、それともネットワーク全体でしたか？
- Was there a need to synchronize configurations at each node, or could nodes be configured independently?
- 各ノードで構成を同期する必要がありましたか、それともノードを個別に構成できますか？
- Did the deployment require a hardware upgrade?
- 展開にはハードウェアのアップグレードが必要でしたか？
- Did the CRH SIDs have domain-wide or node-local significance?
- CRH SIDにはドメイン全体またはノードローカルの有意性がありましたか？
* Effort required to secure
* 確保するために必要な努力
* Performance impact
* パフォーマンスの影響
* Effectiveness of risk mitigation with ACLs
* ACLSによるリスク軽減の有効性
* Cost of risk mitigation with ACLs
* ACLSによるリスク軽減のコスト
* Mechanism used to populate the CRH-FIB
* CRH-FIBの設定に使用されるメカニズム
* Scale of deployment
* 展開の規模
* Interoperability
* 相互運用性
- Did you deploy two interoperable implementations?
- 相互運用可能な2つの実装を展開しましたか？
- Did you experience interoperability problems?
- 相互運用性の問題を経験しましたか？
- Did implementations generally implement the same topological functions with identical arguments?
- 実装は一般に、同じ引数を持つ同じトポロジー機能を実装しましたか？
- Were topological function semantics identical on each implementation?
- トポロジカル関数セマンティクスは各実装で同一でしたか？
* Effectiveness and sufficiency of Operations, Administration, and Maintenance (OAM) mechanisms
* 運用、管理、およびメンテナンス（OAM）メカニズムの有効性と十分性
- Did PING work?
- pingは機能しましたか？
- Did Traceroute work?
- Tracerouteは機能しましたか？
- Did Wireshark work?
- Wiresharkは機能しましたか？
- Did TCPDUMP work?
- tcpdumpは機能しましたか？
IANA has registered the following in the "Routing Types" subregistry within the "Internet Protocol Version 6 (IPv6) Parameters" registry:
IANAは、「インターネットプロトコルバージョン6（IPv6）パラメーター」レジストリ内で「ルーティングタイプ」サブレジストリで以下を登録しています。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 5 | CRH-16 | RFC 9631 |
+-------+-------------+-----------+
| 6 | CRH-32 | RFC 9631 |
+-------+-------------+-----------+
Table 1
[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>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[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>.
[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>.
[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>.
[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>.
[IANA-RT] IANA, "Routing Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[ISO10589-Second-Edition]
ISO/IEC, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/
IP Tools and Utilities", FYI 30, RFC 2151,
DOI 10.17487/RFC2151, June 1997,
<https://www.rfc-editor.org/info/rfc2151>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
This appendix demonstrates CRH processing in the following scenarios:
この付録は、次のシナリオでCRH処理を示しています。
* The CRH SID list contains one entry for each segment in the path (Appendix A.1).
* CRH SIDリストには、パス内の各セグメントの1つのエントリが含まれています（付録A.1）。
* The CRH SID list omits the first entry in the path (Appendix A.2).
* CRH SIDリストは、パスの最初のエントリを省略します（付録A.2）。
Figure 3 provides a reference topology that is used in all examples, and Table 2 describes two entries that appear in each node's CRH-FIB.
図3に、すべての例で使用される参照トポロジーを示し、表2に各ノードのCRH-FIBに表示される2つのエントリについて説明します。
----------- ----------- -----------
|Node: S | |Node: I1 | |Node: I2 |
|Loopback: |---------------|Loopback: |---------------|Loopback: |
|2001:db8::a| |2001:db8::1| |2001:db8::2|
----------- ----------- -----------
| |
| ----------- |
| |Node: D | |
---------------------|Loopback: |---------------------
|2001:db8::b|
-----------
Figure 3: Reference Topology
図3：参照トポロジ
+=====+==============+===================+
| SID | IPv6 Address | Forwarding Method |
+=====+==============+===================+
| 2 | 2001:db8::2 | Least-cost path |
+-----+--------------+-------------------+
| 11 | 2001:db8::b | Least-cost path |
+-----+--------------+-------------------+
Table 2: Node SIDs
表2：ノードSIDS
In this example, Node S sends a packet to Node D via I2, and I2 appears in the CRH segment list.
この例では、ノードSはI2を介してノードDにパケットを送信し、I2はCRHセグメントリストに表示されます。
+-----------------------------------+-------------------+
| Source Address = 2001:db8::a | Segments Left = 1 |
+-----------------------------------+-------------------+
| Destination Address = 2001:db8::2 | SID[0] = 11 |
+-----------------------------------+-------------------+
| | SID[1] = 2 |
+-----------------------------------+-------------------+
Table 3: Packet Travels from S to I2
表3：パケットはSからi2へと移動します
+-----------------------------------+-------------------+
| Source Address = 2001:db8::a | Segments Left = 0 |
+-----------------------------------+-------------------+
| Destination Address = 2001:db8::b | SID[0] = 11 |
+-----------------------------------+-------------------+
| | SID[1] = 2 |
+-----------------------------------+-------------------+
Table 4: Packet Travels from I2 to D
表4：パケットはi2からdへの移動です
In this example, Node S sends a packet to Node D via I2, and I2 does not appear in the CRH segment list.
この例では、ノードSはI2を介してノードDにパケットを送信し、I2はCRHセグメントリストには表示されません。
+-----------------------------------+-------------------+
| Source Address = 2001:db8::a | Segments Left = 1 |
+-----------------------------------+-------------------+
| Destination Address = 2001:db8::2 | SID[0] = 11 |
+-----------------------------------+-------------------+
Table 5: Packet Travels from S to I2
表5：パケットはSからi2へと移動します
+-----------------------------------+-------------------+
| Source Address = 2001:db8::a | Segments Left = 0 |
+-----------------------------------+-------------------+
| Destination Address = 2001:db8::b | SID[0] = 11 |
+-----------------------------------+-------------------+
Table 6: Packet Travels from I2 to D
表6：パケットはi2からdへの移動です
Thanks to Dr. Vanessa Ameen, Dale Carder, Brian Carpenter, Adrian Farrel, Fernando Gont, Joel Halpern, Naveen Kottapalli, Tony Li, Xing Li, Gerald Schmidt, Nancy Shaw, Mark Smith, Ketan Talaulikar, Reji Thomas, and Chandra Venkatraman for their contributions to this document.
ヴァネッサ・アミーン博士、デール・カーダー、ブライアン・カーペンター、エイドリアン・ファレル、フェルナンド・ゴント、ジョエル・ハルパーン、ナビーン・コッタパリ、トニー・リー、シン・リー、ジェラルド・シュミット、ナンシー・ショー、マーク・スミス、ケタン・タラウリカー、レジ・トーマス、チャンドラ・ベニ・ベニ・ベニ・ベニ・ベニ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベネ・ベニスのおかげでこの文書への貢献。
Gang Chen
Baidu
No.10 Xibeiwang East Road
Haidian District
Beijing
100193
China
Email: phdgang@gmail.com
Yifeng Zhou
ByteDance
Building 1, AVIC Plaza
43 N 3rd Ring W Rd
Haidian District
Beijing
100000
China
Email: yifeng.zhou@bytedance.com
Gyan Mishra
Verizon
Silver Spring, MD
United States of America
Email: hayabusagsm@gmail.com
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
United States of America
Email: rbonica@juniper.net
Yuji Kamite
NTT Communications Corporation
3-4-1 Shibaura, Minato-ku, Tokyo
108-8118
Japan
Email: y.kamite@ntt.com
Andrew Alston
Alston Networks
Nairobi
Kenya
Email: aa@alstonnetworks.net
Daniam Henriques
Liquid Telecom
Johannesburg
South Africa
Email: daniam.henriques@liquidtelecom.com
Luay Jalil
Verizon
Richardson, TX
United States of America
Email: luay.jalil@one.verizon.com