[要約] RFC 9268 は、IPv6の新しいHop-by-Hop Optionを定義し、ソースホストから宛先ホストまでの最小パスMTUを記録することを目的としています。この記録された値は、返り値のPath MTUフィールドを使用してソースに通知されます。
Internet Engineering Task Force (IETF) R. Hinden
Request for Comments: 9268 Check Point Software
Category: Experimental G. Fairhurst
ISSN: 2070-1721 University of Aberdeen
August 2022
IPv6 Minimum Path MTU Hop-by-Hop Option
IPv6最小パスMTUホップバイホップオプション
Abstract
概要
This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option.
このドキュメントは、宛先ホストのソースホスト間のフォワードパスに沿って最小パスMTU（PMTU）を記録するために使用される新しいIPv6ホップバイホップオプションを指定します。記録された値は、オプションのReturn Path MTUフィールドを使用してソースに伝達することができます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9268.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9268で取得できます。
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
1.1. Example Operation
1.2. Use of the IPv6 Hop-by-Hop Options Header
2. Motivation and Problem Solved
3. Requirements Language
4. Applicability Statements
5. IPv6 Minimum Path MTU Hop-by-Hop Option
6. Router, Host, and Transport Layer Behaviors
6.1. Router Behavior
6.2. Host Operating System Behavior
6.3. Transport Layer Behavior
6.3.1. Including the Option in an Outgoing Packet
6.3.2. Validation of the Packet that Includes the Option
6.3.3. Receiving the Option
6.3.4. Using the Rtn-PMTU Field
6.3.5. Detecting Path Changes
6.3.6. Detection of Dropping Packets that Include the Option
7. IANA Considerations
8. Security Considerations
8.1. Router Option Processing
8.2. Network-Layer Host Processing
8.3. Validating Use of the Option Data
8.4. Direct Use of the Rtn-PMTU Value
8.5. Using the Rtn-PMTU Value as a Hint for Probing
8.6. Impact of Middleboxes
9. Experiment Goals
10. Implementation Status
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples of Usage
Acknowledgments
Authors' Addresses
This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record the minimum Maximum Transmission Unit (MTU) along the forward path between a source and a destination host. The source host creates a packet with this Option and initializes the Min-PMTU field with the value of the MTU for the outbound link that will be used to forward the packet towards the destination host.
このドキュメントは、ソースと宛先ホストの間のフォワードパスに沿って最小最大送信ユニット（MTU）を記録する新しいIPv6ホップバイホップ（HBH）オプションを指定します。ソースホストは、このオプションを使用してパケットを作成し、MIN-PMTUフィールドを、パケットを宛先ホストに転送するために使用されるアウトバウンドリンクのMTUの値で初期化します。
At each subsequent hop where the Option is processed, the router compares the value of the Min-PMTU field in the Option and the MTU of its outgoing link. If the MTU of the link is less than the Min-PMTU, it rewrites the value in the Option Data with the smaller value. When the packet arrives at the destination host, the host can send the value of the minimum Reported MTU for the path back to the source host using the Rtn-PMTU field in the Option. The source host can then use this value as input to the method that sets the Path MTU (PMTU) used by upper-layer protocols.
オプションが処理される各後続のホップで、ルーターは、オプションのMIN-PMTUフィールドの値とその発信リンクのMTUを比較します。リンクのMTUがMIN-PMTUよりも少ない場合、オプションデータの値を小さい値で書き換えます。パケットが宛先ホストに到着すると、ホストは、オプションのRTN-PMTUフィールドを使用して、ソースホストにパスに対して報告された最小MTUの値を送信できます。ソースホストは、この値を、上層層プロトコルで使用するPATH MTU（PMTU）を設定するメソッドへの入力として使用できます。
The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option is designed to work with packet sizes that can be specified in the IPv6 header. The maximum packet size that can be specified in an IPv6 header is 65,535 octets (2^16).
IPv6 Minimum Path MTU HOP-HOP（MinPMTU HBH）オプションは、IPv6ヘッダーで指定できるパケットサイズで動作するように設計されています。IPv6ヘッダーで指定できる最大パケットサイズは、65,535オクテット（2^16）です。
This method has the potential to complete Path MTU Discovery (PMTUD) in a single round-trip time, even over paths that have successive links, each with a lower MTU.
この方法には、1回の往復時間でMTU発見（PMTUD）を完了する可能性があり、それぞれがより低いMTUを持つ連続したリンクを持つパス上であっても。
The mechanism defined in this document is focused on unicast; it does not describe multicast. That is left for future work.
このドキュメントで定義されているメカニズムは、ユニキャストに焦点を当てています。マルチキャストについては説明していません。それは将来の仕事のために残されています。
The figure below illustrates the operation of the method. In this case, the path between the source host and the destination host comprises three links: the source has a link MTU of size MTU-S, the link between routers R1 and R2 has an MTU of size 9000 bytes, and the final link to the destination has an MTU of size MTU-D.
以下の図は、メソッドの動作を示しています。この場合、ソースホストと宛先ホストの間のパスは3つのリンクで構成されています。ソースにはサイズMTU-SのリンクMTU、Routers R1とR2のリンクにはサイズ9000バイトのMTU、最終リンクがあります。目的地には、MTU-DのMTUがあります。
+--------+ +----+ +----+ +-------+
| | | | | | | |
| Sender +---------+ R1 +--------+ R2 +-------- + Dest. |
| | | | | | | |
+--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+
Figure 1: An Example Path between the Source Host and the Destination Host
図1：ソースホストと宛先ホストの間のパスの例
Three scenarios are described:
3つのシナリオについて説明します。
* Scenario 1 considers all links to have a 9000 byte MTU, and the method is supported by both routers. The initial Min-PMTU is not modified along the path. Therefore, the PMTU is 9000 bytes.
* シナリオ1では、すべてのリンクが9000バイトMTUを持つと考慮し、この方法は両方のルーターによってサポートされています。最初のMIN-PMTUはパスに沿って変更されません。したがって、PMTUは9000バイトです。
* Scenario 2 considers the link between R2 and the destination host (MTU-D) to have an MTU of 1500 bytes. This is the smallest MTU. Router R2 updates the Min-PMTU to 1500 bytes, and the method correctly updates the PMTU to 1500 bytes. Had there been another smaller MTU at a link further along the path that also supports the method, the lower MTU would also have been detected.
* シナリオ2では、R2と宛先ホスト（MTU-D）の間のリンクを1500バイトのMTUを持つことを考慮します。これは最小のMTUです。Router R2はMIN-PMTUを1500バイトに更新し、このメソッドはPMTUを1500バイトに正しく更新します。この方法もサポートするパスに沿ってさらに小さなMTUがある場合、より低いMTUも検出されていました。
* Scenario 3 considers the case where the router preceding the smallest link (R2) does not support the method, and the link to the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, router R2 does not update the Min-PMTU to 1500 bytes. The method then fails to detect the actual PMTU.
* シナリオ3では、最小リンク（R2）の前にあるルーターがメソッドをサポートせず、宛先ホスト（MTU-D）へのリンクが1500バイトのMTUを持っている場合を考慮します。したがって、Router R2はMIN-PMTUを1500バイトに更新しません。そのメソッドは、実際のPMTUを検出できません。
In Scenarios 2 and 3, a lower PMTU would also fail to be detected in the case where PMTUD had been used and an ICMPv6 Packet Too Big (PTB) message had not been delivered to the sender [RFC8201].
シナリオ2および3では、PMTUDが使用されていた場合には低いPMTUも検出されず、ICMPV6パケットが大きすぎる（PTB）メッセージが送信者に配信されていませんでした[RFC8201]。
These scenarios are summarized in the table below. "H" in R1 and/or R2 columns means the router understands the MinPMTU HBH Option.
これらのシナリオは、以下の表にまとめられています。R1および/またはR2列の「H」は、ルーターがMinPMTU HBHオプションを理解することを意味します。
+===+========+========+====+====+==========+=======================+
| | MTU-S | MTU-D | R1 | R2 | Rec PMTU | Note |
+===+========+========+====+====+==========+=======================+
| 1 | 9000 B | 9000 B | H | H | 9000 B | Endpoints attempt to |
| | | | | | | use a 9000 B PMTU. |
+---+--------+--------+----+----+----------+-----------------------+
| 2 | 9000 B | 1500 B | H | H | 1500 B | Endpoints attempt to |
| | | | | | | use a 1500 B PMTU. |
+---+--------+--------+----+----+----------+-----------------------+
| 3 | 9000 B | 1500 B | H | - | 9000 B | Endpoints attempt to |
| | | | | | | use a 9000 B PMTU but |
| | | | | | | need to implement a |
| | | | | | | method to fall back |
| | | | | | | to discover and use a |
| | | | | | | 1500 B PMTU. |
+---+--------+--------+----+----+----------+-----------------------+
Table 1: Three Scenarios That Arise from Using the Path Shown in Figure 1
表1：図1に示すパスの使用から生じる3つのシナリオ
As specified in [RFC8200], IPv6 allows nodes to optionally process the Hop-by-Hop header. Specifically, from Section 4 of [RFC8200]:
[RFC8200]で指定されているように、IPv6を使用すると、ノードはオプションでホップバイホップヘッダーを処理できます。具体的には、[RFC8200]のセクション4から：
| The Hop-by-Hop Options header is not inserted or deleted, but may
| be examined or processed by any node along a packet's delivery
| path, until the packet reaches the node (or each of the set of
| nodes, in the case of multicast) identified in the Destination
| Address field of the IPv6 header. The Hop-by-Hop Options header,
| when present, must immediately follow the IPv6 header. Its
| presence is indicated by the value zero in the Next Header field
| of the IPv6 header.
|
| NOTE: While [RFC2460] required that all nodes must examine and
| process the Hop-by-Hop Options header, it is now expected that
| nodes along a packet's delivery path only examine and process the
| Hop-by-Hop Options header if explicitly configured to do so.
The Hop-by-Hop Option defined in this document is designed to take advantage of this property of how Hop-by-Hop Options are processed. Nodes that do not support this Option SHOULD ignore them. This can mean that the Min-PMTU value does not account for all links along a path.
このドキュメントで定義されているホップバイホップオプションは、ホップバイホップオプションの処理方法のこのプロパティを活用するように設計されています。このオプションをサポートしていないノードは、それらを無視する必要があります。これは、MIN-PMTU値がパスに沿ったすべてのリンクを考慮していないことを意味します。
The current state of Path MTU Discovery on the Internet is problematic. The mechanisms defined in [RFC8201] are known to not work well in all environments. It fails to work in various cases, including when nodes in the middle of the network do not send ICMPv6 PTB messages or rate-limited ICMPv6 messages or do not have a return path to the source host. This results in many transport-layer connections being configured to use smaller packets (e.g., 1280 bytes) by default and makes it difficult to take advantage of paths with a larger PMTU where they do exist. Applications that send large packets are forced to use IPv6 fragmentation [RFC8200], which can reduce the reliability of Internet communication [RFC8900].
インターネット上の現在のパスMTU発見の状態には問題があります。[RFC8201]で定義されているメカニズムは、すべての環境でうまく機能しないことが知られています。ネットワークの中央のノードがICMPV6 PTBメッセージまたはレート制限ICMPV6メッセージを送信しない場合、またはソースホストへのリターンパスがない場合など、さまざまな場合には機能しません。これにより、デフォルトでは、より小さなパケット（たとえば、1280バイト）を使用するように多くの輸送層接続が構成され、存在するより大きなPMTUでパスを利用することを困難にします。大規模なパケットを送信するアプリケーションは、IPv6断片化[RFC8200]を使用することを余儀なくされており、インターネット通信[RFC8900]の信頼性を低下させる可能性があります。
Encapsulations and network-layer tunnels further reduce the payload size available for a transport protocol to use. Also, some use cases increase packet overhead, for example, Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637] encapsulates Layer 2 (L2) packets in an outer IP header and does not allow IP fragmentation.
カプセル化とネットワーク層トンネルは、輸送プロトコルが使用できるペイロードサイズをさらに削減します。また、一部のユースケースは、パケットオーバーヘッドを増加させます。たとえば、一般的なルーティングカプセル化（NVGRE）[RFC7637]を使用したネットワーク仮想化は、外部IPヘッダーのレイヤー2（L2）パケットをカプセル化し、IP断片化を許可しません。
Sending larger packets can improve host performance, e.g., avoiding limits to packet processing by the packet rate. An example of this is how the packet-per-second rate required to reach wire speed on a 10G link with 1280 byte packets is about 977K packets per second (pps) vs. 139K pps for 9000 byte packets.
大型パケットを送信すると、ホストのパフォーマンスが向上する可能性があります。たとえば、パケットレートによるパケット処理の制限を回避できます。この例は、1280バイトパケットを使用した10gリンクでワイヤ速度に到達するために必要なパケットレートが、9000バイトパケットの1秒あたり約977kパケット（PPS）対139K PPSであることです。
The purpose of this document is to improve the situation by defining a mechanism that does not rely on reception of ICMPv6 PTB messages from nodes in the middle of the network. Instead, this provides information to the destination host about the Minimum Path MTU and sends this information back to the source host. This is expected to work better than the current mechanisms based on [RFC8201].
このドキュメントの目的は、ネットワークの中央にあるノードからのICMPV6 PTBメッセージの受信に依存しないメカニズムを定義することにより、状況を改善することです。代わりに、これは最小パスMTUに関する情報を宛先ホストに提供し、この情報をソースホストに送り返します。これは、[RFC8201]に基づいた現在のメカニズムよりもうまく機能すると予想されます。
A similar mechanism was proposed in 1988 for IPv4 in [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith McCloghire. It was later obsoleted in 1990 by [RFC1191], which is the current deployed approach to Path MTU Discovery. In contrast, the method described in this document uses the Hop-by-Hop Option of IPv6. It does not replace PMTUD [RFC8201], Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821], or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) [RFC8899] but rather is designed to compliment these methods.
Jeff Mogul、C。Kent、Craig Partridge、およびKeith McCloghireによって、[RFC1063]のIPv4についても1988年に同様のメカニズムが提案されました。その後、1990年に[RFC1191]によって廃止されました。これは、Path MTU発見への現在の展開アプローチです。対照的に、このドキュメントで説明されている方法は、IPv6のホップバイホップオプションを使用しています。PMTUD [RFC8201]、パケット化レイヤーパスMTUディスカバリー（PLPMTUD）[RFC4821]、またはデータグラムのパケット化レイヤーPMTUディスカバリー（DPLPMTUD）[RFC8899]を置き換えるのではなく、これらの方法を補完するように設計されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Path MTU Option is designed for environments where there is control over the hosts and nodes that connect them and where there is more than one MTU size in use, for example, in data centers and on paths between data centers to allow hosts to better take advantage of a path that is able to support a large PMTU.
PATH MTUオプションは、ホストとノードを接続するホストとノードを制御し、たとえばデータセンターやデータセンター間のパスで使用されているMTUサイズが複数ある環境向けに設計されており、ホストをより適切に取ることができます。大きなPMTUをサポートできるパスの利点。
The design of the Option is so sufficiently simple that it can be executed on a router's fast path. A successful experiment depends on both implementation by host and router vendors and deployment by operators. The contained use case of connections within and between data centers could be a driver for deployment.
オプションの設計は非常に単純であるため、ルーターの高速パスで実行できます。成功した実験は、ホストベンダーとルーターベンダーによる実装とオペレーターによる展開の両方に依存します。データセンター内およびデータセンター間の接続の使用ケースが含まれているのは、展開のドライバーになる可能性があります。
The method could also be useful in other environments, including the general Internet, and offers an advantage when this Hop-by-Hop Option is supported on all paths. The method is more robust when used to probe the path using packets that do not carry application data and when also paired with a method like Packetization Layer PMTUD [RFC4821] or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) [RFC8899].
この方法は、一般的なインターネットを含む他の環境でも役立つ可能性があり、このホップバイホップオプションがすべてのパスでサポートされている場合に利点を提供します。この方法は、アプリケーションデータを運ぶパケットを使用してパスをプローブするために使用されると、パケット化レイヤーPMTUD [RFC4821]またはデータグラムパケット化レイヤーPMTUディスカバリー（DPLPMTUD）[RFC8899]などの方法とペアリングすると、より堅牢です。
The Minimum Path MTU Hop-by-Hop Option has the following format:
最小パスMTUホップバイホップオプションには、次の形式があります。
Option Option Option
Type Data Len Data
+--------+--------+--------+--------+---------+-------+-+
|BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R|
+--------+--------+--------+--------+---------+-------+-+
Figure 2: Format of the Minimum Path MTU Hop-by-Hop Option
図2：最小パスMTUホップバイホップオプションの形式
Option Type (see Section 4.2 of [RFC8200]):
オプションタイプ（[RFC8200]のセクション4.2を参照）：
BB 00 Skip over this Option and continue processing.
BB 00このオプションをスキップして、処理を続けます。
C 1 Option Data can change en route to the packet's final destination.
C 1オプションデータは、パケットの最終目的地に向けて変更できます。
TTTTT 10000 Option Type assigned from IANA [IANA-HBH].
IANA [IANA-HBH]から割り当てられたTTTTT 10000オプションタイプ。
Length: 4 The size of the value field in Option Data field supports PMTU values from 0 to 65,534 octets, the maximum size represented by the Path MTU Option.
長さ：4オプションデータフィールドの値フィールドのサイズは、PATH MTUオプションで表される最大サイズの0から65,534オクテットのPMTU値をサポートします。
Min-PMTU: n 16-bits. The minimum MTU recorded along the path in octets, reflecting the smallest link MTU that the packet experienced along the path. A value less than the IPv6 minimum link MTU [RFC8200] MUST be ignored.
MIN-PMTU：N 16ビット。最小のMTUは、パケットがパスに沿って経験した最小のリンクMTUを反映して、オクテットのパスに沿って記録されました。IPv6最小リンクMTU [RFC8200]より少ない値を無視する必要があります。
Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 most significant bits of the latest received Min-PMTU field for the forward path. The value zero means that no Reported MTU is being returned.
RTN-PMTU：N 15ビット。返されたパスMTUフィールドは、最新の受信したMIN-PMTUフィールドの最も重要な15ビットをフォワードパス用に運びます。値ゼロは、報告されたMTUが返されないことを意味します。
R n 1-bit. R-Flag. Set by the source to signal that the destination host should include the received Rtn-PMTU field updated by the reported Min-PMTU value when the destination host is to send a PMTU Option back to the source host.
r n 1ビット。r-flag。宛先ホストが、宛先ホストがPMTUオプションをソースホストに送信する場合、宛先ホストに報告されたMIN-PMTU値によって更新された受信したRTN-PMTUフィールドを含める必要があることを示すようにソースによって設定されます。
NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) could be implemented by a mask of the latest received Min-PMTU value with 0xFFFE, discarding the right-most bit and then performing a logical 'OR' with the R-Flag value of the sender. This encoding fits in the minimum-sized Hop-by-Hop Option header.
注：最後の2オクテット（RTN-PMTUおよびR-FLAG）のエンコードは、0xFFFEで最新のMIN-PMTU値のマスクによって実装され、適切なビットを破棄してから論理的な 'または'で実行できます。送信者のr-flag値。このエンコードは、最小サイズのホップバイホップオプションヘッダーに適合します。
Routers that are not configured to support Hop-by-Hop Options are not expected to examine or process the contents of this Option [RFC8200].
ホップバイホップオプションをサポートするように構成されていないルーターは、このオプション[RFC8200]の内容を調べたり処理したりすることは期待されていません。
Routers that support Hop-by-Hop Options but are not configured to support this Option SHOULD skip over this Option and continue to process the header [RFC8200].
ホップバイホップオプションをサポートするが、このオプションをサポートするように構成されていないルーターは、このオプションをスキップし、ヘッダー[RFC8200]の処理を続ける必要があります。
Routers that support this Option MUST compare the value of the Min-PMTU field with the MTU configured for the outgoing link. If the MTU of the outgoing link is less than the Min-PMTU, the router rewrites the Min-PMTU in the Option to use the smaller value. (The router processing is performed without checking the valid range of the Min-PMTU or the Rtn-PMTU fields.)
このオプションをサポートするルーターは、MIN-PMTUフィールドの値を、発信リンク用に構成されたMTUと比較する必要があります。発信リンクのMTUがMIN-PMTUよりも少ない場合、ルーターはMIN-PMTUをオプションで書き換えて、より小さな値を使用します。（ルーター処理は、MIN-PMTUまたはRTN-PMTUフィールドの有効な範囲をチェックせずに実行されます。）
A router MUST ignore and MUST NOT change the Rtn-PMTU field or the R-Flag in the Option.
ルーターは、OptionのRTN-PMTUフィールドまたはR-Flagを無視する必要があります。
The PMTU entry associated with the destination in the host's destination cache [RFC4861] SHOULD be updated after detecting a change using the IPv6 Minimum Path MTU Hop-by-Hop Option. This cached value can be used by other flows that share the host's destination cache.
ホストの宛先キャッシュ[RFC4861]の宛先に関連付けられているPMTUエントリは、IPv6 Minimum Path MTU Hop-by-Hopオプションを使用して変更を検出した後に更新する必要があります。このキャッシュされた値は、ホストの宛先キャッシュを共有する他のフローで使用できます。
The value in the host destination cache SHOULD be used by PLPMTUD to select an initial PMTU for a flow. The cached PMTU is only increased by PLPMTUD when the Packetization Layer determines the path actually supports a larger PMTU [RFC4821] [RFC8899].
ホスト宛先キャッシュの値は、PLPMTUDによって使用されて、フローの初期PMTUを選択する必要があります。キャッシュされたPMTUは、パケット化層が実際により大きなPMTU [RFC4821] [RFC8899]を実際にサポートするパスを決定する場合にのみPLPMTUDによって増加します。
When requested to send an IPv6 packet with the MinPMTU HBH Option, the source host includes the Option in an outgoing packet. The source host MUST fill the Min-PMTU field with the MTU configured for the link over which it will send the packet on the next hop towards the destination host.
MinPMTU HBHオプションを使用してIPv6パケットを送信するように要求された場合、ソースホストには発信パケットにオプションが含まれています。ソースホストは、Min-PMTUフィールドに、次のホップでパケットを宛先ホストに送信するリンク用に構成されたMTUで埋める必要があります。
When a host includes the Option in a packet it sends, the host SHOULD set the Rtn-PMTU field to the previously cached value of the received Minimum Path MTU for the flow in the Rtn-PMTU field (see Section 6.3.3). If this value is not set (for example, because there is no cached reported Min-PMTU value), the Rtn-PMTU field value MUST be set to zero.
ホストが送信するパケットにオプションを含めると、ホストはRTN-PMTUフィールドの以前にキャッシュされた値にRTN-PMTUフィールドのフローの最小パスMTUの値に設定する必要があります（セクション6.3.3を参照）。この値が設定されていない場合（たとえば、Cachedが報告されたMIN-PMTU値がないため）、RTN-PMTUフィールド値はゼロに設定する必要があります。
The source host MAY request the destination host to return the reported Min-PMTU value by setting the R-Flag in the Option of an outgoing packet. The R-Flag SHOULD NOT be set when the MinPMTU HBH Option was sent solely to provide requested feedback on the return Path MTU to avoid each response generating another response.
ソースホストは、発信パケットのオプションにR-Flagを設定することにより、宛先ホストに報告されたMIN-PMTU値を返すように要求する場合があります。R-FLAGは、MinPMTU HBHオプションが送信された場合に設定しないでください。各応答が別の応答を生成することを回避するために、リターンパスMTUに関する要求されたフィードバックを提供するだけです。
The destination host controls when to send a packet with this Option in response to an R-Flag, as well as which packets to include it in. The destination host MAY limit the rate at which it sends these packets.
宛先ホストは、r-flagに応じてこのオプションを使用してパケットを送信するタイミングと、それを含めるパケットを制御します。宛先ホストは、これらのパケットを送信するレートを制限する場合があります。
A destination host only sets the R-Flag if it wishes the source host to also return the discovered PMTU value for the path from the destination to the source.
宛先ホストは、ソースホストが宛先からソースまでのパスの発見されたPMTU値を返すことを望んでいる場合にのみR-Flagを設定します。
The normal sequence of operation of the R-Flag using the terminology from the diagram in Figure 1 is:
図1の図の用語を使用したR-Flagの通常の動作シーケンスは次のとおりです。
1. The source sends a probe to the destination. The sender sets the R-Flag.
1. ソースは、プローブを宛先に送信します。送信者はr-flagを設定します。
2. The destination responds by sending a probe including the received Min-PMTU as the Rtn-PMTU. A destination that does not wish to probe the return path sets the R-Flag to 0.
2. 宛先は、受信したMIN-PMTUをRTN-PMTUとして含むプローブを送信することで応答します。リターンパスをプローブしたくない宛先は、r-flagを0に設定します。
This Hop-by-Hop Option is intended to be used with a Path MTU Discovery method.
このホップバイホップオプションは、PATH MTU Discoveryメソッドで使用することを目的としています。
PLPMTUD [RFC8899] uses probe packets for two distinct functions:
PLPMTUD [RFC8899]は、2つの異なる関数にプローブパケットを使用します。
* Probe packets are used to confirm connectivity. Such probes can be of any size up to the Packetization Layer Path MTU (PLPMTU). These probe packets are sent to solicit a response using the path to the remote node. These probe packets can carry the Hop-by-Hop PMTU Option, providing the final size of the packet does not exceed the current PLPMTU. After validating that the packet originates from the path (Section 4.6.1 of [RFC8899]), the PLPMTUD method can use the reported size from the Hop-by-Hop Option as the next search point when it resumes the search algorithm. (This use resembles the use of the PTB_SIZE information in Section 4.6.2 of [RFC8899].)
* プローブパケットは、接続を確認するために使用されます。このようなプローブは、パケット化レイヤーパスMTU（PLPMTU）までの任意のサイズのものです。これらのプローブパケットは、リモートノードへのパスを使用して応答を求めるために送信されます。これらのプローブパケットは、ホップバイホップPMTUオプションを運ぶことができ、パケットの最終サイズを提供しても、現在のPLPMTUを超えません。パケットがパス（[RFC8899]のセクション4.6.1）から発信されることを検証した後、PLPMTUDメソッドは、検索アルゴリズムを再開するときに次の検索ポイントとして、ホップバイホップオプションから報告されたサイズを使用できます。（この使用は、[RFC8899]のセクション4.6.2のPTB_SIZE情報の使用に似ています。）
* A second use of probe packets is to explore if a path supports a packet size greater than the current PLPMTU. If this probe packet is successfully delivered (as determined by the source host), then the PLPMTU is raised to the size of the successful probe. These probe packets do not usually set the Path MTU Hop-by-Hop Option. See Section 1.2 of [RFC8899]. Section 4.1 of [RFC8899] also describes ways that a probe packet can be constructed, depending on whether the probe packets carry application data.
* プローブパケットの2回目の使用は、パスが現在のPLPMTUよりも大きいパケットサイズをサポートするかどうかを調査することです。このプローブパケットが正常に配信された場合（ソースホストによって決定されたように）、PLPMTUは成功したプローブのサイズに引き上げられます。これらのプローブパケットは、通常、MTUホップバイホップオプションを設定しません。[RFC8899]のセクション1.2を参照してください。[RFC8899]のセクション4.1では、プローブパケットがアプリケーションデータを伝達するかどうかに応じて、プローブパケットを構築できる方法についても説明します。
The PMTU Hop-by-Hop Option probe can be sent on packets that include application data but needs to be robust to potential loss of the packet (i.e., with the possibility that retransmission might be needed if the packet is lost).
PMTUホップバイホップオプションプローブは、アプリケーションデータを含むが、パケットの潜在的な損失に対して堅牢である必要があるパケットに送信できます（つまり、パケットが失われた場合に再送信が必要になる可能性があります）。
Using a PMTU probe on packets that do not carry application data will avoid the need for loss recovery if a router on the path drops packets that set this Option. (This avoids the transport needing to retransmit a lost packet that includes this Option.) This is the normal default format for both uses of probes.
アプリケーションデータを運ばないパケットにPMTUプローブを使用すると、パス上のルーターがこのオプションを設定したパケットをドロップすると、損失回復の必要性が回避されます。（これにより、このオプションを含む失われたパケットを再送信する必要があるトランスポートが回避されます。）これは、プローブの両方の使用の通常のデフォルト形式です。
The upper-layer protocol can request the MinPMTU HBH Option to be included in an outgoing IPv6 packet. A transport protocol (or upper-layer protocol) can include this Option only on specific packets used to test the path. This Option does not need to be included in all packets belonging to a flow.
上層層プロトコルは、MinPMTU HBHオプションを発信するIPv6パケットに含めるように要求できます。トランスポートプロトコル（または上層層プロトコル）には、このオプションをパスのテストに使用する特定のパケットにのみ含めることができます。このオプションは、フローに属するすべてのパケットに含める必要はありません。
NOTE: Including this Option in a large packet (e.g., one larger than the present PMTU) is not likely to be useful, since the large packet would itself be dropped by any link along the path with a smaller MTU, preventing the Min-PMTU information from reaching the destination host.
注：大きなパケット（現在のPMTUよりも大きいもの）にこのオプションを含めることは、大きなパケット自体が小さいMTUでパスに沿ったリンクによってドロップされ、MIN-PMTUを防ぐため、役立つ可能性が低くなります。宛先ホストに到達することからの情報。
Discussion:
討論：
* In the case of TCP, the Option could be included in a packet that carries a TCP segment sent after the connection is established. A segment without data could be used to avoid the need to retransmit this data if the probe packet is lost. The discovered value can be used to inform PLPMTUD [RFC4821].
* TCPの場合、接続が確立された後に送信されるTCPセグメントを運ぶパケットにオプションを含めることができます。プローブパケットが失われた場合、このデータを再送信する必要性を回避するために、データのないセグメントを使用できます。発見された値は、PLPMTUD [RFC4821]を通知するために使用できます。
NOTE: A TCP SYN can also negotiate the Maximum Segment Size (MSS), which acts as an upper limit to the packet size that can be sent by a TCP sender. If this Option were to be included in a TCP SYN, it could increase the probability that the SYN segment is lost when routers on the path drop packets with this Option (see Section 6.3.6), which could have an unwanted impact on the result of racing Options [TAPS-ARCH] or feature negotiation.
注：TCP Synは、TCP送信者が送信できるパケットサイズの上限として機能する最大セグメントサイズ（MSS）をネゴシエートすることもできます。このオプションをTCP synに含めると、このオプションを使用してパスドロップパケットのルーター（セクション6.3.6を参照）をドロップすると、Synセグメントが失われる可能性が高くなります。レースオプション[TAPS-ARCH]または機能交渉。
* The use with datagram transport protocols (e.g., UDP) is harder to characterize because applications using datagram transports range from very short-lived (low data-volume applications) exchanges to longer (bulk) exchanges of packets between the source and destination hosts [RFC8085].
* Datagram Transport Protocols（UDPなど）での使用は、Datagram Transportsを使用するアプリケーションが非常に短命の（データボリュームアプリケーションの低い）交換から、ソースホストと宛先ホスト[RFC8085の間の長い（バルク）交換にまで及ぶため、特徴付けが困難です。]。
* Simple-exchange protocols (i.e., low data-volume applications [RFC8085] that only send one or a few packets per transaction) might assume that the PMTU is symmetrical. That is, the PMTU is the same in both directions or at least not smaller for the return path. This optimization does not hold when the paths are not symmetric.
* 単純交換プロトコル（つまり、トランザクションごとに1つまたは数のパケットのみを送信する低データ式アプリケーション[RFC8085]）は、PMTUが対称であると仮定する場合があります。つまり、PMTUは両方向で同じであるか、少なくともリターンパスでは小さくありません。この最適化は、パスが対称でない場合には当てはまりません。
* The MinPMTU HBH Option can be used with ICMPv6 [RFC4443]. This requires a response from the remote node and therefore is restricted to use with ICMPv6 echo messages. The MinPMTU HBH Option could provide additional information about the PMTU that might be supported by a path. This could be used as a diagnostic tool to measure the PMTU of a path. As with other uses, the actual supported PMTU is only confirmed after receiving a response to a subsequent probe of the PMTU size.
* MinPMTU HBHオプションは、ICMPv6 [RFC4443]で使用できます。これには、リモートノードからの応答が必要であるため、ICMPV6エコーメッセージで使用することが制限されています。MinPMTU HBHオプションは、パスによってサポートされる可能性のあるPMTUに関する追加情報を提供できます。これは、パスのPMTUを測定するための診断ツールとして使用できます。他の用途と同様に、実際にサポートされているPMTUは、PMTUサイズの後続のプローブへの応答を受信した後にのみ確認されます。
* A datagram transport can utilize DPLPMTUD [RFC8899]. For example, QUIC (see Section 14.3 of [RFC9000]) can use DPLPMTUD to determine whether the path to a destination will support a desired maximum datagram size. When using the IPv6 MinPMTU HBH Option, the Option could be added to an additional QUIC PMTU probe that is of minimal size (or one no larger than the currently supported PMTU size). Once the return Path MTU value in the MinPMTU HBH Option has been learned, DPLPMTUD can be triggered to test for a larger PLPMTU using an appropriately sized PLPMTU probe packet (see Section 5.3.1 of [RFC8899]).
* データグラムトランスポートは、DPLPMTUD [RFC8899]を利用できます。たとえば、QUIC（[RFC9000]のセクション14.3を参照）を使用して、DPLPMTUDを使用して、宛先へのパスが目的の最大データグラムサイズをサポートするかどうかを判断できます。IPv6 MinpMTU HBHオプションを使用する場合、オプションは最小サイズ（または現在サポートされているPMTUサイズよりも大きいもの）の追加のQUIC PMTUプローブに追加できます。MinPMTU HBHオプションのRETURN PATH MTU値が学習されると、DPLPMTUDをトリガーして、適切なサイズのPLPMTUプローブパケットを使用して、より大きなPLPMTUをテストできます（[RFC8899]のセクション5.3.1を参照）。
* The use of this Option with DNS and DNSSEC over UDP is expected to work for paths where the PMTU is symmetric. The DNS server will learn the PMTU from the DNS query messages. If the Rtn-PMTU value is smaller, then a large DNSSEC response might be dropped and the known problems with PMTUD will then occur. DNS and DNSSEC over transport protocols that can carry the PMTU ought to work.
* UDPを介したDNSおよびDNSSECを使用したこのオプションの使用は、PMTUが対称であるパスで機能すると予想されます。DNSサーバーは、DNSクエリメッセージからPMTUを学習します。RTN-PMTU値が小さい場合、大きなDNSSEC応答が削除され、PMTUDの既知の問題が発生する可能性があります。PMTUを運ぶことができる輸送プロトコルを介したDNSおよびDNSSECは機能するはずです。
* This method also can be used with anycast to discover the PMTU of the path, but the use needs to be aware that the anycast binding might change.
* この方法は、AnycastでパスのPMTUを発見するために使用することもできますが、Anycastのバインディングが変化する可能性があることに注意する必要があります。
An upper-layer protocol (e.g., transport endpoint) using this Option needs to provide protection from data injection attacks by off-path devices [RFC8085]. This requires a method to assure that the information in the Option Data is provided by a node on the path. This validates that the packet forms a part of an existing flow, using context available at the upper layer. For example, a TCP connection or UDP application that maintains the related state and uses a randomized ephemeral port would provide this basic validation to protect from off-path data injection; see Section 5.1 of [RFC8085]. IPsec [RFC4301] and TLS [RFC8446] provide greater assurance.
このオプションを使用する上層層プロトコル（たとえば、輸送エンドポイント）は、オフパスデバイス[RFC8085]によるデータインジェクション攻撃からの保護を提供する必要があります。これには、オプションデータの情報がパス上のノードによって提供されることを保証する方法が必要です。これにより、パケットが上層で利用可能なコンテキストを使用して、既存のフローの一部を形成することを検証します。たとえば、関連状態を維持し、ランダム化されたはかないポートを使用するTCP接続またはUDPアプリケーションは、この基本的な検証を提供して、パス外のデータインジェクションから保護します。[RFC8085]のセクション5.1を参照してください。IPSEC [RFC4301]およびTLS [RFC8446]はより大きな保証を提供します。
The upper layer discards any received packet when the packet validation fails. When packet validation fails, the upper layer MUST also discard the associated Option Data from the MinPMTU HBH Option without further processing.
上層層は、パケットの検証が失敗したときに受け取ったパケットを破棄します。パケットの検証が失敗した場合、上層層は、さらに処理することなく、MinPMTU HBHオプションから関連するオプションデータを破棄する必要があります。
For a connection-oriented upper-layer protocol, caching of the received Min-PMTU could be implemented by saving the value in the connection context at the transport layer. A connectionless upper layer (e.g., one using UDP) requires the upper-layer protocol to cache the value for each flow it uses.
接続指向の上層層プロトコルの場合、受信したMIN-PMTUのキャッシュは、輸送層の接続コンテキストで値を保存することにより実装できます。コネクションレス上層（UDPを使用するものなど）には、使用する各フローの値をキャッシュするために上層層プロトコルが必要です。
A destination host that receives a MinPMTU HBH Option with the R-Flag SHOULD include the MinPMTU HBH Option in the next outgoing IPv6 packet for the corresponding flow.
R-Flagを使用してMinPMTU HBHオプションを受信する宛先ホストには、対応するフローの次の発信IPv6パケットにMinPMTU HBHオプションを含める必要があります。
A simple mechanism could only include this Option (with the Rtn-PMTU field set) the first time this Option is received or when it notifies a change in the Minimum Path MTU. This limits the number of packets, including the Option packets, that are sent. However, this does not provide robustness to packet loss or recovery after a sender loses state.
簡単なメカニズムには、このオプションが初めて受信されたとき、または最小パスMTUの変更が通知されたときに、このオプション（RTN-PMTUフィールドセットを使用）のみを含めることができます。これにより、送信されるオプションパケットを含むパケットの数が制限されます。ただし、これは、送信者が状態を失った後、パケットの損失や回復に堅牢性を提供しません。
Discussion:
討論：
* Some upper-layer protocols send packets less frequently than the rate at which the host receives packets. This provides less frequent feedback of the received Rtn-PMTU value. However, a host always sends the most recent Rtn-PMTU value.
* 一部の上層層プロトコルは、ホストがパケットを受信するレートよりも頻繁にパケットを送信します。これにより、受信したRTN-PMTU値の頻度の低いフィードバックが提供されます。ただし、ホストは常に最新のRTN-PMTU値を送信します。
The Rtn-PMTU field provides an indication of the PMTU from on-path routers. It does not necessarily reflect the actual PMTU between the source and destination hosts. Care therefore needs to be exercised in using the Rtn-PMTU value. Specifically:
RTN-PMTUフィールドは、パスオンパスルーターからのPMTUの指標を提供します。ソースホストと宛先ホストの間の実際のPMTUを必ずしも反映しているわけではありません。したがって、RTN-PMTU値を使用する際には注意が必要です。具体的には：
* The actual PMTU can be lower than the Rtn-PMTU value because the Min-PMTU field was not updated by a router on the path that did not process the Option.
* MIN-PMTUフィールドはオプションを処理しなかったパス上のルーターによって更新されなかったため、実際のPMTUはRT-MTU値よりも低くなる可能性があります。
* The actual PMTU may be lower than the Rtn-PMTU value because there is a Layer 2 device with a lower MTU.
* MTUが低いレイヤー2デバイスがあるため、実際のPMTUはRTN-PMTU値よりも低い場合があります。
* The actual PMTU may be larger than the Rtn-PMTU value because of a corrupted, delayed, or misordered response. A source host MUST ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link.
* 実際のPMTUは、破損、遅延、または誤った応答があるため、RTN-PMTU値よりも大きい場合があります。ソースホストは、発信リンク用に構成されたMTUよりも大きいRTN-PMTU値を無視する必要があります。
* The path might have changed between the time when the probe was sent and when the Rtn-PMTU value received.
* パスは、プローブが送信されたときとRTN-PMTU値が受信された時までに変更された可能性があります。
IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. A node MUST ignore a Rtn-PMTU value less than 1280 octets [RFC8200].
IPv6では、インターネット内のすべてのリンクには1280オクテット以上のMTUが必要です。ノードは、1280オクテット[RFC8200]未満のRTN-PMTU値を無視する必要があります。
To avoid unintentional dropping of packets that exceed the actual PMTU (e.g., Scenario 3 in Section 1.1), the source host can delay increasing the PMTU until a probe packet with the size of the Rtn-PMTU value has been successfully acknowledged by the upper layer, confirming that the path supports the larger PMTU. This probing increases robustness but adds one additional path round-trip time before the PMTU is updated. This use resembles that of PTB messages in Section 4.6 of DPLPMTUD [RFC8899] (with the important difference being that a PTB message can only seek to lower the PMTU, whereas this Option could trigger a probe packet to seek to increase the PMTU).
実際のPMTUを超えるパケットの意図しないドロップを回避するため（セクション1.1のシナリオ3など）、ソースホストは、RTN-PMTU値のサイズのプローブパケットが上層層によって正常に認められるまでPMTUの増加を遅らせる可能性があります。、パスがより大きなPMTUをサポートしていることを確認します。このプロービングは堅牢性を高めますが、PMTUが更新される前に1つのパスラウンドトリップ時間を追加します。この使用は、DPLPMTUD [RFC8899]のセクション4.6のPTBメッセージのそれに似ています（重要な違いは、PTBメッセージがPMTUのみを下げることができるのに対し、このオプションはPMTUを増やすためにプローブパケットをトリガーできることです）。
Section 5.2 of [RFC8201] provides guidance on the caching of PMTU information and also the relation to IPv6 flow labels. Implementations should consider the impact of Equal-Cost Multipath (ECMP) [RFC6438], specifically, whether a PMTU ought to be maintained for each transport endpoint or for each network address.
[RFC8201]のセクション5.2は、PMTU情報のキャッシュとIPv6フローラベルとの関係に関するガイダンスを提供します。実装は、等しいマルチパス（ECMP）[RFC6438]の影響を考慮する必要があります。特に、各トランスポートエンドポイントまたは各ネットワークアドレスについてPMTUを維持する必要があるかどうかを実装する必要があります。
Path characteristics can change, and the actual PMTU could increase or decrease over time, for instance, following a path change when packets are forwarded over a link with a different MTU than that previously used. To bound the delay in discovering an increase in the actual PMTU, a host with a link MTU larger than the current PMTU SHOULD periodically send the MinPMTU HBH Option with the R-bit set. DPLPMTUD provides recommendations concerning how this could be implemented (see Section 5.3 of [RFC8899]). Since the Option consumes less capacity than a full-sized probe packet, there can be an advantage in using this to detect a change in the path characteristics.
パスの特性が変化する可能性があり、実際のPMTUは、以前に使用されていたものとは異なるMTUとのリンク上にパケットが転送されると、パスの変化に続いて、時間の経過とともに時間とともに増加または減少する可能性があります。実際のPMTUの増加を発見する遅延を拘束するには、現在のPMTUよりも大きいリンクMTUを備えたホストが定期的にMinPMTU HBHオプションをRビットセットで送信する必要があります。DPLPMTUDは、これをどのように実装できるかに関する推奨事項を提供します（[RFC8899]のセクション5.3を参照）。オプションはフルサイズのプローブパケットよりも少ない容量を消費するため、パス特性の変化を検出するためにこれを使用することで利点があります。
There is evidence that some middleboxes drop packets that include Hop-by-Hop Options. For example, a firewall might drop a packet that carries an unknown extension header or Option. This practice is expected to decrease as an Option becomes more widely used. It could result in the generation of an ICMPv6 message that indicates the problem. This could be used to (temporarily) suspend use of this Option.
一部のミドルボックスは、ホップバイホップオプションを含むパケットをドロップするという証拠があります。たとえば、ファイアウォールは、未知の拡張機能ヘッダーまたはオプションを搭載したパケットをドロップする場合があります。このプラクティスは、オプションがより広く使用されるにつれて減少すると予想されます。問題を示すICMPV6メッセージの生成につながる可能性があります。これは、（一時的に）このオプションの使用を一時停止するために使用できます。
A middlebox that silently discards a packet with this Option results in the dropping of any packet using the Option. This dropping can be avoided by appropriate configuration in a controlled environment, such as within a data center, but it needs to be considered for Internet usage. Section 6.2 recommends that this Option is not used on packets where loss might adversely impact performance.
このオプションでパケットを静かに破棄するミドルボックスは、オプションを使用してパケットをドロップします。このドロップは、データセンター内などの制御された環境で適切な構成によって回避できますが、インターネットの使用を考慮する必要があります。セクション6.2では、このオプションは、損失がパフォーマンスに悪影響を与える可能性のあるパケットで使用されないことを推奨しています。
IANA has registered an IPv6 Hop-by-Hop Option type in the "Destination Options and Hop-by-Hop Options" registry within the "Internet Protocol Version 6 (IPv6) Parameters" registry group [IANA-HBH]. This assignment is shown in Section 5.
IANAは、「インターネットプロトコルバージョン6（IPv6）パラメーター」レジストリグループ[IANA-HBH]内の「宛先オプションとホップバイホップオプション」レジストリにIPv6ホップバイホップオプションタイプを登録しました。この割り当てはセクション5に示されています。
This section discusses the security considerations. It first reviews router Option processing. It then reviews host processing when receiving this Option at the network layer. It then considers two ways in which the Option Data can be processed, followed by two approaches for using the Option Data. Finally, it discusses middlebox implications related to use in the general Internet.
このセクションでは、セキュリティ上の考慮事項について説明します。最初にルーターオプション処理を確認します。次に、ネットワークレイヤーでこのオプションを受信するときにホスト処理を確認します。次に、オプションデータを処理できる2つの方法を検討し、その後、オプションデータを使用するための2つのアプローチが続きます。最後に、一般的なインターネットでの使用に関連するミドルボックスの影響について説明します。
This Option shares the characteristics of all other IPv6 Hop-by-Hop Options, in that, if not supported at line rate, it could be used to degrade the performance of a router. This Option, while simple, is no different than other uses of IPv6 Hop-by-Hop Options.
このオプションは、他のすべてのIPv6ホップバイホップオプションの特性を共有しています。これは、ラインレートでサポートされていない場合、ルーターのパフォーマンスを低下させるために使用できます。このオプションは、単純ですが、IPv6ホップバイホップオプションの他の使用と違いはありません。
It is common for routers to ignore the Hop-by-Hop Option header or to drop packets containing a Hop-by-Hop Option header. Routers implementing IPv6 according to [RFC8200] only examine and process the Hop-by-Hop Options header if explicitly configured to do so.
ルーターがホップバイホップオプションヘッダーを無視したり、ホップバイホップオプションヘッダーを含むパケットをドロップすることが一般的です。[RFC8200]に従ってIPv6を実装するルーターは、明示的に設定されている場合にのみ、ホップバイホップオプションヘッダーを調べて処理します。
A malicious attacker can forge a packet directed at a host that carries the MinPMTU HBH Option. By design, the fields of this IP Option can be modified by the network.
悪意のある攻撃者は、MinPMTU HBHオプションを運ぶホストに向けられたパケットを偽造できます。設計上、このIPオプションのフィールドはネットワークによって変更できます。
For comparison, the ICMPv6 PTB message used in Path MTU Discovery [RFC8201] and the source host have an inherent trust relationship with the destination host including this Option. This trust relationship can be used to help verify the Option. ICMPv6 PTB messages are sent from any router on the path to the destination host. The source host has no prior knowledge of these routers (except for the first hop router).
比較のために、Path MTU Discovery [RFC8201]で使用されるICMPV6 PTBメッセージとソースホストは、このオプションを含む宛先ホストとの固有の信頼関係を持っています。この信頼関係は、オプションの検証に役立つために使用できます。ICMPV6 PTBメッセージは、宛先ホストへのパス上のルーターから送信されます。ソースホストには、これらのルーターの事前知識がありません（最初のホップルーターを除く）。
Reception of this packet will require processing as the network stack parses the packet before the packet is delivered to the upper-layer protocol. This network-layer Option processing is normally completed before any upper-layer protocol delivery checks are performed.
このパケットの受信には、パケットが上層層プロトコルに配信される前にネットワークスタックがパケットを解析するため、処理が必要です。このネットワーク層オプション処理は、通常、上層層プロトコル配信チェックが実行される前に完了します。
The network layer does not normally have sufficient information to validate that the packet carrying an Option originated from the destination (or an on-path node). It also does not typically have sufficient context to demultiplex the packet to identify the related transport flow. This can mean that any changes resulting from reception of the Option applies to all flows between a pair of endpoints.
ネットワークレイヤーには、通常、オプションを運ぶパケットが宛先（またはパスオンノード）から発生することを検証するのに十分な情報がありません。また、通常、関連する輸送の流れを識別するためにパケットを反映するのに十分なコンテキストがありません。これは、オプションの受信から生じるすべての変更が、エンドポイントのペア間のすべてのフローに適用されることを意味します。
These considerations are no different than other uses of Hop-by-Hop Options, and this is the use case for PMTUD. The following section describes a mitigation for this attack.
これらの考慮事項は、ホップバイホップオプションの他の使用と違いはありません。これはPMTUDのユースケースです。次のセクションでは、この攻撃の緩和について説明します。
Transport protocols should be designed to provide protection from data injection attacks by off-path devices, and mechanisms should be described in the Security Considerations section for each transport specification (see Section 5.1 of "UDP Usage Guidelines" [RFC8085]). For example, a TCP or UDP application that maintains the related state and uses a randomized ephemeral port would provide basic protection. TLS [RFC8446] or IPsec [RFC4301] provide cryptographic authentication. An upper-layer protocol that validates each received packet discards any packet when this validation fails. In this case, the host MUST also discard the associated Option Data from the MinPMTU HBH Option without further processing (Section 6.3).
輸送プロトコルは、オフパスデバイスによるデータインジェクション攻撃からの保護を提供するように設計する必要があります。各輸送仕様のセキュリティに関する考慮事項セクションで説明する必要があります（「UDP使用ガイドライン」[RFC8085]のセクション5.1を参照）。たとえば、関連状態を維持し、ランダム化された一時的なポートを使用するTCPまたはUDPアプリケーションは、基本的な保護を提供します。TLS [RFC8446]またはIPSEC [RFC4301]は暗号化認証を提供します。受信した各パケットを検証する上層層プロトコルは、この検証が失敗したときにパケットを破棄します。この場合、ホストは、さらに処理することなく、MINPMTU HBHオプションから関連するオプションデータを破棄する必要があります（セクション6.3）。
A network node on the path has visibility of all packets it forwards. By observing the network packet payload, the node might be able to construct a packet that might be validated by the destination host. Such a node would also be able to drop or limit the flow in other ways that could be potentially more disruptive. Authenticating the packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates this attack. Note that the authentication style of the Authentication Header (AH) [RFC4302], while authenticating the payload and outer IPv6 header, does not check Hop-by-Hop Options that change on route.
パス上のネットワークノードには、すべてのパケットが転送されるように可視性があります。ネットワークパケットペイロードを観察することにより、ノードは宛先ホストによって検証される可能性のあるパケットを構築できる場合があります。このようなノードは、潜在的に破壊的になる可能性のある他の方法でフローをドロップまたは制限することもできます。たとえば、IPSEC [RFC4301]またはTLS [RFC8446]を使用してパケットを認証すると、この攻撃が軽減されます。認証ヘッダー（AH）[RFC4302]の認証スタイルは、ペイロードと外側のIPv6ヘッダーを認証しますが、ルートで変更されるホップバイホップオプションを確認しないことに注意してください。
The simplest way to utilize the Rtn-PMTU value is to directly use this to update the PMTU. This approach results in a set of security issues when the Option carries malicious data:
RTN-PMTU値を利用する最も簡単な方法は、これを直接使用してPMTUを更新することです。このアプローチは、オプションに悪意のあるデータが含まれている場合、一連のセキュリティ問題が発生します。
* A direct update of the PMTU using the Rtn-PMTU value could result in an attacker inflating or reducing the size of the host PMTU for the destination. Forcing a reduction in the PMTU can decrease the efficiency of network use, might increase the number of packets/ fragments required to send the same volume of payload data, and can prevent sending an unfragmented datagram larger than the PMTU. Increasing the PMTU can result in a path silently dropping packets (described as a black hole in [RFC8899]) when the source host sends packets larger than the actual PMTU. This persists until the PMTU is next updated.
* RTN-PMTU値を使用してPMTUを直接更新すると、攻撃者が宛先のホストPMTUのサイズを膨らませたり縮小したりする可能性があります。PMTUの減少を強制すると、ネットワーク使用の効率が低下し、同じ量のペイロードデータを送信するのに必要なパケット/フラグメントの数が増加し、PMTUよりも大きいフラグメントされていないデータグラムの送信を防ぐことができます。PMTUを増やすと、ソースホストが実際のPMTUよりも大きいパケットを送信すると、パスが静かにパケットをドロップする可能性があります（[RFC8899]のブラックホールと呼ばれる）。これは、PMTUが次に更新されるまで持続します。
* The method can be used to solicit a response from the destination host. A malicious attacker could forge a packet that causes the destination to add the Option to a packet sent to the source host. A forged value of Rtn-PMTU in the Option Data might also impact the remote endpoint, as described in the previous bullet. This persists until a valid MinPMTU HBH Option is received. This attack could be mitigated by limiting the sending of the MinPMTU HBH Option in reply to incoming packets that carry the Option.
* この方法は、宛先ホストからの応答を求めるために使用できます。悪意のある攻撃者は、宛先がソースホストに送信されたパケットにオプションを追加するパケットを偽造できます。オプションデータのRTN-PMTUの偽造値は、前の弾丸に記載されているように、リモートエンドポイントにも影響を与える可能性があります。これは、有効なMinPMTU HBHオプションが受信されるまで持続します。この攻撃は、オプションを運ぶ着信パケットへの返信にMinpMTU HBHオプションの送信を制限することにより、軽減できます。
Another way to utilize the Rtn-PMTU value is to indirectly trigger a probe to determine if the path supports a PMTU of size Rtn-PMTU. This approach needs context for the flow and hence assumes an upper-layer protocol that validates the packet that carries the Option (see Section 8.3). This is the case when used in combination with DPLPMTUD [RFC8899]. A set of security considerations result when an Option carries malicious data:
RTN-PMTU値を利用する別の方法は、パスがサイズRTN-PMTUのPMTUをサポートするかどうかを決定するためにプローブを間接的にトリガーすることです。このアプローチには、フローのコンテキストが必要であるため、オプションを運ぶパケットを検証する上層層プロトコルを想定しています（セクション8.3を参照）。これは、DPLPMTUD [RFC8899]と組み合わせて使用される場合です。オプションが悪意のあるデータを伝えると、一連のセキュリティに関する考慮事項が生じます。
* If the forged packet carries a validated Option with a non-zero Rtn-PMTU field, the upper-layer protocol could utilize the information in the Rtn-PMTU field. A Rtn-PMTU larger than the current PMTU can trigger a probe for a new size.
* Forgedパケットがゼロ以外のRTN-PMTUフィールドを使用して検証済みのオプションを搭載している場合、上層層プロトコルはRTN-PMTUフィールドで情報を利用できます。現在のPMTUよりも大きいRTN-PMTUは、新しいサイズのプローブをトリガーできます。
* If the forged packet carries a non-zero Min-PMTU field, the upper-layer protocol would change the cached information about the path from the source. The cached information at the destination host will be overwritten when the host receives another packet that includes a MinPMTU HBH Option corresponding to the flow.
* 鍛造パケットにゼロ以外のMIN-PMTUフィールドがある場合、上層層プロトコルはソースからのパスに関するキャッシュされた情報を変更します。宛先ホストのキャッシュされた情報は、ホストがフローに対応するMinPMTU HBHオプションを含む別のパケットを受信すると上書きされます。
* Processing of the Option could cause a destination host to add the MinPMTU HBH Option to a packet sent to the source host. This Option will carry a Rtn-PMTU value that could have been updated by the forged packet. The impact of the source host receiving this resembles that discussed previously.
* オプションを処理すると、宛先ホストがソースホストに送信されたパケットにminpmtu HBHオプションを追加する可能性があります。このオプションは、偽造パケットによって更新された可能性のあるRTN-PMTU値を搭載します。ソースホストがこれを受け取ることの影響は、前述のものに似ています。
There is evidence that some middleboxes drop packets that include Hop-by-Hop Options. For example, a firewall might drop a packet that carries an unknown extension header or Option. This practice is expected to decrease as the Option becomes more widely used. Methods to address this are discussed in Section 6.3.6.
一部のミドルボックスは、ホップバイホップオプションを含むパケットをドロップするという証拠があります。たとえば、ファイアウォールは、未知の拡張機能ヘッダーまたはオプションを搭載したパケットをドロップする場合があります。このプラクティスは、オプションがより広く使用されるにつれて減少すると予想されます。これに対処する方法については、セクション6.3.6で説明します。
When a forged packet causes a packet that includes the MinPMTU HBH Option to be sent and the return path does not forward packets with this Option, the packet will be dropped (see Section 6.3.6). This attack is mitigated by validating the Option Data before use and by limiting the rate of responses generated. An upper layer could further mitigate the impact by responding to an R-Flag by including the Option in a packet that does not carry application data.
鍛造パケットがMinPMTU HBHオプションを含むパケットを送信し、リターンパスがこのオプションでパケットを転送しない場合、パケットはドロップされます（セクション6.3.6を参照）。この攻撃は、使用前にオプションデータを検証し、生成された応答率を制限することにより緩和されます。上層層は、アプリケーションデータを運ばないパケットにオプションを含めることにより、R-Flagに応答することにより、さらに影響を軽減できます。
This section describes the experimental goals of this specification.
このセクションでは、この仕様の実験目標について説明します。
A successful deployment of the method depends upon several components being implemented and deployed:
メソッドの展開が成功すると、実装および展開される複数のコンポーネントに依存します。
* Support in the sending node (see Section 6.2). This also requires corresponding support in upper-layer protocols (see Section 6.3).
* 送信ノードでのサポート（セクション6.2を参照）。これには、上層層プロトコルでの対応するサポートも必要です（セクション6.3を参照）。
* Router support in nodes (see Section 6.1). The IETF continues to provide recommendations on the use of IPv6 Hop-by-Hop Options, for example, see Section 2.2.2 of [RFC9099]. This document does not update the way router implementations configure support for Hop-by-Hop Options.
* ノードでのルーターサポート（セクション6.1を参照）。IETFは、たとえば、[RFC9099]のセクション2.2.2を参照してください。このドキュメントでは、ルーターの実装がホップバイホップオプションのサポートを構成する方法を更新しません。
* Support in the receiving node (see Section 6.3.3).
* 受信ノードでのサポート（セクション6.3.3を参照）。
Experience from deployment is an expected input to any decision to progress this specification from Experimental to IETF Standards Track. Appropriate inputs might include:
展開からのエクスペリエンスは、実験的な標準からIETF標準へのこの仕様を進めるという決定への予想される入力です。適切な入力には以下が含まれます。
* reports of implementation experience,
* 実装経験のレポート、
* measurements of the number paths where the method can be used, or
* 方法を使用できる数値パスの測定、または
* measurements showing the benefit realized or the implications of using specific methods over specific paths.
* 実現された利点または特定のパスで特定の方法を使用することの意味を示す測定。
At the time this document was published, there are two known implementations of the Path MTU Hop-by-Hop Option. These are:
このドキュメントが公開された時点で、PATH MTU Hop-by-Hopオプションの2つの既知の実装があります。これらは：
* Wireshark dissector. This is shipping in production in Wireshark version 3.2 [WIRESHARK].
* Wireshark分離器。これは、Wiresharkバージョン3.2 [Wireshark]の生産の配送です。
* A prototype in the open source version of the FD.io Vector Packet Processing (VPP) technology [VPP]. At the time this document was published, the source code can be found [VPP_SRC].
* FD.IOベクターパケット処理（VPP）テクノロジー[VPP]のオープンソースバージョンのプロトタイプ。このドキュメントが公開されたときに、ソースコードが見つかります[vpp_src]。
[IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options", <https://www.iana.org/assignments/ipv6-parameters/>.
[iana-hbh] iana、「宛先オプションとホップバイホップオプション」、<https://www.iana.org/assignments/ipv6-parameters/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Deering、S.、Mogul、J.、およびR. Hinden、ed。、「IPバージョン6のPath MTU Discovery」、STD 87、RFC 8201、DOI 10.17487/RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, July 1988, <https://www.rfc-editor.org/info/rfc1063>.
[RFC1063] Mogul、J.、Kent、C.、Partridge、C.、およびK. McCloghrie、「IP MTUディスカバリーオプション」、RFC 1063、DOI 10.17487/RFC1063、1988年7月、<https：//www.rfc-editor.org/info/rfc1063>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、DOI 10.17487/RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[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>。
[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>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、ed。、 "インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、STD 89、RFC 4443、DOI 10.17487/RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487/RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、DOI 10.17487/RFC4861、2007年9月、<https：/<https：//www.rfc-editor.org/info/rfc4861>。
[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：//ww.rfc-editor.org/info/rfc6438>。
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P.、ed。Y. Wang、ed。、「nvgre：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487/RFC7637、2015年9月、<https://www.rfc-editor.org/info/rfc7637>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G.、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8899] Fairhurst、G.、Jones、T.、Tüxen、M.、Rüngeler、I。、およびT.Völker、「Datagram Transports for Datagram TransportsのPacketization Lay Path Mtu Discovery」、DOI 10.17487/RFC8899、2020年9月、2020年9月、<https://www.rfc-editor.org/info/rfc8899>。
[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>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, <https://www.rfc-editor.org/info/rfc9099>.
[RFC9099] Vyncke、é。、Chittimaneni、K.、Kaeo、M。、およびE. Rey、「IPv6ネットワークの運用セキュリティ上の考慮事項」、RFC 9099、DOI 10.17487/RFC9099、2021年8月、<HTTPS：// WWW。rfc-editor.org/info/rfc9099>。
[TAPS-ARCH] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A., Fairhurst, G., and C. Perkins, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-12, June 2022, <https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps-arch.xml>.
[Taps-arch] Pauly、T.、Ed。、Trammell、B.、ed。、Brunstrom、A.、Fairhurst、G。、およびC. Perkins、「輸送サービスのアーキテクチャ」、進行中の作業、インターネット - ドラフト、ドラフト-ITP-TAPS-ARCH-12、2022年6月、<https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps-arch.xml>。
[VPP] FD.io, "VPP/What is VPP?", <https://wiki.fd.io/view/VPP/What_is_VPP%3F>.
[vpp] fd.io、 "vpp/why vpp？"、<https://wiki.fd.io/view/vpp/what_is_vpp%3f>。
[VPP_SRC] "vpp", commit 21948, ip: HBH MTU recording for IPv6, <https://gerrit.fd.io/r/c/vpp/+/21948>.
[vpp_src] "vpp"、commit 21948、ip：hbh mtu録音のIPv6、<https://gerrit.fd.io/r/c/vpp//21948>。
[WIRESHARK] "Wireshark Network Protocol Analyzer", <https://www.wireshark.org>.
[Wireshark] "Wireshark Network Protocol Analyzer"、<https://www.wireshark.org>。
This section provides examples that illustrate a use of the MinPMTU HBH Option by a source using DPLPMTUD to discover the PLPMTU supported by a path. They consider a path where the on-path router has been configured with an outgoing MTU of d'. The source starts by transmission of packets of size a and then uses DPLPMTUD to seek to increase the size in steps resulting in sizes of b, c, d, e, etc. (chosen by the search algorithm used by DPLPMTUD). The search algorithm terminates with a PLPMTU that is at least d and is less than or equal to d'.
このセクションでは、DPLPMTUDを使用してソースによるMinPMTU HBHオプションの使用を示す例を示して、パスでサポートされているPLPMTUを発見します。彼らは、d 'の発信MTUで設定されたパスルーターが構成されているパスを考慮します。ソースは、サイズAのパケットの送信から始まり、DPLPMTUDを使用して、b、c、d、eなどのサイズをもたらすステップのサイズを増やすことを求めます（dplpmtudで使用される検索アルゴリズムによって選択されます）。検索アルゴリズムは、少なくともdであり、d 'よりも低いPLPMTUで終了します。
The first example considers DPLPMTUD without using the MinPMTU HBH Option. In this case, DPLPMTUD searches using a probe packet that increases in size. Probe packets of size e are sent, which are larger than the actual PMTU. In this example, PTB messages are not received from the routers, and repeated unsuccessful probes result in the search phase completing. Packets of data are never sent with a size larger than the size of the last confirmed probe packet. Acknowledgments (ACKs) of data packets are not shown.
最初の例では、MinPMTU HBHオプションを使用せずにDPLPMTUDを検討します。この場合、サイズが増加するプローブパケットを使用してDPLPMTUDを検索します。サイズEのプローブパケットは送信され、実際のPMTUよりも大きいです。この例では、PTBメッセージはルーターから受信されず、繰り返し失敗したプローブの結果、検索フェーズが完了します。データのパケットは、最後に確認されたプローブパケットのサイズよりも大きいサイズで送信されることはありません。データパケットの謝辞（ACK）は表示されません。
----Packets of data size a ------------------------------>
----Probe size b ---------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size b ------------------------------>
----Probe size c ---------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size c ------------------------------>
----Probe size d ---------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size d ------------------------------>
<---------------------------------- ACK of probe --------
...
----Probe size e --------------X
X----ICMPv6 PTB d' ----|
----Packets of data size d ------------------------------>
----Probe size e --------------X (again)
X----ICMPv6 PTB d' ----|
----Packets of data size d ------------------------------>
...
etc. until MaxProbes are unsuccessful and search phase completes.
----Packets of data size d ------------------------------>
Figure 3
図3
The second example considers DPLPMTUD with the MinPMTU HBH Option set on a connectivity probe packet.
2番目の例では、接続プローブパケットに設定されたMinPMTU HBHオプションを使用してDPLPMTUDを考慮します。
The IPv6 Option is sent end to end, and the Min-PMTU is updated by a router on the path to d', which is returned in a response that also sets the MinPMTU HBH Option. Upon receiving the Rtn-PMTU value, DPLPMTUD immediately sends a probe packet of the target size d'. If the probe packet is confirmed for the path, the PLPMTU is updated, allowing the source to use data packets up to size d'. (The search algorithm is allowed to continue to probe to see if the path supports a larger size.) Packets of data are never sent with a size larger than the last confirmed probe size d'.
IPv6オプションは端から端まで送信され、MIN-PMTUはd 'へのパス上のルーターによって更新されます。これは、MinPMTU HBHオプションも設定する応答で返されます。RTN-PMTU値を受信すると、DPLPMTUDはすぐにターゲットサイズd 'のプローブパケットを送信します。パスのプローブパケットが確認されている場合、PLPMTUが更新され、ソースがサイズd 'までデータパケットを使用できます。（検索アルゴリズムは、パスがより大きなサイズをサポートするかどうかを確認するためにプローブを続けることができます。）データのパケットは、最後に確認されたプローブサイズd 'よりも大きいサイズで送信されることはありません。
----Packets of data size a ------------------------------>
----Connectivity probe with MinPMTU-
+--updated to minPMTU=d'----->
<-----------------ACK with Rtn-PMTU=d'--------------------
----Packets of data size a ------------------------------>
----Probe size d' --------------------------------------->
<---------------------------------- ACK of probe ---------
-----Packets of data size d' ---------------------------->
Search phase completes.
-----Packets of data size d' ---------------------------->
Figure 4
図4
The final example considers DPLPMTUD with the MinPMTU HBH Option set on a connectivity probe packet but shows the effect when this connectivity probe packet is dropped.
最後の例では、MinPMTU HBHオプションを使用したDPLPMTUDを接続プローブパケットに設定しますが、この接続プローブパケットがドロップされたときの効果を示します。
In this case, the packet with the MinPMTU HBH Option is not received. DPLPMTUD searches using probe packets of increasing size, increasing the PLPMTU when the probes are confirmed. An ICMPv6 PTB message is received when the probed size exceeds the actual PMTU, indicating a PTB_SIZE of d'. DPLPMTUD immediately sends a probe packet of the target size d'. If the probe packet is confirmed for the path, the PLPMTU is updated, allowing the source to use data packets up to size d'. If the ICMPv6 PTB message is not received, the DPLPMTU will be the last confirmed probe size, which is d.
この場合、MinPMTU HBHオプションを備えたパケットは受信されません。サイズの増加のプローブパケットを使用したDPLPMTUD検索で、プローブが確認されたときにPLPMTUが増加します。プローブされたサイズが実際のPMTUを超えたときにICMPV6 PTBメッセージが受信され、D 'のPTB_SIZEを示します。DPLPMTUDは、ターゲットサイズd 'のプローブパケットをすぐに送信します。パスのプローブパケットが確認されている場合、PLPMTUが更新され、ソースがサイズd 'までデータパケットを使用できます。ICMPV6 PTBメッセージが受信されない場合、DPLPMTUは最後に確認されたプローブサイズ、つまりdです。
----Packets of data size a ------------------------------->
----Connectivity probe with MinPMTU --------X
----Packets of data size a ------------------------------->
----Probe size b ----------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size b ------------------------------->
----Probe size c ----------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size c ------------------------------->
----Probe size d ----------------------------------------->
<---------------------------------- ACK of probe --------
----Packets of data size d ------------------------------->
----Probe size e ------------X
<--ICMPv6 PTB PTB_SIZE d' --|
----Packets of data size d ------------------------------->
----Probe size d' using target set by PTB_SIZE ----------->
<---------------------------------- ACK of probe --------
Search phase completes.
----Packets of data size d' ------------------------------>
Figure 5
図5
The number of probe rounds depends on the number of steps needed by the search algorithm and is typically larger for a larger PMTU.
プローブラウンドの数は、検索アルゴリズムで必要な手順の数に依存し、通常、より大きなPMTUの場合は大きくなります。
Acknowledgments
謝辞
Helpful comments were received from Tom Herbert, Tom Jones, Fred Templin, Ole Troan, Tianran Zhou, Jen Linkova, Brian Carpenter, Peng Shuping, Mark Smith, Fernando Gont, Michael Dougherty, Erik Kline, and other members of the 6MAN Working Group.
トム・ハーバート、トム・ジョーンズ、フレッド・テンプリン、オレ・トロアン、ティアンラン・周、ジェン・リンコバ、ブライアン・カーペンター、ペン・シュピング、マーク・スミス、フェルナンド・ゴント、マイケル・ドーガーティ、および6manワーキンググループの他のメンバーから有益なコメントが受けられました。
Authors' Addresses
著者のアドレス
Robert M. Hinden Check Point Software 959 Skyway Road San Carlos, CA 94070 United States of America Email: bob.hinden@gmail.com
ロバートM.ヒンデンチェックポイントソフトウェア959スカイウェイロードサンカルロス、カリフォルニア94070アメリカ合衆国電子メール：bob.hinden@gmail.com
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom Email: gorry@erg.abdn.ac.uk
ゴッドレッドフェアハースト大学アバディーン大学エンジニアリングスクールフレイザーノーブルビルアバディーンAB24 3UE英国メールメール：gorry@erg.abdn.ac.uk