Internet Engineering Task Force (IETF) R. Hinden
Request for Comments: 9673 Check Point Software
Updates: 8200 G. Fairhurst
Category: Standards Track University of Aberdeen
ISSN: 2070-1721 October 2024
This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts. This document updates RFC 8200.
このドキュメントは、IPv6ルーターとホストのIPv6ホップバイホップオプションを処理する手順を指定します。IPv6プロトコル仕様（RFC 8200）で指定された手順を変更して、IPv6ホップバイホップオプションをIPv6ルーターとホストで展開および使用するのに役立つようにすることを目的として、IPv6ホップバイホップオプションヘッダーの処理を実用的にします。このドキュメントは、RFC 8200を更新します。
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/rfc9673.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9673で取得できます。
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. Terminology
4. Background
5. Hop-by-Hop Header Processing Procedures
5.1. Processing the Extension Header Carrying Hop-by-Hop Options
5.1.1. Configuration Enabling Hop-by-Hop Header Processing
5.2. Hop-by-Hop Options Processing
5.2.1. Router Alert Option
5.2.2. Configuration of Hop-by-Hop Options Processing
6. Defining New Hop-by-Hop Options
6.1. Example of Robust Usage
7. IANA Considerations
8. Security Considerations
9. Normative References
10. Informative References
Acknowledgments
Authors' Addresses
This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification [RFC8200] to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.
このドキュメントは、IPv6ルーターとホストのIPv6ホップバイホップオプションを処理する手順を指定します。IPv6プロトコル仕様[RFC8200]で指定された手順を変更して、IPv6ホップバイホップオプションをIPv6ルーターおよびホストで展開および使用するのに役立つことを目的として、IPv6ホップバイホップオプションヘッダーの処理を実用的にします。
An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop Options header. The current list of defined Hop-by-Hop options can be found at [IANA-HBH]. The focus for this document is to set the minimum requirements for router processing of Hop-by-Hop options. It also discusses how Hop-by-Hop options are used by hosts. This document does not propose a specific bound to the number or size of Hop-by-Hop options that ought to be processed.
IPv6パケットには、ホップバイホップオプションヘッダーを含めることにより、ホップバイホップオプションが含まれています。定義されたホップバイホップオプションの現在のリストは、[IANA-HBH]にあります。このドキュメントの焦点は、ホップバイホップオプションのルーター処理の最小要件を設定することです。また、ホストによってホップバイホップオプションがどのように使用されるかについても説明します。このドキュメントでは、処理する必要があるホップバイホップオプションの数またはサイズに特定のバインドを提案しません。
This document updates [RFC8200].
このドキュメントは[RFC8200]を更新します。
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」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the following loosely defined terms:
このドキュメントでは、次の緩やかに定義された用語を使用します。
Forwarding Plane:
転送面：
IPv6 routers exchange user or applications data through the Forwarding Plane. Routers process fields contained in IPv6 packet headers. However, they do not process information contained in packet payloads.
IPv6ルーターは、転送面を介してユーザーまたはアプリケーションのデータを交換します。ルーターIPv6パケットヘッダーに含まれるプロセスフィールド。ただし、パケットペイロードに含まれる情報を処理しません。
Control Plane:
コントロールプレーン：
IPv6 routers exchange control information through the Control Plane. The Control Plane processes the management and routing information exchanged with other routers.
IPv6ルーターは、コントロールプレーンを介して制御情報を交換します。コントロールプレーンは、他のルーターと交換された管理情報とルーティング情報を処理します。
Fast Path:
高速パス：
A path through a router that is optimized for forwarding packets. The Fast Path might be supported by Application-Specific Integrated Circuits (ASICs), a Network Processor (NP), or other special purpose hardware. This is the typical processing path within a router taken by the Forwarding Plane.
パケットを転送するために最適化されたルーターを通るパス。高速パスは、アプリケーション固有の統合回路（ASIC）、ネットワークプロセッサ（NP）、またはその他の特別な目的ハードウェアによってサポートされる場合があります。これは、転送面で撮影されたルーター内の典型的な処理パスです。
Slow Path:
スローパス：
A path through a router that is capable of general purpose processing and is not optimized for any particular function. This processing path is used for packets that require special processing or that differ from assumptions made in Fast Path heuristics or to process router control protocols used by the Control Plane.
一般的な目的処理が可能で、特定の機能に最適化されていないルーターを通るパス。この処理パスは、特別な処理を必要とするパケットや、高速パスヒューリスティックで行われた仮定とは異なるパケットや、コントロールプレーンが使用するルーター制御プロトコルを処理するパケットに使用されます。
Full Forwarding Rate:
フル転送率：
The rate at which a router can forward packets without adversely impacting the aggregate forwarding rate. For example, a router could process packets with Hop-by-Hop options at a rate that allows it to maintain the full speed on its outgoing interfaces, which is sometimes called "wire speed".
ルーターが総転送速度に悪影響を与えることなく、パケットを転送できるレート。たとえば、ルーターは、「ワイヤ速度」と呼ばれることもある、発信インターフェイスでフルスピードを維持できるレートで、ホップバイホップオプションでパケットを処理できます。
Source:
ソース：
The node originating the packet.
パケットを発信するノード。
NOTE: [RFC6192] is an example of how designs can separate Control Plane and Forwarding Plane functions. The separation between hardware and software processing described in [RFC6398] does not apply to all router architectures. However, a router that performs all or most processing in software might still incur more processing cost when providing special processing for Hop-by-Hop options.
注：[RFC6192]は、設計が制御プレーンと転送面の機能を分離する方法の例です。[RFC6398]で説明されているハードウェアとソフトウェア処理の分離は、すべてのルーターアーキテクチャには適用されません。ただし、ソフトウェアですべてまたはほとんどの処理を実行するルーターは、ホップバイホップオプションに特別な処理を提供する場合、さらに多くの処理コストが発生する可能性があります。
In early versions of the IPv6 protocol specification [RFC1883] [RFC2460], Hop-by-Hop options were required to be processed by all nodes: routers and hosts. This proved to not be practical in current high speed routers, as observed in Section 2.2 of [RFC7045]: "it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path". The reasons behind this include the following:
IPv6プロトコル仕様[RFC1883] [RFC2460]の初期バージョンでは、すべてのノード（ルーターとホスト）で処理する必要がありました。これは、[RFC7045]のセクション2.2で観察されているように、現在の高速ルーターでは実用的ではないことが証明されました。この背後にある理由には、以下が含まれます。
* The inability to process Hop-by-Hop options at the Full Forwarding Rate can result in issues. In some cases, Hop-by-Hop options would be sent to the control/management components that run on the Slow Path. This could degrade a router's performance and also its ability to process critical control traffic, both of which could be exploited as a Denial-of-Service (DoS) attack against the router.
* フル転送速度でホップバイホップオプションを処理できないと、問題が発生する可能性があります。場合によっては、スローパスで実行される制御/管理コンポーネントにホップバイホップオプションが送信されます。これにより、ルーターのパフォーマンスと、重要な制御トラフィックを処理する能力が低下する可能性があります。どちらもルーターに対するサービス拒否（DOS）攻撃として悪用される可能性があります。
* If a subset of packets within a flow includes Hop-by-Hop options, it could lead to an increased number of reordered packets and greater reordering distances for packets delivered to the destination. Such reordering could occur if the Hop-by-Hop Options header is included only in some packets or if a specific Hop-by-Hop option results in different processing for some of the packets within the flow. Significant reordering of packets within a flow can negatively impact the performance of upper-layer protocols and should therefore be avoided.
* フロー内のパケットのサブセットにホップバイホップオプションが含まれている場合、目的地に配信されるパケットの並べ替えパケットの数が増え、並べ替え距離が大きくなる可能性があります。ホップバイホップオプションヘッダーが一部のパケットにのみ含まれている場合、または特定のホップバイホップオプションがフロー内の一部のパケットの処理が異なる場合、そのような並べ替えが発生する可能性があります。フロー内のパケットの大幅な並べ替えは、上層層プロトコルの性能に悪影響を与える可能性があるため、避ける必要があります。
* Packets could include multiple Hop-by-Hop options. Too many options could make the previous issues worse by increasing the resources required to process them. The total size of the options determines the number of header bytes that might need to be processed. Measurements [Cus23a] show that the probability of successful transmission across the public Internet is currently higher for packets that include Options that result in a short total Extension Header (EH) Chain size (i.e., less than 40 bytes).
* パケットには、複数のホップバイホップオプションを含めることができます。オプションが多すぎると、処理に必要なリソースを増やすことで、以前の問題を悪化させる可能性があります。オプションの合計サイズにより、処理する必要があるヘッダーバイトの数が決まります。測定[CUS23A]は、パブリックインターネット全体で伝送を成功させる確率が、短い総拡張ヘッダー（EH）チェーンサイズ（つまり、40バイト未満）をもたらすオプションを含むパケットの場合、現在高いことを示しています。
[RFC6564] specifies a uniform format for new IPv6 Extension Headers, and this update was incorporated into Section 4.8 of [RFC8200] (note that [RFC8200] obsoleted [RFC2460]).
[RFC6564]は、新しいIPv6拡張ヘッダーの均一な形式を指定し、この更新は[RFC8200]のセクション4.8に組み込まれました（[RFC8200]が廃止された[RFC2460]）。
When the IPv6 protocol specification was updated and published in July 2017 as [RFC8200], the procedures relating to Hop-by-Hop options were specified (paragraphs 5 and 6 of Section 4 of [RFC8200]) as follows:
IPv6プロトコルの仕様が2017年7月に[RFC8200]として更新および公開されたとき、ホップバイホップオプションに関連する手順が指定されました（[RFC8200]のセクション4のパラグラフ5および6）。
The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header.
ホップバイホップオプションヘッダーは挿入または削除されませんが、パケットがノード（またはマルチキャストの場合）にノードに到達するまで、パケットの配信パスに沿ってノードで検査または処理される場合があります。IPv6ヘッダーの宛先アドレスフィールドで識別されます。ホップバイホップオプションヘッダーは、存在する場合、すぐにIPv6ヘッダーを追跡する必要があります。その存在は、IPv6ヘッダーの次のヘッダーフィールドの値ゼロで示されます。
NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.
注：[RFC2460]は、すべてのノードがホップバイホップオプションヘッダーを調べて処理する必要があることを要求していましたが、パケットの配信パスに沿ったノードは、明示的に構成されている場合にホップバイホップオプションヘッダーのみを調べて処理することが期待されています。そうする。
The changes meant that an implementation complied with the IPv6 protocol specification even if it did not process Hop-by-Hop options and that routers were expected to add configuration information to control whether they process the Hop-by-Hop Options header. In practice, routers may include configuration options to control which Hop-by-Hop options they will process.
変更は、ホップバイホップオプションを処理せず、ルーターがホップバイホップオプションヘッダーを処理するかどうかを制御するための構成情報を追加することが期待されていた場合でも、実装がIPv6プロトコルの仕様に準拠していることを意味します。実際には、ルーターには、処理するホップバイホップオプションを制御する構成オプションが含まれている場合があります。
The text regarding the processing of Hop-by-Hop options in [RFC8200] was not intended to change the processing of these options. It documented how they were being used in the Internet at the time RFC 8200 was published (see Appendix B of [RFC8200]). This was a constraint on publishing the IPv6 protocol specification as an IETF Standard.
[RFC8200]のホップバイホップオプションの処理に関するテキストは、これらのオプションの処理を変更することを意図していませんでした。RFC 8200が公開された時点でインターネットでどのように使用されているかを文書化しました（[RFC8200]の付録Bを参照）。これは、IETF標準としてIPv6プロトコル仕様を公開することの制約でした。
The main issues remain:
主な問題は残っています：
* Routers can be configured to drop transit packets containing Hop-by-Hop Options that require processing by a processor that implements the Control Plane. This could be done to protect against a DoS attack on the router [RFC9098] [RFC9288].
* ルーターは、制御プレーンを実装するプロセッサによる処理が必要なホップバイホップオプションを含むトランジットパケットをドロップするように構成できます。これは、ルーター[RFC9098] [RFC9288]に対するDOS攻撃から保護するために行うことができます。
* IPv6 packets that include a Hop-by-Hop Options header are dropped by some Internet paths. A survey in 2015 reported a high loss rate in transit Autonomous Systems (ASes) for packets that include Hop-by-Hop options [RFC7872]. The operational implications of IPv6 packets that include Extension Headers are discussed in [RFC9098]. Measurements taken in 2023 confirm this to still be the case for many types of network paths [Cus23b].
* ホップバイホップオプションヘッダーを含むIPv6パケットは、いくつかのインターネットパスによってドロップされます。2015年の調査では、ホップバイホップオプション[RFC7872]を含むパケットの輸送自律システム（ASE）の高い損失率が報告されています。拡張ヘッダーを含むIPv6パケットの運用上の意味については、[RFC9098]で説明されています。2023年に行われた測定では、これが多くの種類のネットワークパス[CUS23B]に当てはまることを確認しています。
* Allowing multiple Hop-by-Hop options in a single packet in some cases consumes more router resources to process these packets. It also adds complexity to the number of permutations that might need to be processed/configured.
* 場合によっては、単一のパケットで複数のホップバイホップオプションを許可すると、これらのパケットを処理するためにより多くのルーターリソースが消費されます。また、処理/構成を必要とする可能性のある順列の数に複雑さを追加します。
* Including larger or multiple Hop-by-Hop options in a Hop-by-Hop Options header increases the number of bytes that need to be processed in forwarding, which in some designs can impact the cost of processing a packet, and in turn could increase the probability of drop [RFC7872]. A larger Extension Header could also reduce the probability of a router locating all the header bytes required to successfully process an access control list operating on fields after the Hop-by-Hop Options header.
* ホップバイホップオプションに大きいまたは複数のホップバイホップオプションを含めると、転送で処理する必要があるバイト数が増加します。これは、一部の設計ではパケットの処理コストに影響し、順番に増加する可能性があります。ドロップの確率[RFC7872]。また、より大きな拡張ヘッダーは、ホップバイホップオプションヘッダーの後にフィールドで動作するアクセス制御リストを正常に処理するために必要なすべてのヘッダーバイトを配置する可能性を低下させる可能性があります。
* Any option that can be used to force packets into the processor that implements the router's Control Plane can be exploited as a DoS attack on a transit router by saturating the resources needed for router management protocols (routing protocols, network management protocols, etc.), which could cause adverse router operation. This is an issue for the Router Alert Option [RFC2711], which intentionally forwards packets to the Control Plane as discussed in [RFC6398]. This impact could be mitigated by limiting the use of Control Plane resources by a specific packet and/or by using per-function rate-limiters for packets processed by the Control Plane.
* ルーターのコントロールプレーンを実装するプロセッサにパケットを強制するために使用できるオプションは、ルーター管理プロトコル（ルーティングプロトコル、ネットワーク管理プロトコルなど）に必要なリソースを飽和させることにより、トランジットルーターへのDOS攻撃として活用できます。それは不利なルーター操作を引き起こす可能性があります。これは、[RFC6398]で説明されているように、パケットをコントロールプレーンに意図的に転送するルーターアラートオプション[RFC2711]の問題です。この影響は、特定のパケットによる制御プレーンリソースの使用を制限することにより、および/または制御プレーンによって処理されたパケットに対して機能ごとのレート制限剤を使用することにより緩和できます。
Section 3 of [RFC6398] includes a summary of processing the IP Router Alert Option:
[RFC6398]のセクション3には、IPルーターアラートオプションの処理の概要が含まれています。
In a nutshell, the IP Router Alert Option does not provide a convenient universal mechanism to accurately and reliably distinguish between IP Router Alert packets of interest and unwanted IP Router Alert packets. This, in turn, creates a security concern when the IP Router Alert Option is used, because, short of appropriate router-implementation-specific mechanisms, the router slow path is at risk of being flooded by unwanted traffic.
一言で言えば、IPルーターアラートオプションは、関心のあるIPルーターアラートパケットと不要なIPルーターアラートパケットを正確かつ確実に区別するための便利なユニバーサルメカニズムを提供しません。これにより、IPルーターアラートオプションが使用されるときにセキュリティの懸念が生じます。これは、適切なルーター実装固有のメカニズムを除いて、ルータースローパスが不要なトラフィックに浸水するリスクがあるためです。
This is an example of the need to limit the resources that can be consumed when a particular function is executed and to avoid consuming Control Plane resources where support for a function has not been configured.
これは、特定の機能が実行されたときに消費できるリソースを制限し、関数のサポートが構成されていないコントロールプレーンリソースを消費しないようにする必要性の例です。
There has been research that has discussed the general problem with dropping packets containing IPv6 Extension Headers, including the Hop-by-Hop Options header. For example, [Hendriks] states that "Dropping all packets that contain Extension Headers is a bad practice" and that "The share of traffic containing more than one EH however, is very small. For the design of hardware able to handle the dynamic nature of EHs, we therefore recommend to support at least one EH". Operational aspects of the topics discussed in this section are further discussed in [HBH].
Hop-by-Hopオプションヘッダーを含むIPv6拡張ヘッダーを含むパケットをドロップする際の一般的な問題について議論した研究があります。たとえば、[Hendriks]は、「拡張ヘッダーを含むすべてのパケットをドロップすることは悪い練習である」と述べ、「しかし、複数のEHを含むトラフィックのシェアは非常に小さい。ダイナミックな性質を処理できるハードウェアの設計のためにしたがって、EHSのうち、少なくとも1つのEHをサポートすることをお勧めします。このセクションで説明したトピックの運用的側面については、[HBH]でさらに説明します。
"Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarifies how intermediate nodes should process Extension Headers. This document is generally consistent with [RFC7045] and addresses an issue that was raised for discussion when [RFC2460] was updated and replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently clarifies the description in Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].
「IPv6拡張ヘッダーの伝送と処理」[RFC7045]は、中間ノードが拡張ヘッダーを処理する方法を明確にします。このドキュメントは一般に[RFC7045]と一致しており、[RFC2460]が更新され[RFC8200]に置き換えられたときに議論のために提起された問題に対処します。このドキュメントは、次のセクションで説明されているように[RFC8200]を更新し、その結果、BCP 14 [RFC2119] [RFC8174]の言語を使用して、[RFC7045]のセクション2.2の説明を明確にします。
This document defines a set of procedures for the Hop-by-Hop Options header that are intended to make the processing of Hop-by-Hop options practical in modern routers. The common cases are that some Hop-by-Hop options will be processed across the Internet, while others will only be processed within a limited domain [RFC8799] (e.g., where a specific service is made available in that network segment that relies on one or more Hop-by-Hop options).
このドキュメントでは、最新のルーターでホップバイホップオプションの処理を実用化することを目的としたホップバイホップオプションヘッダーの一連の手順を定義します。一般的なケースは、いくつかのホップバイホップオプションがインターネット全体で処理され、他のオプションは限られたドメイン[RFC8799]内でのみ処理されることです（例えば、1つに依存するネットワークセグメントで特定のサービスが利用可能になります。またはそれ以上のホップバイホップオプション）。
This section describes several changes to [RFC8200]. Section 5.1 describes the processing of the Hop-by-Hop options Extension Header, and Section 5.2 describes the processing of individual Hop-by-Hop options. These sections update the text in paragraph 6 of Section 4 of [RFC8200] and, as noted in Section 5.2, modify Section 4.2 of [RFC8200].
このセクションでは、[RFC8200]のいくつかの変更について説明します。セクション5.1では、ホップバイホップオプション拡張ヘッダーの処理について説明し、セクション5.2では、個々のホップバイホップオプションの処理について説明します。これらのセクションは、[RFC8200]のセクション4のパラグラフ6のテキストを更新し、セクション5.2に記載されているように、[RFC8200]のセクション4.2を変更します。
When a packet includes one or more Extension Headers, the Next Header field of the IPv6 Header identifies the type of Extension Header. It does not identify the transport protocol.
パケットに1つ以上の拡張ヘッダーが含まれると、IPv6ヘッダーの次のヘッダーフィールドが拡張ヘッダーのタイプを識別します。輸送プロトコルを識別しません。
The Extension Header used to carry Hop-by-Hop options is defined in Section 4.3 of [RFC8200] and is identified by a Next Header value of 0 in the IPv6 header. Section 4.1 of [RFC8200] requires this Hop-by-Hop Options header to appear immediately after the IPv6 header. [RFC8200] also requires that a Hop-by-Hop Options header only appear at most once in a packet.
ホップバイホップオプションを携帯するために使用される拡張ヘッダーは、[RFC8200]のセクション4.3で定義されており、IPv6ヘッダーの次のヘッダー値は0で識別されます。[RFC8200]のセクション4.1では、このホップバイホップオプションヘッダーがIPv6ヘッダーの直後に表示される必要があります。[RFC8200]は、ホップバイホップオプションヘッダーがパケットにせいぜい1回しか表示されないことも必要です。
The Hop-by-Hop Options header as defined in [RFC8200] can contain one or more Hop-by-Hop options.
[RFC8200]で定義されているホップバイホップオプションヘッダーには、1つ以上のホップバイホップオプションを含めることができます。
Routers that process the Hop-by-Hop Options header SHOULD do so using the method defined in this document. Exceptions to this SHOULD include routers that are configured to drop packets with a Hop-by-Hop Options header to protect downstream devices that do not comply with this specification (see [RFC9288]).
ホップバイホップオプションヘッダーを処理するルーターは、このドキュメントで定義されているメソッドを使用してそうする必要があります。これの例外には、この仕様に準拠していない下流のデバイスを保護するために、ホップバイホップオプションヘッダーでパケットをドロップするように構成されたルーターを含める必要があります（[rfc9288を参照]）。
Even if a router does not process the Hop-by-Hop Options header (for example, when based on configuration), it MUST forward the packet normally based on the remaining Extension Header(s) after the Hop-by-Hop Options header. A router MUST NOT drop a packet solely because it contains an Extension Header carrying Hop-by-Hop options. A configuration could control whether normal processing skips any or all of the Hop-by-Hop options carried in the Hop-by-Hop Options header.
ルーターがホップバイホップオプションヘッダーを処理しない場合（たとえば、構成に基づいている場合）、ホップバイホップオプションヘッダーの後に残りの拡張ヘッダーに基づいて通常パケットを転送する必要があります。ルーターは、ホップバイホップオプションを運ぶ拡張ヘッダーが含まれているためだけにパケットをドロップしてはなりません。構成により、通常の処理がホップバイホップオプションヘッダーで運ばれるホップバイホップオプションのいずれかまたはすべてをスキップするかどうかを制御できます。
It is expected that the Hop-by-Hop Options header will be processed by the destination(s). Hosts SHOULD process the Hop-by-Hop Options header in received packets. A constrained host is an example of a node that does not process the Hop-by-Hop Options header. If a destination does not process the Hop-by-Hop Options header, it MUST process the remainder of the packet normally.
ホップバイホップオプションヘッダーは、宛先によって処理されると予想されます。ホストは、受信したパケットでホップバイホップオプションヘッダーを処理する必要があります。制約付きホストは、ホップバイホップオプションヘッダーを処理しないノードの例です。宛先がホップバイホップオプションヘッダーを処理しない場合、パケットの残りの部分を正常に処理する必要があります。
Section 4 of [RFC8200] allows a router to control its processing of IPv6 Hop-by-Hop options by local configuration. The text is:
[RFC8200]のセクション4では、ルーターがローカル構成ごとにIPv6ホップバイホップオプションの処理を制御できます。テキストは次のとおりです。
NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along the path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.
注：[RFC2460]は、すべてのノードがホップバイホップオプションヘッダーを調べて処理する必要があることを要求していましたが、パスに沿ったノードは、明示的に設定されている場合にホップバイホップオプションヘッダーのみを調べて処理することが期待されています。。
This document clarifies that a configuration could control whether processing skips any specific Hop-by-Hop options carried in the Hop-by-Hop Options header. A router that does not process the contents of the Hop-by-Hop Options header does not process any of the Option Types contained in the Hop-by-Hop Options header.
このドキュメントは、構成により、処理がホップバイホップオプションヘッダーにある特定のホップバイホップオプションをスキップするかどうかを制御できることを明確にしています。ホップバイホップオプションヘッダーの内容を処理しないルーターは、ホップバイホップオプションヘッダーに含まれるオプションタイプのいずれも処理しません。
A Source creating packets with a Hop-by-Hop Options header SHOULD use a method that is robust to network nodes selectively processing only some of the Hop-by-Hop options that are included in the packet or that forward packets without the option(s) being processed (see Section 6.1). A Source MAY, based on local configuration, allow only one Hop-by-Hop option to be included in a packet, or it could allow more than one Hop-by-Hop option but limit their size to increase the likelihood of successful transfer across a network path. Because some routers might only process one or a limited number of options in the Hop-by-Hop Options header, Sources are motivated to order the placement of Hop-by-Hop options within the Hop-by-Hop Options header in decreasing order of importance for their processing by nodes on the path.
ホップバイホップオプションヘッダーを備えたパケットを作成するソースは、パケットに含まれるホップバイホップオプションの一部のみを選択的に処理するため、またはオプションなしでフォワードパケットの一部のみを選択的に処理するために堅牢なメソッドを使用する必要があります（s）処理されている（セクション6.1を参照）。ソースは、ローカル構成に基づいて、1つのホップバイホップオプションをパケットに含めることができます。ネットワークパス。一部のルーターは、ホップバイホップオプションヘッダーで1つまたは限られたオプションのみを処理する可能性があるため、ソースは、ホップバイホップオプションヘッダー内のホップバイホップオプションの配置を注文するように動機付けられています。パス上のノードによる処理の重要性。
A router configuration needs to avoid vulnerabilities that arise when it cannot process the first Hop-by-Hop option at the Full Forwarding Rate. Therefore, a router SHOULD NOT be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding rate. A router SHOULD process additional Hop-by-Hop options, if configured to do so, providing that these also do not adversely impact the aggregate forwarding rate.
ルーター構成は、最初のホップバイホップオプションをフル転送速度で処理できない場合に発生する脆弱性を回避する必要があります。したがって、これが総転送レートに悪影響を与える場合、最初のホップバイホップオプションを処理するようにルーターを構成しないでください。ルーターは、そのように構成されている場合、追加のホップバイホップオプションを処理する必要があります。
If a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the same way specified for an unrecognized Option Type when the action bits are set to "00", and it SHOULD skip the remaining options using the "Hdr Ext Len" field in the Hop-by-Hop Options header. This field specifies the length of the Options Header in 8-octet units. After skipping an option, the router continues processing the remaining options in the header. Skipped options do not need to be verified.
ルーターが特定のホップバイホップオプションを処理できない場合（またはそうするように構成されていない）、アクションビットが「00」に設定されている場合、認識されていないオプションタイプに指定された同じ方法で動作する必要があります。ホップバイホップオプションヘッダーの「HDR Ext Len」フィールドを使用して、残りのオプションをスキップする必要があります。このフィールドは、8オクテットユニットのオプションヘッダーの長さを指定します。オプションをスキップした後、ルーターはヘッダー内の残りのオプションの処理を継続します。スキップされたオプションを検証する必要はありません。
The Router Alert Option [RFC2711] is an exception to this because it is designed to tell a router that the packet needs additional processing, which is usually done in the Control Plane; see Section 5.2.1.
ルーターアラートオプション[RFC2711]は、パケットに追加の処理が必要であり、通常はコントロールプレーンで行われることをルーターに伝えるように設計されているため、これの例外です。セクション5.2.1を参照してください。
Section 4.2 of [RFC8200] defines the Option Type identifiers as internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. The text is:
[RFC8200]のセクション4.2は、オプションタイプ識別子を内部エンコードとして定義し、その最高級の2ビットが処理IPv6ノードがオプションタイプを認識しない場合に実行する必要があるアクションを指定するようにします。テキストは次のとおりです。
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address,
send an ICMP Parameter Problem, Code 2, message to the
packet's Source Address, pointing to the unrecognized
Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
This document modifies this behavior for the "01", "10", and "11" action bits so that if a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the same way specified for an unrecognized Option Type when the action bits are set to "00". It also modifies the behavior for values "10" and "11" in the case where the packet is discarded and the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443], message to the packet's Source Address, pointing to the unrecognized Option Type.
このドキュメントは、「01」、「10」、および「11」アクションビットのこの動作を変更して、ルーターが特定のホップバイホップオプションを処理できない場合（またはそうするように構成されていない）、アクションビットが「00」に設定されている場合、認識されていないオプションタイプに指定されたのと同じ方法で動作します。また、パケットが破棄され、ノードがICMPパラメーターの問題、コード2 [RFC4443]を送信する場合、パケットが破棄された場合の値「10」と「11」の動作を変更します。タイプ。
The modified text for values "01", "10", and "11" is:
値「01」、「10」、および「11」の変更されたテキストは次のとおりです。
01 - MAY discard the packet, if so configured. Nodes should not
rely on routers dropping these unrecognized Option Types.
10 - MAY discard the packet, if so configured, regardless of
whether or not the packet's Destination Address was a
multicast address. If the packet was discarded, an ICMP
Parameter Problem, Code 2, message MAY be sent to the
packet's Source Address, pointing to the unrecognized
Option Type.
11 - MAY discard the packet, if so configured. If the packet
was discarded and the packet's Destination Address was
not a multicast address, an ICMP Parameter Problem,
Code 2, message MAY be sent to the packet's Source
Address, pointing to the unrecognized Option Type.
When an ICMP Parameter Problem, Code 2, message is delivered to the Source, it indicates that at least one node on the path has failed to recognize the option [RFC4443]. Generating any ICMP message incurs additional router processing. Reception of this message is not guaranteed; routers might be unable to be configured so that they do not generate these messages, and they are not always forwarded to the Source. The motivation here is to loosen the requirement to send an ICMPv6 Parameter Problem message when a router forwards a packet without processing the list of all options.
ICMPパラメーターの問題、コード2、メッセージがソースに配信されると、パス上の少なくとも1つのノードがオプション[RFC4443]を認識できなかったことを示します。ICMPメッセージを生成するには、追加のルーター処理が発生します。このメッセージの受信は保証されていません。ルーターはこれらのメッセージを生成しないように構成できない場合があり、常にソースに転送されるとは限りません。ここでの動機は、ルーターがすべてのオプションのリストを処理せずにパケットを転送するときにICMPV6パラメーター問題メッセージを送信するための要件を緩めることです。
The purpose of the Router Alert Option [RFC2711] is to tell a router that the packet needs additional processing in the Control Plane.
ルーターアラートオプション[RFC2711]の目的は、パケットがコントロールプレーンで追加の処理が必要であることをルーターに伝えることです。
The Router Alert Option includes a two-octet Value field that describes the protocol that is carried in the packet. The current specified values can be found in the "IPv6 Router Alert Option Values" IANA registry [IANA-RA].
ルーターアラートオプションには、パケットに掲載されているプロトコルを記述する2オクテットの値フィールドが含まれています。現在の指定された値は、「IPv6ルーターアラートオプション値」IANAレジストリ[IANA-RA]に記載されています。
DISCUSSION
考察
The function of a Router Alert Option can result in the processing that this specification is proposing to eliminate, that is, instructing a router to process the packet in the Control Plane. This processing causes concerns, which are discussed in Section 4. One approach would be to deprecate this, because current usage beyond the local network appears to be limited, and packets containing Hop-by-Hop options are frequently dropped. Deprecation would allow current implementations to continue, and its use could be phased out over time.
ルーターアラートオプションの関数は、この仕様が排除することを提案している処理、つまりルーターにコントロールプレーンのパケットを処理するよう指示する可能性があります。この処理は懸念を引き起こし、セクション4で説明します。1つのアプローチは、これを非難することです。これは、ローカルネットワークを超えた現在の使用が制限されているように見えるため、ホップバイホップオプションを含むパケットが頻繁に削除されるためです。非難すると、現在の実装が継続され、その使用は時間とともに段階的に廃止される可能性があります。
The Router Alert Option could potentially be used with new functions that have to be processed in the Control Plane. Keeping this as the single exception for processing in the Control Plane with the restrictions that follow is a reasonable compromise to allow future flexibility. These restrictions are compatible with Section 5 of [RFC6398].
ルーターアラートオプションは、コントロールプレーンで処理する必要がある新しい機能で使用できます。これをコントロールプレーンで処理するための単一の例外として、以下の制限を維持することは、将来の柔軟性を可能にする合理的な妥協です。これらの制限は、[RFC6398]のセクション5と互換性があります。
As noted in [RFC6398], "Implementations of the IP Router Alert Option SHOULD offer the configuration option to simply ignore the presence of 'IP Router Alert' in IPv4 and IPv6 packets."
[RFC6398]で述べたように、「IPルーターアラートオプションの実装は、IPv4およびIPv6パケットでの「IPルーターアラート」の存在を単純に無視する構成オプションを提供する必要があります。」
A node that is configured to process a Router Alert Option MUST protect itself from an infrastructure attack that could result from processing in the Control Plane. This might include some combination of an access control list to only permit access from trusted nodes, rate limiting of processing, or other methods [RFC6398].
ルーターアラートオプションを処理するように構成されているノードは、コントロールプレーンでの処理から生じる可能性のあるインフラストラクチャ攻撃から保護する必要があります。これには、信頼できるノードからのアクセスのみ、処理のレート制限、またはその他の方法[RFC6398]からアクセス制御リストの組み合わせが含まれる場合があります。
As specified in [RFC2711], the top two bits of the Option Type for the Router Alert Option are always set to "00", indicating that the node should skip over this option as if it does not recognize the Option Type and continue processing the header. An implementation that does recognize the Router Alert Option SHOULD verify that the Router Alert Option contains a protocol, as indicated by the Value field in the Router Alert Option, that is configured as a protocol of interest to that router. A verified packet SHOULD be sent to the Control Plane for further processing [RFC6398]. Otherwise, the router implementation SHOULD forward this packet subject to all normal policies and forwarding rules.
[RFC2711]で指定されているように、ルーターアラートオプションのオプションタイプの上位2ビットは常に「00」に設定されています。これは、ノードがオプションタイプを認識しないかのようにこのオプションをスキップする必要があることを示します。ヘッダ。ルーターアラートオプションを認識する実装では、ルーターアラートオプションの値フィールドで示されるように、ルーターアラートオプションで示されるプロトコルが含まれていることを確認する必要があります。これは、そのルーターにとって関心のあるプロトコルとして構成されています。検証済みのパケットは、さらなる処理のためにコントロールプレーンに送信する必要があります[RFC6398]。それ以外の場合、ルーターの実装では、このパケットをすべての通常のポリシーと転送ルールに従って転送する必要があります。
A router can be configured to process a specific Option. The set of enabled options SHOULD be configurable by the operator of the router.
ルーターは、特定のオプションを処理するように構成できます。有効なオプションのセットは、ルーターの演算子が構成可能にする必要があります。
A possible approach to implementing this is to maintain a lookup table based on an Option Type of the IPv6 options that can be processed at the Full Forwarding Rate. This would allow a router to quickly determine if an option is supported and can be processed. If the option is not supported, then the router processes the option as described in Section 5.1 of this document.
これを実装するための可能なアプローチは、完全な転送速度で処理できるIPv6オプションのオプションタイプに基づいてルックアップテーブルを維持することです。これにより、ルーターはオプションがサポートされ、処理できるかどうかをすばやく判断できます。オプションがサポートされていない場合、ルーターはこのドキュメントのセクション5.1で説明されているようにオプションを処理します。
The actions of the lookup table should be configurable by the operator of the router.
ルーターの演算子がルックアップテーブルのアクションを設定できる必要があります。
This section updates Section 4.8 of [RFC8200].
このセクションは、[RFC8200]のセクション4.8を更新します。
Any future new IPv6 Hop-by-Hop options should be designed to be processed at the Full Forwarding Rate and should have the following characteristics:
将来の新しいIPv6ホップバイホップオプションは、完全な転送速度で処理するように設計する必要があり、次の特性を持つ必要があります。
* New Hop-by-Hop options should be designed to ensure the router can process the options at the Full Forwarding Rate. That is, they should be simple to process.
* 新しいホップバイホップオプションは、ルーターが完全な転送レートでオプションを処理できるように設計する必要があります。つまり、処理が簡単である必要があります。
* New Hop-by-Hop options should be defined with the Action type (highest-order 2 bits of the Option Type) set to "00", which enables skipping over this option and continuing with the processing of the header if a router does not recognize the option.
* 新しいホップバイホップオプションは、「00」に設定されたアクションタイプ（オプションタイプの最大2ビット）で定義する必要があります。オプションを認識します。
* The size of Hop-by-Hop options should not extend beyond what can be expected to be executed at the Full Forwarding Rate. A larger Hop-by-Hop Options header can increase the likelihood that a packet will be dropped [Cus23b].
* ホップバイホップオプションのサイズは、完全な転送レートで実行されると予想されるものを超えて拡張してはなりません。ホップバイホップオプションヘッダーを大きくすると、パケットがドロップされる可能性が高くなります[CUS23B]。
* New Hop-by-Hop options should be designed with the expectation that a router might be configured to only process a subset of Hop-by-Hop options (e.g., the first option) in the Hop-by-Hop Options header.
* 新しいホップバイホップオプションは、ホップバイホップオプションヘッダーのホップバイホップオプション（最初のオプションなど）のサブセットのみを処理するようにルーターが設定される可能性があることを期待して設計する必要があります。
* The design of protocols that use new Hop-by-Hop options should consider that a router may drop packets containing the new Hop-by-Hop option.
* 新しいホップバイホップオプションを使用するプロトコルの設計では、ルーターが新しいホップバイホップオプションを含むパケットをドロップする可能性があることを考慮する必要があります。
If a new Hop-by-Hop option does not meet these criteria, its specification must include a detailed explanation why that is the case and show that there is a reasonable expectation that the option can still proceed at the Full Forwarding Rate. This is consistent with [RFC6564]. This is consistent with [RFC6564].
新しいホップバイホップオプションがこれらの基準を満たしていない場合、その仕様には、その理由がある理由を詳細に説明する必要があり、オプションが完全な転送速度で進行できるという合理的な期待があることを示します。これは[RFC6564]と一致しています。これは[RFC6564]と一致しています。
The general issue of robust operation of packets with new Hop-by-Hop options is described in Section 6.1.
新しいホップバイホップオプションを使用したパケットの堅牢な操作の一般的な問題については、セクション6.1で説明します。
Recent measurement surveys (e.g., [Cus23a]) show that packets that include Extension Headers can cause the packets to be dropped by some Internet paths. In a limited domain, routers can be configured or updated to provide support for any required Hop-by-Hop options.
最近の測定調査（例：[CUS23A]）は、拡張ヘッダーを含むパケットがインターネットパスによってパケットをドロップする可能性があることを示しています。限られたドメインでは、ルーターを構成または更新して、必要なホップバイホップオプションをサポートすることができます。
The primary motivation of this document is to make it more practical to use Hop-by-Hop options beyond such a limited domain, with the expectation that applications can improve the quality of or add new features to their offered service when the path successfully forwards packets with the required Hop-by-Hop options and otherwise refrains from using these options. The focus is on incremental deployability. A protocol feature (such as using Hop-by-Hop options) is incrementally deployable if early adopters gain some benefit on the paths being used, even though other paths do not support the protocol feature. A Source ought to order the Hop-by-Hop options that are carried in the Hop-by-Hop Options header in decreasing order of importance for processing by nodes on the path.
このドキュメントの主な動機は、このような限られたドメインを超えてホップバイホップオプションをより実用的にすることであり、アプリケーションがパスがパケットを正常に転送したときに提供されたサービスの品質を改善したり、提供されたサービスに新しい機能を追加できると期待して必要なホップバイホップオプションを使用すると、これらのオプションの使用を控えます。焦点は、インクリメンタルな展開性にあります。プロトコル機能（ホップバイホップオプションの使用など）は、他のパスがプロトコル機能をサポートしていない場合でも、アーリーアダプターが使用されているパスである程度の利益を得る場合、徐々に展開できます。ソースは、パス上のノードによる処理の重要性の順序を減らすために、ホップバイホップオプションヘッダーに掲載されるホップバイホップオプションを注文する必要があります。
Methods can be developed that do not rely upon all routers to implement a specific Hop-by-Hop option (e.g., [RFC9268]) and that are robust when the current path drops packets that contain a Hop-by-Hop option (e.g., [RFC9098]).
特定のホップバイホップオプション（[RFC9268]など）を実装するためにすべてのルーターに依存しない方法を開発できます。[RFC9098]）。
For example, an application can be designed to first send a test packet that includes the required option or combination of options and then send other packets without including the option. The application does not send additional packets that include this option (or set of options) until the test packet(s) is acknowledged. The need for potential loss recovery when a path drops these test packets can be avoided by choosing packets that do not carry application data that needs to be reliably delivered.
たとえば、アプリケーションは、最初に必要なオプションまたはオプションの組み合わせを含むテストパケットを送信し、オプションを含めることなく他のパケットを送信するように設計できます。アプリケーションは、テストパケットが承認されるまで、このオプション（またはオプションのセット）を含む追加のパケットを送信しません。パスがこれらのテストパケットをドロップする場合の潜在的な損失回復の必要性は、確実に配信する必要があるアプリケーションデータを運ぶことのないパケットを選択することにより、回避できます。
Since the set of nodes forming a path can change with time, this discovery process ought to be repeated from time to time. The process of sending packets both with and without a specific header to discover whether a path can support a specific header is sometimes called "racing". Transport protocol racing is explained in [TAPS-ARCH], and A/B protocol feature testing is described in [Tram17].
パスを形成するノードのセットは時間とともに変化する可能性があるため、この発見プロセスは随時繰り返される必要があります。特定のヘッダーの有無にかかわらず、パスが特定のヘッダーをサポートできるかどうかを発見するプロセスのプロセスは、「レーシング」と呼ばれることもあります。輸送プロトコルレースは[TAPS-ARCH]で説明されており、A/Bプロトコル機能テストは[TRAM17]で説明されています。
This document updates the processing of Hop-by-Hop options. IANA has added this document as an additional reference for the "Destination Options and Hop-by-Hop Options" registry in the "Internet Protocol Version 6 (IPv6) Parameters" registry group [IANA-HBH].
このドキュメントは、ホップバイホップオプションの処理を更新します。IANAは、「インターネットプロトコルバージョン6（IPv6）パラメーター」レジストリグループ[IANA-HBH]の「宛先オプションとホップバイホップオプション」レジストリの追加リファレンスとしてこのドキュメントを追加しました。
Security issues caused by including IPv6 Hop-by-Hop options are well known and have been documented in several places, including [RFC6398], [RFC6192], [RFC7045], and [RFC9098]. The main issue, as noted in Section 4, is that any mechanism that can be used to force packets into the router's Control Plane or Slow Path can be exploited as a DoS attack on a router by saturating the resources needed for router management (routing protocols, network management protocols, etc.), and this can cause the router to fail or perform suboptimally.
IPv6ホップバイホップオプションを含めることによって引き起こされるセキュリティの問題はよく知られており、[RFC6398]、[RFC6192]、[RFC7045]、[RFC9098]など、いくつかの場所で文書化されています。セクション4に記載されている主な問題は、ルーターのコントロールプレーンまたはスローパスにパケットを強制するために使用できるメカニズムは、ルーター管理に必要なリソースを飽和させることにより、ルーターへのDOS攻撃として活用できることです（ルーティングプロトコルを活用できることです。、ネットワーク管理プロトコルなど）。
While Hop-by-Hop options are not required to be processed in the Control Plane, the Router Alert Option is the one exception that is designed to be processed in the Control Plane.
ホップバイホップオプションはコントロールプレーンで処理する必要はありませんが、ルーターアラートオプションは、コントロールプレーンで処理するように設計された1つの例外です。
Some IPv6 nodes implement features that access more of the protocol information than a typical IPv6 router (e.g., [RFC9098]). Examples are nodes that provide DoS mitigation, firewall/access control, traffic engineering, or traffic normalization. These nodes could be configured to drop packets when they are unable to access and process all Extension Headers or are unable to locate and process the higher-layer packet information. This document provides guidance on the requirements concerning Hop-by-Hop options.
一部のIPv6ノードは、典型的なIPv6ルーター（[RFC9098]など）よりも多くのプロトコル情報にアクセスする機能を実装しています。例は、DOS緩和、ファイアウォール/アクセス制御、交通工学、またはトラフィックの正規化を提供するノードです。これらのノードは、すべての拡張ヘッダーにアクセスして処理できない場合、または高層パケット情報を見つけて処理できない場合にパケットをドロップするように構成できます。このドキュメントは、ホップバイホップオプションに関する要件に関するガイダンスを提供します。
Finally, this document notes that Internet protocol processing needs to be robust for malformed/malicious protocol fields. For example, a packet with an excessive number of options could consume significant resources; inclusion of a large Extension Header could potentially cause an on-path router to be unable to utilize hardware optimizations to process later headers (e.g., to perform equal cost multipath forwarding or port filtering). This requirement is not specific to Hop-by-Hop options. It is important that implementations fail gracefully when a malformed or malicious Hop-by-Hop option is encountered.
最後に、このドキュメントは、インターネットプロトコル処理が奇形/悪意のあるプロトコルフィールドに堅牢である必要があることを指摘しています。たとえば、過度の数のオプションを備えたパケットは、重要なリソースを消費する可能性があります。大規模な拡張ヘッダーを含めると、オンパスルーターがハードウェアの最適化を利用して後のヘッダーを処理できなくなる可能性があります（たとえば、等しいコストマルチパス転送またはポートフィルタリングを実行するため）。この要件は、ホップバイホップオプションに固有のものではありません。奇形または悪意のあるホップバイホップオプションに遭遇した場合、実装が優雅に失敗することが重要です。
This document changes how the Hop-by-Hop Options header is processed, which significantly reduces the attack surface. These changes include the following:
このドキュメントは、ホップバイホップオプションヘッダーの処理方法を変更し、攻撃面を大幅に削減します。これらの変更には以下が含まれます。
* A router configuration needs to avoid vulnerabilities that arise when it cannot process a Hop-by-Hop option at the Full Forwarding Rate; therefore, it SHOULD NOT be configured to process the Hop-by-Hop option if it adversely impacts the aggregate forwarding rate. Instead, it SHOULD behave in the same way specified for an unrecognized Option Type when the action bits are set to "00", as specified in Section 5.2.
* ルーターの構成は、フル転送速度でホップバイホップオプションを処理できない場合に発生する脆弱性を回避する必要があります。したがって、総転送レートに悪影響を与える場合、ホップバイホップオプションを処理するように構成されてはなりません。代わりに、セクション5.2で指定されているように、アクションビットが「00」に設定されている場合、認識されていないオプションタイプに指定された同じ方法で動作する必要があります。
* This document adds criteria for the Router Alert Option (Section 5.2.1) to allow control over how it is processed and describes how a node configured to support these options must protect itself from attacks by using the Router Alert Option.
* このドキュメントは、ルーターアラートオプション（セクション5.2.1）の基準を追加して、処理方法を制御できるようにし、これらのオプションをサポートするように構成されたノードがRouterアラートオプションを使用して攻撃から保護する方法を説明する方法を説明します。
* This document sets the expectation that if a packet includes a Hop-by-Hop Options header, the packet will be forwarded across the network path.
* このドキュメントは、パケットにホップバイホップオプションヘッダーが含まれている場合、パケットがネットワークパス全体に転送されるという期待を設定します。
* A Source MAY include a single Hop-by-Hop option (based on local configuration) or MAY be configured to include more Hop-by-Hop options. The configuration of intermediate nodes determines whether a node processes any of these options, and if so, which ones and how many.
* ソースには、単一のホップバイホップオプション（ローカル構成に基づく）を含めるか、より多くのホップバイホップオプションを含めるように構成することができます。中間ノードの構成により、ノードがこれらのオプションのいずれかを処理するかどうか、およびもしあれば、どのオプションといくつのオプションが処理されますか。
* This document adds guidance for the design of any future new Hop-by-Hop option that reduces the computational requirements and encourages a limit to their size.
* このドキュメントは、計算要件を削減し、そのサイズの制限を促進する将来の新しいホップバイホップオプションの設計に関するガイダンスを追加します。
The intent of this document is to highlight that these changes significantly reduce the security issues relating to processing the IPv6 Hop-by-Hop Options header and enable Hop-by-Hop options to be safely used in the Internet.
このドキュメントの目的は、これらの変更がIPv6ホップバイホップオプションヘッダーの処理に関連するセキュリティの問題を大幅に減らし、ホップバイホップオプションをインターネットで安全に使用できるようにすることを強調することです。
[IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options",
<https://www.iana.org/assignments/ipv6-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>.
[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>.
[Cus23a] Custura, A. and G. Fairhurst, "Internet Measurements: IPv6
Extension Header Edition", IEPG Meeting: IETF 116, March
2023, <http://www.iepg.org/2023-03-26-ietf116/eh.pdf>.
[Cus23b] Custura, A., Secchi, R., Boswell, E., and G. Fairhurst,
"Is it possible to extend IPv6?", Computer Communications,
vol. 214, pp. 90-99, DOI 10.1016/j.comcom.2023.10.006,
January 2024,
<https://www.sciencedirect.com/science/article/pii/
S0140366423003705>.
[HBH] Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
"Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-10, 16 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-10>.
[Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A.
Aiko, "Threats and Surprises behind IPv6 Extension
Headers", 2017 Network Traffic Measurement and Analysis
Conference (TMA), DOI 10.23919/TMA.2017.8002912, August
2017, <http://dl.ifip.org/db/conf/tma/tma2017/
tma2017_paper22.pdf>.
[IANA-RA] IANA, "IPv6 Router Alert Option Values",
<https://www.iana.org/assignments/ipv6-routeralert-
values/>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>.
[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>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>.
[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>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9288] Gont, F. and W. Liu, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers at Transit
Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
<https://www.rfc-editor.org/info/rfc9288>.
[TAPS-ARCH]
Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
Fairhurst, G., and C. Perkins, "Architecture and
Requirements for Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-arch-19, 9 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
arch-19>.
[Tram17] Trammell, B., Kühlewind, M., De Vaere, P., Learmonth, I.,
and G. Fairhurst, "Tracking Transport-Layer Evolution with
PATHspider", ANRW '17: Proceedings of the 2017 Applied
Networking Research Workshop, DOI 10.1145/3106328.3106336,
July 2017,
<https://irtf.org/anrw/2017/anrw17-final16.pdf>.
Helpful comments were received from Brian Carpenter, Ron Bonica, Ole Troan, Mike Heard, Tom Herbert, Cheng Li, Éric Vyncke, Greg Mirsky, Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, Ana Custura, Tim Winters, Jingrong Xie, Lorenzo Colitti, Toerless Eckert, Suresh Krishnan, Mikael Abrahamsson, Adrian Farrel, Jie Dong, Jen Linkova, Erik Kline, and other members of the 6MAN Working Group.
ブライアン・カーペンター、ロン・ボニカ、オール・トローン、マイク・ハード、トム・ハーバート、チェン・リー、エリック・ヴィンケ、グレッグ・ミルスキー、Xiaoミン、フェルナンド・ゴント、ダレン・デュケス、ペン・シュピング、デイブ・タラー、アナ・カストラ、ティム・ウィンターズから有益なコメントが受けられました。Jingrong Xie、Lorenzo Colitti、Toerless Eckert、Suresh Krishnan、Mikael Abrahamsson、Adrian Farrel、Jie Dong、Jen Linkova、Erik Kline、および6manワーキンググループのメンバー。
Robert M. Hinden
Check Point Software
100 Oracle Parkway, Suite 800
Redwood City, CA 94065
United States of America
Email: bob.hinden@gmail.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk