[要約] RFC 8883は、IPv6ネットワークでのパケット処理制限による破棄エラーを通知するためのICMPv6エラーメッセージを定義しています。このRFCの目的は、ネットワークデバイスが処理制限に達した場合に、適切なエラー通知を提供することです。
Internet Engineering Task Force (IETF) T. Herbert
Request for Comments: 8883 Intel
Category: Standards Track September 2020
ISSN: 2070-1721
ICMPv6 Errors for Discarding Packets Due to Processing Limits
ICMPv6処理制限によるパケットを破棄するためのエラー
Abstract
概要
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.
ネットワークノードは、処理の制約または制限のためにパケットのプロトコルヘッダを処理できない場合、パケットを破棄することがあります。そのようなパケットがドロップされると、送信者は表示されないので、廃棄されたパケットの原因に対処するための処置をとることができません。この仕様は、プロトコルヘッダを処理できないため、パケットを破棄するノードによって送信できるいくつかの新しいICMPv6エラーを定義します。そのようなICMPv6エラーを受信するノードは、その情報を使用してパケット損失を診断し、それが後続のパケット破棄を回避するために将来のパケットで送信するものを変更することができる。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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/rfc8883.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8883で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Extension Header Limits
1.2. Aggregate Header Limits
1.3. Nonconformant Packet Discard
1.4. Terminology
2. ICMPv6 Errors for Extension Header Limits
2.1. Format
2.2. Unrecognized Next Header Type Encountered by Intermediate
Node (Code 5)
2.3. Extension Header Too Big (Code 6)
2.4. Extension Header Chain Too Long (Code 7)
2.5. Too Many Extension Headers (Code 8)
2.6. Too Many Options in Extension Header (Code 9)
2.7. Option Too Big (Code 10)
3. ICMPv6 Error for Aggregate Header Limits
3.1. Format
3.2. Usage
4. Operation
4.1. Priority of Reporting
4.2. Host Response
5. Applicability and Use Cases
5.1. Reliability of ICMP
5.2. Processing Limits
5.2.1. Long Headers and Header Chains
5.2.2. At End Hosts
5.2.3. At Intermediate Nodes
6. Security Considerations
7. IANA Considerations
7.1. Parameter Problem Codes
7.2. Destination Unreachable Codes
7.3. ICMP Extension Object Classes and Class Sub-types
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Author's Address
This document specifies several new ICMPv6 errors that can be sent when a node discards a packet due to it being unable to process the necessary protocol headers because of processing constraints or limits. New ICMPv6 code points are defined to supplement those defined in [RFC4443]. Six of the errors are specific to the processing of extension headers; another error is used when the aggregate protocol headers in a packet exceed the processing limits of a node.
このドキュメントは、ノードが必要なプロトコルヘッダーを処理できないためにノードがパケットを破棄したときに送信できるいくつかの新しいICMPv6エラーを指定します。新しいICMPv6コードポイントは、[RFC4443]で定義されているものを補足するように定義されています。6つのエラーは、拡張ヘッダーの処理に固有のものです。パケット内の集約プロトコルヘッダがノードの処理限界を超えると、別のエラーが使用されます。
In IPv6, optional internet-layer information is carried in one or more IPv6 extension headers [RFC8200]. Extension headers are placed between the IPv6 header and the upper-layer header in a packet. The term "header chain" refers collectively to the IPv6 header, extension headers, and upper-layer headers occurring in a packet. Individual extension headers may have a maximum length of 2048 octets and must fit into a single packet. Destination Options and Hop-by-Hop Options contain a list of options in type-length-value (TLV) format. Each option includes a length of the data field in octets: the minimum size of an option (non-pad type) is two octets, and the maximum size is 257 octets. The number of options in an extension header is only limited by the length of the extension header and the Path MTU from the source to the destination. Options may be skipped over by a receiver if they are unknown and the Option Type indicates to skip (first two high order bits are 00).
IPv6では、1つ以上のIPv6拡張ヘッダー[RFC8200]でオプションのインターネットレイヤー情報が搭載されています。拡張ヘッダーは、パケット内のIPv6ヘッダーと上位層のヘッダーの間に配置されます。「ヘッダチェーン」という用語は、パケット内で発生するIPv6ヘッダ、拡張ヘッダ、および上位レイヤヘッダをまとめて参照する。個々の拡張ヘッダーは最大長2048オクテットを持ち、単一のパケットに収まらなければなりません。宛先オプションとホップバイホップオプションには、type-length-value（TLV）形式のオプションのリストが含まれています。各オプションには、オクテットのデータフィールドの長さが含まれています。オプションの最小サイズ（非パッドタイプ）は2オクテットで、最大サイズは257オクテットです。拡張ヘッダ内のオプション数は、拡張ヘッダの長さと送信元から宛先へのパスMTUによってのみ制限されます。オプションは、未知であり、オプションタイプがスキップを示す（最初の2つの上位ビットが00の00）。
Per [RFC8200], except for Hop-by-Hop Options, extension headers are not examined or processed by intermediate nodes. However, in deployed networks, many intermediate nodes do examine extension headers for various purposes. For instance, a node may examine all extension headers to locate the transport header of a packet in order to implement transport-layer filtering or to track connections to implement a stateful firewall.
ホップごとのオプションを除いて、エクステンションヘッダーは中間ノードによって調べられたり処理されたりされません[RFC8200]ごとに[RFC8200]。ただし、展開されたネットワークでは、さまざまな中間ノードはさまざまな目的のために拡張ヘッダーを調べます。例えば、ノードは、トランスポート層フィルタリングを実装するために、またはステートフルファイアウォールを実装するための接続を追跡するために、すべての拡張ヘッダを調べてパケットのトランスポートヘッダを見つけることができる。
Destination hosts are expected to process all extension headers and options in Hop-by-Hop and Destination Options.
宛先ホストは、ホップバイホップおよび宛先オプションですべての拡張ヘッダーとオプションを処理することが期待されています。
Due to the variable lengths, high maximum lengths, or potential for a denial-of-service attack of extension headers, many devices impose operational limits on extension headers in packets they process. [RFC7045] discusses the requirements of intermediate nodes that discard packets because of unrecognized extension headers. [RFC8504] discusses limits that may be applied to the number of options in Hop-by-Hop Options or Destination Options extension headers. Both intermediate nodes and end hosts may apply limits to extension header processing. When a limit is exceeded, the typical behavior is to silently discard the packet.
拡張ヘッダーの可変長、最大長さ、またはサービス拒否攻撃の可能性のために、多くのデバイスはプロセスするパケット内の拡張ヘッダーに動作制限を課します。[RFC7045]認識されていない拡張ヘッダーのためにパケットを破棄する中間ノードの要件について説明します。[RFC8504]ホップバイホップオプションまたは宛先オプション拡張ヘッダーのオプション数に適用できる制限について説明します。中間ノードとエンドホストの両方が拡張ヘッダ処理に制限を適用することができる。制限を超えると、典型的な動作はパケットを静かに破棄することです。
This specification defines six Parameter Problem codes that may be sent by a node that discards a packet due to the processing limits of extension headers being exceeded. The information in these ICMPv6 errors may be used for diagnostics to determine why packets are being dropped. Additionally, a source node that receives these ICMPv6 errors may be able to modify its use of extension headers in subsequent packets sent to the destination in order to avoid further occurrences of packets being discarded.
この仕様は、拡張ヘッダの処理制限が超えているためにパケットを破棄するノードによって送信され得る6つのパラメータ問題コードを定義する。これらのICMPv6エラーの情報を診断に使用して、パケットがドロップされている理由を判断できます。さらに、これらのICMPv6エラーを受信するソースノードは、廃棄されているパケットのさらなる発生を回避するために、宛先に送信された後続のパケット内の拡張ヘッダのその使用を変更することができます。
Some hardware devices implement a parsing buffer of a fixed size to process packets. The parsing buffer is expected to contain all the headers (often up to a transport-layer header for filtering) that a device needs to examine. If the aggregate length of headers in a packet exceeds the size of the parsing buffer, a device will either discard the packet or defer processing to a software slow path. In any case, no indication of a problem is sent back to the sender.
一部のハードウェアデバイスは、パケットを処理するための固定サイズの解析バッファを実装します。解析バッファは、デバイスが調べる必要があるすべてのヘッダー（しばしばフィルタリング用のトランスポート層ヘッダー）を含むと予想されます。パケット内のヘッダの集約長さが解析バッファのサイズを超えると、デバイスはパケットまたはソフトウェアの遅いパスへの遅延処理を破棄する。いずれにせよ、問題の表示は送信者に返送されません。
This document defines one code for ICMPv6 Destination Unreachable that is sent by a node that is unable to process the headers of a packet due to the aggregate size of the packet headers exceeding a processing limit. The information in this ICMPv6 error may be used for diagnostics to determine why packets are being dropped. Additionally, a source node that receives this ICMPv6 error may be able to modify the headers used in subsequent packets to try to avoid further occurrences of packets being discarded.
このドキュメントでは、パケットヘッダーの総サイズが処理限界を超えるため、パケットのヘッダーを処理できないノードによって送信されるICMPv6宛先の到達不能の1コードを定義します。このICMPv6エラーの情報は、パケットが削除されている理由を判断するために診断に使用されることがあります。さらに、このICMPv6エラーを受信するソースノードは、後続のパケットで使用されるヘッダーを変更して、パケットのさらなる発生を妨げることを試みることができます。
The ICMP errors defined in this specification may be applicable to scenarios in which a node is dropping packets outside the auspices of any standard specification. For instance, an intermediate node might send a "Headers too long" code in a case where it drops a packet because it is unable to parse deeply enough to extract the transport-layer information needed for packet filtering. Such behavior might be considered nonconformant (with respect to [RFC8200], for instance).
この仕様で定義されているICMPエラーは、ノードが任意の標準仕様の推論外にパケットをドロップしているシナリオに適用できます。たとえば、パケットフィルタリングに必要なトランスポート層情報を抽出するのに十分深く解析できないため、中間ノードはパケットを削除できない場合に「ヘッダーが長すぎる」コードを送信することがあります。そのような動作は、（例えば、RFC8200]に関して）不適合であると見なされ得る。
This specification does not advocate behaviors that might be considered nonconformant. However, packet discard does occur in real deployments, and the intent of this specification is to provide visibility as to why packets are being discarded. In the spirit that providing some reason is better than a silent drop, the sending of ICMP errors is RECOMMENDED even in cases where a node might be discarding packets per a nonconformant behavior.
この仕様は、不適合であると見なされる可能性がある行動を支持していません。ただし、パケット破棄は実際の展開で発生し、この仕様の意図は、パケットが破棄されている理由についての可視性を提供することです。何らかの理由を提供する精神では、サイレントドロップよりも優れているという精神では、ノードが不適合な動作でパケットを破棄している可能性がある場合でも、ICMPエラーの送信をお勧めします。
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」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
Six new codes are defined for the Parameter Problem type.
パラメータ問題タイプに対して6つの新しいコードが定義されています。
The format of the ICMPv6 Parameter Problem message [RFC4443] for an extension header limit exceeded error is:
拡張ヘッダーの制限が超過エラーの場合は、ICMPv6パラメータの問題メッセージ[RFC4443]のフォーマットは次のとおりです。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| As much of the invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC8200] |
IPv6 Header Fields: Destination Address: Copied from the Source Address field of the invoking packet.
IPv6ヘッダーフィールド：宛先アドレス：呼び出しパケットの送信元アドレスフィールドからコピーされます。
ICMPv6 Fields: Type: 4 (Parameter Problem type)
ICMPv6フィールド：タイプ：4（パラメータ問題タイプ）
Code: (pertinent to this specification)
コード:(この仕様に関連）
+----+----------------------------------+
| 5 | Unrecognized Next Header type |
| | encountered by intermediate node |
+----+----------------------------------+
| 6 | Extension header too big |
+----+----------------------------------+
| 7 | Extension header chain too long |
+----+----------------------------------+
| 8 | Too many extension headers |
+----+----------------------------------+
| 9 | Too many options in extension |
| | header |
+----+----------------------------------+
| 10 | Option too big |
+----+----------------------------------+
Table 1
表1
Pointer: Identifies the octet offset within the invoking packet where the problem occurred.
ポインタ：問題が発生した呼び出しパケット内のオクテットオフセットを識別します。
The pointer will point beyond the end of the IPv6 packet if the field exceeding the limit is beyond what can fit in the maximum size of an ICMPv6 error message. If the pointer is used as an offset to read the data in the invoking packet, then a node MUST first validate that the pointer value is less than the length of the invoking packet data.
制限を超えるフィールドがICMPv6エラーメッセージの最大サイズに適合できるものを超える場合、ポインタはIPv6パケットの終わりを超えて表示されます。ポインタが呼び出しパケット内のデータを読み取るためのオフセットとして使用される場合、ノードは最初にポインタ値が呼び出しパケットデータの長さよりも小さいことを検証する必要があります。
2.2. Unrecognized Next Header Type Encountered by Intermediate Node (Code 5)
2.2. 中間ノードで発生した認識されていない次のヘッダータイプ（コード5）
This code SHOULD be sent by an intermediate node that discards a packet because it encounters a Next Header type that is unknown in its examination. The ICMPv6 Pointer field is set to the offset of the unrecognized Next Header value within the original packet.
このコードは、検査中に不明な次のヘッダータイプに遭遇するため、パケットを破棄する中間ノードによって送信されるべきです。ICMPv6ポインタフィールドは、元のパケット内の認識されていない次のヘッダー値のオフセットに設定されます。
Note that this code is sent by intermediate nodes and SHOULD NOT be sent by a final destination. If a final destination node observes an unrecognized header, then it SHOULD send an ICMP Parameter Problem message with an ICMP Code value of 1 ("unrecognized Next Header type encountered") as specified in [RFC8200].
このコードは中間ノードによって送信され、最終的な宛先によって送信されるべきではありません。最終宛先ノードが認識されないヘッダーを監視する場合は、[RFC8200]で指定されているICMPコード値1（「未認識次のヘッダータイプ」）を含むICMPパラメータ問題メッセージを送信する必要があります。
An ICMPv6 Parameter Problem with code for "Extension header too big" SHOULD be sent when a node discards a packet because the size of an extension header exceeds its processing limit. The ICMPv6 Pointer field is set to the offset of the first octet in the extension header that exceeds the limit.
拡張ヘッダーのサイズがその処理制限を超えるため、ノードがパケットを破棄すると、「拡張ヘッダーの大きすぎる」というコードを備えたICMPv6パラメーターの問題がある場合に送信されます。ICMPv6ポインタフィールドは、制限を超える拡張ヘッダーの最初のオクテットのオフセットに設定されます。
An ICMPv6 Parameter Problem with code for "Extension header chain too long" SHOULD be sent when a node discards a packet with an extension header chain that exceeds a limit on the total size in octets of the header chain. The ICMPv6 Pointer is set to the first octet beyond the limit.
ノードが、ヘッダーチェーンのオクテットでの合計サイズの制限を超える拡張ヘッダーチェーンを持つパケットをディスカッションすると、ノードが拡張ヘッダーチェーンを持つパケットを破棄すると送信されるはずです。ICMPv6ポインタは、制限を超えた最初のオクテットに設定されます。
An ICMPv6 Parameter Problem with code for "Too many extension headers" SHOULD be sent when a node discards a packet with an extension header chain that exceeds a limit on the number of extension headers in the chain. The ICMPv6 Pointer is set to the offset of the first octet of the first extension header that is beyond the limit.
ノードがチェーン内の拡張ヘッダーの数の制限を超える拡張ヘッダーチェーンを使用して、ノードが拡張ヘッダーチェーンを持つパケットを破棄するときには、コードを送信する必要があります。ICMPv6ポインタは、制限を超えている最初の拡張ヘッダーの最初のオクテットのオフセットに設定されます。
An ICMPv6 Parameter Problem with code for "Too many options in extension header" SHOULD be sent when a node discards a packet with an extension header that has a number of options that exceeds the processing limits of the node. This code is applicable for Destination Options and Hop-by-Hop Options. The ICMPv6 Pointer field is set to the first octet of the first option that exceeds the limit.
ノードが、ノードの処理制限を超えるオプションを超えるオプションを持つ、ノードが拡張ヘッダーを持つパケットを破棄すると、Extension Headerがパケットを破棄すると送信される必要があります。このコードは、宛先オプションとホップごとのオプションに適用されます。ICMPv6ポインタフィールドは、制限を超える最初のオプションの最初のオクテットに設定されています。
An ICMPv6 Parameter Problem with code for "Option too big" is sent in two different cases: when the length of an individual Hop-by-Hop or Destination Option exceeds a limit, or when the length or number of consecutive Hop-by-Hop or Destination padding options exceeds a limit. In a case where the length of an option exceeds a processing limit, the ICMPv6 Pointer field is set to the offset of the first octet of the option that exceeds the limit. In cases where the length or number of padding options exceeds a limit, the ICMPv6 Pointer field is set to the offset of the first octet of the padding option that exceeds the limit.
「オプションが大きすぎる」のコードに関するICMPv6パラメータの問題は、2つの異なるケースで送信されます。個々のホップバイホップまたは宛先オプションの長さが制限を超えると、または連続したホップごとのホップの長さまたは数または宛先のパディングオプションが制限を超えています。オプションの長さが処理限界を超える場合、ICMPv6ポインタフィールドは、制限を超えるオプションの最初のオクテットのオフセットに設定されます。パディングオプションの長さまたは数が制限を超える場合、ICMPv6ポインタフィールドは、制限を超えるパディングオプションの最初のオクテットのオフセットに設定されます。
Possible limits related to padding include:
パディングに関連する可能性のある制限は次のとおりです。
* The number of consecutive PAD1 options in Destination Options or Hop-by-Hop Options is limited to seven octets [RFC8504].
* 宛先オプションまたはホップバイホップオプションの連続したPAD1オプションの数は、7オクテット[RFC8504]に制限されています。
* The length of PADN options in Destination Options or Hop-by-Hop Options is limited seven octets [RFC8504].
* 宛先オプションまたはホップバイホップオプションのPADNオプションの長さは、7オクテット[RFC8504]が制限されています。
* The aggregate length of a set of consecutive PAD1 or PADN options in Destination Options or Hop-by-Hop Options is limited to seven octets.
* 宛先オプションまたはホップバイホップオプションの一連の連続したPAD1またはPADNオプションの集計長は7オクテットに制限されています。
One code is defined for the Destination Unreachable type for aggregate header limits.
集約ヘッダー制限の宛先unreachable型に1つのコードが定義されています。
This ICMP error may be applied to other headers in a packet than just the IPv6 header or IPv6 extension headers. Therefore, a Destination Unreachable type with a multi-part ICMPv6 message format is used in lieu of the Parameter Problem type, which only indicates errors concerning IPv6 headers.
このICMPエラーは、IPv6ヘッダーまたはIPv6拡張ヘッダーだけでは、パケット内の他のヘッダーに適用できます。したがって、パラメータ問題タイプの代わりに、マルチパートICMPv6メッセージフォーマットを備えた宛先到達不能タイプが使用されます。これは、IPv6ヘッダーに関するエラーのみを示します。
The error for aggregate header limits employs a multi-part ICMPv6 message format as defined in [RFC4884]. The extension object class "Extended Information" is defined to contain objects for ancillary information pertaining to an ICMP Destination Unreachable error. Within this object class, the sub-type "Pointer" is defined, which contains a Pointer field with similar semantics to the Pointer field in ICMP Parameter Problem errors.
集約ヘッダ制限のエラーは、[RFC4884]で定義されているようにマルチパートICMPv6メッセージフォーマットを採用しています。拡張オブジェクトクラス「拡張情報」は、ICMP宛先到達不能エラーに関する付随情報用のオブジェクトを含むように定義されています。このオブジェクトクラス内では、副型の「ポインタ」が定義されており、これにはICMPパラメータ問題エラーの「ポインタ」フィールドに同じ意味を持つポインタフィールドが含まれています。
The format of the ICMPv6 message for an aggregate header limit exceeded is:
集約ヘッダー制限を超えたICMPv6メッセージの形式は次のとおりです。
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 | Code | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Length | Unused | C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
| | P
~ As much of the invoking packet ~
| as possible without the ICMPv6 packet |
| exceeding the minimum IPv6 MTU [RFC8200] |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
|Version| Reserved | Checksum |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
| Length | Class-Num | C-Type | X
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Pointer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
IPv6 Header Fields: Destination Address: Copied from the Source Address field of the invoking packet.
IPv6ヘッダーフィールド：宛先アドレス：呼び出しパケットの送信元アドレスフィールドからコピーされます。
ICMPv6 Fields: Type: 1 - Destination Unreachable
ICMPv6フィールド：タイプ：1 - 送信先到達不能
Code: (pertinent to this specification) 8 - Headers too long
コード:(この仕様に関連）8 - ヘッダーが長すぎる
Length: Length of the padded invoking packet data measured in 64-bit words. The ICMP extension structure immediately follows the padded invoking packet data.
長さ：64ビットワードで測定されたパッド化パケットデータの長さ。ICMP拡張構造は、パディングされたパケットデータの直後に続きます。
Invoking Packet: Contains as much of the invoking packet as possible without the ICMPv6 packet exceeding the minimum IPv6 MTU. The invoking packet data MUST be zero padded to the nearest 64-bit boundary [RFC4884]. If the original invoking packet did not contain 128 octets, the invoking packet data MUST be zero padded to 128 octets.
パケットの呼び出し：ICMPv6パケットが最小IPv6 MTUを超えることなく、できるだけ多くの呼び出しパケットを含みます。呼び出しパケットデータは、最も近い64ビット境界[RFC4884]にゼロパッドされている必要があります。元の呼び出しパケットに128オクテットが含まれていない場合、呼び出しパケットデータは128オクテットにゼロ埋められている必要があります。
ICMP Extension Fields: Version: 2 - per [RFC4884]
ICMP拡張フィールド：バージョン：2 - [RFC4884]
Reserved: 0
予約済み：0
Checksum: The one's complement checksum of the ICMP extension [RFC4884]
チェックサム：ICMP拡張の相補的チェックサム[RFC4884]
Length: 8 - length of the object header and Pointer field
長さ：8 - オブジェクトヘッダーとポインタフィールドの長さ
Class-Num: 4 - Extended Information
クラス番号：4 - 拡張情報
C-Type: 1 - Pointer
C型：1 - ポインタ
Pointer: Identifies the octet offset within the invoking packet where a limit was exceeded.
ポインタ：制限を超えた呼び出しパケット内のオクテットオフセットを識別します。
The pointer will point beyond the end of the invoking packet data if the field exceeding the limit is beyond what can fit in the maximum size of an ICMPv6 error message with the ICMP extension. If the pointer is used as an offset to read the data in the invoking packet, then a node MUST first validate that the pointer value is less than the length of the invoking packet data.
制限を超えるフィールドがICMP拡張子を持つICMPv6エラーメッセージの最大サイズに適合できるものを超える場合、ポインタは呼び出しパケットデータの終了を超えて表示されます。ポインタが呼び出しパケット内のデータを読み取るためのオフセットとして使用される場合、ノードは最初にポインタ値が呼び出しパケットデータの長さよりも小さいことを検証する必要があります。
An ICMPv6 Destination Unreachable error with code for "Headers too long" SHOULD be sent when a node discards a packet because the aggregate length of the headers in the packet exceeds the processing limits of the node. The Pointer in the extended ICMPv6 structure is set to the offset of the first octet that exceeds the limit.
パケット内のヘッダーの集約長はノードの処理制限を超えるため、ノードがパケットを破棄するときには、「ヘッダーに長すぎる」というICMPv6の宛先到達不能エラーが送信されるはずです。拡張ICMPv6構造内のポインタは、制限を超える最初のオクテットのオフセットに設定されています。
This error is sent in response to a node dropping a packet because the aggregate header chain exceeds the processing limits of a node. The aggregate header chain may be composed of protocol headers other than an IPv6 header and IPv6 extension headers. For instance, in the case of a node parsing a UDP encapsulation protocol, the encapsulating UDP header would be considered to be in the aggregate header chain.
このエラーは、アグリゲートヘッダチェーンがノードの処理限界を超えるため、パケットをドロップするノードに応答して送信されます。集約ヘッダチェーンは、IPv6ヘッダおよびIPv6拡張ヘッダ以外のプロトコルヘッダから構成されていてもよい。たとえば、UDPカプセル化プロトコルを解析するノードの場合、カプセル化UDPヘッダーは集約ヘッダーチェーンにあると見なされます。
As noted in Section 4.1, the ICMPv6 Destination Unreachable error with code for "Headers too long" has the lowest precedence of the ICMP errors discussed in this specification. If a packet contains an error corresponding to a Parameter Problem code, then a node SHOULD send the Parameter Problem error instead of sending the ICMPv6 Destination Unreachable error with code for "Headers too long".
セクション4.1で説明されているように、「ヘッダーが長くても長すぎる」というコードを持つICMPv6の宛先到達不能エラーは、この仕様で説明したICMPエラーの優先順位を持ちます。パケットにパラメータの問題コードに対応するエラーが含まれている場合、ノードはICMPv6宛先到達不能エラーを「ヘッダに長すぎる」のコードでパラメータ問題エラーを送信する必要があります。
Nodes that send or receive ICMPv6 errors due to header processing limits MUST comply with ICMPv6 processing as specified in [RFC4443].
ヘッダー処理の制限によりICMPv6エラーを送受信するノードは、[RFC4443]で指定されているようにICMPv6処理に準拠している必要があります。
More than one ICMPv6 error may be applicable to report for a packet. For instance, the number of extension headers in a packet might exceed a limit, and the aggregate length of protocol headers might also exceed a limit. Only one ICMPv6 error SHOULD be sent for a packet, so a priority is defined to determine which error to report.
パケットのレポートには、複数のICMPv6エラーが適用可能です。たとえば、パケット内の拡張ヘッダーの数が制限を超える可能性があり、プロトコルヘッダーの集計長さも制限を超える可能性があります。パケットについては1つのICMPv6エラーのみを送信する必要があるため、レポートするエラーを判断するために優先順位が定義されます。
The RECOMMENDED reporting priority of ICMPv6 errors for processing limits is listed from highest to lowest priority:
処理制限に対するICMPv6エラーの推奨レポート優先順位は、最高から最小の優先順位までリストされています。
1. Existing ICMP errors defined in [RFC4443].
1. [RFC4443]で定義されている既存のICMPエラー。
2. "Unrecognized Next Header type encountered by intermediate node"
2. 「中間ノードによって発生した認識されていない次のヘッダータイプ」
3. "Extension header too big"
3. "拡張ヘッダーが大きすぎる"
4. "Option too big" for length or number of consecutive padding options exceeding a limit.
4. 長さを超える連続したパディングオプションの長さや数は、「オプションが大きすぎる」。
5. "Option too big" for the length of an option exceeding a limit.
5. 「オプションが大きすぎる」オプションを超えているオプションの長さについて。
6. "Too many options in an extension header"
6. "拡張ヘッダーのオプションが多すぎる"
7. "Extension header chain too long" headers exceeding a limit.
7. 「拡張ヘッダチェーンが長すぎる」ヘッダが制限を超えています。
8. "Too many extension headers"
8. 「拡張ヘッダが多すぎる」
9. "Headers too long"
9. 「ヘッダーが長すぎる」
When a source host receives an ICMPv6 error for a processing limit being exceeded, it SHOULD verify the ICMPv6 error is valid and take appropriate action as suggested below.
ソースホストが処理制限を超えているためにICMPv6エラーを受信すると、ICMPv6エラーが有効であることを確認し、以下に提案されているように適切な行動を取ります。
The general validations for ICMP as described in [RFC4443] are applicable. The packet in the ICMP data SHOULD be validated to match the upper-layer process or connection that generated the original packet. Other validation checks that are specific to the upper layers may be performed and are out of the scope of this specification.
[RFC4443]に記載されているICMPの一般的な検証は適用されます。ICMPデータのパケットは、元のパケットを生成した上位層プロセスまたは接続と一致するように検証されます。上位層に固有の他の検証チェックは実行されてもよく、この仕様の範囲外である。
The ICMPv6 error SHOULD be logged with sufficient detail for debugging packet loss. The details of the error, including the addresses and the offending extension header or data, should be retained. This, for instance, would be useful for debugging when a node is misconfigured and unexpectedly discarding packets or when a new extension header is being deployed.
パケット損失をデバッグするために、ICMPv6エラーを十分な詳細で記録する必要があります。アドレスと問題のある拡張ヘッダやデータを含むエラーの詳細は保持されるべきです。これは、例えば、ノードが誤って構成され、予期せぬパケットを破棄したとき、または新しい拡張ヘッダがデプロイされているときにデバッグするのに役立ちます。
A host MAY modify its usage of protocol headers in subsequent packets to avoid repeated occurrences of the same error.
ホストは、同じエラーの繰り返し発生を回避するために、後続のパケット内のプロトコルヘッダの使用を変更することができる。
For ICMPv6 errors caused by extension header limits being exceeded:
拡張ヘッダーの制限が超えているICMPv6エラーの場合：
* An error SHOULD be reported to an application if the application enabled extension headers for its traffic. In response, the application may terminate communications if extension headers are required, stop using extension headers in packets to the destination indicated by the ICMPv6 error, or attempt to modify its use of headers or extension headers to avoid further packet discards.
* アプリケーションがそのトラフィックの拡張ヘッダーを有効にした場合、エラーはアプリケーションに報告されるべきです。それに応答して、アプリケーションは、拡張ヘッダーが必要な場合は通信を終了し、ICMPv6エラーによって示された宛先への拡張ヘッダーを使用するのを停止するか、またはさらにパケットを破棄するためにヘッダーまたは拡張ヘッダーの使用を変更しようとします。
* A host system SHOULD take appropriate action if it is creating packets with extension headers on behalf of the application. If the offending extension header is not required for communication, the host may either stop sending it or otherwise modify its use in subsequent packets sent to the destination indicated in the ICMPv6 error.
* アプリケーションに代わって拡張ヘッダーを持つパケットを作成している場合、ホストシステムは適切な処置をとるべきです。問題のある拡張ヘッダが通信に必要ない場合、ホストはICMPv6エラーに示されている宛先に送信された後続のパケットでその使用を停止するか、その他の方法でその使用を変更することができます。
ICMP is fundamentally an unreliable protocol and, in real deployment, it may consistently fail over some paths. As with any other use of ICMP, it is assumed that the errors defined in this document are only the best effort to be delivered. No protocol should be implemented that relies on reliable delivery of ICMP messages. If necessary, alternative or additional mechanisms may be employed to augment the processes used to deduce the reason that packets are being discarded. For instance, ICMP error messages may be correlated with information attained through Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] or Happy Eyeballs for IPv6 [RFC8305]. Details of the interaction with alternative mechanisms are out of scope of this specification.
ICMPは基本的に信頼性の低いプロトコルであり、実際の展開では、一貫してあるパスを損なう可能性があります。ICMPの他の使用と同様に、この文書で定義されているエラーは配信される最善の努力のみであると仮定されています。ICMPメッセージの信頼できる配信に依存するプロトコルは実装されていません。必要に応じて、パケットが破棄されている理由を推定するために使用されるプロセスを増大させるために代替または追加のメカニズムを使用することができる。例えば、ICMPエラーメッセージは、Packetization Layer Path MTU Discovery（PLPMTUD）[RFC4821]またはIPv6 [RFC8305]のための幸せな眼球を通じて達成された情報と相関させることができる。代替メカニズムとの相互作用の詳細はこの仕様の範囲外です。
This section discusses the trends and motivations of processing limits that warrant ICMP errors.
このセクションでは、ICMPエラーを保証する処理制限のトレンドと動機について説明します。
The trend towards longer and more complex headers and header chains needing to be processed by end nodes, as well as intermediate nodes, is driven by:
エンドノード、および中間ノードによって処理される必要があるより長くてより複雑なヘッダーおよびヘッダーチェーンへの傾向は、次のように駆動されます。
* Increasing prevalence of deep packet inspection in middleboxes. In particular, many intermediate nodes now parse network-layer encapsulation protocols or transport-layer protocols.
* ミドルボックスでのディープパケット検査の有病率を高める特に、多くの中間ノードは、ネットワーク層のカプセル化プロトコルまたはトランスポート層プロトコルを解析するようになりました。
* Deployment of routing headers. For instance, [RFC8754] defines an extension header format that includes a list of IPv6 addresses which may consume a considerable number of bytes.
* ルーティングヘッダーの展開たとえば、[RFC8754]は、かなりのバイト数を消費する可能性があるIPv6アドレスのリストを含む拡張ヘッダーフォーマットを定義します。
* Development of in situ OAM headers that allow a rich set of measurements to be gathered in the data path at the cost of additional header overhead, which may be significant [OAM-IPV6].
* 豊富な測定値を追加のヘッダオーバーヘッドのコストでデータ経路に集めることを可能にするin situ OAMヘッダの開発は、重要な[OAM - IPv6]であり得る。
* Other emerging use cases of Hop-by-Hop and Destination Options.
* ホップバイホップと宛先のオプションのその他の新たなユースケース。
End hosts may implement limits on processing extension headers as described in [RFC8504]. Host implementations are usually software stacks that typically don't have inherent processing limitations. Limits imposed by a software stack are more likely to be for denial-of-service mitigation or performance.
エンドホストは、[RFC8504]に記載されているように拡張ヘッダの処理上の制限を実装することができる。ホスト実装は通常、通常、固有の処理制限を持っていないソフトウェアスタックです。ソフトウェアスタックによって課される制限は、サービス拒否の緩和または性能のためのものである可能性が高いです。
Hardware devices that process packet headers may have limits as to how many headers or bytes of headers they can process. For instance, a middlebox hardware implementation might have a parsing buffer that contains some number of bytes of packet headers to process. Parsing buffers typically have a fixed size such as 64, 128, or 256 bytes. In addition, hardware implementations (and some software implementations) often don't have loop constructs. Processing of a TLV list might be implemented as an unrolled loop so that the number of TLVs that can be processed is limited.
パケットヘッダーを処理するハードウェアデバイスは、処理できるヘッダーのヘッダーまたはバイト数に関する制限を持ちます。たとえば、MiddleBoxハードウェア実装には、プロセスするパケットヘッダーの数回数を含む解析バッファがある可能性があります。解析バッファは通常、64,128、または256バイトのような固定サイズを有する。さらに、ハードウェア実装（および一部のソフトウェア実装）はしばしばループ構成を持っていません。TLVリストの処理は、処理可能なTLVの数が制限されるように、展開ループとして実装されてもよい。
The security considerations for ICMPv6 described in [RFC4443] are applicable. The ICMP errors described in this document MAY be filtered by firewalls in accordance with [RFC4890].
[RFC4443]に記載されているICMPv6のセキュリティ上の考慮事項が適用されます。この文書に記載されているICMPエラーは、[RFC4890]に従ってファイアウォールでフィルタリングすることができます。
In some circumstances, the sending of ICMP errors might conceptually be exploited as a means to covertly deduce the processing capabilities of nodes. Accordingly, an implementation SHOULD allow a configurable policy to withhold sending of the ICMP errors described in this specification in environments where the security of ICMP errors is a concern.
状況によっては、ICMPエラーの送信は、ノードの処理能力を妨げる手段として概念的に利用される可能性があります。したがって、実装は、ICMPエラーのセキュリティが懸念される環境で、この仕様で説明されているICMPエラーの送信を継送することを可能にする必要があります。
IANA has assigned the following codes in the "Type 4 - Parameter Problem" registry within the ICMPv6 Parameters registry [IANA-ICMP]:
IANAには、ICMPv6パラメータレジストリ内の "Type 4 - パラメータ問題"レジストリに次のコードが割り当てられています。
+======+==================================+
| Code | Name |
+======+==================================+
| 5 | Unrecognized Next Header type |
| | encountered by intermediate node |
+------+----------------------------------+
| 6 | Extension header too big |
+------+----------------------------------+
| 7 | Extension header chain too long |
+------+----------------------------------+
| 8 | Too many extension headers |
+------+----------------------------------+
| 9 | Too many options in extension |
| | header |
+------+----------------------------------+
| 10 | Option too big |
+------+----------------------------------+
Table 2
表2.
IANA has assigned the following code in the "Type 1 - Destination Unreachable" registry within the ICMPv6 Parameters registry [IANA-ICMP]:
IANAには、ICMPv6パラメータレジストリ[IANA-ICMP]内の「タイプ1 - 宛先到達不能」レジストリに次のコードが割り当てられています。
+======+==================+
| Code | Name |
+======+==================+
| 8 | Headers too long |
+------+------------------+
Table 3
表3.
IANA has assigned the following Class value in the "ICMP Extension Object Classes and Class Sub-types" registry within the ICMP Parameters registry [IANA-ICMPEXT]:
IANAは、ICMPパラメータレジストリ内の「ICMP拡張オブジェクトクラスとクラスサブタイプ」レジストリに次のクラス値を割り当てました[IANA-ICMPEXT]：
+=============+======================+
| Class Value | Class Name |
+=============+======================+
| 4 | Extended Information |
+-------------+----------------------+
Table 4
表4.
IANA has created a sub-type registry for the "Extended Information" ICMP extension object class. The registration procedure for this registry is "Standards Action". The sub-type value of 0 is reserved; values greater than zero may be assigned.
IANAは、「拡張情報」ICMP拡張オブジェクトクラスのサブタイプレジストリを作成しました。このレジストリの登録手順は「標準アクション」です。サブタイプの値0は予約されています。ゼロより大きい値を割り当てることができます。
IANA has assigned the following sub-type within the "Sub-types - Class 4 - Extended Information" registry within the ICMP Parameters registry:
IANAは、ICMPパラメータレジストリ内の「サブタイプ - クラス4 - 拡張情報」レジストリ内に次のサブタイプを割り当てました。
+=======+=============+
| Value | Description |
+=======+=============+
| 1 | Pointer |
+-------+-------------+
Table 5
表5.
[IANA-ICMP] IANA, "Internet Control Message Protocol version 6 (ICMPv6) Parameters", <https://www.iana.org/assignments/icmpv6-parameters/>.
[IANA-ICMP] IANA、「インターネットコントロールメッセージプロトコルバージョン6（ICMPv6）パラメータ」、<https：//www.iana.org/assignments/icmpv6-parameters/>。
[IANA-ICMPEXT] IANA, "Internet Control Message Protocol (ICMP) Parameters", <https://www.iana.org/assignments/icmp-parameters/>.
[IANA-ICMPEXT] IANA、「インターネット制御メッセージプロトコル（ICMP）パラメータ」、<https：//www.iana.org/assignments/iCmp-parameters/>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.
[RFC4884]ボニャ、R.、GaN、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするための拡張ICMP」、RFC 4884、DOI 10.17487 / RFC4884、2007年4月、<https：//www.rfc-editor.org/info/rfc48884>。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045] Carpenter、B.およびS. Jiang、「IPv6拡張ヘッダーの送信および処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<https：//www.rfc-editor.org/info/rfc7045>。
[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] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[OAM-IPV6] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. Smith, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-03, 18 September 2020, <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-03>.
[OAM-IPv6] Bhandari、S.、Brockners、F.、Pignataro、C.、Gredler、H.、Leddy、J.、Youell、S.、Mizrahi、T.、Kfir、A.、Gafni、B。、Lapukhov、P.、Spiegel、M.、Krishnan、S.、Asati、R.、およびM. Smith、「その場OAM IPv6オプション」、進行中の作業、インターネットドラフト、ドラフトIETF-IPPM-IOAM-IPv6-Options-03,202月18日、<https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-03>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M.およびJ.Heffner、 "Packetization Layer Path MTU Discovery"、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https：//www.rfc-editor.org/info/rfc4821>。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <https://www.rfc-editor.org/info/rfc4890>.
[RFC4890] Davies、E.およびJ.Mohacsi、「ファイアウォールのICMPv6メッセージをフィルタリングするための推奨事項」、RFC 4890、DOI 10.17487 / RFC4890、2007年5月、<https：//ww.rfc-editor.org/info/rfc4890>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D.およびT. Pauly、 "Happy Eyaballs Version 2：並行性を使用したより良い接続"、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/RFC8305>。
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8504] Chown、T.、Loughney、J.、およびT.Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https：//www.rfc-editor.org/ info / rfc8504>。
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8754] Filsfils、C、ED。、Dukes、D.、ED。、PREVIDI、S、Leddy、J.、Matsushima、S.、およびD. Voyer、「IPv6セグメントルーティングヘッダー（SRH）」、RFC8754、DOI 10.17487 / RFC8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。
Acknowledgments
謝辞
The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for their comments and suggestions that improved this document.
作者はRon Bonica、Bob Hinden、Nick Hilliard、Mick Smith、Suresh Krishnan、およびOle Tranに感謝します。この文書を改善するコメントや提案
Author's Address
著者の住所
Tom Herbert Intel Santa Clara, CA United States of America
Tom Herbert Intelサンタクララ、アメリカ合衆国
Email: tom@quantonium.net