Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 9869 T. Jones
Category: Standards Track University of Aberdeen
ISSN: 2070-1721 October 2025
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required.
この文書では、UDP オプションの送信者が、Path MTU Discovery (PMTUD) の堅牢な方法として Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) を実装する方法を指定します。この方法では、UDP オプションのパケット化層を使用します。これにより、アプリケーションはネットワーク パス経由で送信できる最大サイズのデータグラムを検出できるようになります。また、アプリケーションがパスでサポートされている現在の最大パケット サイズ (MPS) を定期的に確認し、必要に応じてこれを更新できるようにする方法も提供します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9869.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9869 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. DPLPMTUD for UDP Options
3.1. Packet Formats
3.2. Sending Probe Packets with the Request Option
3.3. Receiving UDP Options Probe Packets and Sending the RES
Option
4. DPLPMTUD Sender Procedures for UDP Options
4.1. Confirmation of Connectivity Across a Path
4.2. Sending Probe Packets to Increase the PLPMTU
4.3. Validating the Path with UDP Options
4.4. Probe Packets That Do Not Include Application Data
4.5. Probe Packets That Include Application Data
5. Receiving Events from the Network
5.1. Changes in the Path
5.2. Validation of PTB Messages
6. Examples with Different Receiver Behaviors
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that applications implement some form of Path MTU Discovery (PMTUD) to avoid the generation of IP fragments:
ユーザー データグラム プロトコル (UDP) [RFC0768] は、IP 上で最小限のトランスポート サービスを提供し、他のプロトコルの基盤として頻繁に使用されます。UDP ガイドライン [RFC8085] のセクション 3.2 では、IP フラグメントの生成を回避するために、アプリケーションが何らかの形式の Path MTU Discovery (PMTUD) を実装することを推奨しています。
Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.
したがって、アプリケーションは、IP 層によって提供されるパス MTU 情報を使用するか、Path MTU Discovery (PMTUD) 自体 [RFC1191] [RFC1981] [RFC4821] を実装して、宛先へのパスが断片化せずに希望のメッセージ サイズをサポートするかどうかを決定する必要があります (SHOULD)。
The UDP API [RFC8304] offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but it does not offer any automated mechanisms for an application to discover the MPS supported by a path. Upper Layer protocols, which include applications, can implement mechanisms for PMTUD above the UDP API.
UDP API [RFC8304] は、アプリケーションが ICMP Packet Too Big (PTB) メッセージを受信し、送信されるデータグラムの最大サイズを制御するための呼び出しを提供しますが、アプリケーションがパスでサポートされている MPS を検出するための自動メカニズムは提供しません。アプリケーションを含む上位層プロトコルは、UDP API の上に PMTUD のメカニズムを実装できます。
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes a method for a bidirectional Packetization Layer (PL) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. DPLPMTUD [RFC8899] specifies this support for datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism that does not solely rely on ICMP PTB messages and works on paths that drop ICMP PTB messages.
パケット化層パス MTU 検出 (PLPMTUD) [RFC4821] は、双方向パケット化層 (PL) がパス上でサポートされる最大のパケット化層 PMTU (PLPMTU) を検索する方法を説明しています。DPLPMTUD [RFC8899] は、データグラムトランスポートに対するこのサポートを指定しています。PLPMTUD および DPLPMTUD は、ICMP PTB メッセージのみに依存せず、ICMP PTB メッセージをドロップするパス上で動作するプローブ メカニズムを使用することで堅牢性を実現します。
UDP Options [RFC9868] supplies functionality that can be used to implement DPLPMTUD within the transport service or in an Upper Layer protocol (including an application) that uses UDP Options. This document specifies how DPLPMTUD using UDP Options is implemented (Section 6.1 of [RFC8899]) and requires support to be enabled at both the sender and receiver.
UDP オプション [RFC9868] は、トランスポート サービス内、または UDP オプションを使用する上位層プロトコル (アプリケーションを含む) 内で DPLPMTUD を実装するために使用できる機能を提供します。この文書は、UDP オプションを使用した DPLPMTUD がどのように実装されるかを指定し ([RFC8899] のセクション 6.1)、送信者と受信者の両方でサポートを有効にする必要があります。
Implementing DPLPMTUD within the transport service above UDP Options avoids the need for each Upper Layer protocol to implement the DPLPMTUD method. It provides a standard method for applications to discover the current MPS for a path and to detect when this changes. It can be used with Equal-Cost Multipath (ECMP) routing and/or multihoming. If multipath or multihoming is supported, a state machine is needed for each path.
UDP オプション上のトランスポート サービス内に DPLPMTUD を実装すると、各上位層プロトコルで DPLPMTUD メソッドを実装する必要がなくなります。これは、アプリケーションがパスの現在の MPS を検出し、これがいつ変更されたかを検出するための標準的な方法を提供します。Equal-Cost Multipath (ECMP) ルーティングやマルチホーミングと併用できます。マルチパスまたはマルチホーミングがサポートされている場合は、パスごとにステート マシンが必要です。
DPLPMTUD is not specified for multicast. The method requires explicit acknowledgement of probe packets provided by UDP Options, which is primarily intended for unicast use (see Section 23 of [RFC9868]).
DPLPMTUD はマルチキャストに指定されていません。この方法は、主にユニキャストでの使用を目的とした UDP オプションによって提供されるプローブ パケットの明示的な確認応答を必要とします ([RFC9868] のセクション 23 を参照)。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the terms defined for DPLPMTUD (Sections 2 and 5 of [RFC8899]).
この文書では、DPLPMTUD ([RFC8899] のセクション 2 および 5) に対して定義された用語を使用します。
A UDP Options sender implementing DPLPMTUD uses the method specified in [RFC8899]. In this specification, DPLPMTUD is realized using a pair of UDP Options: the Request (REQ) Option and the Response (RES) Option (Section 11.7 of [RFC9868]). The method also uses the End of Options List (EOL) Option (Section 11.1 of [RFC9868]) to introduce padding to set the size of a probe packet.
DPLPMTUD を実装する UDP オプション送信側は、[RFC8899] で指定されたメソッドを使用します。この仕様では、DPLPMTUD は、一対の UDP オプション、つまり要求 (REQ) オプションと応答 (RES) オプションを使用して実現されます ([RFC9868] のセクション 11.7)。このメソッドはまた、オプション リストの終わり (EOL) オプション ([RFC9868] のセクション 11.1) を使用して、プローブ パケットのサイズを設定するためのパディングを導入します。
Use of DPLPMTUD MUST be explicitly enabled by the application, for instance, once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol. Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option until DPLPMTUD has been enabled. This is to help protect from misuse of the mechanism for other forms of probing.
たとえば、アプリケーションが接続を確立し、リモートの上位層プロトコルとデータを交換する準備ができたら、DPLPMTUD の使用をアプリケーションによって明示的に有効にする必要があります。同様に、DPLPMTUD 受信者は、DPLPMTUD が有効になるまで、UDP REQ オプションに応答してはなりません (MUST NOT)。これは、他の形式のプローブのメカニズムの悪用を防ぐために役立ちます。
Probe packets consume network capacity and incur endpoint processing (Section 4.1 of [RFC8899]). Implementations ought to send a probe packet with a UDP REQ Option only when required by their local DPLPMTUD state machine, i.e., when confirming the base PMTU for the path, probing to increase the PLPMTU, or confirming the current PLPMTU.
プローブ パケットはネットワーク容量を消費し、エンドポイント処理が発生します ([RFC8899] のセクション 4.1)。実装では、ローカルの DPLPMTUD ステート マシンで必要な場合、つまり、パスのベース PMTU を確認する場合、PLPMTU を増やすためにプローブする場合、または現在の PLPMTU を確認する場合にのみ、UDP REQ オプションを含むプローブ パケットを送信する必要があります。
DPLPMTUD can be implemented over UDP Options in two ways:
DPLPMTUD は、次の 2 つの方法で UDP オプション上に実装できます。
* Implementation within the UDP transport service.
* UDP トランスポート サービス内での実装。
* Implementation in an Upper Layer protocol (or application) that uses UDP Options.
* UDP オプションを使用する上位層プロトコル (またはアプリケーション) での実装。
When DPLPMTUD is implemented within the UDP transport service, the DPLPMTUD state machine is responsible for sending probe packets to determine a PLPMTU, as described in this document. This determines an MPS, the largest size of application data block that can be sent across a network path using a single datagram. The Upper Layer protocol is responsible for deciding when a session enables DPLPMTUD.
DPLPMTUD が UDP トランスポート サービス内に実装されている場合、DPLPMTUD ステート マシンは、このドキュメントで説明されているように、プローブ パケットを送信して PLPMTU を決定する役割を果たします。これにより、単一のデータグラムを使用してネットワーク パスを介して送信できるアプリケーション データ ブロックの最大サイズである MPS が決まります。上位層プロトコルは、セッションで DPLPMTUD をいつ有効にするかを決定します。
The discovered PLPMTU can be used to either:
検出された PLPMTU は次のいずれかに使用できます。
* set the maximum datagram size for the current path or
* 現在のパスの最大データグラム サイズを設定するか、
* set the maximum fragment size when a sender uses the UDP Fragmentation Option to divide a datagram into multiple UDP fragments for transmission. The size of each UDP fragment is then less than or equal to the size of the discovered largest IP packet that can be received across the current path.
* 送信者が UDP フラグメンテーション オプションを使用してデータグラムを複数の UDP フラグメントに分割して送信する場合の最大フラグメント サイズを設定します。各 UDP フラグメントのサイズは、現在のパスを介して受信できる、検出された最大の IP パケットのサイズ以下になります。
The figure below shows an implementation of DPLPMTUD within the UDP transport service. It illustrates key interactions between the layers. This design requires an API primitive to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port. By default, this API MUST disable DPLPMTUD processing.
次の図は、UDP トランスポート サービス内での DPLPMTUD の実装を示しています。これは、レイヤー間の重要な相互作用を示しています。この設計には、アプリケーションが特定の UDP ポートに対して DPLPMTUD ステート マシンを有効にするかどうかを制御できるようにする API プリミティブが必要です。デフォルトでは、この API は DPLPMTUD 処理を無効にしなければなりません。
+--------------------------------+
| Upper Layer Protocol |
| or Application |
+---------------------------+----+
^ | Messages (with UDP Options)
| receive send v Primitives for MPS, Min_PMTU, etc.
+---+----------------------------+
| DPLPMTUD State Machine |
| Maximum Packet Size (MPS) |
| PLPMTU, Probed-Size, Min_PMTU|
| Token Values & Probes, etc. |
+---------------------------+----+
^ | Messages (with UDP Options)
| | Send/Receive: Probes with Options
| receive send v Events: ICMP, Interface MTU, etc.
+---+----------------------------+
| UDP Options Transport |
+---------------------------+----+
^ | Datagrams (with UDP Options)
| | Fragmented Datagrams with UDP Options
| receive send v Events: ICMP, Interface MTU, etc.
Note: UDP allows an Upper Layer protocol to send datagrams with or without payload data (with or without UDP Options). These are delivered across the network to the remote Upper Layer. When DPLPMTUD is implemented within the UDP transport service, probe packets that include a REQ or RES UDP Option can be sent with no UDP payload. In this case, these probe packets were not generated by a sending application; therefore, the corresponding received datagrams are not delivered to the remote application.
注: UDP を使用すると、上位層プロトコルでペイロード データの有無にかかわらず (UDP オプションの有無にかかわらず) データグラムを送信できます。これらは、ネットワークを介してリモートの上位層に配信されます。DPLPMTUD が UDP トランスポート サービス内に実装されている場合、REQ または RES UDP オプションを含むプローブ パケットは、UDP ペイロードなしで送信できます。この場合、これらのプローブ パケットは送信アプリケーションによって生成されたものではありません。したがって、対応する受信データグラムはリモート アプリケーションに配信されません。
When DPLPMTUD is instead implemented by an Upper Layer protocol, the format and content of probe packets are determined by the Upper Layer protocol. This design is also permitted to use the REQ and RES Options provided by UDP Options.
代わりに DPLPMTUD が上位層プロトコルによって実装される場合、プローブ パケットの形式と内容は上位層プロトコルによって決定されます。このデザインでは、UDP オプションによって提供される REQ および RES オプションの使用も許可されます。
If DPLPMTUD is active at more than one layer, then the values of the tokens used in REQ Options need to be coordinated with any values used for other DPLPMTUD probe packets to ensure that each probe packet can be identified by a unique token. When configurable, a configuration ought to avoid performing such discovery both within UDP Options and also by an Upper Layer protocol that sends and receives probe packets via UDP Options. Section 6.1 of [RFC8899] recommends that: "An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability."
DPLPMTUD が複数のレイヤーでアクティブである場合、REQ オプションで使用されるトークンの値は、他の DPLPMTUD プローブ パケットに使用される値と調整して、各プローブ パケットが一意のトークンで識別できるようにする必要があります。構成可能な場合、構成では、UDP オプション内で、また UDP オプションを介してプローブ パケットを送受信する上位層プロトコルによっても、そのような検出を実行することを回避する必要があります。[RFC8899] のセクション 6.1 では、「基盤となるトランスポート システムがこの機能を提供する場合、アプリケーションは DPLPMTUD の使用を避けるべきです (SHOULD)」と推奨しています。
The UDP Options used in this document are described in [RFC9868] and are used in the following ways:
この文書で使用される UDP オプションは [RFC9868] で説明されており、次の方法で使用されます。
* The REQ Option is set by a sending PL to solicit a response from a remote receiver. A four-byte (four-octet) token identifies each request.
* REQ オプションは、リモート受信者からの応答を要求するために送信側 PL によって設定されます。4 バイト (4 オクテット) のトークンが各リクエストを識別します。
* A sending PL can use the EOL Option together with a minimum datagram length to pad probe packets.
* 送信側 PL は、EOL オプションを最小データグラム長とともに使用して、プローブ パケットをパディングできます。
* The RES Option is sent by a UDP Options receiver in response to a previously received REQ Option. Each RES Option echoes the last received four-byte token.
* RES オプションは、以前に受信した REQ オプションに応答して UDP オプション受信機によって送信されます。各 RES オプションは、最後に受信した 4 バイトのトークンをエコーします。
* If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second). This rate limit is to mitigate the DoS vector without significantly impacting the operation of DPLPMTUD. An example in Section 6 describes a case where this might be used.
* UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、応答側はこれらの応答のレートを制限しなければなりません (たとえば、ポートの各ペアが測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するように制限する)。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。セクション 6 の例では、これが使用されるケースについて説明します。
* Reception of a RES Option by the REQ sender confirms that a specific probe packet has been received by the remote UDP Options receiver.
* REQ 送信者による RES オプションの受信により、特定のプローブ パケットがリモート UDP オプション受信者によって受信されたことが確認されます。
The token allows a UDP Options sender to distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger RTT). Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL) [RFC8085]. The UDP Options sender MUST NOT reuse a token value within the MSL. A four-byte value for the token field provides sufficient space for multiple unique probe packets to be made within the MSL. Since UDP Options operates over UDP, the token values only need to be unique for the specific 5-tuple over which it is operating.
このトークンにより、UDP オプションの送信者は、最初のプローブ パケットに対する確認応答と、後続のプローブ パケットの受信を確認する確認応答 (たとえば、より大きな RTT で代替パスに沿って移動する) を区別できるようになります。各プローブ パケットは、最大セグメント ライフタイム (MSL) [RFC8085] 内で UDP オプション送信者によって一意に識別可能でなければなりません (MUST)。UDP オプションの送信者は、MSL 内のトークン値を再利用してはなりません (MUST NOT)。トークン フィールドの 4 バイト値は、MSL 内で作成される複数の一意のプローブ パケットに十分なスペースを提供します。UDP オプションは UDP 上で動作するため、トークン値は、動作している特定の 5 タプルに対して一意である必要があるだけです。
The value of the four-byte token field SHOULD be initialized to a randomized value to enhance protection from off-path attacks, as described in Section 5.1 of [RFC8085].
[RFC8085]のセクション5.1で説明されているように、オフパス攻撃からの保護を強化するために、4バイトのトークンフィールドの値はランダム化された値に初期化されるべきです(SHOULD)。
DPLPMTUD relies upon sending a probe packet with a specific size. Each probe packet includes the UDP Options area containing a REQ Option and any other required options concluded with an EOL Option (Section 11.1 of [RFC9868]), followed by any padding needed to inflate to the required probe size.
DPLPMTUD は、特定のサイズのプローブ パケットの送信に依存します。各プローブ パケットには、REQ オプションと、EOL オプション ([RFC9868] のセクション 11.1) で終了するその他の必要なオプションを含む UDP オプション領域が含まれており、その後に必要なプローブ サイズに拡張するために必要なパディングが続きます。
A probe packet can therefore be up to the maximum size supported by the local interface (i.e., the Interface MTU). Item 2 in Section 3 of [RFC8899] requires the network interface below DPLPMTUD to provide a way to transmit a probe packet that is larger than the current PLPMTU. The size of this probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD [RFC1191][RFC8201] or the PMTU size held in the IP-layer cache), as noted in item 2 in Section 3 of [RFC8899]).
したがって、プローブ パケットは、ローカル インターフェイスでサポートされる最大サイズ (つまり、インターフェイス MTU) にすることができます。[RFC8899] のセクション 3 の項目 2 では、現在の PLPMTU より大きいプローブ パケットを送信する方法を提供するために、DPLPMTUD の下のネットワーク インターフェイスが必要です。このプローブパケットのサイズは、ネットワーク層メカニズムによって設定された最大 PMTU ([RFC8899] のセクション 3 の項目 2 に記載されているように、PMTUD [RFC1191][RFC8201] によって発見されたものや IP 層キャッシュに保持されている PMTU サイズなど) によって制限されてはなりません (MUST NOT)。
UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP or IP layer. Therefore, Section 3 of [RFC8899] requires: "In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation."
この文書で説明されているように、DPLPMTUD プローブ パケットとして使用される UDP データグラムは、UDP 層または IP 層で断片化してはなりません (MUST NOT)。したがって、[RFC8899] のセクション 3 では、「IPv4 では、プローブ パケットは、IP ヘッダーに Don't Fragment (DF) ビットを設定して、ネットワーク層のエンドポイント フラグメンテーションを行わずに送信しなければなりません (MUST)」と規定しています。
When DPLPMTUD is enabled, a UDP Options receiver responds by sending a UDP datagram with the RES Option when it receives a UDP Options datagram with the REQ Option.
DPLPMTUD が有効な場合、UDP オプション受信側は、REQ オプション付きの UDP オプション データグラムを受信すると、RES オプション付きの UDP データグラムを送信して応答します。
The operation of DPLPMTUD can depend on the support at the remote UDP Options endpoint, the way in which DPLPMTUD is implemented, and in some cases, the application data that is exchanged over the UDP transport service. When UDP Options is not supported by the remote receiver, DPLPMTUD will be unable to confirm the path or to discover the PLPMTU. This will result in the minimum configured PLPMTU (MIN_PLPMTU). More explanation of usage is provided in Section 6.
DPLPMTUD の動作は、リモート UDP オプション エンドポイントでのサポート、DPLPMTUD の実装方法、および場合によっては UDP トランスポート サービス経由で交換されるアプリケーション データに依存します。UDP オプションがリモート受信側でサポートされていない場合、DPLPMTUD はパスを確認したり、PLPMTU を検出したりできません。これにより、最小構成 PLPMTU (MIN_PLPMTU) が得られます。使用法の詳細についてはセクション 6 で説明します。
Note: A receiver that only responds when there is a datagram queued for transmission by the Upper Layer could potentially receive multiple datagrams with a REQ Option before it can respond. When sent, the RES Option will only acknowledge the latest received token value. A sender would then conclude that any earlier REQ Options were not successfully received. However, DPLPMTUD does not usually result in sending more than one probe packet per timeout interval, and a delay in responding will already have been treated as a failed probe attempt. Therefore, this does not significantly impact performance, although a more prompt response would have resulted in DPLPMTUD recording reception of all probe packets.
注: 上位層による送信のためにキューに入れられたデータグラムがある場合にのみ応答する受信機は、応答する前に REQ オプションを使用して複数のデータグラムを受信する可能性があります。送信時に、RES オプションは最後に受信したトークン値のみを確認します。その後、送信者は、以前の REQ オプションは正常に受信されなかったと結論付けます。ただし、DPLPMTUD では通常、タイムアウト間隔ごとに複数のプローブ パケットが送信されることはなく、応答の遅延はすでにプローブ試行の失敗として扱われています。したがって、これはパフォーマンスに大きな影響を与えませんが、より迅速な応答により、DPLPMTUD はすべてのプローブ パケットの受信を記録することになります。
DPLPMTUD utilizes three types of probe. These are described in the following sections:
DPLPMTUD は 3 種類のプローブを利用します。これらについては、次のセクションで説明します。
* Probes to confirm the path can support the BASE_PLPMTU (Section 5.1.4 of [RFC8899]).
* パスが BASE_PLPMTU をサポートできることを確認するためのプローブ ([RFC8899] のセクション 5.1.4)。
* Probes to detect whether the path can support a larger PLPMTU.
* パスがより大きな PLPMTU をサポートできるかどうかを検出するためのプローブ。
* Probes to validate that the path supports the current PLPMTU.
* パスが現在の PLPMTU をサポートしていることを検証するためのプローブ。
The DPLPMTUD method requires a PL to confirm connectivity over the path (Section 5.1.4 of [RFC8899]), but UDP itself does not offer a mechanism for this.
DPLPMTUD メソッドでは、PL がパス上の接続を確認する必要があります ([RFC8899] のセクション 5.1.4) が、UDP 自体はこれのためのメカニズムを提供しません。
UDP Options can provide this required functionality. A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity for the path by sending a probe packet padded to size BASE_PLPMTU. This confirmation probe MUST include the REQ UDP Option to elicit a response from the remote DPLPMTUD. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size that has successfully traversed the path to the receiver. This also confirms that the remote endpoint supports the RES Option.
UDP オプションは、この必要な機能を提供できます。この仕様を実装する UDP オプション送信者は、サイズ BASE_PLPMTU にパディングされたプローブ パケットを送信することによって、パスの接続性の肯定的な確認を引き出しなければなりません (MUST)。この確認プローブには、リモート DPLPMTUD からの応答を引き出すための REQ UDP オプションが含まれなければなりません (MUST)。対応する RES オプションを使用してデータグラムを受信すると、受信者へのパスを正常に通過した、調査されたサイズのパケットの受信が確認されます。これにより、リモート エンドポイントが RES オプションをサポートしていることも確認されます。
From time to time, DPLPMTUD enters the SEARCHING state, described in Section 5.2 of [RFC8899], (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the current path can support a larger PLPMTU. When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) Option (see Section 11.5 of [RFC9868]), this value MAY be used as a hint to initialize this search to increase the PLPMTU.
時折、DPLPMTUD は [RFC8899] のセクション 5.2 で説明されている SEARCHING 状態に入り (例: PMTU_RAISE_TIMER の期限切れ後)、現在のパスがより大きな PLPMTU をサポートできるかどうかを検出します。リモートエンドポイントが UDP 最大データグラムサイズ (MDS) オプション ([RFC9868] のセクション 11.5 を参照) をアドバタイズする場合、この値は、PLPMTU を増やすためにこの検索を初期化するためのヒントとして使用されてもよい(MAY)。
Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data (see "Probing using padding data" in Section 4.1 of [RFC8899]), since they will be lost whenever their size exceeds the actual PMTU. [RFC8899] requires a probe packet to elicit a positive acknowledgement that the path has delivered a datagram of the specific probed size; therefore, a probe packet MUST include the REQ Option when using transport options for UDP [RFC9868].
PLPMTU を増加しようとするプローブ パケットは、サイズが実際の PMTU を超えるたびに失われるため、アプリケーション データを伝送すべきではありません ([RFC8899] のセクション 4.1 の「パディング データを使用したプローブ」を参照)。[RFC8899] では、パスが特定のプローブされたサイズのデータグラムを配信したという肯定的な確認応答を引き出すためにプローブ パケットを要求しています。したがって、UDP [RFC9868] のトランスポート オプションを使用する場合、プローブ パケットには REQ オプションが含まれなければなりません (MUST)。
At the receiver, a received probe packet that does not carry application data does not form a part of the end-to-end transport data and is not delivered to the Upper Layer protocol (i.e., application or protocol layered above UDP). A zero-length payload notification could still be delivered to the application (see Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses the implications when using UDP Options.
受信側では、アプリケーション データを伝送しない受信プローブ パケットは、エンドツーエンドのトランスポート データの一部を形成せず、上位層プロトコル (つまり、UDP の上層にあるアプリケーションまたはプロトコル) に配信されません。[RFC9868] のセクション 18 では、UDP オプションを使用する場合の影響について説明していますが、長さゼロのペイロード通知は依然としてアプリケーションに配信される可能性があります ([RFC8085] のセクション 5 を参照)。
A PL using DPLPMTUD MUST validate that a path continues to support the PLPMTU discovered in a previous search for a suitable PLPMTU value, as defined in Section 6.1.4 of [RFC8899]. This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state (Section 5.2 of [RFC8899]) to detect black-holing of data (Section 4.3 of [RFC8899] defines a DPLPMTUD black hole).
DPLPMTUD を使用する PL は、[RFC8899] のセクション 6.1.4 で定義されているように、適切な PLPMTU 値の以前の検索で発見された PLPMTU をパスが引き続きサポートしていることを検証しなければなりません (MUST)。この検証は、データのブラックホールを検出するために DPLPMTUD SEARCH_COMPLETE 状態 ([RFC8899] のセクション 5.2) でプローブ パケットを送信します ([RFC8899] のセクション 4.3 は DPLPMTUD ブラック ホールを定義しています)。
Path validation can be implemented within UDP Options by generating a probe packet of size PLPMTU, which MUST include a REQ Option to elicit a positive confirmation that the path has delivered this probe packet. A probe packet used to validate the path MAY use either "Probing using padding data" to construct a probe packet that does not carry any application data or "Probing using application data and padding data"; see Section 4.1 of [RFC8899]. When using "Probing using padding data", the UDP Options API does not indicate receipt of the zero-length probe packet (see Section 6 of [RFC9868]).
パス検証は、サイズ PLPMTU のプローブ パケットを生成することで UDP オプション内で実装できます。これには、パスがこのプローブ パケットを配信したという肯定的な確認を引き出すための REQ オプションが含まれなければなりません。パスの検証に使用されるプローブ パケットは、アプリケーション データを運ばないプローブ パケットを構築するために「パディング データを使用したプローブ」、または「アプリケーション データとパディング データを使用したプローブ」のいずれかを使用してもよい(MAY)。[RFC8899] のセクション 4.1 を参照してください。「パディングデータを使用したプローブ」を使用する場合、UDP オプション API は長さゼロのプローブパケットの受信を示しません ([RFC9868] のセクション 6 を参照)。
A simple implementation of the method might be designed to only use probe packets in a UDP datagram that includes no application data. The size of each probe packet is padded to the required probe size including the REQ Option. This implements "Probing using padding data" (Section 4.1 of [RFC8899]) and avoids having to retransmit application data when a probe fails. This could be achieved by setting a minimum datagram length, such that the options list ends in EOL (Section 11.1 of [RFC9868]) with any additional space zero-filled as needed (see Section 15 of [RFC9868]). In this use, the probe packets do not form a part of the end-to-end transport data and a receiver does not deliver them to the Upper Layer protocol.
このメソッドの単純な実装は、アプリケーション データを含まない UDP データグラム内のプローブ パケットのみを使用するように設計される場合があります。各プローブ パケットのサイズは、REQ オプションを含む必要なプローブ サイズにパディングされます。これにより、「パディング データを使用したプローブ」([RFC8899] のセクション 4.1) が実装され、プローブが失敗した場合にアプリケーション データを再送信する必要がなくなります。これは、オプションリストが EOL ([RFC9868] のセクション 11.1) で終了し、必要に応じて追加のスペースにゼロが埋められるように、データグラムの最小長を設定することで実現できます ([RFC9868] のセクション 15 を参照)。この使用法では、プローブ パケットはエンドツーエンドのトランスポート データの一部を形成せず、受信機はそれらを上位層プロトコルに配信しません。
An implementation always uses the format in Section 4.4 when DPLPMTUD searches to increase the PLPMTU.
DPLPMTUD が PLPMTU を増やすために検索する場合、実装では常にセクション 4.4 の形式が使用されます。
An alternative format is permitted for a probe packet that is used to confirm the connectivity or to validate the path. These probe packets MAY carry application data. (UDP payload data is permitted because these probe packets perform black-hole detection and will therefore usually have a higher probability of successful transmission, similar to other packets sent by the Upper Layer protocol.) Section 4.1 of [RFC8899] provides a discussion of the merits and demerits of including application data. For example, this reduces the need to send additional datagrams.
接続性の確認またはパスの検証に使用されるプローブ パケットには、代替フォーマットが許可されています。これらのプローブ パケットはアプリケーション データを伝送してもよい(MAY)。(UDP ペイロード データが許可されるのは、これらのプローブ パケットがブラック ホール検出を実行するため、通常、上位層プロトコルによって送信される他のパケットと同様に、送信が成功する確率が高くなります。) [RFC8899] のセクション 4.1 では、アプリケーション データを含めることの長所と短所について説明しています。たとえば、これにより追加のデータグラムを送信する必要性が減ります。
This type of probe packet MAY use a control message format defined by the Upper Layer protocol, provided that the message does not need to be delivered reliably. The REQ Option MUST be included when the sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method tracks the transmission of probe packets (using the REQ Option token).
このタイプのプローブ パケットは、メッセージを確実に配信する必要がない場合、上位層プロトコルで定義された制御メッセージ フォーマットを使用してもよい(MAY)。REQ オプションは、送信側上位層プロトコルが DPLPMTUD を実行するときに含める必要があります。DPLPMTUD メソッドは、(REQ オプション トークンを使用して) プローブ パケットの送信を追跡します。
A receiver that responds to DPLPMTUD MUST process the REQ Option and include the corresponding RES Option with an Upper Layer protocol message that it returns to the requester (examples of receiver processing are provided in Section 6).
DPLPMTUD に応答する受信者は、REQ オプションを処理し、要求者に返す上位層プロトコル メッセージに対応する RES オプションを含めなければなりません (受信者の処理の例はセクション 6 で提供されます)。
Probe packets that use this format form a part of the end-to-end transport data and can be used to manage the PLPMTU in just one direction or can be used for both directions.
この形式を使用するプローブ パケットは、エンドツーエンドのトランスポート データの一部を形成し、一方向のみで PLPMTU を管理するために使用することも、両方向に使用することもできます。
This specification does not rely upon reception of events from the network, but an implementation can utilize these events when they are provided.
この仕様はネットワークからのイベントの受信には依存しませんが、実装ではこれらのイベントが提供されたときにそれを利用できます。
A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received. For example, a notification that a path has changed could trigger path validation to provide black-hole protection (Section 4.3 of [RFC8899]).
パスの変更またはプローブ パケットの損失により、DPLPMTUD が PLPMTU を更新する可能性があります。DPLPMTUD [RFC8899] は、パス特性が最後に確認されてから発生した可能性のあるパス変更や、受信される一貫性のないパス情報の可能性に対して、方法が堅牢であることを推奨しています。たとえば、パスが変更されたという通知は、ブラックホール保護を提供するためにパスの検証をトリガーできます ([RFC8899] のセクション 4.3)。
An Upper Layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout) [RFC8899].
上位層プロトコルは、高いパケット損失率 (またはプロトコル タイムアウトの繰り返し) [RFC8899] を観察した場合に、DPLPMTUD をトリガーしてパスを検証する可能性があります。
Section 3 of [RFC8899] requires any methods designed to share the PLPMTU between PLs (such as updating the IP cache PMTU for an interface/destination) to be robust to the wide variety of underlying network forwarding behaviors. For example, an implementation could avoid sharing PMTU information that could potentially relate to packets sent with the same address over a different interface.
[RFC8899] のセクション 3 では、基盤となるさまざまなネットワーク転送動作に対して堅牢であるために、PL 間で PLPMTU を共有するように設計された方法 (インターフェイス/宛先の IP キャッシュ PMTU の更新など) を要求しています。たとえば、実装では、異なるインターフェイスを介して同じアドレスで送信されたパケットに関連する可能性がある PMTU 情報の共有を回避できます。
Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages.
ICMP PTB メッセージの受信のサポートは、DPLPMTUD ではオプションです。したがって、UDP オプションの送信者は、受信した ICMP PTB メッセージを無視できます。
Before processing an ICMP PTB message, the DPLPMTUD method needs to perform two checks to ensure that the message was received in response to a sent probe packet:
ICMP PTB メッセージを処理する前に、DPLPMTUD メソッドは 2 つのチェックを実行して、送信されたプローブ パケットに対する応答としてメッセージが受信されたことを確認する必要があります。
* DPLPMTUD first utilizes the quoted information in each PTB message. The receiver MUST validate the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node (see Section 4.6.1 of [RFC8899]).
* DPLPMTUD は、まず各 PTB メッセージ内で引用された情報を利用します。受信者は、送信ノードから発信されたメッセージを検証するために、ICMP PTB メッセージ ペイロードで運ばれる引用パケット内のプロトコル情報を検証しなければなりません ([RFC8899] のセクション 4.6.1 を参照)。
* The receiver SHOULD utilize information that is not simple for an off-path attacker to determine (see Section 4.6.1 of [RFC8899]). Specifically, a UDP Options receiver SHOULD confirm that the token contained in the UDP REQ Option of the quoted packet has a value that corresponds to a probe packet that was recently sent by the current endpoint.
* 受信者は、オフパス攻撃者にとって判断が容易ではない情報を利用すべきである(SHOULD)([RFC8899]のセクション4.6.1を参照)。具体的には、UDP オプション受信者は、引用されたパケットの UDP REQ オプションに含まれるトークンが、現在のエンドポイントによって最近送信されたプローブ パケットに対応する値を持つことを確認する必要があります (SHOULD)。
An implementation unable to support this validation MUST ignore received ICMP PTB messages.
この検証をサポートできない実装は、受信した ICMP PTB メッセージを無視しなければなりません (MUST)。
When enabled, a DPLPMTUD endpoint that implements UDP Options normally responds with a UDP datagram with a RES Option when requested by a sender.
有効にすると、UDP オプションを実装する DPLPMTUD エンドポイントは、通常、送信者から要求されたときに、RES オプションを含む UDP データグラムで応答します。
The following examples describe various possible receiver behaviors:
次の例は、考えられるさまざまな受信機の動作を説明しています。
* No DPLPMTUD receiver support: One case is when a sender supports this specification, but no RES Option is received from the remote endpoint. In this example, the method is unable to discover the PLPMTU. This will result in using the MIN_PLPMTU. Such a remote endpoint might be not configured to process UDP Options or might not return a datagram with a RES Option for some other reason (e.g., packet loss, insufficient space to include the option, filtering on the path, etc.).
* DPLPMTUD 受信側サポートなし: 1 つのケースは、送信側がこの仕様をサポートしているが、リモート エンドポイントから RES オプションを受信しない場合です。この例では、メソッドは PLPMTU を検出できません。これにより、MIN_PLPMTU が使用されます。このようなリモート エンドポイントは、UDP オプションを処理するように構成されていない可能性や、他の理由 (例: パケット損失、オプションを含めるスペースの不足、パス上のフィルタリングなど) により RES オプションを含むデータグラムを返さない可能性があります。
* DPLPMTUD receiver uses application datagrams: In a second case, both the sender and receiver support DPLPMTUD using the specification, and the receiver only returns a RES Option with the next UDP datagram that is sent to the requester. Therefore, reception of a REQ Option does not systematically trigger a response. This allows DPLPMTUD to operate when there is a flow of datagrams in both directions, provided there is periodic feedback (e.g., one acknowledgement packet per RTT). It requires the PLPMTU at the receiver to be sufficiently large enough that the RES Option can be included in the feedback packets that are sent in the return direction. This method avoids opportunities to misuse the method as a DoS attack. However, when there is a low rate of transmission (or no datagrams are sent) in the return direction, this will prevent prompt delivery of the RES Option. At the DPLPMTUD sender, this results in probe packets failing to be acknowledged in time and could result in a smaller PLPMTU than is actually supported by the path or in using the MIN_PLPMTU.
* DPLPMTUD 受信者はアプリケーション データグラムを使用します。2 番目のケースでは、送信者と受信者の両方が仕様を使用して DPLPMTUD をサポートし、受信者はリクエスターに送信される次の UDP データグラムとともに RES オプションのみを返します。したがって、REQ オプションの受信は体系的に応答をトリガーしません。これにより、定期的なフィードバック (例: RTT ごとに 1 つの確認パケット) がある場合、両方向のデータグラム フローがある場合に DPLPMTUD が動作できるようになります。戻り方向に送信されるフィードバック パケットに RES オプションを含めることができるように、受信側の PLPMTU が十分に大きいことが必要です。この方法により、この方法が DoS 攻撃として悪用される機会が回避されます。ただし、戻り方向の送信速度が低い (またはデータグラムが送信されない) 場合、RES オプションの迅速な配信が妨げられます。これにより、DPLPMTUD 送信側でプローブ パケットが時間内に確認応答されなくなり、パスまたは MIN_PLPMTU の使用で実際にサポートされるよりも PLPMTU が小さくなる可能性があります。
* Unidirectional transfer: Another case is where an application only transfers data in one direction (or predominantly in one direction). In this case, the wait at the receiver for a datagram to be queued before returning a RES Option could easily result in a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD could allow exchanging datagrams without a payload (as discussed in earlier sections) to return the RES Option.
* 単方向転送: アプリケーションがデータを一方向のみ (または主に一方向) に転送するもう 1 つのケースがあります。この場合、RES オプションを返す前にデータグラムがキューに入れられるまで受信側で待機すると、DPLPMTUD 送信側でプローブ タイムアウトが簡単に発生する可能性があります。この場合、DPLPMTUD により、(前のセクションで説明したように) ペイロードなしでデータグラムを交換して RES オプションを返すことができます。
* DPLPMTUD receiver permitted to send responses in UDP datagrams with no payload: A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data) solely to return a RES Option (e.g., sent when no other datagrams are queued for transmission). This would allow an endpoint to probe the set of UDP ports that have been configured with support for this specification using a DPLPMTUD probe packet. Although this results in some additional traffic overhead, it has the advantage that it can ensure timely progress of DPLPMTUD. Section 3.1 specifies: "If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second)". This rate limit is to mitigate the DoS vector, without significantly impacting the operation of DPLPMTUD.
* DPLPMTUD 受信機は、ペイロードのない UDP データグラムで応答を送信することを許可されています: DPLPMTUD 受信機は、RES オプションを返すためだけにデータグラム (たとえば、ペイロード データがゼロ) を生成できます (たとえば、他のデータグラムが送信のためにキューに入れられていないときに送信されます)。これにより、エンドポイントは、DPLPMTUD プローブ パケットを使用して、この仕様をサポートするように構成された UDP ポートのセットをプローブできるようになります。これにより、追加のトラフィック オーバーヘッドが発生しますが、DPLPMTUD をタイムリーに進行させることができるという利点があります。セクション 3.1 では、「UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、レスポンダーはこれらの応答のレートを制限しなければなりません (例: 測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するようにポートの各ペアを制限する)」と規定されています。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The security considerations for using UDP Options are described in [RFC9868]. The method does not change the integrity protection offered by the UDP Options method.
UDP オプションを使用する場合のセキュリティに関する考慮事項は、[RFC9868] で説明されています。このメソッドは、UDP オプション メソッドによって提供される整合性保護を変更しません。
The security considerations for using DPLPMTUD are described in [RFC8899]. On-path attackers could maliciously drop or modify probe packets to seek to decrease the PMTU or to maliciously modify probe packets in an attempt to black-hole traffic.
DPLPMTUD を使用する場合のセキュリティに関する考慮事項は [RFC8899] で説明されています。パス上の攻撃者は、PMTU を減少させようとしてプローブ パケットを悪意を持ってドロップまたは変更したり、トラフィックをブラックホール化するためにプローブ パケットを悪意を持って変更したりする可能性があります。
The specification recommends that the token value in the REQ Option is initialized to a randomized value. This is to enhance protection from off-path attacks. If a subsequent probe packet uses a token value that is easily derived from the initial value (e.g., incrementing the value), a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe packets are not transiting via the observer. This would allow probe packets to be forged, with an impact similar to other on-path attacks against probe packets. This attack could be mitigated by using an unpredictable token value for each probe packet.
仕様では、REQ オプションのトークン値をランダムな値に初期化することが推奨されています。これは、オフパス攻撃からの保護を強化するためです。後続のプローブ パケットが初期値から容易に導出されるトークン値を使用する場合 (値をインクリメントするなど)、不正な動作を行うオンパス オブザーバーは、たとえこれらのプローブ パケットがオブザーバーを経由していない場合でも、その送信者からの後続のプローブ パケットに使用されるトークン値を決定する可能性があります。これにより、プローブ パケットが偽造される可能性があり、プローブ パケットに対する他のパス上の攻撃と同様の影響が生じます。この攻撃は、各プローブ パケットに予測不可能なトークン値を使用することで軽減できる可能性があります。
The method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilizes ICMP PTB messages received to a probe packet MUST use the quoted packet to validate the UDP port information in combination with the token contained in the UDP Option before processing the packet using the DPLPMTUD method.
このメソッドは、DPLPMTUD で説明されている ICMP PTB メッセージ検証メソッドを変更しません。プローブ パケットに対して受信した ICMP PTB メッセージを利用する UDP オプション送信者は、DPLPMTUD メソッドを使用してパケットを処理する前に、引用符付きパケットを使用して、UDP オプションに含まれるトークンと組み合わせて UDP ポート情報を検証しなければなりません (MUST)。
Upper Layer protocols or applications that employ encryption ought to perform DPLPMTUD at a layer above UDP Options and not enable UDP Options support for DPLPMTUD. This allows the application to control when DPLPMTUD is used to control the additional traffic that this generates. This also ensures that DPLPMTUD probe packets are encrypted.
暗号化を使用する上位層のプロトコルまたはアプリケーションは、UDP オプションより上の層で DPLPMTUD を実行する必要があり、DPLPMTUD に対する UDP オプションのサポートを有効にしないでください。これにより、アプリケーションは、生成される追加トラフィックを制御するために DPLPMTUD を使用するタイミングを制御できるようになります。これにより、DPLPMTUD プローブ パケットが確実に暗号化されます。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP",
RFC 9868, DOI 10.17487/RFC9868, October 2025,
<https://www.rfc-editor.org/info/rfc9868>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[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>.
[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>.
[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>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>.
Gorry Fairhurst and Tom Jones are supported by funding provided by the University of Aberdeen. The authors would like to thank Magnus Westerlund and Mohamed Boucadair for their detailed comments and also other people who contributed to completing this document.
ゴリー・フェアハーストとトム・ジョーンズは、アバディーン大学から提供された資金によってサポートされています。著者らは、詳細なコメントを寄せてくれた Magnus Westerlund と Mohamed Boucadair、そしてこの文書の完成に貢献した他の人々に感謝の意を表します。
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: tom@erg.abdn.ac.uk