[要約] RFC 9288はIPv6拡張ヘッダーを含むIPv6パケットのフィルタリングに関する勧告を提供し、セキュリティおよび運用上の懸念を分析します。目的は、トランジットルーターでのIPv6パケットの適切なフィルタリングに関するガイダンスを提供することです。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 9288 SI6 Networks
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
August 2022
Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
Transit RoutersでIPv6拡張ヘッダーを含むIPv6パケットのフィルタリングに関する推奨事項
Abstract
概要
This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.
このドキュメントは、IPv6拡張ヘッダーと関連するIPv6オプションのセキュリティへの影響を分析します。さらに、IPv6拡張ヘッダーとそれらに含まれる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/rfc9288.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9288で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology and Assumptions Employed in This Document
2.1. Terminology
2.2. Applicability Statement
2.3. Router Default Behavior and Features
3. IPv6 Extension Headers
3.1. General Discussion
3.2. General Security Implications
3.3. Rationale for Our Advice on the Handling of IPv6 Packets
with Specific IPv6 Extension Headers
3.4. Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers
3.5. Advice on the Handling of IPv6 Packets with Specific IPv6
Extension Headers
3.6. Advice on the Handling of Packets with Unknown IPv6
Extension Headers
4. IPv6 Options
4.1. General Discussion
4.2. General Security Implications of IPv6 Options
4.3. Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Options
4.4. Advice on the Handling of Packets with Specific IPv6
Options
4.5. Advice on the Handling of Packets with Unknown IPv6 Options
5. IANA Considerations
6. Privacy Considerations
7. Security Considerations
8. References
8.1. Normative References
8.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, particularly when the IPv6 header chain needs to be processed for, as an example, enforcing Access Control Lists (ACLs) or implementing other functions [RFC9098].
IPv6拡張ヘッダー（EHS）は、IPv6プロトコルの拡張を可能にし、IPv6断片化などのコア機能をサポートします。ただし、一般的な実装の制限は、EHSがIPv6パケットルーティング機器の課題を提示することを示唆しています。特に、IPv6ヘッダーチェーンを例として、アクセス制御リスト（ACLS）の実施または他の機能の実装[RFC9098]を実施する必要がある場合。
Several studies (e.g., [Huston-2022], [JAMES], and [RFC7872]) suggest that there is widespread dropping of IPv6 packets that contain IPv6 EHs. In some cases, such packet drops occur at transit routers. While some operators are known to intentionally drop packets that contain IPv6 EHs, it is possible that some of the measured packet drops are the result of inappropriate advice in this area.
いくつかの研究（例：[Huston-2022]、[James]、および[RFC7872]）は、IPv6 EHSを含むIPv6パケットの広範なドロップがあることを示唆しています。場合によっては、このようなパケットドロップはトランジットルーターで発生します。一部のオペレーターは、IPv6 EHSを含むパケットを意図的にドロップすることが知られていますが、測定されたパケットドロップの一部は、この分野での不適切なアドバイスの結果である可能性があります。
This document analyzes both the general security implications of IPv6 EHs, as well as the security implications of specific EH and option types. It also provides advice on the filtering of IPv6 packets based on the IPv6 EHs and the IPv6 options they contain. Since various protocols may use IPv6 EHs (possibly with IPv6 options), discarding packets based on the IPv6 EHs or IPv6 options they contain can have implications on the proper functioning of such protocols. Thus, this document also attempts to discuss the operational and interoperability implications of such filtering policies.
このドキュメントは、IPv6 EHSの一般的なセキュリティへの影響と、特定のEHとオプションタイプのセキュリティへの影響の両方を分析します。また、IPv6 EHSとそれらに含まれるIPv6オプションに基づいたIPv6パケットのフィルタリングに関するアドバイスも提供します。さまざまなプロトコルはIPv6 EHS（おそらくIPv6オプションを使用）を使用する可能性があるため、IPv6 EHSまたはIPv6オプションに基づいてパケットを破棄すると、そのようなプロトコルの適切な機能に影響を与える可能性があります。したがって、このドキュメントは、このようなフィルタリングポリシーの運用可能性および相互運用性の意味についても議論しようとします。
The resulting packet filtering policy typically depends on where in the network such policy is enforced. When the policy is enforced in a transit network, the policy typically follows a "deny-list" approach, where only packets with clear negative implications are dropped. On the other hand, when the policy is enforced closer to the destination systems, the policy typically follows an "accept-list" approach, where only traffic that is expected to be received is allowed. The advice in this document is aimed only at transit routers that may need to enforce a filtering policy based on the IPv6 EHs and IPv6 options a packet may contain, following a "deny-list" approach; hence, it is likely to be much more permissive than a filtering policy to be employed at, for example, the edge of an enterprise network. The advice in this document is meant to improve the current situation of the dropping of packets with IPv6 EHs in the Internet [RFC7872] in such cases where packets are being dropped due to inappropriate or missing guidelines.
結果のパケットフィルタリングポリシーは通常、ネットワークの場所に依存します。そのようなポリシーが施行されています。ポリシーがトランジットネットワークで実施されると、ポリシーは通常、「拒否リスト」アプローチに従います。このアプローチでは、明確な否定的な意味を持つパケットのみが削除されます。一方、ポリシーが宛先システムに近づいている場合、ポリシーは通常、「受け入れリスト」アプローチに従います。このドキュメントのアドバイスは、IPv6 EHSおよびIPv6オプションに基づいてフィルタリングポリシーを実施する必要があるトランジットルーターのみを対象としています。したがって、たとえば、エンタープライズネットワークのエッジで採用されるフィルタリングポリシーよりもはるかに許容性が高い可能性があります。このドキュメントのアドバイスは、不適切または不足しているガイドラインのためにパケットが削除されている場合に、インターネットでIPv6 EHSを使用したパケットのドロップの現在の状況を改善することを目的としています。
This document is similar in nature to [RFC7126], which addresses the same problem for the IPv4 case. However, in IPv6, the problem space is compounded by the fact that IPv6 specifies a number of IPv6 EHs and a number of IPv6 options that may be valid only when included in specific EH types.
このドキュメントは、[RFC7126]と本質的に類似しており、IPv4の場合と同じ問題に対処しています。ただし、IPv6では、IPv6が多くのIPv6 EHSと特定のEHタイプに含まれる場合にのみ有効なIPv6オプションの多数を指定するという事実によって、問題空間が悪化します。
This document completes and complements the considerations for protecting the control plane from packets containing IP options that can be found in [RFC6192].
このドキュメントは、[RFC6192]にあるIPオプションを含むパケットからコントロールプレーンを保護するための考慮事項を完成させ、補完します。
Section 2 specifies the terminology and conventions employed throughout this document. Section 3 discusses IPv6 EHs and provides advice in the area of filtering IPv6 packets that contain such IPv6 EHs. Section 4 discusses IPv6 options and provides advice in the area of filtering IPv6 packets that contain such options.
セクション2では、このドキュメント全体で採用されている用語と規則を指定しています。セクション3では、IPv6 EHSについて説明し、そのようなIPv6 EHSを含むIPv6パケットをフィルタリングする領域でアドバイスを提供します。セクション4では、IPv6オプションについて説明し、そのようなオプションを含むIPv6パケットをフィルタリングする領域でアドバイスを提供します。
The terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" (drop with appropriate notification to sender) are employed as defined in [RFC3871]. Throughout this document, we also employ the term "discard" as a generic term to indicate the act of discarding a packet, irrespective of whether the sender is notified of such a drop and whether the specific filtering action is logged.
「許可」（トラフィックを許可）、「ドロップ」（送信者への通知なしでドロップ）、および「拒否」（適切な通知でドロップする）という用語は、[RFC3871]で定義されているように使用されます。このドキュメント全体を通して、「廃棄」という用語を一般的な用語として使用して、送信者にそのようなドロップが通知されているかどうか、特定のフィルタリングアクションが記録されるかどうかに関係なく、パケットを破棄する行為を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document provides advice on the filtering of IPv6 packets with EHs at transit routers for traffic not explicitly destined to them, for cases in which such filtering is deemed as necessary.
このドキュメントは、そのようなフィルタリングが必要であるとみなされる場合のために、それらに明示的に運命づけられていないトラフィックのためのTransitルーターでのEHSを使用したIPv6パケットのフィルタリングに関するアドバイスを提供します。
This document assumes that nodes comply with the requirements in [RFC7045]. Namely,
このドキュメントは、ノードが[RFC7045]の要件に準拠していることを前提としています。つまり、
If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers.
転送ノードが標準のIPv6拡張ヘッダーを含むパケットを破棄する場合、そのようなヘッダーを認識できなかった結果だけでなく、構成可能なポリシーの結果である必要があります。これは、各標準タイプの拡張ヘッダーの廃棄ポリシーが個別に構成可能でなければならないことを意味します。デフォルトの構成では、すべての標準拡張ヘッダーを可能にする必要があります。
The advice provided in this document is only meant to guide an operator in configuring forwarding devices and is not to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational policies but does not change the implementation defaults required by [RFC7045].
このドキュメントで提供されるアドバイスは、転送デバイスの構成にオペレーターを導くためのみであり、ネットワークデバイスのデフォルトの構成設定に関するアドバイスとして解釈されるべきではありません。つまり、このドキュメントは運用ポリシーに関してアドバイスを提供しますが、[RFC7045]で必要な実装のデフォルトを変更しません。
We recommend that configuration options be made available to govern the processing of each IPv6 EH type and each IPv6 Option Type. Such configuration options should include the following possible settings:
各IPv6 EHタイプと各IPv6オプションタイプの処理を管理するために、構成オプションを利用できるようにすることをお勧めします。このような構成オプションには、次の可能な設定を含める必要があります。
* Permit this IPv6 EH or IPv6 Option Type.
* このIPv6 EHまたはIPv6オプションタイプを許可します。
* Drop packets containing this IPv6 EH or IPv6 Option Type.
* このIPv6 EHまたはIPv6オプションタイプを含むドロップパケット。
* Reject packets containing this IPv6 EH or IPv6 Option Type (where the packet drop is signaled with an ICMPv6 error message).
* このIPv6 EHまたはIPv6オプションタイプを含むパケットを拒否します（Packet DropがICMPV6エラーメッセージで信号が表示されます）。
* Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.
* このIPv6 EHまたはIPv6オプションタイプを含むレート制限トラフィック。
* Ignore this IPv6 EH or IPv6 Option Type (as if it was not present), and process the packet according the rules for the remaining headers. We note that if a packet carries forwarding information (e.g., in an IPv6 Routing Header (RH)), this might be an inappropriate or undesirable action.
* このIPv6 EHまたはIPv6オプションタイプ（まるで存在しないかのように）を無視し、残りのヘッダーのルールに従ってパケットを処理します。パケットが転送情報を搭載している場合（たとえば、IPv6ルーティングヘッダー（RH））、これは不適切または望ましくないアクションである可能性があることに注意してください。
We note that special care needs to be taken when devices log packet drops/rejects. Devices should count the number of packets dropped/ rejected, but the logging of drop/reject events should be limited so as to not overburden device resources.
デバイスのログパケットがドロップ/拒否される場合、特別な注意が必要であることに注意してください。デバイスは、ドロップ/拒否されたパケットの数をカウントする必要がありますが、ドロップ/拒否イベントのロギングは、デバイスのリソースを過剰に負担しないように制限する必要があります。
Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. However, throughout this document (when recommending that packets be discarded), we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop.
最後に、パケットを破棄するとき、これはトラブルシューティングの目的に使用されるため、送信者がパケットドロップの信号を送信することが一般的に望ましいことに注意してください。ただし、このドキュメント全体（パケットを破棄することを推奨する場合）を通じて、送信者がパケットドロップの信号を送られているかどうかを指定せずに、アクションを「破棄」と一般的に参照します。
IPv6 EHs [RFC8200] allow for the extension of the IPv6 protocol. Since both IPv6 EHs and upper-layer protocols share the same namespace ("Next Header" registry/namespace), [RFC7045] identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer protocols. This document discusses the filtering of packets based on the IPv6 EHs (as specified by [RFC7045]) they contain.
IPv6 EHS [RFC8200]は、IPv6プロトコルの拡張を可能にします。IPv6 EHSと上層層プロトコルの両方が同じ名前空間（「次のヘッダー」レジストリ/名前空間）を共有するため、[RFC7045]は、現在割り当てられているインターネットプロトコル番号のどれがIPv6 EHS対上層プロトコルを特定しているかを識別します。このドキュメントでは、IPv6 EHS（[RFC7045]で指定されている）に基づくパケットのフィルタリングについて説明します。
[RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments must contain the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can enforce the filtering policies discussed in this document or resort to simply discarding the offending packets when they fail to include the entire IPv6 header chain [RFC8200].
[RFC8200]は、非フラグメントされていないIPv6データグラムとIPv6のファーストフラグがIPv6ヘッダーチェーン全体を含める必要があることを指定します[RFC7112]。したがって、中間システムは、このドキュメントで議論されているフィルタリングポリシーを実施したり、IPv6ヘッダーチェーン全体を含めない場合に問題のあるパケットを単純に破棄するように頼ることができます[RFC8200]。
We note that in order to implement filtering rules on the fast path, it may be necessary for the filtering device to limit the depth into the packet that can be inspected before giving up. In circumstances where such a limitation exists, it is recommended that implementations provide a configuration option that specifies whether to discard packets if the aforementioned limit is encountered. Operators may then determine, according to their own circumstances, how such packets will be handled.
高速パスにフィルタリングルールを実装するには、フィルタリングデバイスがあきらめる前に検査できるパケットに深さを制限する必要がある場合があることに注意してください。このような制限が存在する状況では、実装が前述の制限が発生した場合にパケットを破棄するかどうかを指定する構成オプションを提供することをお勧めします。その後、オペレーターは、自分の状況に応じて、そのようなパケットがどのように処理されるかを判断する場合があります。
In some device architectures, IPv6 packets that contain IPv6 EHs can cause the corresponding packets to be processed on the slow path and, hence, may be leveraged for the purpose of Denial-of-Service (DoS) attacks [RFC9098] [Cisco-EH] [FW-Benchmark].
一部のデバイスアーキテクチャでは、IPv6 EHSを含むIPv6パケットにより、対応するパケットがスローパスで処理される可能性があるため、サービス拒否（DOS）攻撃[RFC9098] [CISCO-EH] [FWベンチマーク]。
Operators are urged to consider the IPv6 EH and IPv6 options handling capabilities of their devices as they make deployment decisions in the future.
オペレーターは、将来展開決定を行う際に、デバイスのIPv6 EHおよびIPv6オプションの処理機能を検討することをお勧めします。
3.3. Rationale for Our Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers
3.3. 特定のIPv6エクステンションヘッダーを使用したIPv6パケットの取り扱いに関するアドバイスの理論的根拠
* IPv6 packets with IPv6 Extension Headers (or options) that are not expected to traverse transit routers should be dropped.
* Transitルーターを通過するとは予想されていないIPv6拡張ヘッダー（またはオプション）を備えたIPv6パケットをドロップする必要があります。
* IPv6 packets with IPv6 Extension Headers (or options) that are only expected to traverse transit routers when a specific technology is employed should be permitted (or dropped) based on the knowledge regarding the use of such technology in the transit provider in question (i.e., permit the packets if the technology is employed, or drop them).
* IPv6拡張ヘッダー（またはオプション）を備えたIPv6パケットは、特定のテクノロジーが採用されている場合にのみ通過する場合にのみ通過すると予想されるパケットを使用します。テクノロジーが採用されている場合はパケットを許可するか、ドロップします）。
* IPv6 packets with IPv6 Extension Headers (or options) that represent a concrete attack vector to network infrastructure devices should be dropped.
* ネットワークインフラストラクチャデバイスへのコンクリート攻撃ベクトルを表すIPv6拡張ヘッダー（またはオプション）を備えたIPv6パケットをドロップする必要があります。
* IPv6 packets with any other IPv6 Extension Headers (or options) should be permitted. This is an intentional trade-off made to minimize ossification.
* 他のIPv6拡張ヘッダー（またはオプション）を備えたIPv6パケットを許可する必要があります。これは、骨化を最小限に抑えるために行われた意図的なトレードオフです。
3.4. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers
3.4. 特定のIPv6拡張ヘッダーを使用したIPv6パケットの取り扱いに関するアドバイスの概要
This section summarizes the advice provided in Section 3.5, providing references to the specific sections in which a detailed analysis can be found.
このセクションでは、セクション3.5に記載されているアドバイスをまとめて、詳細な分析を見つけることができる特定のセクションへの参照を提供します。
+=====================+=========================+===========+
| EH Type | Filtering Policy | Reference |
+=====================+=========================+===========+
| Hop-by-Hop Options | Drop or Ignore | Section |
| Header (Proto=0) | | 3.5.1 |
+---------------------+-------------------------+-----------+
| Routing Header | Drop only Routing Type | Section |
| (Proto=43) | 0, Routing Type 1, and | 3.5.2 |
| | Routing Type 3. Permit | |
| | other Routing Types | |
+---------------------+-------------------------+-----------+
| Fragment Header | Permit | Section |
| (Proto=44) | | 3.5.3 |
+---------------------+-------------------------+-----------+
| Encapsulating | Permit | Section |
| Security Payload | | 3.5.4 |
| (Proto=50) | | |
+---------------------+-------------------------+-----------+
| Authentication | Permit | Section |
| Header (Proto=51) | | 3.5.5 |
+---------------------+-------------------------+-----------+
| Destination Options | Permit | Section |
| Header(Proto=60) | | 3.5.6 |
+---------------------+-------------------------+-----------+
| Mobility Header | Permit | Section |
| (Proto=135) | | 3.5.7 |
+---------------------+-------------------------+-----------+
| Host Identity | Permit | Section |
| Protocol | | 3.5.8 |
| (Proto=139) | | |
+---------------------+-------------------------+-----------+
| Shim6 Protocol | Permit | Section |
| (Proto=140) | | 3.5.9 |
+---------------------+-------------------------+-----------+
| Use for | Drop | Section |
| experimentation and | | 3.5.10 |
| testing (Proto=253 | | |
| and 254) | | |
+---------------------+-------------------------+-----------+
Table 1: Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers
表1：特定のIPv6エクステンションヘッダーを使用したIPv6パケットの取り扱いに関するアドバイスの概要
3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers
3.5. 特定のIPv6拡張ヘッダーを使用したIPv6パケットの取り扱いに関するアドバイス
The Hop-by-Hop (HBH) Options header is used to carry optional information that may be examined by every node along a packet's delivery path. It is expected that nodes will examine the Hop-by-Hop Options header if explicitly configured to do so.
Hop-by-Hop（HBH）オプションヘッダーは、パケットの配信パスに沿ってすべてのノードで調べられるオプションの情報を運ぶために使用されます。明示的に設定されている場合、ノードはホップバイホップオプションヘッダーを調べることが予想されます。
NOTE: A previous revision of the IPv6 core specification [RFC2460] originally required all nodes to examine and process the Hop-by-Hop Options header. However, even before the publication of [RFC8200], a number of implementations already provided the option of ignoring this header unless explicitly configured to examine it.
注：IPv6コア仕様[RFC2460]の以前の改訂では、元々すべてのノードがホップバイホップオプションヘッダーを調べて処理する必要がありました。ただし、[RFC8200]の公開前であっても、多くの実装により、明示的に検査するように設定されていない限り、このヘッダーを無視するオプションが既に提供されました。
This EH is specified in [RFC8200]. As of May 2022, the following options have been specified for the Hop-by-Hop Options header:
このEHは[RFC8200]で指定されています。2022年5月現在、ホップバイホップオプションヘッダーには、次のオプションが指定されています。
* Type 0x00: Pad1 [RFC8200]
* タイプ0x00：PAD1 [RFC8200]
* Type 0x01: PadN [RFC8200]
* タイプ0x01：padn [rfc8200]
* Type 0x05: Router Alert [RFC2711]
* タイプ0x05：ルーターアラート[RFC2711]
* Type 0x07: CALIPSO [RFC5570]
* タイプ0x07：Calipso [RFC5570]
* Type 0x08: SMF_DPD [RFC6621]
* タイプ0x08：smf_dpd [rfc6621]
* Type 0x23: RPL Option [RFC9008]
* タイプ0x23：RPLオプション[RFC9008]
* Type 0x26: Quick-Start [RFC4782]
* タイプ0x26：クイックスタート[RFC4782]
* Type 0x4D: (Deprecated)
* タイプ0x4d ：（非推奨）
* Type 0x63: RPL Option [RFC6553]
* タイプ0x63：RPLオプション[RFC6553]
* Type 0x6D: MPL Option [RFC7731]
* タイプ0x6D：MPLオプション[RFC7731]
* Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
* タイプ0x8a：エンドポイント識別（非推奨）[nimrod-eid]
* Type 0xC2: Jumbo Payload [RFC2675]
* タイプ0xc2：ジャンボペイロード[RFC2675]
* Type 0xEE: IPv6 DFF Header [RFC6971]
* タイプ0xee：IPv6 DFFヘッダー[RFC6971]
* Type 0x1E: RFC3692-style Experiment [RFC4727]
* タイプ0x1E：RFC3692スタイルの実験[RFC4727]
* Type 0x3E: RFC3692-style Experiment [RFC4727]
* タイプ0x3E：RFC3692スタイルの実験[RFC4727]
* Type 0x5E: RFC3692-style Experiment [RFC4727]
* タイプ0x5E：RFC3692スタイルの実験[RFC4727]
* Type 0x7E: RFC3692-style Experiment [RFC4727]
* タイプ0x7E：RFC3692スタイルの実験[RFC4727]
* Type 0x9E: RFC3692-style Experiment [RFC4727]
* タイプ0x9E：RFC3692スタイルの実験[RFC4727]
* Type 0xBE: RFC3692-style Experiment [RFC4727]
* タイプ0xbe：RFC3692スタイルの実験[RFC4727]
* Type 0xDE: RFC3692-style Experiment [RFC4727]
* タイプ0xde：RFC3692スタイルの実験[RFC4727]
* Type 0xFE: RFC3692-style Experiment [RFC4727]
* タイプ0xfe：RFC3692スタイルの実験[RFC4727]
Legacy nodes that process this extension header might be subject to DoS attacks.
この拡張ヘッダーを処理するレガシーノードは、DOS攻撃の対象となる場合があります。
NOTE: While [RFC8200] has removed the requirement for all nodes to examine and process the Hop-by-Hop Options header, the deployed base may still reflect the legacy [RFC2460] behavior for a while; hence, the potential security problems of this EH are still of concern.
注：[RFC8200]は、すべてのノードがホップバイホップオプションヘッダーを調べて処理するための要件を削除しましたが、展開されたベースはまだしばらくの間、レガシー[RFC2460]の動作を反映している可能性があります。したがって、このEHの潜在的なセキュリティ問題は依然として懸念があります。
Discarding packets containing a Hop-by-Hop Options header would break any of the protocols that rely on it for proper functioning. For example, it would break RSVP [RFC2205] and multicast deployments and would cause IPv6 jumbograms to be discarded.
ホップバイホップオプションヘッダーを含むパケットの破棄は、適切な機能のためにそれに依存しているプロトコルのいずれかを破壊します。たとえば、RSVP [RFC2205]とマルチキャストの展開を破り、IPv6ジャンボグラムを破棄します。
Nodes implementing [RFC8200] would already ignore this extension header unless explicitly required to process it. For legacy nodes [RFC2460], the recommended configuration for the processing of these packets depends on the features and capabilities of the underlying platform, the configuration of the platform, and also the deployment environment of the platform. On platforms that allow the forwarding of packets with IPv6 HBH Options headers on the fast path, we recommend that packets with IPv6 HBH Options headers be forwarded as normal. Otherwise, on platforms in which the processing of packets with IPv6 HBH Options headers is carried out in the slow path and an option is provided to rate-limit these packets, we recommend that this option be selected. Finally, when packets containing IPv6 HBH Options headers are processed in the slow path and the underlying platform does not have any mitigation options available for attacks based on these packets, we recommend that such platforms discard packets containing IPv6 HBH Options headers.
[RFC8200]を実装するノードは、明示的に処理する必要がない限り、この拡張ヘッダーを既に無視します。レガシーノード[RFC2460]の場合、これらのパケットの処理に推奨される構成は、基礎となるプラットフォームの機能と機能、プラットフォームの構成、プラットフォームの展開環境に依存します。高速パスでIPv6 HBHオプションヘッダーを使用してパケットを転送できるプラットフォームでは、IPv6 HBHオプションヘッダーを備えたパケットを通常どおり転送することをお勧めします。それ以外の場合、IPv6 HBHオプションヘッダーを使用したパケットの処理が遅いパスで実行され、これらのパケットをレートに制限するオプションが提供されるプラットフォームでは、このオプションを選択することをお勧めします。最後に、IPv6 HBHオプションヘッダーを含むパケットがスローパスで処理され、基礎となるプラットフォームにはこれらのパケットに基づいた攻撃に使用できる緩和オプションがない場合、そのようなプラットフォームはIPv6 HBHオプションヘッダーを含むパケットを破棄することをお勧めします。
Finally, we note that the Routing Protocol for Low-Power and Lossy Networks (RPL) routers [RFC6550] must not discard packets based on the presence of an IPv6 Hop-by-Hop Options header, as this would break the RPL.
最後に、低電力および損失ネットワーク（RPL）ルーターのルーティングプロトコル[RFC6550]は、RPLを破壊するため、IPv6ホップバイホップオプションヘッダーの存在に基づいてパケットを破棄してはなりません。
The Routing Header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.
ルーティングヘッダーは、IPv6ソースによって使用され、パケットの宛先に向かう途中で「訪問」する1つ以上の中間ノードをリストします。
This EH is specified in [RFC8200]. The Routing Type 0 had originally been specified in [RFC2460] and was later obsoleted by [RFC5095]; thus, it was removed from [RFC8200].
このEHは[RFC8200]で指定されています。ルーティングタイプ0は元々[RFC2460]で指定されていたが、後に[RFC5095]によって廃止された。したがって、[RFC8200]から削除されました。
As of May 2022, the following Routing Types have been specified:
2022年5月現在、次のルーティングタイプが指定されています。
* Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
* タイプ0：ソースルート（非推奨）[RFC2460] [RFC5095]
* Type 1: Nimrod (DEPRECATED)
* タイプ1：ニムロッド（非推奨）
* Type 2: Type 2 Routing Header [RFC6275]
* タイプ2：タイプ2ルーティングヘッダー[RFC6275]
* Type 3: RPL Source Route Header [RFC6554]
* タイプ3：RPLソースルートヘッダー[RFC6554]
* Type 4: Segment Routing Header (SRH) [RFC8754]
* タイプ4：セグメントルーティングヘッダー（SRH）[RFC8754]
* Types 5-252: Unassigned
* タイプ5-252：未割り当て
* Type 253: RFC3692-style Experiment 1 [RFC4727]
* タイプ253：RFC3692スタイルの実験1 [RFC4727]
* Type 254: RFC3692-style Experiment 2 [RFC4727]
* タイプ254：RFC3692スタイルの実験2 [RFC4727]
* Type 255: Reserved
* タイプ255：予約済み
The security implications of Routing Headers of Routing Type 0 have been discussed in detail in [Biondi-2007] and [RFC5095]. Routing Type 1 was never widely implemented. The security implications of Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4 (SRH) are discussed in [RFC6275], [RFC6554], and [RFC8754], respectively.
ルーティングタイプ0のルーティングヘッダーのセキュリティへの影響については、[Biondi-2007]および[RFC5095]で詳細に説明されています。ルーティングタイプ1は広く実装されていませんでした。ルーティングタイプ2、ルーティングタイプ3、およびルーティングタイプ4（SRH）のルーティングヘッダーのセキュリティへの影響については、それぞれ[RFC6275]、[RFC6554]、および[RFC8754]で説明しています。
Blocking packets containing Routing Headers of Routing Type 0 or Routing Type 1 has no operational implications, since both have been deprecated. Blocking packets containing Routing Headers of Routing Type 2 would break Mobile IPv6. Packets containing Routing Headers of Routing Type 3 may be safely blocked at RPL domain boundaries, since such headers are employed within a single RPL domain. Blocking packets containing Routing Headers of Routing Type 4 (SRH) will break Segment Routing (SR) deployments if the filtering policy is enforced on packets being forwarded within an SR domain.
ルーティングタイプ0またはルーティングタイプ1のルーティングヘッダーを含むブロッキングパケットには、両方が非推奨されているため、運用上の意味はありません。ルーティングタイプ2のルーティングヘッダーを含むブロッキングパケットは、モバイルIPv6を破ります。ルーティングタイプ3のルーティングヘッダーを含むパケットは、そのようなヘッダーが単一のRPLドメイン内で使用されるため、RPLドメイン境界で安全にブロックされる場合があります。ルーティングタイプ4（SRH）のルーティングヘッダーを含むブロッキングパケットは、SRドメイン内で転送されているパケットにフィルタリングポリシーが施行されている場合、セグメントルーティング（SR）展開を破壊します。
Intermediate systems should discard packets containing Routing Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other Routing Types should be permitted, as required by [RFC7045].
中間システムは、[RFC7045]で要求されているように、ルーティングタイプ0、ルーティングタイプ1、またはルーティングタイプ3のルーティングヘッダーを含むパケットを破棄する必要があります。
This EH provides the fragmentation and reassembly functionality for IPv6.
これにより、IPv6の断片化と再組み立て機能が提供されます。
This EH is specified in [RFC8200].
このEHは[RFC8200]で指定されています。
The security implications of the Fragment Header range from DoS attacks (e.g., based on flooding a target with IPv6 fragments) to information leakage attacks [RFC7739].
フラグメントヘッダーのセキュリティへの影響は、DOS攻撃（たとえば、ターゲットのIPv6フラグメントでターゲットの浸水に基づく）から情報漏れ攻撃[RFC7739]に及びます。
Blocking packets that contain a Fragment Header will break any protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). However, IP fragmentation is known to introduce fragility to Internet communication [RFC8900].
フラグメントヘッダーを含むブロッキングパケットは、フラグメンテーションに依存する可能性のあるプロトコルを破壊します（例：DNS [RFC1034]）。ただし、IPの断片化は、インターネット通信[RFC8900]に脆弱性を導入することが知られています。
Intermediate systems should permit packets that contain a Fragment Header.
中間システムは、フラグメントヘッダーを含むパケットを許可する必要があります。
This EH is employed for the IPsec suite [RFC4303].
このEHは、IPSECスイート[RFC4303]に使用されます。
This EH is specified in [RFC4303].
このEHは[RFC4303]で指定されています。
Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at the destination system by wasting CPU resources in validating the contents of the packet.
IPv6 EHSの一般的な意味に加えて、このEHは、パケットの内容を検証する際にCPUリソースを無駄にすることにより、宛先システムでDOS攻撃を潜在的に実行するために使用できます。
Discarding packets that employ this EH would break IPsec deployments.
このEHを使用するパケットを破棄すると、IPSECの展開が壊れます。
Intermediate systems should permit packets containing the Encapsulating Security Payload EH.
中間システムでは、カプセル化セキュリティペイロードEHを含むパケットが許可されます。
The Authentication Header can be employed to provide authentication services in IPv4 and IPv6.
認証ヘッダーを使用して、IPv4およびIPv6で認証サービスを提供できます。
This EH is specified in [RFC4302].
このEHは[RFC4302]で指定されています。
Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at the destination system by wasting CPU resources in validating the contents of the packet.
IPv6 EHSの一般的な意味に加えて、このEHは、パケットの内容を検証する際にCPUリソースを無駄にすることにより、宛先システムでDOS攻撃を潜在的に実行するために使用できます。
Discarding packets that employ this EH would break IPsec deployments.
このEHを使用するパケットを破棄すると、IPSECの展開が壊れます。
Intermediate systems should permit packets containing an Authentication Header.
中間システムでは、認証ヘッダーを含むパケットが許可される必要があります。
The Destination Options (DO) header is used to carry optional information that needs be examined only by a packet's destination node(s).
宛先オプション（do）ヘッダーは、パケットの宛先ノードによってのみ検査される必要があるオプションの情報を運ぶために使用されます。
This EH is specified in [RFC8200]. As of May 2022, the following options have been specified for this EH:
このEHは[RFC8200]で指定されています。2022年5月の時点で、このEHには次のオプションが指定されています。
* Type 0x00: Pad1 [RFC8200]
* タイプ0x00：PAD1 [RFC8200]
* Type 0x01: PadN [RFC8200]
* タイプ0x01：padn [rfc8200]
* Type 0x04: Tunnel Encapsulation Limit [RFC2473]
* タイプ0x04：トンネルのカプセル化制限[RFC2473]
* Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250]
* タイプ0x0f：IPv6のパフォーマンスと診断指標（PDM）[RFC8250]
* Type 0x4D: (Deprecated)
* タイプ0x4d ：（非推奨）
* Type 0xC9: Home Address [RFC6275]
* タイプ0xc9：ホームアドレス[RFC6275]
* Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
* タイプ0x8a：エンドポイント識別（非推奨）[nimrod-eid]
* Type 0x8B: ILNP Nonce [RFC6744]
* タイプ0x8b：ILNP nonce [rfc6744]
* Type 0x8C: Line-Identification Option [RFC6788]
* タイプ0x8C：ライン識別オプション[RFC6788]
* Type 0x1E: RFC3692-style Experiment [RFC4727]
* タイプ0x1E：RFC3692スタイルの実験[RFC4727]
* Type 0x3E: RFC3692-style Experiment [RFC4727]
* タイプ0x3E：RFC3692スタイルの実験[RFC4727]
* Type 0x5E: RFC3692-style Experiment [RFC4727]
* タイプ0x5E：RFC3692スタイルの実験[RFC4727]
* Type 0x7E: RFC3692-style Experiment [RFC4727]
* タイプ0x7E：RFC3692スタイルの実験[RFC4727]
* Type 0x9E: RFC3692-style Experiment [RFC4727]
* タイプ0x9E：RFC3692スタイルの実験[RFC4727]
* Type 0xBE: RFC3692-style Experiment [RFC4727]
* タイプ0xbe：RFC3692スタイルの実験[RFC4727]
* Type 0xDE: RFC3692-style Experiment [RFC4727]
* タイプ0xde：RFC3692スタイルの実験[RFC4727]
* Type 0xFE: RFC3692-style Experiment [RFC4727]
* タイプ0xfe：RFC3692スタイルの実験[RFC4727]
No security implications are known, other than the general security implications of IPv6 EHs. For a discussion of possible security implications of specific options specified for the DO header, please see Section 4.4.
IPv6 EHSの一般的なセキュリティへの影響を除いて、セキュリティへの影響は知られていません。DOヘッダーに指定された特定のオプションの可能なセキュリティへの影響について議論するには、セクション4.4を参照してください。
Discarding packets that contain a Destination Options header would break protocols that rely on this EH type for conveying information (such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the Tunnel Encapsulation Limit option [RFC2473].
宛先オプションヘッダーを含むパケットの廃棄は、情報を伝達するためにこのEHタイプに依存するプロトコルを破壊します（識別子ロケーターネットワークプロトコル（ILNP）[RFC6740]およびモバイルIPv6 [RFC6275]）、および採用したIPv6タンネルトンネルのカプセル化制限オプション[RFC2473]。
Intermediate systems should permit packets that contain a Destination Options header.
中間システムは、宛先オプションヘッダーを含むパケットを許可する必要があります。
The Mobility Header is an EH used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings in Mobile IPv6.
モビリティヘッダーは、モバイルIPv6のバインディングの作成と管理に関連するすべてのメッセージングのモバイルノード、特派員ノード、およびホームエージェントが使用するEHです。
This EH is specified in [RFC6275].
このEHは[RFC6275]で指定されています。
A thorough security assessment of the security implications of the Mobility Header and related mechanisms can be found in Section 15 of [RFC6275].
モビリティヘッダーと関連メカニズムのセキュリティへの影響に関する徹底的なセキュリティ評価は、[RFC6275]のセクション15に記載されています。
Discarding packets containing this EH would break Mobile IPv6.
このEHを含むパケットを破棄すると、モバイルIPv6が破損します。
Intermediate systems should permit packets that contain a Mobility Header.
中間システムでは、モビリティヘッダーを含むパケットが許可される必要があります。
This EH is employed with the Host Identity Protocol (HIP), which is a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing the separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes.
このEHは、同意のホストが共有IP層状態を安全に確立および維持できるプロトコルであるホストIDプロトコル（HIP）で採用されています。IPアドレスの変更全体。
This EH is specified in [RFC7401].
このEHは[RFC7401]で指定されています。
The security implications of the HIP header are discussed in detail in Section 8 of [RFC7401].
股関節ヘッダーのセキュリティへの影響については、[RFC7401]のセクション8で詳しく説明します。
Discarding packets that contain a HIP header would break HIP deployments.
股関節ヘッダーを含むパケットを破棄すると、ヒップの展開が破損します。
Intermediate systems should permit packets that contain a HIP header.
中間システムは、股関節ヘッダーを含むパケットを許可する必要があります。
This EH is employed by the Shim6 protocol [RFC5533].
このEHは、SHIM6プロトコル[RFC5533]によって採用されています。
This EH is specified in [RFC5533].
このEHは[RFC5533]で指定されています。
The specific security implications are discussed in detail in Section 16 of [RFC5533].
特定のセキュリティへの影響については、[RFC5533]のセクション16で詳しく説明します。
Discarding packets that contain this EH will break Shim6.
このEHを含むパケットを破棄すると、SHIM6が破損します。
Intermediate systems should permit packets containing this EH.
中間システムは、このEHを含むパケットを許可する必要があります。
3.5.10. Use for Experimentation and Testing (Protocol Numbers=253 and 254)
3.5.10. 実験とテストに使用する（プロトコル番号= 253および254）
These IPv6 EHs are employed for performing RFC3692-style experiments (see [RFC3692] for details).
これらのIPv6 EHは、RFC3692スタイルの実験を実行するために採用されています（詳細については[RFC3692]を参照）。
These EHs are specified in [RFC3692] and [RFC4727].
これらのEHは[RFC3692]および[RFC4727]で指定されています。
The security implications of these EHs will depend on their specific use.
これらのEHSのセキュリティへの影響は、それらの特定の使用に依存します。
For obvious reasons, discarding packets that contain these EHs limits the ability to perform legitimate experiments across IPv6 routers.
明らかな理由で、これらのEHSを含むパケットを破棄すると、IPv6ルーター全体で正当な実験を実行する能力が制限されます。
Operators should determine, according to their own circumstances, whether to discard packets containing these EHs.
オペレーターは、自分の状況に応じて、これらのEHSを含むパケットを破棄するかどうかを判断する必要があります。
3.6. Advice on the Handling of Packets with Unknown IPv6 Extension Headers
3.6. 不明なIPv6拡張ヘッダーを使用したパケットの取り扱いに関するアドバイス
We refer to IPv6 EHs that have not been assigned an Internet Protocol number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown IPv6 Extension Headers" ("unknown IPv6 EHs").
[IANA-Protocols]のIANAによってインターネットプロトコル番号（およびマークされている）が[不明なIPv6拡張ヘッダー]（「不明なIPv6 EHS」）と割り当てられていないIPv6 EHSを参照します。
New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol.
新しいIPv6 EHSは、IPv6プロトコルの将来の拡張の一部として指定される場合があります。
Since IPv6 EHs and upper-layer protocols employ the same namespace, it is impossible to tell whether an unknown Internet Protocol number is being employed for an IPv6 EH or an upper-layer protocol.
IPv6 EHSおよび上層層プロトコルは同じ名前空間を使用しているため、IPv6 EHまたは上層層プロトコルには未知のインターネットプロトコル番号が採用されているかどうかを判断することは不可能です。
The processing of unknown IPv6 EHs is specified in [RFC7045].
未知のIPv6 EHSの処理は[RFC7045]で指定されています。
For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs.
明らかな理由から、未知のIPv6 EHSの特定のセキュリティへの影響を判断することは不可能です。
As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry, which is [IANA-PROTOCOLS], should be monitored such that filtering rules are updated as new IPv6 EHs are standardized.
[RFC7045]で述べたように、不明なIPv6 EHSを破棄すると、新しいIPv6 EHSおよび輸送プロトコルの展開が遅くなる可能性があります。[IANA-Protocols]である対応するIANAレジストリは、新しいIPv6 EHSが標準化されるとフィルタリングルールが更新されるように監視する必要があります。
We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded.
IPv6 EHSと上層層プロトコルは同じ番号のスペースを共有するため、未知のIPv6 EHSを破棄すると、未知の上層層プロトコルが破棄されるパケットがカプセル化される可能性があることに注意してください。
Operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 EHs.
オペレーターは、自分の状況に応じて、不明なIPv6 EHSを含むパケットを破棄するかどうかを判断する必要があります。
The following subsections describe specific security implications of different IPv6 options and provide advice regarding filtering packets that contain such options.
以下のサブセクションでは、さまざまなIPv6オプションの特定のセキュリティへの影響を説明し、そのようなオプションを含むフィルタリングパケットに関するアドバイスを提供します。
The general security implications of IPv6 options are closely related to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU and, hence, could present a Distributed Denial-of-Service (DDoS) risk to that router's general-purpose CPU (and thus to the router itself). For some architectures, a possible mitigation would be to rate-limit the packets that are to be processed by the general-purpose CPU (see, e.g., [Cisco-EH]).
IPv6オプションの一般的なセキュリティへの影響は、IPv6 EHSについてセクション3.2で説明したものと密接に関連しています。基本的に、IPv6オプションを含むパケットは、IPv6ルーターの汎用CPUによって処理する必要がある場合があります。自体）。一部のアーキテクチャでは、緩和の可能性は、汎用CPUによって処理されるパケットを評価することです（たとえば、[Cisco-EH]を参照）。
4.3. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options
4.3. 特定のIPv6オプションを使用したIPv6パケットの処理に関するアドバイスの概要
This section summarizes the advice provided in Section 4.4, and it includes references to the specific sections in which a detailed analysis can be found.
このセクションでは、セクション4.4に記載されているアドバイスを要約し、詳細な分析を見つけることができる特定のセクションへの参照が含まれています。
+===============================+======================+===========+
| Option | Filtering Policy | Reference |
+===============================+======================+===========+
| Pad1 (Type=0x00) | Permit | Section |
| | | 4.4.1 |
+-------------------------------+----------------------+-----------+
| PadN (Type=0x01) | Permit | Section |
| | | 4.4.2 |
+-------------------------------+----------------------+-----------+
| Tunnel Encapsulation Limit | Permit | Section |
| (Type=0x04) | | 4.4.3 |
+-------------------------------+----------------------+-----------+
| Router Alert (Type=0x05) | Permit based on | Section |
| | needed functionality | 4.4.4 |
+-------------------------------+----------------------+-----------+
| CALIPSO (Type=0x07) | Permit based on | Section |
| | needed functionality | 4.4.5 |
+-------------------------------+----------------------+-----------+
| SMF_DPD (Type=0x08) | Permit based on | Section |
| | needed functionality | 4.4.6 |
+-------------------------------+----------------------+-----------+
| PDM Option (Type=0x0F) | Permit | Section |
| | | 4.4.7 |
+-------------------------------+----------------------+-----------+
| RPL Option (Type=0x23) | Permit | Section |
| | | 4.4.8 |
+-------------------------------+----------------------+-----------+
| Quick-Start (Type=0x26) | Permit | Section |
| | | 4.4.9 |
+-------------------------------+----------------------+-----------+
| Deprecated (Type=0x4D) | Drop | Section |
| | | 4.4.10 |
+-------------------------------+----------------------+-----------+
| MPL Option (Type=0x6D) | Permit | Section |
| | | 4.4.12 |
+-------------------------------+----------------------+-----------+
| Jumbo Payload (Type=0xC2) | Permit based on | Section |
| | needed functionality | 4.4.16 |
+-------------------------------+----------------------+-----------+
| RPL Option (Type=0x63) | Drop | Section |
| | | 4.4.11 |
+-------------------------------+----------------------+-----------+
| Endpoint Identification | Drop | Section |
| (Type=0x8A) | | 4.4.13 |
+-------------------------------+----------------------+-----------+
| ILNP Nonce (Type=0x8B) | Permit | Section |
| | | 4.4.14 |
+-------------------------------+----------------------+-----------+
| Line-Identification Option | Drop | Section |
| (Type=0x8C) | | 4.4.15 |
+-------------------------------+----------------------+-----------+
| Home Address (Type=0xC9) | Permit | Section |
| | | 4.4.17 |
+-------------------------------+----------------------+-----------+
| IP_DFF (Type=0xEE) | Permit based on | Section |
| | needed functionality | 4.4.18 |
+-------------------------------+----------------------+-----------+
| RFC3692-style Experiment | Permit based on | Section |
| (Types = 0x1E, 0x3E, 0x5E, | needed functionality | 4.4.19 |
| 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) | | |
+-------------------------------+----------------------+-----------+
Table 2: Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options
表2：特定のIPv6オプションを使用したIPv6パケットの処理に関するアドバイスの概要
The following subsections contain a description of each of the IPv6 options that have so far been specified, a summary of the security implications of each of such options, a discussion of possible interoperability implications if packets containing such options are discarded, and specific advice regarding whether packets containing these options should be permitted.
以下のサブセクションには、これまでに指定された各IPv6オプションの説明、そのような各オプションのセキュリティへの影響の要約、そのようなオプションを含むパケットが廃棄された場合の相互運用性への影響の議論、および具体的なアドバイスが含まれています。これらのオプションを含むパケットを許可する必要があります。
This option is used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length.
このオプションは、後続のオプションを調整し、含有ヘッダーを長さ8オクテットの倍数にパッドアウトするために必要な場合に使用されます。
This option is specified in [RFC8200].
このオプションは[RFC8200]で指定されています。
None.
なし。
Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.
このオプションを含むパケットを破棄すると、IPv6オプションに依存するプロトコルが壊れる可能性があります。
Intermediate systems should not discard packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてパケットを破棄しないでください。
This option is used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length.
このオプションは、後続のオプションを調整し、含有ヘッダーを長さ8オクテットの倍数にパッドアウトするために必要な場合に使用されます。
This option is specified in [RFC8200].
このオプションは[RFC8200]で指定されています。
Because of the possible size of this option, it could be leveraged as a large-bandwidth covert channel.
このオプションのサイズの可能性があるため、大型帯域幅の秘密のチャネルとして活用できます。
Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.
このオプションを含むパケットを破棄すると、IPv6オプションに依存するプロトコルが壊れる可能性があります。
Intermediate systems should not discard IPv6 packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてIPv6パケットを破棄しないでください。
The Tunnel Encapsulation Limit option can be employed to specify how many further levels of nesting the packet is permitted to undergo.
トンネルのカプセル化制限オプションを使用して、パケットをネストすることが許可されているさらなるレベルのレベルを指定できます。
This option is specified in [RFC2473].
このオプションは[RFC2473]で指定されています。
These are discussed in [RFC2473].
これらは[RFC2473]で説明されています。
Discarding packets based on the presence of this option could result in tunnel traffic being discarded.
このオプションの存在に基づいてパケットを破棄すると、トンネルのトラフィックが破棄される可能性があります。
Intermediate systems should not discard packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてパケットを破棄しないでください。
The Router Alert option [RFC2711] is employed by a number of protocols, including the Resource reSerVation Protocol (RSVP) [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], Multicast Router Discovery (MRD) [RFC4286], and General Internet Signaling Transport (GIST) [RFC5971]. Its usage is discussed in detail in [RFC6398].
ルーターアラートオプション[RFC2711]は、リソース予約プロトコル（RSVP）[RFC2205]、マルチキャストリスナーディスカバリー（MLD）[RFC2710] [RFC3810]、マルチキャストルーターディスカバリー（MRD）[RFC4286]を含む多くのプロトコルで採用されています。および一般的なインターネットシグナル伝達輸送（GIST）[RFC5971]。その使用法については、[RFC6398]で詳しく説明しています。
This option is specified in [RFC2711].
このオプションは[RFC2711]で指定されています。
Since this option causes the contents of the packet to be inspected by the handling device, this option could be leveraged for performing DoS attacks. The security implications of the Router Alert option are discussed in detail in [RFC6398].
このオプションにより、パケットの内容がハンドリングデバイスによって検査されるため、このオプションはDOS攻撃を実行するために活用できます。ルーターアラートオプションのセキュリティへの影響については、[RFC6398]で詳しく説明しています。
Discarding packets that contain this option would break any protocols that rely on them, such as RSVP and multicast deployments. Please see Section 4.4.4.3 for further details.
このオプションを含むパケットを破棄すると、RSVPやマルチキャスト展開など、それらに依存するプロトコルが破損します。詳細については、セクション4.4.4.3を参照してください。
Packets containing this option should be permitted in environments where support for RSVP, multicast routing, or similar protocols is required.
このオプションを含むパケットは、RSVP、マルチキャストルーティング、または同様のプロトコルのサポートが必要な環境で許可する必要があります。
This option is used for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.
このオプションは、IPv6パケット上の明示的なパケット感度ラベルをエンコードするために使用されます。これは、信頼され、信頼できるマルチレベルSecure（MLS）ネットワーク環境内でのみ使用することを目的としています。
This option is specified in [RFC5570].
このオプションは[RFC5570]で指定されています。
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
パケット内のこのオプションの存在は、それ自体で特定の新しい脅威を作成するものではありません。このオプションを備えたパケットは、通常、グローバルなパブリックインターネットでは見られないはずです。
If packets with this option are discarded or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be discarded by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect Sensitivity Label with the received data from the packet whose Common Architecture Label IPv6 Security Option (CALIPSO) was stripped by a middlebox (such as a packet scrubber). Associating an incorrect Sensitivity Label can cause the received information to be handled either as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic. As noted in [RFC5570], IPsec [RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO.
このオプションを備えたパケットが破棄されている場合、またはソースから宛先への送信中にオプションがパケットから剥がされた場合、適切にラベル付けされていないため、パケット自体が受信機によって破棄される可能性があります。場合によっては、受信者はパケットを受け取ることがありますが、共通のアーキテクチャラベルIPv6セキュリティオプション（Calipso）が中間ボックス（パケットスクラバーなど）で剥がされたパケットから受信したデータと誤った感度ラベルを関連付けます。誤った感度ラベルを関連付けると、受信した情報が実際にはより感度が高く（「アップグレード」）、または実際よりも感度が低く（「ダウングレード」）、どちらも問題があります。[RFC5570]で述べたように、IPSEC [RFC4301] [RFC4302] [RFC4303]を使用して、カリプソを保護できます。
Recommendations for handling the CALIPSO depend on the deployment environment rather than on whether an intermediate system happens to be deployed as a transit device (e.g., IPv6 transit router).
Calipsoを処理するための推奨事項は、中間システムがたまたまトランジットデバイスとして展開されているかどうかではなく、展開環境に依存します（例：IPv6トランジットルーター）。
Explicit configuration is the only method via which an intermediate system can know whether that particular intermediate system has been deployed within an MLS environment. In many cases, ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls) are the majority of the deployed intermediate systems inside an MLS network environment.
明示的な構成は、中間システムがその特定の中間システムがMLS環境内に展開されているかどうかを知ることができる唯一の方法です。多くの場合、通常の市販の中間システム（IPv6ルーターやファイアウォールなど）は、MLSネットワーク環境内に展開された中間システムの大部分です。
For intermediate systems that DO NOT implement [RFC5570], there should be a configuration option to either (a) drop packets containing the CALIPSO or (b) ignore the presence of the CALIPSO and forward the packets normally. In non-MLS environments, such intermediate systems should have this configuration option set to (a) above. In MLS environments, such intermediate systems should have this option set to (b) above. The default setting for this configuration option should be set to (a) above, because MLS environments are much less common than non-MLS environments.
[RFC5570]を実装していない中間システムの場合、（a）Calipsoを含むドロップパケットまたは（b）Calipsoの存在を無視して、正常にパケットを転送する構成オプションが必要です。非MLS環境では、このような中間システムには、この構成オプションが上記の（a）に設定されている必要があります。MLS環境では、このような中間システムには、上記の（b）にこのオプションを設定する必要があります。MLS環境は非MLS環境よりもはるかに一般的ではないため、この構成オプションのデフォルト設定は（a）上記に設定する必要があります。
For intermediate systems that DO implement [RFC5570], there should be configuration options (a) and (b) from the preceding paragraph and also a third configuration option (c) to process packets containing a CALIPSO as per [RFC5570]. When deployed in non-MLS environments, such intermediate systems should have this configuration option set to (a) above. When deployed in MLS environments, such intermediate systems should have this configuration option set to (c). The default setting for this configuration option MAY be set to (a) above, because MLS environments are much less common than non-MLS environments.
[RFC5570]を実装する中間システムの場合、前の段落から構成オプション（a）および（b）が必要である必要があります。非MLS環境に展開された場合、このような中間システムには、この構成オプションが上記の（a）に設定されている必要があります。MLS環境に展開された場合、このような中間システムには、この構成オプションが（c）に設定されている必要があります。MLS環境は非MLS環境よりもはるかに一般的ではないため、この構成オプションのデフォルト設定は（a）上記に設定できます。
This option is employed in the (experimental) Simplified Multicast Forwarding (SMF) for unique packet identification for IPv6 Identification-based DPD (I-DPD) and as a mechanism to guarantee non-collision of hash values for different packets when Hash-based DPD (H-DPD) is used.
このオプションは、IPv6識別ベースのDPD（I-DPD）の一意のパケット識別のために（実験的）単純化されたマルチキャスト転送（SMF）と、ハッシュベースのDPDの場合、異なるパケットのハッシュ値の非衝突を保証するメカニズムとして採用されています。（H-DPD）が使用されます。
This option is specified in [RFC6621].
このオプションは[RFC6621]で指定されています。
None. The use of transient numeric identifiers is subject to the security and privacy considerations discussed in [NUMERIC-IDS].
なし。一時的な数値識別子の使用は、[numeric-ids]で議論されているセキュリティとプライバシーの考慮事項の対象となります。
Dropping packets containing this option within a Mobile Ad Hoc Network (MANET) domain would break SMF. However, dropping such packets at the border of such domain would have no negative impact.
モバイルアドホックネットワーク（MANET）ドメイン内にこのオプションを含むパケットをドロップすると、SMFが破損します。ただし、そのようなドメインの境界にそのようなパケットをドロップすることは、マイナスの影響を与えません。
Intermediate systems that are not within a MANET domain should discard packets that contain this option.
MANETドメイン内にない中間システムは、このオプションを含むパケットを破棄する必要があります。
This option is employed to convey sequence numbers and timing information in IPv6 packets as a basis for measurements.
このオプションは、測定の基礎としてIPv6パケットのシーケンス番号とタイミング情報を伝えるために採用されています。
This option is specified in [RFC8250].
このオプションは[RFC8250]で指定されています。
These are discussed in [RFC8250]. Additionally, since this option employs transient numeric identifiers, implementations may be subject to the issues discussed in [NUMERIC-IDS].
これらは[RFC8250]で説明されています。さらに、このオプションは一時的な数値識別子を採用しているため、実装には[numeric-ids]で説明されている問題の対象となる場合があります。
Dropping packets containing this option will result in negative interoperability implications for traffic employing this option as a basis for measurements.
このオプションを含むパケットをドロップすると、測定の基礎としてこのオプションを採用するトラフィックに否定的な相互運用性の影響が生じます。
Intermediate systems should not discard packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてパケットを破棄しないでください。
The RPL Option provides a mechanism to include routing information in each datagram that a RPL router forwards.
RPLオプションは、RPLルーターが転送する各データグラムにルーティング情報を含めるメカニズムを提供します。
This option is specified in [RFC9008].
このオプションは[RFC9008]で指定されています。
These are discussed in [RFC9008].
これらは[RFC9008]で説明されています。
This option can survive outside of a RPL instance. As a result, discarding packets based on the presence of this option would break some use cases for RPL (see [RFC9008]).
このオプションは、RPLインスタンス以外で生き残ることができます。その結果、このオプションの存在に基づいてパケットを破棄すると、RPLの一部のユースケースが破損します（[RFC9008]を参照）。
Intermediate systems should not discard IPv6 packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてIPv6パケットを破棄しないでください。
This IP option is used in the specification of Quick-Start for TCP and IP, which is an experimental mechanism that allows transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period) [RFC4782].
このIPオプションは、TCPとIPのクイックスタートの仕様に使用されます。これは、ルーターと協力して、輸送プロトコルが開始時に許可された送信率を決定し、時には中央で許可された送信率を決定できる実験メカニズムである。データ転送（たとえば、アイドル期間後）[RFC4782]。
This option is specified in [RFC4782] on the "Experimental" track.
このオプションは、[実験的な]トラックの[RFC4782]で指定されています。
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks:
[RFC4782]のセクション9.6は、クイックスタートは2種類の攻撃に対して脆弱であることを指摘しています。
* attacks to increase the routers' processing and state load and
* ルーターの処理と状態の負荷を増やすための攻撃と
* attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections
* 偽のクイックスタートリクエストでの攻撃利用可能なクイックスタート帯域幅を一時的に結び付け、ルーターが他の接続からクイックスタートリクエストを承認するのを防ぎます
We note that if routers in a given environment do not implement and enable the Quick-Start mechanism, only the general security implications of IP options (discussed in Section 4.2) would apply.
特定の環境のルーターがクイックスタートメカニズムを実装および有効にしない場合、IPオプションの一般的なセキュリティへの影響のみが適用されることに注意してください。
If packets with IPv6 Quick Start options are blocked, the host trying to establish a TCP connection will fall back to not including the Quick Start option -- this means that the feature will be disabled, and additional delays in connection establishment will be introduced (as discussed in Section 4.7.2 of [RFC4782]). We note, however, that Quick-Start has been proposed as a mechanism that could be of use in controlled environments and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782].
IPv6クイックスタートオプションを備えたパケットがブロックされている場合、TCP接続を確立しようとするホストはクイックスタートオプションを含めないことに戻ります - これは機能が無効になり、接続された確立の追加の遅延が導入されることを意味します（[RFC4782]のセクション4.7.2で説明しました）。ただし、クイックスタートは、グローバルインターネットでのユビキタスな展開を意図または適切なメカニズムとしてではなく、制御された環境で使用できるメカニズムとして提案されていることに注意してください[RFC4782]。
Intermediate systems should not discard IPv6 packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてIPv6パケットを破棄しないでください。
No information has been found about this option type.
このオプションタイプに関する情報は見つかりませんでした。
No information has been found about this option type.
このオプションタイプに関する情報は見つかりませんでした。
No information has been found about this option type; hence, it has been impossible to perform the corresponding security assessment.
このオプションタイプに関する情報は見つかりませんでした。したがって、対応するセキュリティ評価を実行することは不可能でした。
Unknown.
わからない。
Intermediate systems should discard packets that contain this option.
中間システムは、このオプションを含むパケットを破棄する必要があります。
The RPL Option provides a mechanism to include routing information in each datagram that a RPL router forwards.
RPLオプションは、RPLルーターが転送する各データグラムにルーティング情報を含めるメカニズムを提供します。
This option was originally specified in [RFC6553]. It has been deprecated by [RFC9008].
このオプションは、もともと[RFC6553]で指定されていました。[RFC9008]によって非推奨されています。
These are discussed in Section 5 of [RFC6553].
これらについては、[RFC6553]のセクション5で説明します。
This option is meant to be employed within a RPL instance. As a result, discarding packets based on the presence of this option outside of a RPL instance will not result in interoperability implications.
このオプションは、RPLインスタンス内で使用されることを目的としています。その結果、RPLインスタンス以外のこのオプションの存在に基づいてパケットを破棄しても、相互運用性の影響は得られません。
Intermediate systems should discard packets that contain a RPL Option.
中間システムは、RPLオプションを含むパケットを破棄する必要があります。
This option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks.
このオプションは、低電力および損失ネットワーク（MPL）用のマルチキャストプロトコルで使用され、制約付きネットワークでIPv6マルチキャスト転送を提供します。
This option is specified in [RFC7731] and is meant to be included only in Hop-by-Hop Options headers.
このオプションは[RFC7731]で指定されており、ホップバイホップオプションヘッダーにのみ含めることを目的としています。
These are discussed in [RFC7731].
これらは[RFC7731]で説明されています。
Dropping packets that contain an MPL Option within an MPL network would break the MPL. However, dropping such packets at the border of such networks will have no negative impact.
MPLネットワーク内にMPLオプションを含むパケットをドロップすると、MPLが破損します。ただし、そのようなネットワークの境界にそのようなパケットを削除することは、マイナスの影響を与えません。
Intermediate systems should not discard packets based on the presence of this option. However, since this option has been specified for the Hop-by-Hop Options header, such systems should consider the discussion in Section 3.5.1.
中間システムは、このオプションの存在に基づいてパケットを破棄しないでください。ただし、このオプションはホップバイホップオプションヘッダーに指定されているため、そのようなシステムはセクション3.5.1で説明を検討する必要があります。
The Endpoint Identification option was meant to be used with the Nimrod routing architecture [NIMROD-DOC] but has never seen widespread deployment.
エンドポイント識別オプションは、Nimrodルーティングアーキテクチャ[Nimrod-Doc]で使用されることを意図していましたが、広範な展開を見たことはありません。
This option is specified in [NIMROD-DOC].
このオプションは[nimrod-doc]で指定されています。
Undetermined.
未定。
None.
なし。
Intermediate systems should discard packets that contain this option.
中間システムは、このオプションを含むパケットを破棄する必要があります。
This option is employed by the Identifier-Locator Network Protocol for IPv6 (ILNPv6) to provide protection against off-path attacks for packets when ILNPv6 is in use and as a signal during initial network-layer session creation that ILNPv6 is proposed for use with this network-layer session, rather than classic IPv6.
このオプションは、IPv6（ILNPV6）の識別子ロケーターネットワークプロトコルによって採用され、ILNPV6が使用されている場合のパケットのオフパス攻撃に対する保護を提供し、ILNPV6がこれを使用することを提案する最初のネットワーク層セッション作成中にシグナルとして使用されます。古典的なIPv6ではなく、ネットワーク層セッション。
This option is specified in [RFC6744].
このオプションは[RFC6744]で指定されています。
These are discussed in [RFC6744].
これらは[RFC6744]で説明されています。
Discarding packets that contain this option will break ILNPv6 deployments.
このオプションを含むパケットを破棄すると、ILNPV6の展開が破損します。
Intermediate systems should not discard packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてパケットを破棄しないでください。
This option is used by an Edge Router to identify the subscriber premises in scenarios where several subscriber premises may be logically connected to the same interface of an Edge Router.
このオプションは、エッジルーターによって使用されて、いくつかのサブスクライバー施設がエッジルーターの同じインターフェイスに論理的に接続されるシナリオでサブスクライバーの前提を識別します。
This option is specified in [RFC6788].
このオプションは[RFC6788]で指定されています。
These are discussed in [RFC6788].
これらは[RFC6788]で説明されています。
Since this option is meant to be used when tunneling Neighbor Discovery messages in some broadband network deployment scenarios, discarding packets based on the presence of this option at intermediate systems will result in no interoperability implications.
このオプションは、一部のブロードバンドネットワーク展開シナリオで近隣発見メッセージをトンネリングするときに使用することを意図しているため、中間システムでのこのオプションの存在に基づいてパケットを破棄しても、相互運用性の影響はありません。
Intermediate systems should discard packets that contain this option.
中間システムは、このオプションを含むパケットを破棄する必要があります。
The Jumbo Payload option provides the means for supporting payloads larger than 65535 bytes.
ジャンボペイロードオプションは、65535バイトを超えるペイロードをサポートする手段を提供します。
This option is specified in [RFC2675].
このオプションは[RFC2675]で指定されています。
There are no specific issues arising from this option, except for improper validity checks of the option and associated packet lengths.
オプションの不適切な妥当性チェックと関連するパケットの長さを除き、このオプションから発生する特定の問題はありません。
Discarding packets based on the presence of this option will cause IPv6 jumbograms to be discarded.
このオプションの存在に基づいてパケットを破棄すると、IPv6ジャンボグラムが破棄されます。
An operator should permit this option only in specific scenarios in which support for IPv6 jumbograms is required.
オペレーターは、IPv6ジャンボグラムのサポートが必要な特定のシナリオでのみこのオプションを許可する必要があります。
The Home Address option is used by a Mobile IPv6 node while away from home to inform the recipient of the mobile node's home address.
ホームアドレスオプションは、自宅から離れている間にモバイルIPv6ノードで使用され、モバイルノードの自宅住所を受信者に通知します。
This option is specified in [RFC6275].
このオプションは[RFC6275]で指定されています。
There are no (known) additional security implications, other than those discussed in [RFC6275].
[RFC6275]で説明したもの以外に、追加のセキュリティへの影響はありません。
Discarding IPv6 packets based on the presence of this option will break Mobile IPv6.
このオプションの存在に基づいてIPv6パケットを破棄すると、モバイルIPv6が破損します。
Intermediate systems should not discard IPv6 packets based on the presence of this option.
中間システムは、このオプションの存在に基づいてIPv6パケットを破棄しないでください。
This option is employed with the (experimental) Depth-First Forwarding (DFF) in unreliable networks.
このオプションは、信頼性の低いネットワークで（実験的な）深度順方向転送（DFF）を使用して採用されています。
This option is specified in [RFC6971].
このオプションは[RFC6971]で指定されています。
These are specified in [RFC6971].
これらは[RFC6971]で指定されています。
Dropping packets containing this option within a routing domain that is running DFF would break DFF. However, dropping such packets at the border of such domains will have no operational or interoperability implications.
DFFを実行しているルーティングドメイン内にこのオプションを含むパケットをドロップすると、DFFが破損します。ただし、そのようなドメインの境界でそのようなパケットを削除すると、運用性または相互運用性の影響はありません。
Intermediate systems that do not operate within a routing domain that is running DFF should discard packets containing this option.
DFFを実行しているルーティングドメイン内で動作しない中間システムは、このオプションを含むパケットを破棄する必要があります。
4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)
4.4.19. RFC3692スタイルの実験（タイプ= 0x1e、0x3e、0x5e、0x7e、0x9e、0xbe、0xde、0xfe）
These options can be employed for performing RFC3692-style experiments. It is only appropriate to use these values in explicitly configured experiments; they must not be shipped as defaults in implementations.
これらのオプションは、RFC3692スタイルの実験を実行するために使用できます。これらの値を明示的に構成された実験で使用することのみが適切です。実装のデフォルトとして出荷されてはなりません。
These options are specified in [RFC4727] in the context of RFC3692-style experiments.
これらのオプションは、RFC3692スタイルの実験のコンテキストで[RFC4727]で指定されています。
The specific security implications will depend on the specific use of these options.
特定のセキュリティへの影響は、これらのオプションの特定の使用に依存します。
For obvious reasons, discarding packets that contain these options limits the ability to perform legitimate experiments across IPv6 routers.
明らかな理由で、これらのオプションを含むパケットを破棄すると、IPv6ルーター全体で正当な実験を実行する機能が制限されます。
Operators should determine, according to their own circumstances, whether to discard packets containing these IPv6 options.
オペレーターは、自分の状況に応じて、これらのIPv6オプションを含むパケットを破棄するかどうかを判断する必要があります。
We refer to IPv6 options that have not been assigned an IPv6 Option Type in the corresponding registry, which is [IANA-IPV6-PARAM], as "unknown IPv6 options".
対応するレジストリにIPv6オプションタイプを割り当てられていないIPv6オプション、[IANA-IPV6-PARAM]、「不明なIPv6オプション」と呼びます。
New IPv6 options may be specified as part of future protocol work.
新しいIPv6オプションは、将来のプロトコル作業の一部として指定される場合があります。
The processing of unknown IPv6 options is specified in [RFC8200].
未知のIPv6オプションの処理は[RFC8200]で指定されています。
For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 options.
明らかな理由から、未知のIPv6オプションの特定のセキュリティへの影響を判断することは不可能です。
Discarding unknown IPv6 options may slow down the deployment of new IPv6 options. As noted in [IPv6-OPTIONS], the corresponding IANA registry, which is [IANA-IPV6-PARAM], should be monitored such that IPv6 option filtering rules are updated as new IPv6 options are standardized.
不明なIPv6オプションを破棄すると、新しいIPv6オプションの展開が遅くなる可能性があります。[IPv6-Options]で述べたように、[IANA-IPV6-PARAM]である対応するIANAレジストリは、新しいIPv6オプションが標準化されているため、IPv6オプションフィルタリングルールが更新されるように監視する必要があります。
Operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 options.
オペレーターは、独自の状況に応じて、不明なIPv6オプションを含むパケットを破棄するかどうかを判断する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
There are no privacy considerations associated with this document.
このドキュメントに関連するプライバシーに関する考慮事項はありません。
This document provides advice on the filtering of IPv6 packets that contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve the current situation of widespread dropping of such IPv6 packets in those cases where the drops result from improper configuration defaults or inappropriate advice in this area.
このドキュメントは、IPv6トランジットルーターでIPv6 EHS（および場合によってはIPv6オプション）を含むIPv6パケットのフィルタリングに関するアドバイスを提供します。これは、この領域での不適切な構成のデフォルトまたは不適切なアドバイスに起因するドロップが生じる場合のこのようなIPv6パケットの広範な低下の現在の状況を改善することを目的としています。
As discussed in Section 3.3, one of the underlying principles for the advice provided in this document is that IPv6 packets with specific EHs or options that may represent an attack vector for infrastructure devices should be dropped. While this policy helps mitigate some specific attack vectors, the recommendations in this document will not help to mitigate vulnerabilities based on implementation errors [RFC9098].
セクション3.3で説明したように、このドキュメントで提供されるアドバイスの根本的な原則の1つは、インフラストラクチャデバイスの攻撃ベクトルを表す可能性のある特定のEHSまたはオプションを備えたIPv6パケットを削除する必要があることです。このポリシーはいくつかの特定の攻撃ベクトルを軽減するのに役立ちますが、このドキュメントの推奨事項は、実装エラーに基づいて脆弱性を軽減するのに役立ちません[RFC9098]。
We also note that depending on the router architecture, attempts to filter packets based on the presence of IPv6 EHs or options might itself represent an attack vector to network infrastructure devices [RFC9098].
また、ルーターアーキテクチャによっては、IPv6 EHSまたはオプションの存在に基づいてパケットをフィルタリングしようとすると、それ自体がネットワークインフラストラクチャデバイス[RFC9098]への攻撃ベクトルを表す可能性があることに注意してください。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、DOI 10.17487/RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「Resource Reservation Protocol（RSVP） - バージョン1機能仕様」、RFC 2205、doi10.17487/rfc2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、DOI 10.17487/RFC2473、1998年12月、<https://www.rfc-editor.org/info/rfc2473>
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.
[RFC2675]ボーマン、D.、ディアリング、S。、およびR.ヒンデン、「IPv6ジャンボグラム」、RFC 2675、DOI 10.17487/RFC2675、1999年8月、<https://www.rfc-editor.org/info/RFC26755>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、DOI 10.17487/RFC2710、1999年10月、<https：//www.rfc-editritor.org/info/rfc2710>。
[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>.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、DOI 10.17487/RFC2711、1999年10月、<https://www.rfc-editor.org/info/rfc2711>。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、DOI 10.17487/RFC3692、2004年1月、<https://www.rfc-editor.org/info/rfc3692>
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、ed。and L. Costa、ed。、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、DOI 10.17487/RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.
[RFC4286] Haberman、B。およびJ. Martin、「マルチキャストルーター発見」、RFC 4286、DOI 10.17487/RFC4286、2005年12月、<https://www.rfc-editor.org/info/rfc4286>
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487/RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487/RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）をカプセル化するIP」、RFC 4303、DOI 10.17487/RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/info/rfc4727>.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、DOI 10.17487/RFC4727、2006年11月、<https://ww.rfc-editor.org/info/rfc4727>。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「TCPおよびIPのクイックスタート」、RFC 4782、DOI 10.17487/RFC4782、2007年1月、<https：// wwwwwwwwww.rfc-editor.org/info/rfc4782>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「IPv6のタイプ0ルーティングヘッダーの非推奨」、RFC 5095、DOI 10.17487/RFC5095、2007年12月、<https：//www.rfc-editor.org/info/rfc5095>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E。およびM. Bagnulo、「Shim6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、DOI 10.17487/RFC533、2009年6月、<https：//www.rfc-editor.org/info/RFC5533>。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, <https://www.rfc-editor.org/info/rfc5570>.
[RFC5570] Stjohns、M.、Atkinson、R.、およびG. Thomas、「Common Architecture Label IPv6 Security Option（Calipso）」、RFC 5570、DOI 10.17487/RFC5570、2009年7月、<https：//ww.rfc-editor.org/info/rfc5570>。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <https://www.rfc-editor.org/info/rfc5971>.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、DOI 10.17487/RFC5971、2010年10月、<https://www.rfc-editor.org/info/rfc5971>
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487/RFC6275、2011年7月、<https：//www.rfc-editor。org/info/rfc6275>。
[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>.
[RFC6398] Le Faucheur、F.、ed。、「IPルーターアラートの考慮事項と使用法」、BCP 168、RFC 6398、DOI 10.17487/RFC6398、2011年10月、<https://www.rfc-editor.org/info/RFC6398>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550] Winter、T.、Ed。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR. Alexander、「低電力および損失ネットワーク用のRPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487/RFC6550、2012年3月、<https://www.rfc-editor.org/info/RFC6550>。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>.
[RFC6553] Hui、J。およびJp。Vasseur、「データプレーンデータグラムにRPL情報を運ぶための低電力および損失ネットワーク（RPL）オプションのルーティングプロトコル」、RFC 6553、DOI 10.17487/RFC6553、<https：//www.rfc-editor。org/info/rfc6553>。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.
[RFC6554] Hui、J.、Vasseur、JP。、Culler、D。、およびV. Manral、「低電力および損失ネットワーク（RPL）のルーティングプロトコルを備えたソースルートのIPv6ルーティングヘッダー」、RFC 6554、doi 10.17487/rfc6554、2012年3月、<https://www.rfc-editor.org/info/rfc6554>。
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, <https://www.rfc-editor.org/info/rfc6621>.
[RFC6621] Macker、J.、ed。、「簡略化されたマルチキャスト転送」、RFC 6621、DOI 10.17487/RFC6621、2012年5月、<https://www.rfc-editor.org/info/rfc6621>。
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, <https://www.rfc-editor.org/info/rfc6740>.
[RFC6740]アトキンソン、RJ。とsn。Bhatti、「Identifier-Locator Network Protocol（ILNP）Architectural Description」、RFC 6740、DOI 10.17487/RFC6740、2012年11月、<https://www.rfc-editor.org/info/rfc6740>。
[RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 2012, <https://www.rfc-editor.org/info/rfc6744>.
[RFC6744]アトキンソン、RJ。とsn。Bhatti、「IPv6（ILNPV6）の識別子ロケーターネットワークプロトコルのIPv6 NonCE宛先オプション」、RFC 6744、DOI 10.17487/RFC6744、2012年11月、<https://www.rfc-editor.org/info/rfc6744>。
[RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. Nordmark, "The Line-Identification Option", RFC 6788, DOI 10.17487/RFC6788, November 2012, <https://www.rfc-editor.org/info/rfc6788>.
[RFC6788] Krishnan、S.、Kavanagh、A.、Varga、B.、Ooghe、S.、およびE. Nordmark、「ライン識別オプション」、RFC 6788、DOI 10.17487/RFC6788、2012年11月、<HTTPS：//www.rfc-editor.org/info/rfc6788>。
[RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. Cespedes, "Depth-First Forwarding (DFF) in Unreliable Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, <https://www.rfc-editor.org/info/rfc6971>.
[RFC6971] Herberg、U.、ed。、Cardenas、A.、Iwao、T.、Dow、M.、S。Cespedes、「信頼できないネットワークにおける深度順方向（DFF）」、RFC 6971、DOI 10.17487/RFC6971、2013年6月、<https://www.rfc-editor.org/info/rfc6971>。
[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。and S. Jiang、「IPv6拡張ヘッダーの伝送と処理」、RFC 7045、DOI 10.17487/RFC7045、2013年12月、<https://www.rfc-editor.org/info/rfc7045>。
[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>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R.、Ed。、Heer、T.、Jokela、P。、およびT. Henderson、「ホストIDプロトコルバージョン2（HIPV2）」、RFC 7401、DOI 10.17487/RFC7401、2015年4月、<：//www.rfc-editor.org/info/rfc7401>。
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, <https://www.rfc-editor.org/info/rfc7731>.
[RFC7731] Hui、J。およびR. Kelsey、「低電力および損失ネットワーク用マルチキャストプロトコル（MPL）」、RFC 7731、DOI 10.17487/RFC7731、2016年2月、<https：//www.rfc-editor.org/info/rfc7731>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <https://www.rfc-editor.org/info/rfc8250>.
[RFC8250] Elkins、N.、Hamilton、R。、およびM. Ackermann、「IPv6パフォーマンスと診断指標（PDM）目的地オプション」、RFC 8250、DOI 10.17487/RFC8250、2017年9月、<https：//www.rfc8250-editor.org/info/rfc8250>。
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8754] Filsfils、C.、Ed。、Dukes、D.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、およびD. Voyer、「IPv6セグメントルーティングヘッダー（SRH）」、RFC8754、doi 10.17487/rfc8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。
[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] Bonica、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O.、およびF. Gont、「IP断片化は壊れやすい」、BCP 230、RFC 8900、DOI 10.17487/RFC8900、2020年9月、<https://www.rfc-editor.org/info/rfc8900>。
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6- in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, April 2021, <https://www.rfc-editor.org/info/rfc9008>.
[RFC9008] Robles、M.I.、Richardson、M。、およびP. Thubert、「RPIオプションタイプ、ソースルート用のルーティングヘッダー、RPLデータプレーンでのIPv6-IPV6カプセル化」、RFC 9008、DOI 10.17487/RFC9008、2021年4月、<https://www.rfc-editor.org/info/rfc9008>。
[Biondi-2007] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference, April 2007, <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[Biondi-2007] Biondi、P。およびA. Ebalard、「IPv6ルーティングヘッダーセキュリティ」、Cansecwest Security Conference、2007年4月、<http://www.secdev.org/conf/ipv6_rh_security-csw07.pdf>。
[Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and Considerations", Whitepaper, October 2006, <https://www.cisco.com/en/US/technologies/tk648/tk872/ technologies_white_paper0900aecd8054d37d.pdf>.
[Cisco-EH] Cisco Systems、「IPv6拡張ヘッダーのレビューと考慮事項」、WhitePaper、2006年10月、<https://www.cisco.com/en/us/technologies/tk648/tk872/ technologies_white_paper0900aecd8054d37d.pdf>
[FW-Benchmark] Zack, E., "Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, Berlin, Germany, June 2013, <https://www.ipv6hackers.org/files/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf>.
[FWベンチマーク] Zack、E。、「ファイアウォールセキュリティ評価とベンチマークIPv6ファイアウォールロードテスト」、IPv6ハッカー会議＃1、ベルリン、ドイツ、2013年6月、<https://www.ipv6hackers.org/files/meetings/IPv6-Hackers-1/Zack-IPV6Hackers1-Firewall-Security-Assessment-and-benchmarkink.pdf>。
[Huston-2022] Huston, G. and J. Damas, "IPv6 Fragmentation and EH Behaviours", IEPG Meeting at IETF 113", March 2022, <https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>.
[Huston-2022] Huston、G。and J. Damas、「IPv6 Fragmentation and EH Behaviors」、IEPG Meeting at Ietf 113」、2022年3月、<https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>。
[IANA-IPV6-PARAM] IANA, "Internet Protocol Version 6 (IPv6) Parameters", <https://www.iana.org/assignments/ipv6-parameters>.
[IANA-IPV6-PARAM] IANA、「インターネットプロトコルバージョン6（IPv6）パラメーター」、<https://www.iana.org/assignments/ipv6-parameters>。
[IANA-PROTOCOLS] IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers>.
[iana-protocols] iana、「プロトコル番号」、<https://www.iana.org/assignments/protocol-numbers>。
[IPv6-OPTIONS] Gont, F., Liu, W., and R. P. Bonica, "Transmission and Processing of IPv6 Options", Work in Progress, Internet-Draft, draft-gont-6man-ipv6-opt-transmit-02, 21 August 2015, <https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-opt-transmit-02>.
[IPv6-Options] Gont、F.、Liu、W。、およびR. P. Bonica、「IPv6オプションの伝送と処理」、進行中の作業、インターネットドラフト、ドラフト-Gont-6man-IPV6-OPT-Transmit-02、2015年8月21日、<https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-opt-transmit-02>。
[JAMES] Iurman, J., "Just Another Measurement of Extension header Survivability (JAMES)", Work in Progress, Internet-Draft, draft-vyncke-v6ops-james-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-02>.
[James] Iurman、J。、「拡張ヘッダーの生存性（James）のもう1つの測定」、Work in Progress、Internet-Draft、Draft-vyncke-V6ops-James-02、2022年7月11日、<https：// datatracker。ietf.org/doc/html/draft-vyncke-v6ops-james-02>。
[NIMROD-DOC] "Nimrod Documentation", <http://ana-3.lcs.mit.edu/~jnc/nimrod>.
[nimrod-doc] "nimrod documentation"、<http://ana-3.lcs.mit.edu/~jnc/nimrod>。
[NIMROD-EID] Lynn, C., "Endpoint Identifier Destination Option", Work in Progress, Internet-Draft, draft-ietf-nimrod-eid-00, 2 March 1996, <https://datatracker.ietf.org/doc/html/draft-ietf-nimrod-eid-00>.
[nimrod-eid] lynn、C。、「エンドポイント識別子宛先オプション」、作業中の作業、インターネットドラフト、ドラフト-nimrod-eid-00、1996年3月2日、<https://datatracker.ietf.org/doc/html/draft-itf-nimrod-eid-00>。
[NUMERIC-IDS] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-11>.
[numeric-ids] gont、F。and I. arce、「一時的な数値識別子の生成」、進行中の作業、インターネットドラフト、ドラフト-ARTF-PEARG-IDS-GENERATION-11、2022年7月11日、<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-11>。
[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] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487/RFC2460、1998年12月、<https://www.rfc-editor.org/info/RFC2460>。
[RFC3871] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 2004, <https://www.rfc-editor.org/info/rfc3871>.
[RFC3871] Jones、G.、ed。、「大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラストラクチャの運用セキュリティ要件」、RFC 3871、DOI 10.17487/RFC3871、2004年9月、<https：//www.rfc-editor。org/info/rfc3871>。
[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] Dugal、D.、Pignataro、C。、およびR. Dunn、「ルーター制御プレーンの保護」、RFC 6192、DOI 10.17487/RFC6192、2011年3月、<https://www.rfc-editor.org/g/情報/RFC6192>。
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, <https://www.rfc-editor.org/info/rfc7126>.
[RFC7126] Gont、F.、Atkinson、R。、およびC. Pignataro、「IPv4オプションを含むIPv4パケットのフィルタリングに関する推奨事項」、BCP 186、RFC 7126、DOI 10.17487/RFC7126、2014年2月、<https：.rfc-editor.org/info/rfc7126>。
[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] Gont、F.、Linkova、J.、Chown、T。、およびW. Liu、「現実世界のIPv6拡張ヘッダーによるパケットのドロップに関する観察」、RFC 7872、DOI 10.17487/RFC7872、2016年6月、<https://www.rfc-editor.org/info/rfc7872>。
[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>.
[RFC9098] Gont、F.、Hilliard、N.、Doering、G.、Kumari、W.、Huston、G。、およびW. Liu、「拡張ヘッダーによるIPv6パケットの運用上の意味」、RFC 9098、DOI 10.17487/RFC9098、2021年9月、<https://www.rfc-editor.org/info/rfc9098>。
Acknowledgements
謝辞
The authors would like to thank Ron Bonica for his work on earlier draft versions of this document.
著者は、このドキュメントの以前のドラフトバージョンに関する彼の研究についてRon Bonicaに感謝したいと思います。
The authors of this document would like to thank (in alphabetical order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles, Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter Van de Velde, Éric Vyncke, and Robert Wilton for providing valuable comments on earlier draft versions of this document.
この文書の著者は、（アルファベット順に）ミカエル・アブラハムソン、ブライアン・カーペンター、ティム・チャウン、ロマン・ダニリウ、ダレン・デュークス、ラース・エッガート、デビッド・ファーマー、マイク・ハード、ボブ・ヒンデン、クリスチャン・フイテマ、ベンジャミン・カドゥク、エリック・ライン、マレー・クチェラウィー、ジェン・リンコヴァ、カルロス・ピグナタロ、アルバロ・レターナ、マリア・イネス・ロブレス、ザヘダッツザマン・サルカー、ドナルド・スミス、パスカル・トゥーバート、オレ・トローアン、ガンター・ヴァン・デ・ヴェルデ、エリック・ヴィンケ、ロバート・ウィルトト。
This document borrows some text and analysis from [RFC7126], which is authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
このドキュメントは、Fernando Gont、Randall Atkinson、およびCarlos Pignataroによって執筆されている[RFC7126]からいくつかのテキストと分析を借用しています。
The authors would like to thank Warren Kumari and Éric Vyncke for their guidance during the publication process for this document.
著者は、この文書の公開プロセス中のガイダンスについて、Warren KumariとEric Vynckeに感謝したいと思います。
Fernando would also like to thank Brian Carpenter and Ran Atkinson who, over the years, have answered many questions and provided valuable comments that have benefited his protocol-related work (including the present document).
フェルナンドはまた、ブライアン・カーペンターに感謝し、長年にわたって多くの質問に答え、彼のプロトコル関連の作品（現在の文書を含む）に利益をもたらした貴重なコメントを提供してきたアトキンソンを走らせたいと思います。
Authors' Addresses
著者のアドレス
Fernando Gont SI6 Networks Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com
Fernando Gont SI6 Networks Segurola Y Habana 4310 7mo Piso Ciudad Autonoma de Buenos Aires Argentinaメール：fgont@si6networks.com URI：https：//www.si6networks.com
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China Email: liushucheng@huawei.com
Will（Shucheng）Liu Huawei Technologies Bantian、Longgang District Shenzhen 518129 China Email：liushucheng@huawei.com