[要約] RFC 9098は、IPv6パケットの拡張ヘッダーがネットワーク運用に与える影響について説明します。この文書の目的は、拡張ヘッダーを使用する際の考慮事項と対策を提供することです。利用場面には、セキュリティポリシーの設定、パフォーマンス最適化、トラブルシューティングが含まれます。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 9098 SI6 Networks
Category: Informational N. Hilliard
ISSN: 2070-1721 INEX
G. Doering
SpaceNet AG
W. Kumari
Google
G. Huston
APNIC
W. Liu
Huawei Technologies
September 2021
Operational Implications of IPv6 Packets with Extension Headers
拡張ヘッダを持つIPv6パケットの運用上の影響
Abstract
概要
This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.
この文書では、IPv6プロトコル仕様書（RFC 8200）で指定されたIPv6拡張ヘッダーの運用上の影響をまとめ、IPv6拡張ヘッダーを持つパケットが公衆インターネットに廃棄された理由を分析しようとしています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9098.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9098で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Disclaimer
4. Background Information
5. Previous Work on IPv6 Extension Headers
6. Packet-Forwarding Engine Constraints
6.1. Recirculation
7. Requirement to Process Layer 3 / Layer 4 Information in
Intermediate Systems
7.1. ECMP and Hash-Based Load Sharing
7.2. Enforcing Infrastructure ACLs
7.3. DDoS Management and Customer Requests for Filtering
7.4. Network Intrusion Detection and Prevention
7.5. Firewalling
8. Operational and Security Implications
8.1. Inability to Find Layer 4 Information
8.2. Route-Processor Protection
8.3. Inability to Perform Fine-Grained Filtering
8.4. Security Concerns Associated with IPv6 Extension Headers
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
IPv6 extension headers (EHs) allow for the extension of the IPv6 protocol and provide support for core functionality such as IPv6 fragmentation. However, common implementation limitations suggest that EHs present a challenge for IPv6 packet routing equipment and middleboxes, and evidence exists that IPv6 packets with EHs are intentionally dropped in the public Internet in some circumstances.
IPv6拡張ヘッダー（EHS）は、IPv6プロトコルの拡張を可能にし、IPv6フラグメンテーションなどのコア機能をサポートします。ただし、一般的な実装の制限事項は、EHSがIPv6パケットルーティング機器とミドルボックスに課題を提示し、状況によっては、EHSのIPv6パケットが意図的にパブリックインターネットに落とされているという証拠が存在しています。
This document has the following goals:
この文書には次の目標があります。
* Raise awareness about the operational and security implications of IPv6 extension headers specified in [RFC8200] and present reasons why some networks resort to intentionally dropping packets containing IPv6 extension headers.
* [RFC8200]で指定されたIPv6拡張ヘッダーの運用上およびセキュリティの影響についての意識を高めると、IPv6の拡張ヘッダーを含むパケットを意図的にドロップするためのいくつかのネットワークに頼る理由。
* Highlight areas where current IPv6 support by networking devices may be suboptimal, such that the aforementioned support is improved.
* ハイライトネットワーク装置による現在のIPv6サポートが最適な部分であってもよく、前述のサポートが改善される。
* Highlight operational issues associated with IPv6 extension headers, such that those issues are considered in IETF standardization efforts.
* IETF標準化の取り組みにおいてこれらの問題が考慮されるように、IPv6拡張ヘッダーに関連する運用上の問題を強調表示します。
Section 4 of this document provides background information about the IPv6 packet structure and associated implications. Section 5 summarizes previous work that has been carried out in the area of IPv6 extension headers. Section 6 discusses packet-forwarding engine constraints in contemporary routers. Section 7 discusses why intermediate systems may need to access Layer 4 information to make a forwarding decision. Finally, Section 8 discusses operational implications of IPv6 EHs.
この文書のセクション4は、IPv6パケット構造と関連する影響に関する背景情報を提供します。IPv6拡張ヘッダーの領域で実行された以前の作品を節約5。セクション6は現代ルータのパケット転送エンジンの制約について説明します。セクション7は、中間システムが転送決定をするために層4の情報にアクセスする必要があるかもしれない理由について説明する。最後に、セクション8はIPv6 EHSの運用上の意味を説明します。
This document uses the term "intermediate system" to describe both routers and middleboxes when there is no need to distinguish between the two and where the important issue is that the device being discussed forwards packets.
この文書は、2つの間を区別する必要がない場合、および重要な問題が議論されているデバイスがパケットを転送することである場合、「中間システム」という用語を使用して、ルータとミドルボックスの両方を記述します。
This document analyzes the operational challenges represented by packets that employ IPv6 extension headers and documents some of the operational reasons why these packets are often dropped in the public Internet. This document is not a recommendation to drop such packets, but rather an analysis of why they are currently dropped.
このドキュメントは、IPv6拡張ヘッダーを採用し、これらのパケットが公衆インターネットで廃棄されることが多い操作上の理由のいくつかを文書化するパケットによって表される運用上の課題を分析します。この文書は、そのようなパケットを削除することをお勧めしませんが、むしろそれらが現在削除されている理由の分析です。
It is useful to compare the basic structure of IPv6 packets against that of IPv4 packets and analyze the implications of the two different packet structures.
IPv6パケットの基本構造をIPv4パケットの基本構造と比較し、2つの異なるパケット構造の影響を分析することが有用です。
IPv4 packets have a variable-length header size that allows for the use of IPv4 "options" -- optional information that may be of use to nodes processing IPv4 packets. The IPv4 header length is specified in the "Internet Header Length" (IHL) field of the mandatory IPv4 header and must be in the range of 20 octets (the minimum IPv4 header size) to 60 octets, accommodating at most 40 octets of options. The upper-layer protocol type is specified via the "Protocol" field of the mandatory IPv4 header.
IPv4パケットには、IPv4 "Options"の使用を可能にする可変長ヘッダーサイズがあります - IPv4パケットの処理をノードにするために使用できるオプションの情報。IPv4ヘッダーの長さは、必須IPv4ヘッダーの「Internet Header Length」（IHL）フィールドに指定されており、最大40オクテットのオプションに対応して、20オクテット（最小IPv4ヘッダーサイズ）から60オクテットの範囲内でなければなりません。上位層プロトコルタイプは、必須IPv4ヘッダーの「プロトコル」フィールドを介して指定されています。
Protocol, IHL
+--------+
| |
| v
+------//-----+------------------------+
| | |
| IPv4 | Upper-Layer |
| Header | Protocol |
| | |
+-----//------+------------------------+
variable length
<------------->
Figure 1: IPv4 Packet Structure
図1：IPv4パケット構造
IPv6 took a different approach to the IPv6 packet structure. Rather than employing a variable-length header as IPv4 does, IPv6 employs a packet structure similar to a linked list, where a mandatory fixed-length IPv6 header is followed by an arbitrary number of optional extension headers, with the upper-layer header being the last header in the IPv6 header chain. Each extension header typically specifies its length (unless it is implicit from the extension header type) and the "next header" (NH) type that follows in the IPv6 header chain.
IPv6はIPv6パケット構造に異なるアプローチを取りました。IPv4として可変長ヘッダを採用するのではなく、IPv6はリンクされたリストと同様のパケット構造を採用しています。ここで、必須の固定長IPv6ヘッダーの後には任意の数のオプションの拡張ヘッダーが続きます。IPv6ヘッダーチェーンの最後のヘッダー。各拡張ヘッダは通常、その長さ（拡張ヘッダの種類から暗黙的でない限り）と、IPv6ヘッダチェーンで次の「次へヘッダ」（NH）型を指定します。
NH NH, EH-length NH, EH-length
+-------+ +------+ +-------+
| | | | | |
| v | v | v
+-------------+-------------+-//-+---------------+--------------+
| | | | | |
| IPv6 | Ext. | | Ext. | Upper-Layer |
| header | Header | | Header | Protocol |
| | | | | |
+-------------+-------------+-//-+---------------+--------------+
fixed length variable number of EHs & length
<------------> <-------------------------------->
Figure 2: IPv6 Packet Structure
図2：IPv6パケット構造
This packet structure has the following implications:
このパケット構造には次のような意味があります。
* [RFC8200] requires the entire IPv6 header chain to be contained in the first fragment of a packet, therefore limiting the IPv6 header chain to the size of the path MTU.
* [RFC8200]パケットの最初のフラグメントにIPv6ヘッダーチェーン全体を含める必要があるため、IPv6ヘッダーチェーンをパスMTUのサイズに制限します。
* Other than the path MTU constraints, there are no other limits to the number of IPv6 EHs that may be present in a packet. Therefore, there is no upper limit regarding how deep into the IPv6 packet the upper-layer protocol header may be found.
* パスMTUの制約以外に、パケットに存在する可能性があるIPv6 EHSの数に他の制限はありません。したがって、IPv6パケットへの深さの上限は、上限プロトコルヘッダが見つかることができるかに関する上限はない。
* The only way for a node to obtain the upper-layer protocol type or find the upper-layer protocol header is to parse and process the entire IPv6 header chain, in sequence, starting from the mandatory IPv6 header until the last header in the IPv6 header chain is found.
* ノードが上位レイヤープロトコルタイプを取得する唯一の方法は、IPv6ヘッダーの最後のヘッダーから必須のIPv6ヘッダーから始めて、IPv6ヘッダーチェーン全体を順番に解析して処理することです。チェーンが見つかりました。
Some of the operational and security implications of IPv6 extension headers have been discussed in the IETF:
IPv6拡張ヘッダーの運用上およびセキュリティの影響のいくつかは、IETFで説明されています。
* [OPERATORS] discusses a rationale for which operators drop IPv6 fragments.
* [演算子]オペレータがIPv6フラグメントを削除する根拠を論じる。
* [HEADERS] discusses possible issues arising from "long" IPv6 header chains.
* [ヘッダー]「長い」IPv6ヘッダチェーンから発生する可能性のある問題について説明します。
* [PARSING] describes how inconsistencies in the way IPv6 packets with extension headers are parsed by different implementations could result in evasion of security controls and presents guidelines for parsing IPv6 extension headers, with the goal of providing a common and consistent parsing methodology for IPv6 implementations.
* [解析]拡張ヘッダを持つIPv6パケットが異なる実装によって解析される方法の矛盾は、セキュリティ管理の回避をもたらし、IPv6実装のための共通で一貫した解析方法論を提供することを目的として、IPv6拡張ヘッダーを解析するためのガイドラインを示しています。
* [IPV6-EH] analyzes the security implications of IPv6 EHs, as well as the operational implications of dropping packets that employ IPv6 EHs and associated options.
* [IPv6-EH] IPv6 EHSのセキュリティの影響、ならびにIPv6 EHSおよび関連するオプションを使用するパケットを削除することの操作的な意味を分析します。
* [RFC7113] discusses how some popular Router Advertisement Guard (RA-Guard) implementations are subject to evasion by means of IPv6 extension headers.
* [RFC7113]どのように普及したルータ広告ガード（RA-Guard）の実装がIPv6拡張ヘッダーによってどのように回避されるかについて説明します。
* [RFC8900] analyzes the fragility introduced by IP fragmentation.
* [RFC8900] IP断片化により導入された脆弱性を分析します。
A number of recent RFCs have discussed issues related to IPv6 extension headers and have specified updates to RFC 2460 [RFC2460] (an earlier version of the IPv6 standard). Many of these updates have now been incorporated into the current IPv6 core standard [RFC8200] or the IPv6 node requirements [RFC8504]. Namely,
いくつかの最近のRFCは、IPv6拡張ヘッダーに関連する問題について議論し、RFC 2460 [RFC2460]（以前のバージョンのIPv6規格）に更新を指定しました。これらのアップデートの多くは現在のIPv6コア標準[RFC8200]またはIPv6ノード要件[RFC8504]に組み込まれています。つまり
* [RFC5095] discusses the security implications of Routing Header Type 0 (RHT0) and deprecates it.
* [RFC5095]は、ルーティングヘッダータイプ0（rht0）のセキュリティの意味を説明し、それを廃止します。
* [RFC5722] analyzes the security implications of overlapping fragments and provides recommendations in this area.
* [RFC5722]オーバーラップフラッグメントのセキュリティの影響を分析し、この分野での推奨事項を提供します。
* [RFC7045] clarifies how intermediate nodes should deal with IPv6 extension headers.
* [RFC7045]中間ノードがIPv6拡張ヘッダーにどのように対処するべきかを明確にします。
* [RFC7112] discusses the issues arising in a specific fragmentation case where the IPv6 header chain is fragmented into two or more fragments and formally forbids such fragmentation.
* [RFC7112] IPv6ヘッダーチェーンが2つ以上のフラグメントに細分化され、そのような断片化を表現することを規則的に禁止する特定の断片化の場合に発生する問題について説明します。
* [RFC6946] discusses a flawed (but common) processing of the so-called IPv6 "atomic fragments" and specifies improved processing of such packets.
* [RFC6946]は、いわゆるIPv6「原子断片」の欠陥（しかし一般的な）処理について説明し、そのようなパケットの改善された処理を指定する。
* [RFC8021] deprecates the generation of IPv6 atomic fragments.
* [RFC8021] IPv6原子断片の生成を廃止する。
* [RFC8504] clarifies processing rules for packets with extension headers and also allows hosts to enforce limits on the number of options included in IPv6 EHs.
* [RFC8504]拡張ヘッダーを持つパケットの処理規則を明確にし、またIPv6 EHSに含まれるオプションの数に対してホストが制限を強制することを可能にします。
* [RFC7739] discusses the security implications of predictable fragment Identification values and provides recommendations for the generation of these values.
* [RFC7739]予測可能なフラグメント識別値のセキュリティの意味を説明し、これらの値を生成するための推奨事項を提供します。
* [RFC6980] analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery for IPv6 and formally recommends against such usage.
* [RFC6980] IPv6の隣接発見でIPv6フラグメンテーションを採用するというセキュリティの意味を分析し、その使用法に対して正式に推奨します。
Additionally, [RFC8200] has relaxed the requirement that "all nodes must examine and process the Hop-by-Hop Options header" from [RFC2460], by specifying that only nodes that have been explicitly configured to process the Hop-by-Hop Options header are required to do so.
さらに、[RFC8200]は、ホップバイホップオプションを処理するように明示的に構成されているノードのみを指定することで、[すべてのノードが[RFC2460]から「ホップバイホップオプションヘッダー」の「ホップバイホップオプションヘッダー」から「検討して処理する必要があります」という要件を緩和しました。ヘッダーはそうする必要があります。
A number of studies have measured the extent to which packets employing IPv6 extension headers are dropped in the public Internet:
いくつかの研究は、IPv6拡張ヘッダを使用しているパケットがパブリックインターネットでドロップされる範囲を測定した。
* [PMTUD-Blackholes] and [Linkova-Gont-IEPG90] present some preliminary measurements regarding the extent to which packets containing IPv6 EHs are dropped in the public Internet.
* [PMTUD-Blackholes]と[Linkova-gont-iepg90]は、IPv6 EHSを含むパケットがパブリックインターネットでドロップされる範囲に関していくつかの予備的な測定を示しています。
* [RFC7872] presents more comprehensive results and documents the methodology used to obtain these results.
* [RFC7872]これらの結果を得るために使用された方法論には、より包括的な結果と文書を提示します。
* [Huston-2017] and [Huston-2020] measure packet drops resulting from IPv6 fragmentation when communicating with DNS servers.
* [Huston-2017]と[Huston-2020] DNSサーバーと通信するときにIPv6フラグメンテーションから生じるパケットドロップを測定します。
Most contemporary carrier-grade routers use dedicated hardware, e.g., Application-Specific Integrated Circuits (ASICs) or Network Processing Units (NPUs), to determine how to forward packets across their internal fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One common method of handling next-hop lookups is to send a small portion of the ingress packet to a lookup engine with specialized hardware, e.g., ternary content-addressable memory (TCAM) or reduced latency dynamic random-access memory (RLDRAM), to determine the packet's next hop. Technical constraints mean that there is a trade-off between the amount of data sent to the lookup engine and the overall packet-forwarding rate of the lookup engine. If more data is sent, the lookup engine can inspect further into the packet, but the overall packet-forwarding rate of the system will be reduced. If less data is sent, the overall packet-forwarding rate of the router will be increased, but the packet lookup engine may not be able to inspect far enough into a packet to determine how it should be handled.
ほとんどの現代的なキャリアグレードルータは、専用のハードウェア、例えばアプリケーション固有の集積回路（ASIC）またはネットワーク処理装置（NPU）を使用して、内部ファブリックを横切ってパケットを転送する方法を決定します（[IEPG94-Scudder]および[APNIC-SCUDDER] ] 詳細については）。ネクストホップルックアップを処理する一般的な方法の1つは、専用のハードウェア、例えば3値コンテンツアドレス指定可能メモリ（TCAM）またはレイテンシダイナミックランダムアクセスメモリ（RLDRAM）を備えたルックアップエンジンに入力パケットの小部分を送信することです。パケットのネクストホップを決定します。技術的制約は、ルックアップエンジンに送信されたデータ量とルックアップエンジンのパケット転送速度の全体的なパケット転送率との間にトレードオフがあることを意味します。より多くのデータが送信された場合、ルックアップエンジンはパケット内にさらに検査することができますが、システムの全体的なパケット転送速度が短縮されます。より少ないデータが送信された場合、ルータの全体的なパケット転送速度が増加しますが、パケットルックアップエンジンはパケットに十分なほど十分に検査できない場合があります。
| NOTE:
|
| For example, some contemporary high-end routers are known to
| inspect up to 192 bytes, while others are known to parse up
| to 384 bytes of header.
If a hardware-forwarding engine on a contemporary router cannot make a forwarding decision about a packet because critical information is not sent to the lookup engine, then the router will normally drop the packet. Section 7 discusses some of the reasons for which a contemporary router might need to access Layer 4 information to make a forwarding decision.
クリティカルな情報がルックアップエンジンに送信されないため、現代のルータのハードウェア転送エンジンがパケットに関する転送決定を下すことができない場合、ルータは通常パケットをドロップします。セクション7は、現代のルータが転送決定をするためにレイヤ4情報にアクセスする必要があるかもしれない理由のいくつかを論じています。
Historically, some packet-forwarding engines punted packets of this kind to the control plane for more in-depth analysis, but this is unfeasible on most contemporary router architectures as a result of the vast difference between the hardware-based forwarding capacity of the router and the processing capacity of the control plane and the size of the management link that connects the control plane to the forwarding plane. Other platforms may have a separate software-based forwarding plane that is distinct both from the hardware-based forwarding plane and the control plane. However, the limited CPU resources of this software-based forwarding plane, as well as the limited bandwidth of the associated link, results in similar throughput constraints.
歴史的には、いくつかのパケット転送エンジンは、より詳細な分析のためにこの種のパケットをコントロールプレーンに釣り合っていたが、これはルータのハードウェアベースの転送容量の間の膨大な違いの結果として、ほとんどの現代のルータアーキテクチャ上で実行不可能である。制御面の処理能力および制御面を転送面に接続する管理リンクのサイズ。他のプラットフォームは、ハードウェアベースの転送プレーンと制御プレーンの両方から異なる別のソフトウェアベースの転送プレーンを有することができる。しかしながら、このソフトウェアベースの転送プレーンの制限されたCPUリソース、ならびに関連するリンクの限られた帯域幅は、同様のスループットの制約をもたらす。
If an IPv6 header chain is sufficiently long such that it exceeds the packet lookup capacity of the router, the router might be unable to determine how the packet should be handled and thus could resort to dropping the packet.
IPv6ヘッダーチェーンがルーターのパケットルックアップ容量を超えるように十分に長い場合、ルータはパケットの処理方法を決定できないため、パケットのドロップに頼ることができます。
Although type-length-value (TLV) chains are amenable to iterative processing on architectures that have packet lookup engines with deep inspection capabilities, some packet-forwarding engines manage IPv6 header chains using recirculation. This approach processes extension headers one at a time: when processing on one extension header is completed, the packet is looped back through the processing engine again. This recirculation process continues repeatedly until there are no more extension headers left to be processed.
Type-Length-Value（TLV）チェーンは、ディープ検査機能を備えたパケット検索エンジンを持つアーキテクチャの反復処理に適していますが、パケット転送エンジンによっては再循環を使用してIPv6ヘッダーチェーンを管理します。このアプローチは一度に拡張ヘッダを処理する：1つの拡張ヘッダ上で処理が完了すると、パケットは再び処理エンジンを介してループバックされる。この再循環プロセスは、処理されるべきよりこれ以上拡張ヘッダがなくなるまで繰り返し続けている。
Recirculation is typically used on packet-forwarding engines with limited lookup capability, because it allows arbitrarily long header chains to be processed without the complexity and cost associated with packet-forwarding engines, which have deep lookup capabilities. However, recirculation can impact the forwarding capacity of hardware, as each packet will pass through the processing engine multiple times. Depending on configuration, the type of packets being processed, and the hardware capabilities of the packet-forwarding engine, the data-plane throughput performance on the router might be negatively affected.
再循環は通常、Lookup能力が限られているパケット転送エンジンで使用されます。なぜなら、任意の長いヘッダーチェーンをパケット転送エンジンに関連付けずに、深いルックアップ機能を持ちます。しかしながら、各パケットが処理エンジンを複数回通過するので、再循環はハードウェアの転送容量に影響を与える可能性がある。構成に応じて、処理中のパケットの種類、およびパケット転送エンジンのハードウェア機能、ルータのデータプレーンスループットパフォーマンスが悪影響を受ける可能性があります。
7. Requirement to Process Layer 3 / Layer 4 Information in Intermediate Systems
7. 中間システムにおけるレイヤ3 /レイヤ4情報を処理するための要件
The following subsections discuss some of the reasons for which intermediate systems may need to process Layer 3 / Layer 4 information to make a forwarding decision.
以下のサブセクションは、中間システムが転送決定を下すためにレイヤ3 /レイヤ4情報を処理する必要があるかもしれないいくつかの理由について説明する。
In the case of Equal Cost Multipath (ECMP) load sharing, the intermediate system needs to make a decision regarding which of its interfaces to use to forward a given packet. Since round-robin usage of the links is usually avoided to prevent packet reordering, forwarding engines need to use a mechanism that will consistently forward the same data streams down the same forwarding paths. Most forwarding engines achieve this by calculating a simple hash using an n-tuple gleaned from a combination of Layer 2 through to Layer 4 protocol header information. This n-tuple will typically use the src/dst Media Access Control (MAC) addresses, src/dst IP addresses, and, if possible, further Layer 4 src/dst port information.
等価コストマルチパス（ECMP）負荷分散の場合、中間システムは、そのインタフェースのどのインタフェースを使用して所与のパケットを転送するために決定する必要がある。ラウンドロビン使用量は通常、パケットの並べ替えを防ぐために回避されるので、転送エンジンは、同じデータストリームを同じ転送パスに常に転送するメカニズムを使用する必要がある。ほとんどの転送エンジンは、レイヤ2からレイヤ4プロトコルヘッダ情報への組み合わせから集められたNタプルを使用して単純なハッシュを計算することによってこれを達成する。このNタプルは通常、SRC / DSTメディアアクセス制御（MAC）アドレス、SRC / DST IPアドレス、および可能であれば、さらにレイヤ4 SRC / DSTポート情報を使用します。
In the IPv6 world, flows are expected to be identified by means of the IPv6 "Flow Label" [RFC6437]. Thus, ECMP and hash-based load sharing should be possible without the need to process the entire IPv6 header chain to obtain upper-layer information to identify flows. [RFC7098] discusses how the IPv6 Flow Label can be used to enhance Layer 3/4 load distribution and balancing for large server farms.
IPv6の世界では、フローはIPv6 "Flow Label" [RFC6437]によって識別されると予想されます。したがって、フローを識別するために上位層情報を取得するために、IPv6ヘッダチェーン全体を処理する必要なしに、ECMPおよびハッシュベースの負荷分散を可能にする必要がある。[RFC7098] IPv6フローラベルを使用して、Layer 3/4負荷分散と大規模なサーバーファームのバランスをとることができる方法について説明します。
Historically, many IPv6 implementations failed to set the Flow Label, and hash-based ECMP/load-sharing devices also did not employ the Flow Label for performing their task. While support of [RFC6437] is currently widespread for current versions of all popular host implementations, there is still only marginal usage of the IPv6 Flow Label for ECMP and load balancing [Almeida-2020]. A contributing factor could be the issues that have been found in host implementations and middleboxes [Jaeggli-2018].
歴史的に、多くのIPv6実装はフローラベルを設定できず、ハッシュベースのECMP / Load-Sharingデバイスもタスクを実行するためのフローラベルを使用しませんでした。[RFC6437]のサポートは現在、一般的なホスト実装の現在のバージョンにとって広範囲に普及していますが、ECMPのIPv6フローラベルの限界使用、almeida-2020]。貢献要因は、ホスト実装とミドルボックス[JAEGGLI-2018]で見つかった問題です。
Clearly, widespread support of [RFC6437] would relieve intermediate systems from having to process the entire IPv6 header chain, making Flow Label-based ECMP and load sharing [RFC6438] feasible.
明らかに、[RFC6437]の広範なサポートは、IPv6ヘッダーチェーン全体を処理し、フローラベルベースのECMPとロードシェアリングを実行できるようにすることを可能にします。
If an intermediate system cannot determine consistent n-tuples for calculating flow hashes, data streams are more likely to end up being distributed unequally across ECMP and load-shared links. This may lead to packet drops or reduced performance.
フローハッシュを計算するための中間システムが一貫したN-タプルを決定できない場合、データストリームはECMPおよびロード共有リンク間で不等に分散される可能性が高いです。これにより、パケットが低下したり、パフォーマンスが低下したりする可能性があります。
Infrastructure Access Control Lists (iACLs) drop unwanted packets destined to a network's infrastructure. Typically, iACLs are deployed because external direct access to a network's infrastructure addresses is operationally unnecessary and can be used for attacks of different sorts against router control planes. To this end, traffic usually needs to be differentiated on the basis of Layer 3 or Layer 4 criteria to achieve a useful balance of protection and functionality. For example, an infrastructure may be configured with the following policy:
インフラストラクチャアクセス制御リスト（IACLS）ネットワークのインフラストラクチャ宛ての不要なパケットを削除します。通常、ネットワークのインフラストラクチャアドレスへの外部直接アクセスが動作上不要で、ルータ制御プレーンに対するさまざまな種類の攻撃に使用できるため、IACLは展開されています。この目的のために、トラフィックは通常、保護と機能性の有用なバランスを達成するために、レイヤ3またはレイヤ4の基準に基づいて区別される必要があります。たとえば、インフラストラクチャは次のポリシーで設定できます。
* Permit some amount of ICMP echo (ping) traffic towards a router's addresses for troubleshooting.
* トラブルシューティングのためにルータのアドレスに向かってある程度のICMPエコー（PING）トラフィックを許可します。
* Permit BGP sessions on the shared network of an exchange point (potentially differentiating between the amount of packets/second permitted for established sessions and for connection establishment), but do not permit other traffic from the same peer IP addresses.
* 交換点の共有ネットワーク上のBGPセッションを許可する（確立されたセッションのパケットの量/秒の間を区別し、接続確立のために区別される）が、同じピアIPアドレスから他のトラフィックを許可しない。
If a forwarding router cannot determine consistent n-tuples for calculating flow hashes, data streams are more likely to end up being distributed unequally across ECMP and load-shared links. This may lead to packet drops or reduced performance.
転送ルータがフローハッシュを計算するための一貫したNタプルを決定できない場合、データストリームは、ECMPおよびロード共有リンク間で不等に分散される可能性が高い。これにより、パケットが低下したり、パフォーマンスが低下したりする可能性があります。
If a network cannot deploy infrastructure ACLs, then the security of the network may be compromised as a result of the increased attack surface.
ネットワークがインフラストラクチャACLを展開できない場合、ネットワークのセキュリティは攻撃面の増加の結果として損なわれる可能性があります。
The case of customer Distributed Denial-of-Service (DDoS) protection and edge-to-core customer protection filters is similar in nature to the iACL protection. Similar to iACL protection, Layer 4 ACLs generally need to be applied as close to the edge of the network as possible, even though the intent is usually to protect the customer edge rather than the provider core. Application of Layer 4 DDoS protection to a network edge is often automated using BGP Flowspec [RFC8955] [RFC8956].
顧客分散サービス拒否（DDOS）保護とエッジ間の顧客保護フィルタの場合は、IACL保護と本質的に類似しています。IACL保護と同様に、レイヤ4 ACLは通常、インテントが通常プロバイダコアではなく顧客エッジを保護するために可能な限りネットワークの端部に近いものとして適用する必要があります。ネットワークエッジへのレイヤ4 DDOS保護の適用は、BGP Flowspec [RFC8955] [RFC8956]を使用して自動化されます。
For example, a website that normally only handles traffic on TCP ports 80 and 443 could be subject to a volumetric DDoS attack using NTP and DNS packets with a randomized source IP address, thereby rendering source-based remote triggered black hole [RFC5635] mechanisms useless. In this situation, ACLs that provide DDoS protection could be configured to block all UDP traffic at the network edge without impairing the web server functionality in any way. Thus, being able to block arbitrary protocols at the network edge can avoid DDoS-related problems both in the provider network and on the customer edge link.
たとえば、TCPポート80および443上のトラフィックを通常扱うWebサイトは、ランダム化された送信元IPアドレスを持つNTPパケットとDNSパケットを使用したボリュメトリックDDOS攻撃を受ける可能性があり、それによってソースベースのリモートトリガーブラックホール[RFC5635]メカニズムを無駄にします。。この状況では、DDOS保護を提供するACLは、Webサーバの機能を損なうことなく、ネットワークエッジですべてのUDPトラフィックをブロックするように設定できます。したがって、ネットワークエッジで任意のプロトコルをブロックすることができることは、プロバイダネットワークおよびカスタマーエッジリンクの両方でDDOS関連の問題を回避することができる。
Network Intrusion Detection Systems (NIDS) examine network traffic and try to identify traffic patterns that can be correlated to network-based attacks. These systems generally attempt to inspect application-layer traffic (if possible) but, at the bare minimum, inspect Layer 4 flows. When attack activity is inferred, the operator is notified of the potential intrusion attempt.
ネットワーク侵入検知システム（NIDS）ネットワークトラフィックを調べて、ネットワークベースの攻撃に関連付けることができるトラフィックパターンを識別します。これらのシステムは一般的に（可能であれば）アプリケーション層のトラフィックを検査しようとしますが、最小の裸で、検査層4の流れを点検します。攻撃活動が推測されると、潜在的な侵入試行が潜在的な侵入試行が通知されます。
Network Intrusion Prevention Systems (IPS) operate similarly to NIDSs, but they can also prevent intrusions by reacting to detected attack attempts by e.g., triggering packet filtering policies at firewalls and other devices.
ネットワーク侵入防止システム（IPS）はNIDSSと同様に動作しますが、それらは、例えば、ファイアウォールや他のデバイスでのパケットフィルタリングポリシーをトリガすることによって、検出された攻撃試行に反応することによって侵入を防ぐことができます。
Use of extension headers can be problematic for NIDS/IPS, since:
以来、拡張ヘッダの使用はNIDS / IPSにとって問題となる可能性があります。
* Extension headers increase the complexity of resulting traffic and the associated work and system requirements to process it.
* 拡張ヘッダーは、その結果のトラフィックの複雑さとそれを処理するための関連する作業とシステム要件の複雑さを高めます。
* Use of unknown extension headers can prevent a NIDS or IPS from processing Layer 4 information.
* 未知の拡張ヘッダの使用は、レイヤ4情報を処理するNIDSまたはIPSが妨げられることがある。
* Use of IPv6 fragmentation requires a stateful fragment-reassembly operation, even for decoy traffic employing forged source addresses (see, e.g., [nmap]).
* IPv6フラグメンテーションの使用は、鍛造された送信元アドレスを使用するデコイトラフィックでさえも、ステートフルフラグメント再構成操作を必要とする（例えば、[NMAP]参照）。
As a result, in order to increase the efficiency or effectiveness of these systems, packets employing IPv6 extension headers are often dropped at the network ingress point(s) of networks that deploy these systems.
その結果、これらのシステムの効率や有効性を高めるために、IPv6拡張ヘッダーを採用したパケットは、これらのシステムを展開するネットワークのネットワーク入力ポイントで低下します。
Firewalls enforce security policies by means of packet filtering. These systems usually inspect Layer 3 and Layer 4 traffic but can often also examine application-layer traffic flows.
ファイアウォールはパケットフィルタリングによってセキュリティポリシーを強制します。これらのシステムは通常、レイヤ3とレイヤ4のトラフィックを検査しますが、アプリケーション層のトラフィックフローも検証できます。
As with a NIDS or IPS (Section 7.4), use of IPv6 extension headers can represent a challenge to network firewalls, since:
NIDSまたはIPSと同様に（セクション7.4）、IPv6拡張ヘッダーの使用は、次のものなので、ネットワークファイアウォールへのチャレンジを表すことができます。
* Extension headers increase the complexity of resulting traffic and the associated work and system requirements to process it, as outlined in [Zack-FW-Benchmark].
* 拡張ヘッダーは、[Zack-FW-Benchmark]で概説されているように、その結果のトラフィックとそれを処理するための関連する作業とシステム要件の複雑さを高めます。
* Use of unknown extension headers can prevent firewalls from processing Layer 4 information.
* 未知の拡張ヘッダを使用すると、ファイアウォールがレイヤ4情報を処理するのを防ぐことができます。
* Use of IPv6 fragmentation requires a stateful fragment-reassembly operation, even for decoy traffic employing forged source addresses (see, e.g., [nmap]).
* IPv6フラグメンテーションの使用は、鍛造された送信元アドレスを使用するデコイトラフィックでさえも、ステートフルフラグメント再構成操作を必要とする（例えば、[NMAP]参照）。
Additionally, a common firewall filtering policy is the so-called "default deny", where all traffic is blocked (by default), and only expected traffic is added to an "allow/accept list".
さらに、一般的なファイアウォールフィルタリングポリシーは、すべてのトラフィックがブロックされています（デフォルト）、「許可/ accept list」に期待されるトラフィックだけが追加されます。
As a result, packets employing IPv6 extension headers are often dropped by network firewalls, either because of the challenges represented by extension headers or because the use of IPv6 extension headers has not been explicitly allowed.
その結果、IPv6拡張ヘッダーを使用するパケットは、拡張ヘッダーによって表される課題のため、またはIPv6拡張ヘッダーの使用が明示的に許可されていないため、ネットワークファイアウォールによってドロップされることがよくあります。
Note that although the data presented in [Zack-FW-Benchmark] was several years old at the time of publication of this document, many contemporary firewalls use comparable hardware and software architectures; consequently, the conclusions of this benchmark are still relevant, despite its age.
[Zack-FWベンチマーク]に表示されているデータは、この文書の公開時に数年前のデータであるが、現代の多くのファイアウォールは同等のハードウェアとソフトウェアアーキテクチャを使用しています。その結果、このベンチマークの結論は、その年齢にもかかわらず依然として関連性があります。
As discussed in Section 7, intermediate systems that need to find the Layer 4 header must process the entire IPv6 header chain. When such devices are unable to obtain the required information, the forwarding device has the option to drop the packet unconditionally, forward the packet unconditionally, or process the packet outside the normal forwarding path. Forwarding packets unconditionally will usually allow for the circumvention of security controls (see, e.g., Section 7.5), while processing packets outside of the normal forwarding path will usually open the door to Denial-of-Service (DoS) attacks (see, e.g., Section 6). Thus, in these scenarios, devices often simply resort to dropping such packets unconditionally.
セクション7で説明したように、レイヤ4ヘッダーを見つける必要がある中間システムは、IPv6ヘッダーチェーン全体を処理しなければなりません。そのような装置が必要な情報を取得することができない場合、転送装置は無条件にパケットをドロップし、無条件にパケットを転送すること、または通常の転送経路の外側にパケットを処理することができる。パケットを無条件に転送すると、通常はセキュリティコントロールの回避が可能になります（例7.5を参照）、通常の転送経路の外側のパケットの処理は通常、サービス拒否（DOS）攻撃へのドアを開く（など）。セクション6）。したがって、これらのシナリオでは、デバイスはしばしばそのようなパケットを無条件にドロップすることに頼ることがよくあります。
Most contemporary carrier-grade routers have a fast hardware-assisted forwarding plane and a loosely coupled control plane, connected together with a link that has much less capacity than the forwarding plane could handle. Traffic differentiation cannot be performed by the control plane because this would overload the internal link connecting the forwarding plane to the control plane.
ほとんどの現代的なキャリアグレードのルータは、転送面よりもはるかに少ない容量を持つリンクとともに接続された高速ハードウェアアシスト転送面と疎結合制御面を持ちます。これにより、転送面をコントロールプレーンに接続する内部リンクがオーバーロードされるため、トラフィックの微分を制御することはできません。
The Hop-by-Hop Options header has been particularly challenging since, in most circumstances, the corresponding packet is punted to the control plane for processing. As a result, many operators drop IPv6 packets containing this extension header [RFC7872]. [RFC6192] provides advice regarding protection of a router's control plane.
ホップバイホップオプションヘッダは、ほとんどの場合、対応するパケットが処理のために制御面にパントされているので特に困難である。その結果、多くの演算子はこの拡張ヘッダ[RFC7872]を含むIPv6パケットを削除します。[RFC6192]ルータの制御面の保護に関するアドバイスを提供します。
Some intermediate systems do not have support for fine-grained filtering of IPv6 extension headers. For example, an operator that wishes to drop packets containing RHT0 may only be able to filter on the extension header type (Routing Header). This could result in an operator enforcing a coarser filtering policy (e.g., "drop all packets containing a Routing Header" vs. "only drop packets that contain a Routing Header Type 0").
いくつかの中間システムは、IPv6拡張ヘッダーの微細な粒子フィルタリングをサポートしていません。たとえば、rht0を含むパケットを削除したいオペレータは、拡張ヘッダータイプ（ルーティングヘッダー）でのみフィルタリングできます。これにより、オペレータがより粗いフィルタリングポリシーを強制することがある（例えば、ルーティングヘッダタイプ0を含むルーティングヘッダを含むすべてのパケットが「ルーティングヘッダを含む全パケットをドロップする」ということをもたらす可能性がある。
The security implications of IPv6 extension headers generally fall into one or more of these categories:
IPv6拡張ヘッダーのセキュリティへの影響は、一般的にこれらのカテゴリのうちの1つ以上に分類されます。
* Evasion of security controls
* セキュリティ管理の回避
* DoS due to processing requirements
* 処理要件によるDOS
* DoS due to implementation errors
* 実装エラーによるDOS
* Issues specific to the extension header type
* 拡張ヘッダータイプに固有の問題
Unlike IPv4 packets where the upper-layer protocol can be trivially found by means of the IHL field of the IPv4 header, the structure of IPv6 packets is more flexible and complex. This can represent a challenge for devices that need to find this information, since locating upper-layer protocol information requires that all IPv6 extension headers be examined. In turn, this presents implementation difficulties, since some packet-filtering mechanisms that require upper-layer information (even if just the upper-layer protocol type) can be trivially circumvented by inserting IPv6 extension headers between the main IPv6 header and the upper-layer protocol header. [RFC7113] describes this issue for the RA-Guard case, but the same techniques could be employed to circumvent other IPv6 firewall and packet-filtering mechanisms. Additionally, implementation inconsistencies in packet-forwarding engines can result in evasion of security controls [PARSING] [Atlasis2014] [BH-EU-2014].
IPv4ヘッダーのIHLフィールドによって上位レイヤプロトコルを簡潔に見つけることができるIPv4パケットとは異なり、IPv6パケットの構造はより柔軟で複雑です。上位レイヤプロトコル情報を見つけるためには、すべてのIPv6拡張ヘッダーを検査する必要があるため、この情報を見つける必要があるデバイスに対する課題を表すことができます。次に、これは、メインIPv6ヘッダーと上位層の間にIPv6拡張ヘッダーを挿入することによって上層の情報を必要とするいくつかのパケットフィルタリングメカニズムを実際に回避できるため、これは実装困難を示しています。プロトコルヘッダー[RFC7113] RA-Guardの場合についてこの問題を説明していますが、他のIPv6ファイアウォールとパケットフィルタリングメカニズムを回避するために同じ技術を採用することができます。さらに、パケット転送エンジンにおける実装の不一致は、セキュリティ管理の回避をもたらすことができます[解析] [ATLASIS2014] [BH-EU-2014]。
Sometimes, packets with IPv6 extension headers can impact throughput performance on intermediate systems. Unless appropriate mitigations are put in place (e.g., packet dropping and/or rate limiting), an attacker could simply send a large amount of IPv6 traffic employing IPv6 extension headers with the purpose of performing a DoS attack (see Sections 6.1 and 8 for further details). The extent to which performance is affected on these devices is implementation dependent.
時には、IPv6拡張ヘッダーを持つパケットは、中間システムでスループット性能に影響を与える可能性があります。適切な緩和が適切に配置されていない限り（パケットドロップおよび/またはレート制限）、攻撃者は単にDOS攻撃を実行する目的でIPv6拡張ヘッダーを使用して大量のIPv6トラフィックを送信することができます（さらにセクション6.1および8を参照）。詳細）。これらのデバイスにどのパフォーマンスが影響を受ける範囲は実装に依存しています。
| NOTE:
|
| In the most trivial case, a packet that includes a Hop-by-
| Hop Options header might go through the slow forwarding
| path, to be processed by the router's CPU. Alternatively, a
| router configured to enforce an ACL based on upper-layer
| information (e.g., upper-layer protocol type or TCP
| Destination Port) may need to process the entire IPv6 header
| chain in order to find the required information, thereby
| causing the packet to be processed in the slow path
| [Cisco-EH-Cons]. We note that, for obvious reasons, the
| aforementioned performance issues can affect devices such as
| firewalls, NIDSs, etc. [Zack-FW-Benchmark].
IPv6 implementations, like all other software, tend to mature with time and wide-scale deployment. While the IPv6 protocol itself has existed for over 20 years, serious bugs related to IPv6 extension header processing continue to be discovered (see, e.g., [Cisco-Frag], [Microsoft-SA], and [FreeBSD-SA]). Because there is currently little operational reliance on IPv6 extension headers, the corresponding code paths are rarely exercised, and there is the potential for bugs that still remain to be discovered in some implementations.
他のすべてのソフトウェアと同様に、IPv6実装は、時間と広範な展開とともに成熟する傾向があります。IPv6プロトコル自体が20年以上存在していますが、IPv6拡張ヘッダー処理に関連する深刻なバグは発見され続けています（例えば、[Cisco-Frag]、[Microsoft-SA]、[FreeBSD-SA]）。現在、IPv6拡張ヘッダーへの動作依存がほとんどないため、対応するコードパスはめったに行使されず、いくつかの実装ではまだ発見されていないバグの可能性があります。
The IPv6 Fragment Header is employed for the fragmentation and reassembly of IPv6 packets. While many of the security implications of the fragmentation/reassembly mechanism are known from the IPv4 world, several related issues have crept into IPv6 implementations. These range from DoS attacks to information leakages, as discussed in [RFC7739], [Bonica-NANOG58], and [Atlasis2012].
IPv6フラグメントヘッダーは、IPv6パケットの断片化および再組み立てに使用されます。断片化/再構成メカニズムのセキュリティの影響の多くはIPv4の世界から知られていますが、いくつかの関連する問題はIPv6実装に分かりました。[RFC7739]、[Bonica-Nanog58]、および[Atlasis2012]で説明したように、DOS攻撃から情報漏洩までのこれらの範囲。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security implications of IPv6 extension headers are discussed in Section 8.4. This document does not introduce any new security issues.
IPv6拡張ヘッダーのセキュリティ上の影響については、セクション8.4で説明します。この文書は新しいセキュリティ上の問題を紹介しません。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095]能力、J.、Savola、P.、およびG.Nville-Neil、「IPv6のルーティングヘッダの脱落」、RFC 5095、DOI 10.17487 / RFC5095、2007年12月、<https：//www.rfc-editor.org/info/rfc5095>。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <https://www.rfc-editor.org/info/rfc5722>.
[RFC5722] Krishnan、S。、「重複するIPv6フラグメントの取り扱い」、RFC 5722、DOI 10.17487 / RFC5722、2009年12月、<https：//www.rfc-editor.org/info/rfc5722>。
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, <https://www.rfc-editor.org/info/rfc6946>.
[RFC6946]、F.、「IPv6の処理」アトミック「フラグメント」、RFC 6946、DOI 10.17487 / RFC6946、2013年5月、<https：//www.rfc-editor.org/info/rfc6946>。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, <https://www.rfc-editor.org/info/rfc6980>.
[RFC6980] Gont、F。、「IPv6隣接ディスカバリーによるIPv6フラグメンテーションのセキュリティの意味」、RFC 6980、DOI 10.17487 / RFC6980、2013年8月、<https：//www.rfc-editor.org/info/rfc6980>。
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, <https://www.rfc-editor.org/info/rfc7112>.
[RFC7112] Gont、F.、Manral、V.およびR. Bonica、「特大IPv6ヘッダーチェーンの意味」、RFC 7112、DOI 10.17487 / RFC7112、2014年1月、<https：//www.rfc-editor.org/ info / rfc7112>。
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", RFC 8021, DOI 10.17487/RFC8021, January 2017, <https://www.rfc-editor.org/info/rfc8021>.
[RFC8021]ゴント、F.、Liu、W.およびT.アンダーソン、「有害と考えられているIPv6原子フラグメントの生成」、RFC 8021、DOI 10.17487 / RFC8021、2017年1月、<https：//www.rfc-編集者。org / info / rfc8021>。
[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>。
[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>。
[Almeida-2020] Almeida, R., Cunha, I., Teixeira, R., Veitch, D., and C. Diot, "Classification of Load Balancing in the Internet", IEEE INFOCOM 2020, DOI 10.1109/INFOCOM41043.2020.9155387, July 2020, <https://homepages.dcc.ufmg.br/~cunha/papers/ almeida20infocom-mca.pdf>.
[Almeida-2020] Almeida、R.、Cunha、I.、Teixeira、R.、Veitch、D.、およびC. DIOT、「インターネットにおける負荷分散の分類」、IEEE Infocom 2020、DOI 10.1109 / INFOCOM 41043.2020.91553872020年7月、<https：//homepages.dcc.ufmg.br/~cunha/papers/ almeida20infocom-mca.pdf>。
[APNIC-Scudder] Scudder, J., "Modern router architecture and IPv6", APNIC Blog, June 2020, <https://blog.apnic.net/2020/06/04/ modern-router-architecture-and-ipv6/>.
[APNIC-SCUDDER] Scudder、J.、Modern Router ArchitectureおよびIPv6 "、Apnic Blog、2020年6月、<https：//blog.apnic.net/2020/06/04/現代ルーター - アーキテクチャー-および-IPv6/>。
[Atlasis2012] Atlasis, A., "Attacking IPv6 Implementation Using Fragmentation", Black Hat Europe 2012, March 2012, <https://void.gr/kargig/ipv6/bh-eu-12-Atlasis-Attacking_IPv6-Slides.pdf>.
[ATLASIS2012] Atlasis、A。、「フラグメンテーションを使用したIPv6実装の攻撃」、ブラックハットヨーロッパ2012、2012年3月、<https：//void.gr/kargig/ipv6/bh-eu-12-atlasis-attacking_ipv6-slides.pdf>。
[Atlasis2014] Atlasis, A., "A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices", May 2014, <http://www.insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices/>.
[ATLASIS2014] Atlasis、A。、「IPv6セキュリティデバイスを回避するためのIPv6拡張ヘッダを乱用する新規方法」、<http://www.insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices />。
[BH-EU-2014] Atlasis, A., Rey, E., and R. Schaefer, "Evasion of High-End IDPS Devices at the IPv6 Era", Black Hat Europe 2014, 2014, <https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf>.
[BH-EU-2014] Atlasis、A.、Rey、E.、R.Schaefer、「IPv6時代のハイエンドIDPSデバイスの回避」、ブラックハットヨーロッパ2014,2014、<https：// www。ernw.de/download/eu-14- atlasis-rey-schaefer-briefings-evasion-of-highend-ips-devices-wp.pdf>
[Bonica-NANOG58] Bonica, R., "IPv6 Fragmentation: The Case For Deprecation", NANOG 58, June 2013, <https://www.nanog.org/sites/default/files/ mon.general.fragmentation.bonica.pdf>.
[Bonica-Nanog58] Bonica、R.、 "IPv6フラグメンテーション：廃止予定の場合、Nanog 58、2013年6月、<https://www.nanog.org/sites/default/files/ mon.general.fragmentation.boonica.pdf>。
[Cisco-EH-Cons] Cisco, "IPv6 Extension Headers Review and Considerations", October 2006, <http://www.cisco.com/en/US/technologies/tk648/tk872/ technologies_white_paper0900aecd8054d37d.pdf>.
[Cisco-EH-SONS]シスコ、「IPv6拡張ヘッダーレビューと考慮事項」、2006年10月、<http://www.cisco.com/en/us/technologies/tk648/tk872/ technologies_white_papay0900aecd8054d37d.pdf>。
[Cisco-Frag] Cisco, "Cisco IOS XR Software Crafted IPv6 Packet Denial of Service Vulnerability", June 2015, <http://tools.cisco.com/security/center/content/ CiscoSecurityAdvisory/cisco-sa-20150611-iosxr>.
[Cisco-Frag] Cisco、「Cisco IOS XRソフトウェアは、IPv6パケット脆弱性脆弱性」、2015年6月、<http://tools.cisco.com/security/Center/Content/ CiscoSecurityAdvisory / Cisco-SA-20150611-IOSXR>。
[FreeBSD-SA] The FreeBSD Project, "IPv6 Hop-by-Hop options use-after-free bug", September 2020, <https://www.freebsd.org/security/advisories/FreeBSD-SA-20:24.ipv6.asc>.
[FreeBSD-SA] FreeBSDプロジェクト、「IPv6ホップバイホップオプションを使用しています」、2020年9月、<https://www.freebsdd.org/security/advisories/FreeBSD-SA-20:24.ipv6.ass>。
[HEADERS] Kumari, W., Jaeggli, J., Bonica, R. P., and J. Linkova, "Operational Issues Associated With Long IPv6 Header Chains", Work in Progress, Internet-Draft, draft-wkumari-long-headers-03, 16 June 2015, <https://datatracker.ietf.org/doc/html/draft-wkumari-long-headers-03>.
[ヘッダ]熊線、W.、Jaeggli、J.、Bonica、RP、J. Linkova、「長いIPv6ヘッダチェーンに関連する運用上の問題」、進行中の作業、インターネットドラフト、ドラフトWKUMARI-LONG-HEADERS-03、2015年6月16日、<https://datatracker.ietf.org/doc/html/draft-wkumari-long-headers-03>
[Huston-2017] Huston, G., "Dealing with IPv6 fragmentation in the DNS", APNIC Blog, August 2017, <https://blog.apnic.net/2017/08/22/dealing-ipv6- fragmentation-dns/>.
[Huston-2017] Huston、G.、「DNSにおけるIPv6フラグメンテーションを扱う」、APNIC BLOG、2017年8月、<https://blog.apnic.net/2017/08/22/dealing-ipv6- fragmentation-dns/>。
[Huston-2020] Huston, G., "Measurement of IPv6 Extension Header Support", NPS/CAIDA 2020 Virtual IPv6 Workshop, June 2020, <https://www.cmand.org/workshops/202006-v6/ slides/2020-06-16-xtn-hdrs.pdf>.
[Huston-2020] Huston、G.、「IPv6拡張ヘッダの測定」、NPS / Caida 2020 Virtual IPv6ワークショップ、2020年6月、<https：//www.cmand.org/workshops/202006-v6/スライド/ 2020-06-16-XTN-HDRS.PDF>。
[IEPG94-Scudder] Petersen, B. and J. Scudder, "Modern Router Architecture for Protocol Designers", IEPG 94, November 2015, <http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf>.
[IEPG94-Scudder] Petersen、B.およびJ.Scudder、「プロトコルデザイナーのための現代ルーターアーキテクチャ」、IEPG 94、2015年11月、<http://www.iepg.org/2015-11-01-ietf94/iepg-routerArchitecture-jgs.pdf>。
[IPV6-EH] Gont, F. and W. Liu, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-08, 3 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-08>.
[IPv6-EH] Gont、F.およびW. Liu、「TransitルータでのIPv6拡張ヘッダーを含むIPv6パケットのフィルタリングに関する推奨事項」、進行中の作業、インターネットドラフト、草案-IETF-OPSEC-IPv6-EHフィルタリング-08,3 6月3日、<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-hiltering-08>
[Jaeggli-2018] Jaeggli, J., "IPv6 flow label: misuse in hashing", APNIC Blog, January 2018, <https://blog.apnic.net/2018/01/11/ ipv6-flow-label-misuse-hashing/>.
[Jaeggli-2018] Jaeggli、J.、 "IPv6フローラベル：ハッシュでの誤用"、Apnic Blog、2018年1月、<https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse - ハッシュ/>。
[Linkova-Gont-IEPG90] Linkova, J. and F. Gont, "IPv6 Extension Headers in the Real World v2.0", IEPG 90, July 2014, <http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6- ehs-in-the-real-world-v2.0.pdf>.
[Linkova-Gont-IEPG90] Linkova、J.およびF. F. Gont、2014年7月、2014年7月、<http://www.iepg.org/2014-07-にある「Real World V2.0のIPv6拡張ヘッダー」20-IETF90 / IEPG-IETF90-IPv6- eHS-in-the-real-world-v2.0.pdf>。
[Microsoft-SA] Microsoft, "Windows TCP/IP Remote Code Execution Vulnerability", CVE-2021-24094, February 2021, <https://msrc.microsoft.com/update-guide/vulnerability/ CVE-2021-24094>.
[Microsoft-SA]マイクロソフト、「Windows TCP / IPリモートコードの実行脆弱性」、CVE-2021-24094、2021年2月、<https：//msrc.microsoft.com/update-guide/vulnerability/cve-2021-24094>。
[nmap] Lyon, G., "Firewall/IDS Evasion and Spoofing", Chapter 15. Nmap Reference Guide, <https://nmap.org/book/man-bypass-firewalls-ids.html>.
[NMAP]リヨン、G.、「ファイアウォール/ IDS回避となりすまし」、第15章「NMAPリファレンスガイド」、<https：//nmap.org/book/man-bypass-firewalls-ids.html>。
[OPERATORS] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, Ed., "Why Operators Filter Fragments and What It Implies", Work in Progress, Internet-Draft, draft-taylor-v6ops-fragdrop-02, 3 December 2013, <https://datatracker.ietf.org/doc/html/draft-taylor-v6ops-fragdrop-02>.
[オペレーター] Jaeggli、J.、Colitti、L.、Kumari、W.、Vyncke、E.、Kaeo、M.、およびT.Taylor、Ed。、「なぜオペレータは断片とそれが何を意味するのか」、進行中の作業、インターネットドラフト、ドラフト - Taylor-v6ops-fragdrop-02,2013、<https://datatracker.ietf.org/doc/html/draft-taylor-v6ops-fragdrop-02>。
[PARSING] Kampanakis, P., "Implementation Guidelines for Parsing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-kampanakis-6man-ipv6-eh-parsing-01, 5 August 2014, <https://datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh-parsing-01>.
[解析]カンパナキス、P.、「IPv6拡張ヘッダの解析のための実施ガイドライン」、進行中の作業、インターネットドラフト、ドラフト - カンパナキス-6man-IPv6-EH-Parsing-01,01,5,58月5日、<HTTPS：// DataTracker.ietf.org / doc / html / draft-kampanakis-6man-ipv6-eh-parsing-01>。
[PMTUD-Blackholes] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet using RIPE Atlas", University of Amsterdam, MSc. Systems & Network Engineering, July 2012, <http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf>.
[PMTUD-Blackholes]デボー、M.およびJ.ボスマ、「インターネット上のパスMTUブラックホールの発見」、アムステルダム大学MSC。システムとネットワークエンジニアリング、2012年7月、<http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf>。
[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>.
[RFC2460]「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<https://www.rfc-editor.org/info/RFC2460>。
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, <https://www.rfc-editor.org/info/rfc5635>.
[RFC5635] Kumari、W.およびD. McPherson、「ユニキャストリバースパスフォワーディング（URPF）」、RFC 5635、DOI 10.17487 / RFC5635、2009年8月、<https：//www.rfc-編集者。ORG / INFO / RFC5635>。
[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>.
[RFC6192]ダグナル、D.、Pignataro、C.、R.Dunn、「ルーターコントロールプレーンの保護」、RFC 6192、DOI 10.17487 / RFC6192、2011年3月、<https：//www.rfc-editor.org/情報/ RFC6192>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B.およびS. Amante、「トンネルの同等のコストマルチパスルーティングのためのIPv6フローラベルの使用」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<https：//www.rfc-editor.org/info/rfc6438>
[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>。
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 10.17487/RFC7098, January 2014, <https://www.rfc-editor.org/info/rfc7098>.
[RFC7098] Carpenter、B.、Jiang、S.およびW. Tarreau、2014年1月、2014年1月、<https：// www.2014、<https：// www.2098、RFC 7098、DOI 10.17487 / RFC7098。rfc-editor.org/info/rfc7098>。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, <https://www.rfc-editor.org/info/rfc7113>.
[RFC7113] Gont、F.、「IPv6ルータ広告ガード（RA-Guard）の実装アドバイス」、RFC 7113、DOI 10.17487 / RFC7113、2014年2月、<https：//www.rfc-editor.org/info/rfc7113>。
[RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC7739] Gont、F。、「予測可能なフラグメント識別値のセキュリティへの影響」、RFC 7739、DOI 10.17487 / RFC7739、2016年2月、<https：//www.rfc-editor.org/info/rfc7739>。
[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>.
[RFC7872]ゴント、F、Linkova、J.、Chown、T.、およびW. Liu、RFC 7872、DOI 10.17487 / RFC7872、2016年6月<https：//www.rfc-editor.org/info/rfc7872>。
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/info/rfc8900>.
[RFC8900]ボニャ、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O.、F.ゴント、「IPフラグメンテーションと見なす」、BCP 230、RFC 8900、DOI 10.17487 / RFC8900、2020年9月、<https://www.rfc-editor.org/info/rfc8900>。
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8955] LOIBL、C.、HARES、S.、Raszuk、R.、Mcpherson、D.、およびM. Bacher、「フロー仕様規則の普及」、RFC 8955、DOI 10.17487 / RFC8955、2020年12月2020日、<HTTPS：//www.rfc-editor.org/info/rfc8955>。
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.
[RFC8956] LOIBL、C、ED。、RASZUK、R.、ED。、およびS.HARES、ED。、「IPv6のフロー仕様規則の普及」、RFC 8956、DOI 10.17487 / RFC8956、2020年12月、<HTTPS：//www.rfc-editor.org/info/rfc8956>。
[Zack-FW-Benchmark] Zack, E., "Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, June 2013, <https://www.ipv6hackers.org/files/meetings/ipv6- hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf>.
[Zack-FWベンチマーク]ザック、E.、「ファイアウォールセキュリティアセスメントとベンチマークIPv6ファイアウォールロードテスト」、IPv6ハッカー会議、IPv6ハッカー会議、2013年6月、<https://www.ipv6hackers.org/files/meetings/ipv6-Hackers-1 / Zack-IPv6hackers1-firewall-security-assual-and-benchmarking.pdf>。
Acknowledgements
謝辞
The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Fred Baker, Dale W. Carder, Brian Carpenter, Tim Chown, Owen DeLong, Gorry Fairhurst, Guillermo Gont, Tom Herbert, Lee Howard, Tom Petch, Sander Steffann, Eduard Vasilenko, Éric Vyncke, Rob Wilton, Jingrong Xie, and Andrew Yourtchenko for providing valuable comments on earlier draft versions of this document.
著者らは、（アルファベット順に）Mikael Abrahamsson、Fred Baker、Dale W.大胆な大規模な大規模な大会、ティムチェーン、オーウェラのデロング、Gorery auryhurst、Guillermo Gont、Tom Herbert、Lee Howard、Tom Petch、Sander Steffann、Eduardvasilenko、vyncke、rob Wilton、Jingrong Xie、およびAndrew Yourtchenkoこの文書の既にドラフトバージョンで貴重なコメントを提供します。
Fernando Gont would like to thank Jan Zorz / Go6 Lab <https://go6lab.si/>, Jared Mauch, and Sander Steffann <https://steffann.nl/> for providing access to systems and networks that were employed to perform experiments and measurements involving packets with IPv6 extension headers.
Fernandoは、Jan Zorz / Go6 Lab <https://go6lab.si/>、JARED MAUCH、およびSANDER STEFFANN <https://steffann.nl/>を実行したいと思います。IPv6拡張ヘッダーを持つパケットを含む実験と測定
Authors' Addresses
著者の住所
Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autonoma de Buenos Aires Argentina
Fernando Gont Si 6 Networks Segurola y Habana 4310,7mo Piso Villa Devoto Ciudad Autoloma de Buenos Airesアルゼンチン
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Nick Hilliard INEX 4027 Kingswood Road Dublin 24 Ireland
Nick Hilliard€4027 Kingswood Roadダブリン24アイルランド
Email: nick@inex.ie
Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 D-80807 Muenchen Germany
GERT DOLENET AG Joseph-Dollinger-Bogen 14 D-80807 Muenchenドイツ
Email: gert@space.net
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
Geoff Huston
Geoff Huston.
Email: gih@apnic.net
URI: https://www.apnic.net
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
Will（Shucheng）Liu Huawei Technologies Bantian、Longgang District深セン518129中国
Email: liushucheng@huawei.com