[要約] RFC 4821は、パケット化レイヤーパスMTU探索の仕組みを提案しています。その目的は、ネットワークパス上の最適なMTUサイズを特定し、パフォーマンスを最適化することです。
Network Working Group M. Mathis
Request for Comments: 4821 J. Heffner
Category: Standards Track PSC
March 2007
Packetization Layer Path MTU Discovery
パケット化レイヤーパスMTU発見
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.
このドキュメントでは、TCPまたはその他のパケット化レイヤーに依存するPATH MTU Discovery（PMTUD）の堅牢な方法について説明し、徐々に大きなパケットを持つインターネットパスをプローブします。この方法は、IPバージョン4と6のICMPベースのPATH MTU発見をそれぞれ指定するRFC 1191およびRFC 1981の拡張として説明されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Accounting for Header Sizes . . . . . . . . . . . . . . . 10
5.2. Storing PMTU Information . . . . . . . . . . . . . . . . . 11
5.3. Accounting for IPsec . . . . . . . . . . . . . . . . . . . 12
5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Common Packetization Properties . . . . . . . . . . . . . . . 13
6.1. Mechanism to Detect Loss . . . . . . . . . . . . . . . . . 13
6.2. Generating Probes . . . . . . . . . . . . . . . . . . . . 13
7. The Probing Method . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Packet Size Ranges . . . . . . . . . . . . . . . . . . . . 14
7.2. Selecting Initial Values . . . . . . . . . . . . . . . . . 16
7.3. Selecting Probe Size . . . . . . . . . . . . . . . . . . . 17
7.4. Probing Preconditions . . . . . . . . . . . . . . . . . . 18
7.5. Conducting a Probe . . . . . . . . . . . . . . . . . . . . 18
7.6. Response to Probe Results . . . . . . . . . . . . . . . . 19
7.6.1. Probe Success . . . . . . . . . . . . . . . . . . . . 19
7.6.2. Probe Failure . . . . . . . . . . . . . . . . . . . . 19
7.6.3. Probe Timeout Failure . . . . . . . . . . . . . . . . 20
7.6.4. Probe Inconclusive . . . . . . . . . . . . . . . . . . 20
7.7. Full-Stop Timeout . . . . . . . . . . . . . . . . . . . . 20
7.8. MTU Verification . . . . . . . . . . . . . . . . . . . . . 21
8. Host Fragmentation . . . . . . . . . . . . . . . . . . . . . . 22
9. Application Probing . . . . . . . . . . . . . . . . . . . . . 23
10. Specific Packetization Layers . . . . . . . . . . . . . . . . 23
10.1. Probing Method Using TCP . . . . . . . . . . . . . . . . . 23
10.2. Probing Method Using SCTP . . . . . . . . . . . . . . . . 25
10.3. Probing Method for IP Fragmentation . . . . . . . . . . . 26
10.4. Probing Method Using Applications . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31
This document describes a method for Packetization Layer Path MTU Discovery (PLPMTUD), which is an extension to existing Path MTU Discovery methods described in [RFC1191] and [RFC1981]. In the absence of ICMP messages, the proper MTU is determined by starting with small packets and probing with successively larger packets. The bulk of the algorithm is implemented above IP, in the transport layer (e.g., TCP) or other "Packetization Protocol" that is responsible for determining packet boundaries.
このドキュメントでは、[RFC1191]および[RFC1981]で説明されている既存のパスMTU発見方法の拡張であるパケット化レイヤーパスMTU発見（PLPMTUD）の方法について説明します。ICMPメッセージがない場合、適切なMTUは、小さなパケットから開始し、連続的に大きなパケットでプローブすることにより決定されます。アルゴリズムの大部分は、パケット境界の決定を担当するトランスポート層（TCPなど）または他の「パケット化プロトコル」にIPの上に実装されます。
This document does not update RFC 1191 or RFC 1981; however, since it supports correct operation without ICMP, it implicitly relaxes some of the requirements for the algorithms specified in those documents.
このドキュメントは、RFC 1191またはRFC 1981を更新しません。ただし、ICMPを使用しない正しい操作をサポートするため、これらのドキュメントで指定されたアルゴリズムの要件の一部を暗黙的に緩和します。
The methods described in this document rely on features of existing protocols. They apply to many transport protocols over IPv4 and IPv6. They do not require cooperation from the lower layers (except that they are consistent about which packet sizes are acceptable) or from peers. As the methods apply only to senders, variants in implementations will not cause interoperability problems.
このドキュメントで説明されている方法は、既存のプロトコルの機能に依存しています。それらは、IPv4およびIPv6を介した多くの輸送プロトコルに適用されます。彼らは、下層からの協力を必要としません（どのパケットサイズが許容されるかについて一貫していることを除きます）またはピアから。メソッドは送信者にのみ適用されるため、実装のバリエーションは相互運用性の問題を引き起こしません。
For sake of clarity, we uniformly prefer TCP and IPv6 terminology. In the terminology section, we also present the analogous IPv4 terms and concepts for the IPv6 terminology. In a few situations, we describe specific details that are different between IPv4 and IPv6.
明確にするために、TCPとIPv6の用語を均一に好みます。用語セクションでは、IPv6用語の類似のIPv4用語と概念も示します。いくつかの状況では、IPv4とIPv6の間で異なる特定の詳細について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This document is a product of the Path MTU Discovery (PMTUD) working group of the IETF and draws heavily on RFC 1191 and RFC 1981 for terminology, ideas, and some of the text.
このドキュメントは、IETFのPATH MTU Discovery（PMTUD）ワーキンググループの製品であり、用語、アイデア、およびテキストの一部については、RFC 1191およびRFC 1981に重点を置いています。
Packetization Layer Path MTU Discovery (PLPMTUD) is a method for TCP or other Packetization Protocols to dynamically discover the MTU of a path by probing with progressively larger packets. It is most efficient when used in conjunction with the ICMP-based Path MTU Discovery mechanism as specified in RFC 1191 and RFC 1981, but resolves many of the robustness problems of the classical techniques since it does not depend on the delivery of ICMP messages.
パケット化レイヤーパスMTUディスカバリー（PLPMTUD）は、TCPまたは他のパケット化プロトコルが、徐々に大きなパケットでプローブすることによりパスのMTUを動的に発見する方法です。RFC 1191およびRFC 1981で指定されているICMPベースのPATH MTU発見メカニズムと組み合わせて使用すると、最も効率的ですが、ICMPメッセージの配信に依存しないため、古典的手法の堅牢性の問題の多くを解決します。
This method is applicable to TCP and other transport- or application-level protocols that are responsible for choosing packet boundaries (e.g., segment sizes) and have an acknowledgment structure that delivers to the sender accurate and timely indications of which packets were lost.
この方法は、パケットの境界（セグメントサイズなど）の選択を担当するTCPおよびその他のトランスポートまたはアプリケーションレベルのプロトコルに適用され、送信者に正確でタイムリーな指標を送信者に提供する確認構造を持っています。
The general strategy is for the Packetization Layer to find an appropriate Path MTU by probing the path with progressively larger packets. If a probe packet is successfully delivered, then the effective Path MTU is raised to the probe size.
一般的な戦略は、パケット化レイヤーが、徐々に大きいパケットでパスを調査することにより、適切なパスMTUを見つけることです。プローブパケットが正常に配信されると、有効なパスMTUがプローブサイズに引き上げられます。
The isolated loss of a probe packet (with or without an ICMP Packet Too Big message) is treated as an indication of an MTU limit, and not as a congestion indicator. In this case alone, the Packetization Protocol is permitted to retransmit any missing data without adjusting the congestion window.
プローブパケットの孤立した損失（ICMPパケットがあまりにも大きなメッセージであるかどうかの有無にかかわらず）は、MTU制限の表示として扱われ、混雑指標としてではありません。この場合だけで、パケット化プロトコルは、輻輳ウィンドウを調整せずに欠落データを再送信することができます。
If there is a timeout or additional packets are lost during the probing process, the probe is considered to be inconclusive (e.g., the lost probe does not necessarily indicate that the probe exceeded the Path MTU). Furthermore, the losses are treated like any other congestion indication: window or rate adjustments are mandatory per the relevant congestion control standards [RFC2914]. Probing can resume after a delay that is determined by the nature of the detected failure.
調査プロセス中にタイムアウトまたは追加のパケットが失われた場合、プローブは決定的ではないと見なされます（たとえば、失われたプローブは、プローブがパスMTUを超えたことを必ずしも示すものではありません）。さらに、損失は他の混雑の兆候と同様に扱われます。窓またはレートの調整は、関連する混雑制御基準[RFC2914]に従って必須です。調査は、検出された障害の性質によって決定される遅延後に再開できます。
PLPMTUD uses a searching technique to find the Path MTU. Each conclusive probe narrows the MTU search range, either by raising the lower limit on a successful probe or lowering the upper limit on a failed probe, converging toward the true Path MTU. For most transport layers, the search should be stopped once the range is narrow enough that the benefit of a larger effective Path MTU is smaller than the search overhead of finding it.
PLPMTUDは、検索手法を使用してPATH MTUを見つけます。各決定的なプローブは、成功したプローブの下限を上げるか、失敗したプローブの上限を下げることにより、真のパスMTUに収束することにより、MTU検索範囲を狭めます。ほとんどの輸送層では、より大きな効果的なパスMTUの利点が検索オーバーヘッドよりも小さいため、範囲が十分に狭くなったら検索を停止する必要があります。
The most likely (and least serious) probe failure is due to the link experiencing congestion-related losses while probing. In this case, it is appropriate to retry a probe of the same size as soon as the Packetization Layer has fully adapted to the congestion and recovered from the losses. In other cases, additional losses or timeouts indicate problems with the link or Packetization Layer. In these situations, it is desirable to use longer delays depending on the severity of the error.
最も可能性の高い（そして最も深刻ではない）プローブの故障は、調査中に混雑関連の損失を経験しているリンクによるものです。この場合、パケット化レイヤーが混雑に完全に適合し、損失から回復するとすぐに、同じサイズのプローブを再試行することが適切です。それ以外の場合、追加の損失またはタイムアウトは、リンクまたはパケット化レイヤーの問題を示しています。これらの状況では、エラーの重大度に応じて、より長い遅延を使用することが望ましいです。
An optional verification process can be used to detect situations where raising the MTU raises the packet loss rate. For example, if a link is striped across multiple physical channels with inconsistent MTUs, it is possible that a probe will be delivered even if it is too large for some of the physical channels. In such cases, raising the Path MTU to the probe size can cause severe packet loss and abysmal performance. After raising the MTU, the new MTU size can be verified by monitoring the loss rate.
オプションの検証プロセスを使用して、MTUを上げるとパケットの損失率が上昇する状況を検出できます。たとえば、一貫性のないMTUを備えた複数の物理チャネルにリンクが縞模様になっている場合、物理チャネルの一部では大きすぎてもプローブが配信される可能性があります。そのような場合、PATH MTUをプローブサイズに上げると、重度のパケット損失とひどいパフォーマンスが発生する可能性があります。MTUを上げた後、損失率を監視することにより、新しいMTUサイズを検証できます。
Packetization Layer PMTUD (PLPMTUD) introduces some flexibility in the implementation of classical Path MTU Discovery. It can be configured to perform just ICMP black hole recovery to increase the robustness of classical Path MTU Discovery, or at the other extreme, all ICMP processing can be disabled and PLPMTUD can completely replace classical Path MTU Discovery.
Packetization Layer PMTUD（PLPMTUD）は、古典的なパスMTU発見の実装にある程度の柔軟性を導入します。ICMPブラックホールの回復を実行するように構成して、古典的なパスMTU発見の堅牢性を高めるか、他の極端に、すべてのICMP処理を無効にすることができ、PLPMTUDは古典的なパスMTU発見を完全に置き換えることができます。
Classical Path MTU Discovery is subject to protocol failures (connection hangs) if ICMP Packet Too Big (PTB) messages are not delivered or processed for some reason [RFC2923]. With PLPMTUD, classical Path MTU Discovery can be modified to include additional consistency checks without increasing the risk of connection hangs due to spurious failures of the additional checks. Such changes to classical Path MTU Discovery are beyond the scope of this document.
ICMPパケットが大きすぎる（PTB）メッセージが配信または処理されない場合、古典的なパスMTU発見はプロトコル障害（接続ハング）の対象となります[RFC2923]。PLPMTUDを使用すると、Classical Path MTU発見を変更して、追加のチェックの不正な失敗のために接続ハングのリスクを高めることなく、追加の一貫性チェックを含めることができます。古典的なパスMTU発見のこのような変更は、このドキュメントの範囲を超えています。
In the limiting case, all ICMP PTB messages might be unconditionally ignored, and PLPMTUD can be used as the sole method to discover the Path MTU. In this configuration, PLPMTUD parallels congestion control. An end-to-end transport protocol adjusts properties of the data stream (window size or packet size) while using packet losses to deduce the appropriateness of the adjustments. This technique seems to be more philosophically consistent with the end-to-end principle of the Internet than relying on ICMP messages containing transcribed headers of multiple protocol layers.
制限の場合、すべてのICMP PTBメッセージは無条件に無視される可能性があり、PLPMTUDはPATH MTUを発見する唯一の方法として使用できます。この構成では、PLPMTUDはうっ血制御に似ています。エンドツーエンドのトランスポートプロトコルは、パケットの損失を使用して調整の適切性を推測しながら、データストリーム（ウィンドウサイズまたはパケットサイズ）のプロパティを調整します。この手法は、複数のプロトコル層の転写されたヘッダーを含むICMPメッセージに依存するよりも、インターネットのエンドツーエンドの原則とより哲学的に一致しているようです。
Most of the difficulty in implementing PLPMTUD arises because it needs to be implemented in several different places within a single node. In general, each Packetization Protocol needs to have its own implementation of PLPMTUD. Furthermore, the natural mechanism to share Path MTU information between concurrent or subsequent connections is a path information cache in the IP layer. The various Packetization Protocols need to have the means to access and update the shared cache in the IP layer. This memo describes PLPMTUD in terms of its primary subsystems without fully describing how they are assembled into a complete implementation.
PLPMTUDを実装することの難しさのほとんどは、単一のノード内のいくつかの異なる場所で実装する必要があるために発生します。一般に、各パケット化プロトコルには、PLPMTUDの独自の実装が必要です。さらに、同時接続または後続の接続間でPATH MTU情報を共有する自然なメカニズムは、IPレイヤーのパス情報キャッシュです。さまざまなパケット化プロトコルには、IPレイヤーの共有キャッシュにアクセスして更新する手段が必要です。このメモは、PLPMTUDが、それらが完全な実装にどのように組み立てられているかを完全に説明することなく、そのプライマリサブシステムの観点から説明しています。
The vast majority of the implementation details described in this document are recommendations based on experiences with earlier versions of Path MTU Discovery. These recommendations are motivated by a desire to maximize robustness of PLPMTUD in the presence of less than ideal network conditions as they exist in the field.
このドキュメントで説明されている実装の詳細の大部分は、Path MTU発見の以前のバージョンの経験に基づいた推奨事項です。これらの推奨事項は、フィールドに存在する理想的なネットワーク条件が存在する場合、PLPMTUDの堅牢性を最大化したいという願望によって動機付けられています。
This document does not contain a complete description of an implementation. It only sketches details that do not affect interoperability with other implementations and have strong externally imposed optimality criteria (e.g., the MTU searching and caching heuristics). Other details are explicitly included because there is an obvious alternative implementation that doesn't work well in some (possibly subtle) case.
このドキュメントには、実装の完全な説明は含まれていません。他の実装との相互運用性に影響を与えない詳細をスケッチし、外部から強い最適性基準（例えば、MTU検索とキャッシュヒューリスティック）を備えています。一部の（おそらく微妙な）ケースではうまく機能しない明らかな代替実装があるため、他の詳細が明示的に含まれています。
Section 3 provides a complete glossary of terms.
セクション3には、条件の完全な用語集を提供します。
Section 4 describes the details of PLPMTUD that affect interoperability with other standards or Internet protocols.
セクション4では、他の標準やインターネットプロトコルとの相互運用性に影響を与えるPLPMTUDの詳細について説明します。
Section 5 describes how to partition PLPMTUD into layers, and how to manage the path information cache in the IP layer.
セクション5では、PLPMTUDをレイヤーに分割する方法と、IPレイヤーでパス情報キャッシュを管理する方法について説明します。
Section 6 describes the general Packetization Layer properties and features needed to implement PLPMTUD.
セクション6では、PLPMTUDを実装するために必要な一般的なパケット化層のプロパティと機能について説明します。
Section 7 describes how to use probes to search for the Path MTU.
セクション7では、プローブを使用してパスMTUを検索する方法について説明します。
Section 8 recommends using IPv4 fragmentation in a configuration that mimics IPv6 functionality, to minimize future problems migrating to IPv6.
セクション8では、IPv6機能を模倣する構成でIPv4断片化を使用して、IPv6に移行する将来の問題を最小限に抑えることをお勧めします。
Section 9 describes a programming interface for implementing PLPMTUD in applications that choose their own packet boundaries and for tools to be able to diagnose path problems that interfere with Path MTU Discovery.
セクション9では、独自のパケット境界を選択するアプリケーションにPLPMTUDを実装するためのプログラミングインターフェイスと、PATH MTU発見を妨げるパスの問題を診断できるツールについて説明します。
Section 10 discusses implementation details for specific protocols, including TCP.
セクション10では、TCPを含む特定のプロトコルの実装の詳細について説明します。
We use the following terms in this document:
このドキュメントでは、次の用語を使用します。
IP: Either IPv4 [RFC0791] or IPv6 [RFC2460].
IP：IPv4 [RFC0791]またはIPv6 [RFC2460]のいずれか。
Node: A device that implements IP.
ノード：IPを実装するデバイス。
Upper layer: A protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and Internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself.
上層：IPのすぐ上のプロトコル層。例としては、TCPやUDPなどの輸送プロトコル、ICMPなどの制御プロトコル、OSPFなどのルーティングプロトコル、IPX、AppleTalk、またはIP自体などのIPなどのIPを「トンネル」している（つまり、カプセル化された）IP自体を「トンネル」しています。。
Link: A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or Asynchronous Transfer Mode (ATM) networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6. Occasionally we use the slightly more general term "lower layer" for this concept.
リンク：ノードがリンクレイヤー、つまりIPのすぐ下のレイヤーで通信できる通信機能または媒体。例は、イーサネット（シンプルまたはブリッジ）です。PPPリンク;X.25、フレームリレー、または非同期転送モード（ATM）ネットワーク。IPv4やIPv6上のトンネルなど、インターネット（またはそれ以上の）層「トンネル」。時折、この概念には少し一般的な用語「下層」を使用します。
Interface: A node's attachment to a link.
インターフェイス：リンクへのノードの添付ファイル。
Address: An IP layer identifier for an interface or a set of interfaces.
アドレス：インターフェイスまたはインターフェイスのセットのIPレイヤー識別子。
Packet: An IP header plus payload.
パケット：IPヘッダーとペイロード。
MTU: Maximum Transmission Unit, the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted on a link or path. Note that this could more properly be called the IP MTU, to be consistent with how other standards organizations use the acronym MTU.
MTU：最大送信ユニット、IPヘッダーやペイロードを含む最大のIPパケットのサイズで、リンクまたはパスで送信できます。これは、他の標準組織が頭字語MTUを使用する方法と一致するために、より適切にIP MTUと呼ばれる可能性があることに注意してください。
Link MTU: The Maximum Transmission Unit, i.e., maximum IP packet size in bytes, that can be conveyed in one piece over a link. Be aware that this definition is different from the definition used by other standards organizations.
リンクMTU：最大送信ユニット、つまり、リンク上で1つのピースで伝達できる最大IPパケットサイズ。この定義は、他の標準組織で使用される定義とは異なることに注意してください。
For IETF documents, link MTU is uniformly defined as the IP MTU over the link. This includes the IP header, but excludes link layer headers and other framing that is not part of IP or the IP payload.
IETFドキュメントの場合、リンクMTUはリンク上のIP MTUとして均一に定義されています。これにはIPヘッダーが含まれますが、IPまたはIPペイロードの一部ではないリンクレイヤーヘッダーとその他のフレーミングを除外します。
Be aware that other standards organizations generally define link MTU to include the link layer headers.
他の標準組織は一般に、リンクレイヤーヘッダーを含めるようにリンクMTUを定義していることに注意してください。
Path: The set of links traversed by a packet between a source node and a destination node.
パス：ソースノードと宛先ノードの間のパケットによって通過するリンクのセット。
Path MTU, or PMTU: The minimum link MTU of all the links in a path between a source node and a destination node.
Path MTU、またはPMTU：ソースノードと宛先ノードの間のパス内のすべてのリンクの最小リンクMTU。
Classical Path MTU Discovery: Process described in RFC 1191 and RFC 1981, in which nodes rely on ICMP Packet Too Big (PTB) messages to learn the MTU of a path.
古典的なパスMTU発見：RFC 1191およびRFC 1981で説明されているプロセスでは、ノードがICMPパケットに依存している（PTB）メッセージに依存してパスのMTUを学習します。
Packetization Layer: The layer of the network stack that segments data into packets.
パケット化レイヤー：データをパケットにセグメント化するネットワークスタックのレイヤー。
Effective PMTU: The current estimated value for PMTU used by a Packetization Layer for segmentation.
効果的なPMTU：セグメンテーションのためにパケット化レイヤーによって使用されるPMTUの現在の推定値。
PLPMTUD: Packetization Layer Path MTU Discovery, the method described in this document, which is an extension to classical PMTU Discovery.
PLPMTUD：パケット化レイヤーパスMTU発見、このドキュメントで説明されている方法は、古典的なPMTU発見の拡張です。
PTB (Packet Too Big) message: An ICMP message reporting that an IP packet is too large to forward. This is the IPv6 term that corresponds to the IPv4 ICMP "Fragmentation Needed and DF Set" message.
PTB（パケットが大きすぎる）メッセージ：IPパケットが大きすぎて転送できないことを報告するICMPメッセージ。これは、IPv4 ICMP "断片化が必要であり、DFセット"メッセージに対応するIPv6用語です。
Flow: A context in which MTU Discovery algorithms can be invoked. This is naturally an instance of a Packetization Protocol, for example, one side of a TCP connection.
Flow：MTU Discoveryアルゴリズムを呼び出すことができるコンテキスト。これは当然、パケット化プロトコルのインスタンス、たとえばTCP接続の片側です。
MSS: The TCP Maximum Segment Size [RFC0793], the maximum payload size available to the TCP layer. This is typically the Path MTU minus the size of the IP and TCP headers.
MSS：TCP最大セグメントサイズ[RFC0793]、TCPレイヤーが利用できる最大ペイロードサイズ。これは通常、MTUからIPヘッダーとTCPヘッダーのサイズを差し引いたパスです。
Probe packet: A packet that is being used to test a path for a larger MTU.
プローブパケット：より大きなMTUのパスをテストするために使用されているパケット。
Probe size: The size of a packet being used to probe for a larger MTU, including IP headers.
プローブサイズ：IPヘッダーを含むより大きなMTUのプローブに使用されるパケットのサイズ。
Probe gap: The payload data that will be lost and need to be retransmitted if the probe is not delivered.
プローブギャップ：失われ、プローブが配信されない場合は再送信する必要があるペイロードデータ。
Leading window: Any unacknowledged data in a flow at the time a probe is sent.
先行ウィンドウ：プローブが送信された時点でのフロー内の未充填データのデータはありません。
Trailing window: Any data in a flow sent after a probe, but before the probe is acknowledged.
後続のウィンドウ：プローブの後に送信されるフロー内のデータは、プローブが認められる前に。
Search strategy: The heuristics used to choose successive probe sizes to converge on the proper Path MTU, as described in Section 7.3.
検索戦略：ヒューリスティックは、セクション7.3で説明されているように、適切なパスMTUに収束するための連続したプローブサイズを選択していました。
Full-stop timeout: A timeout where none of the packets transmitted after some event are acknowledged by the receiver, including any retransmissions. This is taken as an indication of some failure condition in the network, such as a routing change onto a link with a smaller MTU. This is described in more detail in Section 7.7.
フルストップタイムアウト：レシーバーが再送信を含む、レシーバーによっていくつかのイベントの後に送信されたパケットが承認されないタイムアウト。これは、より小さなMTUとのリンクへのルーティングの変更など、ネットワーク内の何らかの故障条件の兆候と見なされます。これについては、セクション7.7で詳しく説明します。
All links MUST enforce their MTU: links that might non-deterministically deliver packets that are larger than their rated MTU MUST consistently discard such packets.
すべてのリンクは、MTUを実施する必要があります。定格MTUよりも大きいパケットを非決定的に配信する可能性のあるリンクは、そのようなパケットを一貫して破棄する必要があります。
In the distant past, there were a small number of network devices that did not enforce MTU, but could not reliably deliver oversized packets. For example, some early bit-wise Ethernet repeaters would forward arbitrarily sized packets, but could not do so reliably due to finite hardware data clock stability. This is the only requirement that PLPMTUD places on lower layers. It is important that this requirement be explicit to forestall the future standardization or deployment of technologies that might be incompatible with PLPMTUD.
遠い過去には、MTUを強制しなかったが、特大のパケットを確実に配信できなかった少数のネットワークデバイスがありました。たとえば、一部の初期のビットごとのイーサネットリピーターは、任意のサイズのパケットを転送しますが、有限のハードウェアデータクロックの安定性のために確実に行うことはできませんでした。これは、PLPMTUDが下層に配置する唯一の要件です。この要件は、PLPMTUDと互換性がない可能性のあるテクノロジーの将来の標準化または展開を未然に防ぐために明示的であることが重要です。
All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6 functionality. All fragmentation SHOULD be done on the host, and all IPv4 packets, including fragments, SHOULD have the DF bit set such that they will not be fragmented (again) in the network. See Section 8.
すべてのホストは、IPv6機能を模倣するモードでIPv4フラグメンテーションを使用する必要があります。すべての断片化はホストで行う必要があり、フラグメントを含むすべてのIPv4パケットは、ネットワーク内で（再び）断片化されないようにDFビットを設定する必要があります。セクション8を参照してください。
The requirements below only apply to those implementations that include PLPMTUD.
以下の要件は、PLPMTUDを含む実装にのみ適用されます。
To use PLPMTUD, a Packetization Layer MUST have a loss reporting mechanism that provides the sender with timely and accurate indications of which packets were lost in the network.
PLPMTUDを使用するには、パケット化レイヤーには、ネットワークでパケットが失われたパケットがタイムリーで正確な表示を提供する損失報告メカニズムが必要です。
Normal congestion control algorithms MUST remain in effect under all conditions except when only an isolated probe packet is detected as lost. In this case alone, the normal congestion (window or data rate) reduction SHOULD be suppressed. If any other data loss is detected, standard congestion control MUST take place.
孤立したプローブパケットのみが失われたと検出された場合を除き、通常の輻輳制御アルゴリズムは、すべての条件下で有効なままでなければなりません。この場合だけで、通常の輻輳（ウィンドウまたはデータレート）の削減を抑制する必要があります。他のデータ損失が検出された場合、標準的な輻輳制御が行われなければなりません。
Suppressed congestion control MUST be rate limited such that it occurs less frequently than the worst-case loss rate for TCP congestion control at a comparable data rate over the same path (i.e., less than the "TCP-friendly" loss rate [tcp-friendly]). This SHOULD be enforced by requiring a minimum headway between a suppressed congestion adjustment (due to a failed probe) and the next attempted probe, which is equal to one round-trip time for each packet permitted by the congestion window. This is discussed further in Section 7.6.2.
抑制された輻輳制御は、同じパスにわたる同等のデータレートでTCP輻輳制御の最悪の損失率よりも少ない頻度で発生するように、レート制限されている必要があります（つまり、「TCPフレンドリー」損失率よりも少ない[TCPフレンドリー]）。これは、抑制された輻輳調整（プローブの障害による）と次の試みのプローブとの間の最小限の前進を要求することにより強制する必要があります。これについては、セクション7.6.2でさらに説明します。
Whenever the MTU is raised, the congestion state variables MUST be rescaled so as not to raise the window size in bytes (or data rate in bytes per seconds).
MTUが上昇するたびに、バイトでウィンドウサイズを上げないように、うっ血状態の変数を再スケーリングする必要があります（または1秒あたりのバイトのデータレート）。
Whenever the MTU is reduced (e.g., when processing ICMP PTB messages), the congestion state variable SHOULD be rescaled so as not to raise the window size in packets.
MTUが削減されるたびに（たとえば、ICMP PTBメッセージを処理する場合）、パケットのウィンドウサイズを上げないように、うっ血状態の変数を再スケーリングする必要があります。
If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU and make the required congestion control adjustments.
PLPMTUDが特定のパスに対してMTUを更新する場合、パス表現を共有するすべてのパケット化レイヤーセッション（セクション5.2で説明されているように）は、新しいMTUを利用して必要な混雑制御調整を行うために通知する必要があります。
All implementations MUST include mechanisms for applications to selectively transmit packets larger than the current effective Path MTU, but smaller than the first-hop link MTU. This is necessary to implement PLPMTUD using a connectionless protocol within an application and to implement diagnostic tools that do not rely on the operating system's implementation of Path MTU Discovery. See Section 9 for further discussion.
すべての実装には、現在の実効パスMTUよりも大きいが、最初のホップリンクMTUよりも小さいパケットを選択的に送信するためのアプリケーションのメカニズムを含める必要があります。これは、アプリケーション内のConnectionless Protocolを使用してPLPMTUDを実装し、Path MTU発見のオペレーティングシステムの実装に依存しない診断ツールを実装するために必要です。詳細については、セクション9を参照してください。
Implementations MAY use different heuristics to select the initial effective Path MTU for each protocol. Connectionless protocols and protocols that do not support PLPMTUD SHOULD have their own default value for the initial effective Path MTU, which can be set to a more conservative (smaller) value than the initial value used by TCP and other protocols that are well suited to PLPMTUD. There SHOULD be per-protocol and per-route limits on the initial effective Path MTU (eff_pmtu) and the upper searching limit (search_high). See Section 7.2 for further discussion.
実装では、異なるヒューリスティックを使用して、各プロトコルの初期効果的なパスMTUを選択できます。PLPMTUDをサポートしていないコネクションレスプロトコルとプロトコルには、初期の効果的なパスMTUの独自のデフォルト値が必要です。。初期の有効パスMTU（EFF_PMTU）および上部検索制限（Search_High）には、プロトコルごとと1ルートごとの制限が必要です。詳細については、セクション7.2を参照してください。
Packetization Layer Path MTU Discovery is most easily implemented by splitting its functions between layers. The IP layer is the best place to keep shared state, collect the ICMP messages, track IP header sizes, and manage MTU information provided by the link layer interfaces. However, the procedures that PLPMTUD uses for probing and verification of the Path MTU are very tightly coupled to features of the Packetization Layers, such as data recovery and congestion control state machines.
パケット化レイヤーパスMTUディスカバリーは、レイヤー間で機能を分割することで最も簡単に実装されます。IPレイヤーは、共有状態を維持し、ICMPメッセージを収集し、IPヘッダーサイズを追跡し、リンクレイヤーインターフェイスで提供されるMTU情報を管理するのに最適な場所です。ただし、PLPMTUDがパスMTUの調査と検証に使用する手順は、データの回復や輻輳制御状態マシンなど、パケット化レイヤーの特徴と非常に密接に結びついています。
Note that this layering approach is a direct extension of the advice in the current PMTUD specifications in RFC 1191 and RFC 1981.
この階層化アプローチは、RFC 1191およびRFC 1981の現在のPMTUD仕様におけるアドバイスの直接拡張であることに注意してください。
The way in which PLPMTUD operates across multiple layers requires a mechanism for accounting header sizes at all layers between IP and the Packetization Layer (inclusive). When transmitting non-probe packets, it is sufficient for the Packetization Layer to ensure an upper bound on final IP packet size, so as not to exceed the current effective Path MTU. All Packetization Layers participating in classical Path MTU Discovery have this requirement already. When conducting a probe, the Packetization Layer MUST determine the probe packet's final size including IP headers. This requirement is specific to PLPMTUD, and satisfying it may require additional inter-layer communication in existing implementations.
PLPMTUDが複数のレイヤーで動作する方法は、IPとパケット化レイヤー（包括的）の間のすべてのレイヤーでヘッダーサイズをアカウンティングするメカニズムを必要とします。非プローブパケットを送信する場合、パケット化レイヤーが最終的なIPパケットサイズの上限を確保するだけで十分です。古典的なパスMTU発見に参加しているすべてのパケット化レイヤーには、この要件がすでにあります。プローブを実行する場合、パケット化レイヤーは、IPヘッダーを含むプローブパケットの最終サイズを決定する必要があります。この要件はPLPMTUDに固有であり、既存の実装で追加の層間通信が必要になる場合があります。
This memo uses the concept of a "flow" to define the scope of the Path MTU Discovery algorithms. For many implementations, a flow would naturally correspond to an instance of each protocol (i.e., each connection or session). In such implementations, the algorithms described in this document are performed within each session for each protocol. The observed PMTU (eff_pmtu in Section 7.1) MAY be shared between different flows with a common path representation.
このメモは、「フロー」の概念を使用して、PATH MTU Discoveryアルゴリズムの範囲を定義します。多くの実装では、フローは自然に各プロトコルのインスタンス（つまり、各接続またはセッション）に対応します。このような実装では、このドキュメントで説明されているアルゴリズムは、各プロトコルの各セッション内で実行されます。観測されたPMTU（セクション7.1のEFF_PMTU）は、共通のパス表現で異なるフロー間で共有される場合があります。
Alternatively, PLPMTUD could be implemented such that its complete state is associated with the path representations. Such an implementation could use multiple connections or sessions for each probe sequence. This approach is likely to converge much more quickly in some environments, such as where an application uses many small connections, each of which is too short to complete the Path MTU Discovery process.
あるいは、PLPMTUDを実装して、その完全な状態がパス表現に関連付けられるようにすることができます。このような実装では、各プローブシーケンスに複数の接続またはセッションを使用できます。このアプローチは、アプリケーションが多くの小さな接続を使用している場合など、一部の環境ではるかに迅速に収束する可能性が高く、それぞれがPATH MTU発見プロセスを完了するには短すぎます。
Within a single implementation, different protocols can use either of these two approaches. Due to protocol specific differences in constraints on generating probes (Section 6.2) and the MTU searching algorithm (Section 7.3), it may not be feasible for different Packetization Layer protocols to share PLPMTUD state. This suggests that it may be possible for some protocols to share probing state, but other protocols can only share observed PMTU. In this case, the different protocols will have different PMTU convergence properties.
単一の実装では、異なるプロトコルがこれら2つのアプローチのいずれかを使用できます。プローブの生成（セクション6.2）とMTU検索アルゴリズム（セクション7.3）の生成に関する制約のプロトコルの違いにより、PLPMTUD状態を共有するさまざまなパケット化レイヤープロトコルが実行できない場合があります。これは、一部のプロトコルがプロービング状態を共有することが可能であることを示唆していますが、他のプロトコルは観測されたPMTUのみを共有できます。この場合、異なるプロトコルには異なるPMTU収束特性があります。
The IP layer SHOULD be used to store the cached PMTU value and other shared state such as MTU values reported by ICMP PTB messages. Ideally, this shared state should be associated with a specific path traversed by packets exchanged between the source and destination nodes. However, in most cases a node will not have enough information to completely and accurately identify such a path. Rather, a node must associate a PMTU value with some local representation of a path. It is left to the implementation to select the local representation of a path.
IPレイヤーを使用して、キャッシュされたPMTU値と、ICMP PTBメッセージによって報告されたMTU値など、その他の共有状態を保存する必要があります。理想的には、この共有状態は、ソースノードと宛先ノード間で交換されるパケットによって通過する特定のパスに関連付けられる必要があります。ただし、ほとんどの場合、ノードにはそのようなパスを完全かつ正確に識別するのに十分な情報がありません。むしろ、ノードはPMTU値をパスのローカル表現に関連付ける必要があります。パスのローカル表現を選択するのは実装に任されています。
An implementation MAY use the destination address as the local representation of a path. The PMTU value associated with a destination would be the minimum PMTU learned across the set of all paths in use to that destination. The set of paths in use to a particular destination is expected to be small, in many cases consisting of a single path. This approach will result in the use of optimally sized packets on a per-destination basis, and integrates nicely with the conceptual model of a host as described in [RFC2461]: a PMTU value could be stored with the corresponding entry in the destination cache. Since Network Address Translators (NATs) and other forms of middle boxes may exhibit differing PMTUs simultaneously at a single IP address, the minimum value SHOULD be stored.
実装は、宛先アドレスをパスのローカル表現として使用する場合があります。宛先に関連付けられたPMTU値は、その目的地に使用されるすべてのパスのセット全体で学習した最小PMTUです。特定の目的地に使用されているパスのセットは、多くの場合、単一のパスで構成される小さいと予想されます。このアプローチにより、命令ごとに最適なサイズのパケットが使用され、[RFC2461]で説明されているホストの概念モデルとうまく統合されます。ネットワークアドレス翻訳者（NAT）およびその他の形式の中央ボックスは、単一のIPアドレスで同時に異なるPMTUを示す可能性があるため、最小値を保存する必要があります。
Network or subnet numbers MUST NOT be used as representations of a path, because there is not a general mechanism to determine the network mask at the remote host.
ネットワークまたはサブネット番号は、リモートホストでネットワークマスクを決定する一般的なメカニズムがないため、パスの表現として使用してはなりません。
For source-routed packets (i.e., packets containing an IPv6 routing header, or IPv4 Loose Source and Record Route (LSRR) or Strict Source and Record Route (SSRR) options), the source route MAY further qualify the local representation of a path. An implementation MAY use source route information in the local representation of a path.
ソースルーティングパケット（つまり、IPv6ルーティングヘッダー、またはIPv4ルーズソースおよびレコードルート（LSRR）またはStrict Source and Record Route（SSRR）オプションを含むパケット）の場合、ソースルートはパスのローカル表現をさらに適格にすることができます。実装は、パスのローカル表現でソースルート情報を使用する場合があります。
If IPv6 flows are in use, an implementation MAY use the 3-tuple of the Flow label and the source and destination addresses [RFC2460][RFC3697] as the local representation of a path. Such an approach could theoretically result in the use of optimally sized packets on a per-flow basis, providing finer granularity than MTU values maintained on a per-destination basis.
IPv6フローが使用されている場合、実装はフローラベルの3タプルを使用し、ソースおよび宛先アドレスを使用する場合があります[RFC2460] [RFC3697]。このようなアプローチは、理論的には、流量ごとに最適なサイズのパケットを使用する可能性があり、推定ごとに維持されているMTU値よりも細かい粒度を提供します。
This document does not take a stance on the placement of IP Security (IPsec) [RFC2401], which logically sits between IP and the Packetization Layer. A PLPMTUD implementation can treat IPsec either as part of IP or as part of the Packetization Layer, as long as the accounting is consistent within the implementation. If IPsec is treated as part of the IP layer, then each security association to a remote node may need to be treated as a separate path. If IPsec is treated as part of the Packetization Layer, the IPsec header size MUST be included in the Packetization Layer's header size calculations.
このドキュメントでは、IPセキュリティ（IPSEC）[RFC2401]の配置に関するスタンスはありません。これは、論理的にIPとパケット化レイヤーの間にあります。PLPMTUDの実装は、IPSECをIPの一部として、または会計が実装内で一貫している限り、パケット化レイヤーの一部として扱うことができます。IPSECがIPレイヤーの一部として扱われている場合、リモートノードへの各セキュリティアソシエーションを別のパスとして扱う必要がある場合があります。IPSECがパケット化レイヤーの一部として扱われる場合、IPSECヘッダーサイズはパケット化レイヤーのヘッダーサイズの計算に含める必要があります。
In the case of a multicast destination address, copies of a packet may traverse many different paths to reach many different nodes. The local representation of the "path" to a multicast destination must in fact represent a potentially large set of paths.
マルチキャストの宛先アドレスの場合、パケットのコピーは多くの異なるパスを通過して、多くの異なるノードに到達する場合があります。マルチキャスト宛先への「パス」のローカル表現は、実際には潜在的に大きなパスセットを表す必要があります。
Minimally, an implementation MAY maintain a single MTU value to be used for all multicast packets originated from the node. This MTU SHOULD be sufficiently small that it is expected to be less than the Path MTU of all paths comprising the multicast tree. If a Path MTU of less than the configured multicast MTU is learned via unicast means, the multicast MTU MAY be reduced to this value. This approach is likely to result in the use of smaller packets than is necessary for many paths.
最終的には、実装は、ノードから発信されたすべてのマルチキャストパケットに使用される単一のMTU値を維持する場合があります。このMTUは、マルチキャストツリーを含むすべてのパスのPATH MTUよりも少ないと予想されるほど十分に小さい必要があります。構成されたマルチキャストMTUよりも少ないパスMTUがユニキャスト平均を介して学習される場合、マルチキャストMTUはこの値に削減される場合があります。このアプローチは、多くのパスに必要なよりも小さなパケットを使用する可能性があります。
If the application using multicast gets complete delivery reports (unlikely since this requirement has poor scaling properties), PLPMTUD MAY be implemented in multicast protocols such that the smallest path MTU learned across a group becomes the effective MTU for that group.
マルチキャストを使用したアプリケーションが完全な配信レポートを取得した場合（この要件のスケーリングプロパティが低いため）、PLPMTUDがマルチキャストプロトコルに実装される可能性があるため、MTUがグループで学習した最小のパスがそのグループの有効なMTUになります。
This section describes general Packetization Layer properties and characteristics needed to implement PLPMTUD. It also describes some implementation issues that are common to all Packetization Layers.
このセクションでは、PLPMTUDを実装するために必要な一般的なパケット化層のプロパティと特性について説明します。また、すべてのパケット化レイヤーに共通するいくつかの実装の問題についても説明しています。
It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses. PLPMTUD makes MTU adjustments on the basis of detected losses. Any delays or inaccuracy in loss notification is likely to result in incorrect MTU decisions or slow convergence. It is important that the mechanism can robustly distinguish between the isolated loss of just a probe and other losses in the probe's leading and trailing windows.
パケット化層には、損失を検出および報告するためのタイムリーで堅牢なメカニズムがあることが重要です。PLPMTUDは、検出された損失に基づいてMTU調整を行います。損失通知における遅延または不正確さは、MTUの決定や収束が誤っている可能性があります。このメカニズムは、プローブの単なる損失と、プローブの主要な窓の他の損失の孤立した損失を堅牢に区別できることが重要です。
It is best if Packetization Protocols use an explicit loss detection mechanism such as a Selective Acknowledgment (SACK) scoreboard [RFC3517] or ACK Vector [RFC4340] to distinguish real losses from reordered data, although implicit mechanisms such as TCP Reno style duplicate acknowledgments counting are sufficient.
Packetization Protocolsが、選択的承認（SACK）スコアボード[RFC3517]やACKベクター[RFC4340]などの明示的な損失検出メカニズムを使用して、リアル順序データと再注文データを区別しますが、TCP RENOスタイルデプレイチング承認のカウント十分な。
PLPMTUD can also be implemented in protocols that rely on timeouts as their primary mechanism for loss recovery; however, timeouts SHOULD NOT be used as the primary mechanism for loss indication unless there are no other alternatives.
PLPMTUDは、損失回復の主要なメカニズムとしてタイムアウトに依存するプロトコルに実装することもできます。ただし、他の選択肢がない限り、タイムアウトは損失兆候の主要なメカニズムとして使用すべきではありません。
There are several possible ways to alter Packetization Layers to generate probes. The different techniques incur different overheads in three areas: difficulty in generating the probe packet (in terms of Packetization Layer implementation complexity and extra data motion), possible additional network capacity consumed by the probes, and the overhead of recovering from failed probes (both network and protocol overheads).
パケット化レイヤーを変更してプローブを生成する方法はいくつかあります。さまざまな手法では、3つの領域で異なるオーバーヘッドが発生します。プローブパケットの生成の難しさ（パケット化レイヤーの実装の複雑さと追加のデータモーションの観点から）、プローブによって消費される追加のネットワーク容量の可能性、および失敗したプローブからの回復のオーバーヘッド（両方のネットワークおよびプロトコルオーバーヘッド）。
Some protocols might be extended to allow arbitrary padding with dummy data. This greatly simplifies the implementation because the probing can be performed without participation from higher layers and if the probe fails, the missing data (the "probe gap") is ensured to fit within the current MTU when it is retransmitted. This is probably the most appropriate method for protocols that support arbitrary length options or multiplexing within the protocol itself.
一部のプロトコルは、ダミーデータを使用した任意のパディングを許可するために拡張される場合があります。これにより、高層からの参加なしにプローブを実行でき、プローブが失敗した場合、欠損データ（「プローブギャップ」）が再送信時に現在のMTU内に収まるようになるため、実装が大幅に簡素化されます。これはおそらく、プロトコル自体内で任意の長さオプションまたは多重化をサポートするプロトコルにとって最も適切な方法です。
Many Packetization Layer protocols can carry pure control messages (without any data from higher protocol layers), which can be padded to arbitrary lengths. For example, the SCTP PAD chunk can be used in this manner (see Section 10.2). This approach has the advantage that nothing needs to be retransmitted if the probe is lost.
多くのパケット化レイヤープロトコルは、純粋な制御メッセージ（より高いプロトコル層からのデータなし）を運ぶことができます。たとえば、SCTPパッドチャンクはこの方法で使用できます（セクション10.2を参照）。このアプローチには、プローブが失われた場合、何も再送信する必要はないという利点があります。
These techniques do not work for TCP, because there is not a separate length field or other mechanism to differentiate between padding and real payload data. With TCP the only approach is to send additional payload data in an over-sized segment. There are at least two variants of this approach, discussed in Section 10.1.
これらの手法は、パディングと実際のペイロードデータを区別するための個別の長さフィールドまたはその他のメカニズムがないため、TCPでは機能しません。TCPでは、唯一のアプローチは、追加のサイズのセグメントで追加のペイロードデータを送信することです。このアプローチには、セクション10.1で説明されている少なくとも2つのバリエーションがあります。
In a few cases, there may be no reasonable mechanisms to generate probes within the Packetization Layer protocol itself. As a last resort, it may be possible to rely on an adjunct protocol, such as ICMP ECHO ("ping"), to send probe packets. See Section 10.3 for further discussion of this approach.
いくつかのケースでは、パケット化レイヤープロトコル自体内でプローブを生成する合理的なメカニズムがない場合があります。最後の手段として、ICMPエコー（「Ping」）などの補助プロトコルに依存して、プローブパケットを送信することが可能かもしれません。このアプローチの詳細については、セクション10.3を参照してください。
This section describes the details of the MTU probing method, including how to send probes and process error indications necessary to search for the Path MTU.
このセクションでは、PATH MTUを検索するために必要なプローブを送信する方法やプロセスエラー表示を含むMTUプロービング方法の詳細について説明します。
This document describes the probing method using three state variables:
このドキュメントでは、3つの状態変数を使用した調査方法について説明します。
search_low: The smallest useful probe size, minus one. The network is expected to be able to deliver packets of size search_low.
search_low：最小のプローブサイズ、マイナス1。ネットワークは、Search_lowのサイズのパケットを配信できると予想されます。
search_high: The greatest useful probe size. Packets of size search_high are expected to be too large for the network to deliver.
Search_high：最大の有用なプローブサイズ。Search_highのサイズのパケットは、ネットワークが配信するには大きすぎると予想されます。
eff_pmtu: The effective PMTU for this flow. This is the largest non-probe packet permitted by PLPMTUD for the path.
EFF_PMTU：このフローに効果的なPMTU。これは、PLPMTUDがパスで許可する最大の非プローブパケットです。
search_low eff_pmtu search_high
| | |
...------------------------->
non-probe size range
<-------------------------------------->
probe size range
Figure 1
図1
When transmitting non-probes, the Packetization Layer SHOULD create packets of a size less than or equal to eff_pmtu.
非ポーチを送信する場合、パケット化レイヤーはEFF_PMTU以下のサイズのパケットを作成する必要があります。
When transmitting probes, the Packetization Layer MUST select a probe size that is larger than search_low and smaller than or equal to search_high.
プローブを送信する場合、パケット化レイヤーは、Search_lowよりも大きく、Search_high以下のプローブサイズを選択する必要があります。
When probing upward, eff_pmtu always equals search_low. In other states, such as initial conditions, after ICMP PTB message processing or following PLPMTUD on another flow sharing the same path representation, eff_pmtu may be different from search_low. Normally, eff_pmtu will be greater than or equal to search_low and less than search_high. It is generally expected but not required that probe size will be greater than eff_pmtu.
上向きに調査する場合、EFF_PMTUは常にSearch_lowに等しくなります。他の州では、初期条件など、ICMP PTBメッセージ処理後、または同じパス表現を共有する別のフローのPLPMTUDに従うことは、EFF_PMTUがSeart_Lowとは異なる場合があります。通常、EFF_PMTUはSearch_Lowよりも大きく、Search_Highよりも少なくなります。一般的に予想されますが、プローブサイズがEFF_PMTUより大きくなることは必須です。
For initial conditions when there is no information about the path, eff_pmtu may be greater than search_low. The initial value of search_low SHOULD be conservatively low, but performance may be better if eff_pmtu starts at a higher, less conservative, value. See Section 7.2.
パスに関する情報がない初期条件の場合、eff_pmtuはsearch_lowよりも大きい場合があります。search_lowの初期値は控えめに低くする必要がありますが、EFF_PMTUがより高く、保守的でない価値から始まる場合、パフォーマンスが向上する場合があります。セクション7.2を参照してください。
If eff_pmtu is larger than search_low, it is explicitly permitted to send non-probe packets larger than search_low. When such a packet is acknowledged, it is effectively an "implicit probe" and search_low SHOULD be raised to the size of the acknowledged packet. However, if an "implicit probe" is lost, it MUST NOT be treated as a probe failure as a true probe would be. If eff_pmtu is too large, this condition will only be detected with ICMP PTB messages or black hole discovery (see Section 7.7).
EFF_PMTUがSearch_Lowよりも大きい場合、Search_lowよりも大きい非プローブパケットを送信することが明示的に許可されています。このようなパケットが認められている場合、それは事実上「暗黙的なプローブ」であり、検索_lowは、認められたパケットのサイズに掲載する必要があります。ただし、「暗黙のプローブ」が失われた場合、真のプローブがそうであるように、プローブの故障として扱われてはなりません。EFF_PMTUが大きすぎる場合、この状態はICMP PTBメッセージまたはブラックホールの発見でのみ検出されます（セクション7.7を参照）。
The initial value for search_high SHOULD be the largest possible packet that might be supported by the flow. This may be limited by the local interface MTU, by an explicit protocol mechanism such as the TCP MSS option, or by an intrinsic limit such as the size of a protocol length field. In addition, the initial value for search_high MAY be limited by a configuration option to prevent probing above some maximum size. Search_high is likely to be the same as the initial Path MTU as computed by the classical Path MTU Discovery algorithm.
Search_highの初期値は、フローによってサポートされる可能性のある最大のパケットである必要があります。これは、ローカルインターフェイスMTU、TCP MSSオプションなどの明示的なプロトコルメカニズム、またはプロトコル長フィールドのサイズなどの本質的な制限によって制限される場合があります。さらに、Search_Highの初期値は、最大サイズを超えるプローブを防ぐために構成オプションによって制限される場合があります。Search_highは、古典的なパスMTU Discoveryアルゴリズムによって計算された初期パスMTUと同じである可能性があります。
It is RECOMMENDED that search_low be initially set to an MTU size that is likely to work over a very wide range of environments. Given today's technologies, a value of 1024 bytes is probably safe enough. The initial value for search_low SHOULD be configurable.
Search_lowは、最初に非常に幅広い環境で動作する可能性が高いMTUサイズに設定することをお勧めします。今日のテクノロジーを考えると、1024バイトの値はおそらく十分に安全です。search_lowの初期値は構成可能である必要があります。
Properly functioning Path MTU Discovery is critical to the robust and efficient operation of the Internet. Any major change (as described in this document) has the potential to be very disruptive if it causes any unexpected changes in protocol behaviors. The selection of the initial value for eff_pmtu determines to what extent a PLPMTUD implementation's behavior resembles classical PMTUD in cases where the classical method is sufficient.
適切に機能するパスMTU発見は、インターネットの堅牢で効率的な操作にとって重要です。（このドキュメントで説明されているように）大きな変更は、プロトコルの動作に予期しない変更を引き起こす場合、非常に破壊的になる可能性があります。EFF_PMTUの初期値の選択は、PLPMTUDの実装の動作が、古典的な方法で十分な場合の古典的なPMTUDにどの程度似ているかを決定します。
A conservative configuration would be to set eff_pmtu to search_high, and rely on ICMP PTB messages to set the eff_pmtu down as appropriate. In this configuration, classical PMTUD is fully functional and PLPMTUD is only invoked to recover from ICMP black holes through the procedure described in Section 7.7.
保守的な構成は、EFF_PMTUをSearch_Highに設定し、ICMP PTBメッセージに依存してEFF_PMTUを必要に応じて下にダウンすることです。この構成では、古典的なPMTUDは完全に機能し、PLPMTUDはセクション7.7で説明されている手順を通じてICMPブラックホールから回復するためにのみ呼び出されます。
In some cases, where it is known that classical PMTUD is likely to fail (for example, if ICMP PTB messages are administratively disabled for security reasons), using a small initial eff_pmtu will avoid the costly timeouts required for black hole detection. The trade-off is that using a smaller than necessary initial eff_pmtu might cause reduced performance.
場合によっては、古典的なPMTUDが失敗する可能性があることが知られている場合（たとえば、ICMP PTBメッセージがセキュリティ上の理由で管理上無効になっている場合）、小さな初期EFF_PMTUを使用すると、ブラックホール検出に必要な費用のかかるタイムアウトが回避されます。トレードオフは、必要よりも少ない初期eff_pmtuを使用すると、パフォーマンスが低下する可能性があるということです。
Note that the initial eff_pmtu can be any value in the range search_low to search_high. An initial eff_pmtu of 1400 bytes might be a good compromise because it would be safe for nearly all tunnels over all common networking gear, and yet close to the optimal MTU for the majority of paths in the Internet today. This might be improved by using some statistics of other recent flows: for example, the initial eff_pmtu for a flow might be set to the median of the probe size for all recent successful probes.
初期eff_pmtuは、search_low to search_highの範囲の任意の値になることができることに注意してください。1400バイトの初期eff_pmtuは、すべての一般的なネットワーキングギアのほぼすべてのトンネルにとって安全であり、今日のインターネット内の大部分のパスで最適なMTUに近いため、良い妥協点になる可能性があります。これは、他の最近のフローの統計を使用することで改善される可能性があります。たとえば、フローの初期EFF_PMTUは、最近のすべての成功したプローブのプローブサイズの中央値に設定される場合があります。
Since the cost of PLPMTUD is dominated by the protocol specific overheads of generating and processing probes, it is probably desirable for each protocol to have its own heuristics to select the initial eff_pmtu. It is especially important that connectionless protocols and other protocols that may not receive clear indications of ICMP black holes use conservative (smaller) initial values for eff_pmtu, as described in Section 10.3.
PLPMTUDのコストは、プローブの生成および処理プローブのプロトコル固有のオーバーヘッドに支配されているため、各プロトコルが初期EFF_PMTUを選択する独自のヒューリスティックを持つことがおそらく望ましいです。セクション10.3で説明されているように、ICMPブラックホールの明確な適応症を受け取らない可能性のあるConnectionless Protocolsやその他のプロトコルがEFF_PMTUの保守的な（より小さな）初期値を使用することが特に重要です。
There SHOULD be per-protocol and per-route configuration options to override initial values for eff_pmtu and other PLPMTUD state variables.
EFF_PMTUおよびその他のPLPMTUD状態変数の初期値をオーバーライドするために、プロトコルごとと1ルートごとの構成オプションが必要です。
The probe may have a size anywhere in the "probe size range" described above. However, a number of factors affect the selection of an appropriate size. A simple strategy might be to do a binary search halving the probe size range with each probe. However, for some protocols, such as TCP, failed probes are more expensive than successful ones, since data in a failed probe will need to be retransmitted. For such protocols, a strategy that raises the probe size in smaller increments might have lower overhead. For many protocols, both at and above the Packetization Layer, the benefit of increasing MTU sizes may follow a step function such that it is not advantageous to probe within certain regions at all.
プローブは、上記の「プローブサイズ範囲」のどこにでもサイズを持っている場合があります。ただし、多くの要因が適切なサイズの選択に影響します。単純な戦略は、プローブごとにプローブサイズの範囲を半分にするバイナリ検索を行うことです。ただし、TCPなどの一部のプロトコルの場合、故障したプローブのデータを再送信する必要があるため、故障したプローブは成功したプローブよりも高価です。このようなプロトコルの場合、プローブサイズをより少ない増分で上げる戦略は、架空の方が低い可能性があります。パケット化レイヤーの両方で、多くのプロトコルでは、MTUサイズを増やすことの利点は、特定の領域内でのプローブに有利ではないようにステップ関数に従う可能性があります。
As an optimization, it may be appropriate to probe at certain common or expected MTU sizes, for example, 1500 bytes for standard Ethernet, or 1500 bytes minus header sizes for tunnel protocols.
最適化として、たとえば標準イーサネットの1500バイト、またはトンネルプロトコルのヘッダーサイズを引いた1500バイトなど、特定の一般的または予想されるMTUサイズでプローブすることが適切かもしれません。
Some protocols may use other mechanisms to choose the probe sizes. For example, protocols that have certain natural data block sizes might simply assemble messages from a number of blocks until the total size is smaller than search_high, and if possible larger than search_low.
一部のプロトコルでは、他のメカニズムを使用してプローブサイズを選択できます。たとえば、特定の自然なデータブロックサイズを持つプロトコルは、合計サイズがSearch_Highよりも小さく、可能であればSearch_lowよりも大きいまで、多数のブロックからメッセージを組み立てるだけです。
Each Packetization Layer MUST determine when probing has converged, that is, when the probe size range is small enough that further probing is no longer worth its cost. When probing has converged, a timer SHOULD be set. When the timer expires, search_high should be reset to its initial value (described above) so that probing can resume. Thus, if the path changes, increasing the Path MTU, then the flow will eventually take advantage of it. The value for this timer MUST NOT be less than 5 minutes and is recommended to be 10 minutes, per RFC 1981.
各パケット化レイヤーは、プローブが収束した時期、つまりプローブサイズの範囲が十分に小さい場合、さらなるプローブがコストの価値がなくなる場合に決定する必要があります。プローブが収束した場合、タイマーを設定する必要があります。タイマーの有効期限が切れたら、検索は初期値（上記の）にリセットする必要があり、調査が再開できるようにします。したがって、パスが変化し、パスMTUが増加すると、フローは最終的にそれを利用します。このタイマーの値は5分以内ではなく、RFC 1981に従って10分にすることをお勧めします。
Before sending a probe, the flow MUST meet at least the following conditions:
プローブを送信する前に、フローは少なくとも次の条件を満たす必要があります。
o It has no outstanding probes or losses.
o 未払いのプローブや損失はありません。
o If the last probe failed or was inconclusive, then the probe timeout has expired (see Section 7.6.2).
o 最後のプローブが失敗したか、決定的でない場合、プローブのタイムアウトが期限切れになります（セクション7.6.2を参照）。
o The available window is greater than the probe size.
o 使用可能なウィンドウは、プローブサイズよりも大きいです。
o For a protocol using in-band data for probing, enough data is available to send the probe.
o 調査のためにインバンドデータを使用したプロトコルの場合、プローブを送信するのに十分なデータが利用可能です。
In addition, the timely loss detection algorithms in most protocols have pre-conditions that SHOULD be satisfied before sending a probe. For example, TCP Fast Retransmit is not robust unless there are sufficient segments following a probe; that is, the sender SHOULD have enough data queued and sufficient receiver window to send the probe plus at least Tcprexmtthresh [RFC2760] additional segments. This restriction may inhibit probing in some protocol states, such as too close to the end of a connection, or when the window is too small.
さらに、ほとんどのプロトコルのタイムリーな損失検出アルゴリズムには、プローブを送信する前に満たす必要がある事前条件があります。たとえば、TCP高速再送信は、プローブに続いて十分なセグメントがない限り、堅牢ではありません。つまり、送信者は、プローブと少なくともTCPREXMTTHRESH [RFC2760]追加セグメントを送信するのに十分なデータと十分なレシーバーウィンドウを持っている必要があります。この制限は、接続の終わりに近すぎるなど、一部のプロトコル状態やウィンドウが小さすぎる場合など、プロービングを阻害する場合があります。
Protocols MAY delay sending non-probes in order to accumulate enough data to meet the pre-conditions for probing. The delayed sending algorithm SHOULD use some self-scaling technique to appropriately limit the time that the data is delayed. For example, the returning ACKs can be used to prevent the window from falling by more than the amount of data needed for the probe.
プロトコルは、プロービングの事前条件を満たすのに十分なデータを蓄積するために、非ポーチの送信を遅らせる可能性があります。遅延送信アルゴリズムは、データが遅延する時間を適切に制限するために、いくつかのセルフスケーリング手法を使用する必要があります。たとえば、戻ってきたACKを使用して、プローブに必要なデータ量を超える量でウィンドウが落ちるのを防ぐことができます。
Once a probe size in the appropriate range has been selected, and the above preconditions have been met, the Packetization Layer MAY conduct a probe. To do so, it creates a probe packet such that its size, including the outermost IP headers, is equal to the probe size. After sending the probe it awaits a response, which will have one of the following results:
適切な範囲のプローブサイズが選択され、上記の前提条件が満たされると、パケット化層がプローブを導入する場合があります。そのためには、最も外側のIPヘッダーを含むサイズがプローブサイズに等しくなるように、プローブパケットを作成します。プローブを送信した後、それは応答を待ちます。これは、次の結果のいずれかがあります。
Success: The probe is acknowledged as having been received by the remote host.
成功：プローブは、リモートホストが受信したと認められています。
Failure: A protocol mechanism indicates that the probe was lost, but no packets in the leading or trailing window were lost.
障害：プロトコルメカニズムは、プローブが失われたことを示していますが、先頭または後続のウィンドウにパケットが失われていません。
Timeout failure: A protocol mechanism indicates that the probe was lost, and no packets in the leading window were lost, but is unable to determine whether any packets in the trailing window were lost. For example, loss is detected by a timeout, and go-back-n retransmission is used.
タイムアウトの障害：プロトコルメカニズムは、プローブが失われ、先行ウィンドウ内のパケットが失われなかったことを示しますが、トレーリングウィンドウのパケットが失われたかどうかを判断できません。たとえば、損失はタイムアウトによって検出され、Go-Back-Nの再送信が使用されます。
Inconclusive: The probe was lost in addition to other packets in the leading or trailing windows.
決定的なもの：先頭または後続のウィンドウの他のパケットに加えて、プローブは失われました。
When a probe has completed, the result SHOULD be processed as follows, categorized by the probe's result type.
プローブが完了したら、結果を次のように処理し、プローブの結果タイプによって分類する必要があります。
When the probe is delivered, it is an indication that the Path MTU is at least as large as the probe size. Set search_low to the probe size. If the probe size is larger than the eff_pmtu, raise eff_pmtu to the probe size. The probe size might be smaller than the eff_pmtu if the flow has not been using the full MTU of the path because it is subject to some other limitation, such as available data in an interactive session.
プローブが配信されると、パスMTUが少なくともプローブサイズと同じ大きさであることを示しています。Search_lowをプローブサイズに設定します。プローブサイズがEFF_PMTUよりも大きい場合は、EFF_PMTUをプローブサイズに上げます。フローがパスの完全なMTUを使用していない場合、プローブサイズはEFF_PMTUよりも小さくなる可能性があります。
Note that if a flow's packets are routed via multiple paths, or over a path with a non-deterministic MTU, delivery of a single probe packet does not indicate that all packets of that size will be delivered. To be robust in such a case, the Packetization Layer SHOULD conduct MTU verification as described in Section 7.8.
フローのパケットが複数のパスを介してルーティングされている場合、または非決定的なMTUを使用したパスを介してルーティングされている場合、単一のプローブパケットの配信は、そのサイズのすべてのパケットが配信されることを示していないことに注意してください。そのような場合に堅牢になるために、パケット化層はセクション7.8で説明されているようにMTU検証を実行する必要があります。
When only the probe is lost, it is treated as an indication that the Path MTU is smaller than the probe size. In this case alone, the loss SHOULD NOT be interpreted as congestion signal.
プローブのみが失われた場合、Path MTUがプローブサイズよりも小さいことを示す兆候として扱われます。この場合だけで、損失は輻輳信号として解釈されるべきではありません。
In the absence of other indications, set search_high to the probe size minus one. The eff_pmtu might be larger than the probe size if the flow has not been using the full MTU of the path because it is subject to some other limitation, such as available data in an interactive session. If eff_pmtu is larger than the probe size, eff_pmtu MUST be reduced to no larger than search_high, and SHOULD be reduced to search_low, as the eff_pmtu has been determined to be invalid, similar to after a full-stop timeout (see Section 7.7).
他の適応症がない場合は、検索_highをプローブサイズから1つずつ設定します。Flowがパスの完全なMTUを使用していない場合、EFF_PMTUは、インタラクティブセッションで利用可能なデータなど、他の制限の対象となるため、パスの完全なMTUを使用していない場合、プローブサイズよりも大きくなる可能性があります。EFF_PMTUがプローブサイズよりも大きい場合、EFF_PMTUはSearch_High以下に縮小する必要があり、EFF_PMTUがフルストップタイムアウト後と同様に無効であると判断されているため、Search_Lowに縮小する必要があります（セクション7.7を参照）。
If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message. Note that the ICMP message may be received either before or after the protocol loss indication.
プローブパケットに一致するICMP PTBメッセージが受信された場合、メッセージに示されているMTU値からSearch_HighおよびEFF_PMTUが設定される場合があります。ICMPメッセージは、プロトコル損失の表示の前または後に受信される場合があることに注意してください。
A probe failure event is the one situation under which the Packetization Layer SHOULD ignore loss as a congestion signal. Because there is some small risk that suppressing congestion control might have unanticipated consequences (even for one isolated loss), it is REQUIRED that probe failure events be less frequent than the normal period for losses under standard congestion control. Specifically, after a probe failure event and suppressed congestion control, PLPMTUD MUST NOT probe again until an interval that is larger than the expected interval between congestion control events. See Section 4 for details. The simplest estimate of the interval to the next congestion event is the same number of round trips as the current congestion window in packets.
プローブ障害イベントは、包装層が輻輳信号として損失を無視するような状況です。混雑制御を抑制することは、予期せぬ結果をもたらす可能性があるため（1つの孤立した損失であっても）小さなリスクがあるため、標準的な輻輳制御下での損失の通常の期間よりもプローブ障害イベントが少ないことが必要です。具体的には、プローブ障害イベントと輻輳制御を抑制した後、PLPMTUDは、混雑制御イベント間の予想間隔よりも大きい間隔が大きくなるまで再度プローブしてはなりません。詳細については、セクション4を参照してください。次の輻輳イベントの間隔の最も単純な推定は、パケットの現在の輻輳ウィンドウと同じ数の往復です。
If the loss was detected with a timeout and repaired with go-back-n retransmission, then congestion window reduction will be necessary. The relatively high price of a failed probe in this case may merit a longer time interval until the next probe. A time interval that is five times the non-timeout failure case (Section 7.6.2) is RECOMMENDED.
タイムアウトで損失が検出され、Go-Back-Nの再送信で修理された場合、輻輳ウィンドウの削減が必要になります。この場合の失敗したプローブの比較的高い価格は、次のプローブまで長い時間間隔に値する場合があります。時間間隔は、時間間隔ではありませんが、時間間隔は時間間隔ではありません（セクション7.6.2）が推奨されます。
The presence of other losses near the loss of the probe may indicate that the probe was lost due to congestion rather than due to an MTU limitation. In this case, the state variables eff_pmtu, search_low, and search_high SHOULD NOT be updated, and the same-sized probe SHOULD be attempted again as soon as the probing preconditions are met (i.e., once the packetization layer has no outstanding unrecovered losses). At this point, it is particularly appropriate to re-probe since the flow's congestion window will be at its lowest point, minimizing the probability of congestive losses.
プローブの損失に近い他の損失が存在することは、MTUの制限のためではなく、混雑のためにプローブが失われたことを示している可能性があります。この場合、状態変数EFF_PMTU、SEARCH_LOW、およびSEARCH_HIGHを更新するべきではなく、プロービングの前処理が満たされるとすぐに同じサイズのプローブを再試行する必要があります（つまり、パケット化層に未払いの未払いの損失がない場合）。この時点では、フローの混雑ウィンドウが最低点になり、うっ血性損失の可能性が最小限に抑えるため、再プローブが特に適切です。
Under all conditions, a full-stop timeout (also known as a "persistent timeout" in other documents) SHOULD be taken as an indication of some significantly disruptive event in the network, such as a router failure or a routing change to a path with a smaller MTU. For TCP, this occurs when the R1 timeout threshold described by [RFC1122] expires.
すべての条件下では、フルストップのタイムアウト（他のドキュメントでは「永続的なタイムアウト」とも呼ばれます）は、ルーターの障害やパスへのルーティングの変更など、ネットワーク内の大幅に破壊的なイベントの兆候と見なす必要があります。より小さなMTU。TCPの場合、これは[RFC1122]で記述されたR1タイムアウトのしきい値が失効したときに発生します。
If there is a full-stop timeout and there was not an ICMP message indicating a reason (PTB, Net unreachable, etc., or the ICMP message was ignored for some reason), the RECOMMENDED first recovery action is to treat this as a detected ICMP black hole as defined in [RFC2923].
フルストップのタイムアウトがあり、理由を示すICMPメッセージがなかった場合（PTB、Net Unearableなど、またはICMPメッセージが何らかの理由で無視された場合、推奨される最初の回復アクションはこれを検出されたものとして扱うことです[RFC2923]で定義されているICMPブラックホール。
The response to a detected black hole depends on the current values for search_low and eff_pmtu. If eff_pmtu is larger than search_low, set eff_pmtu to search_low. Otherwise, set both eff_pmtu and search_low to the initial value for search_low. Upon additional successive timeouts, search_low and eff_pmtu SHOULD be halved, with a lower bound of 68 bytes for IPv4 and 1280 bytes for IPv6. Even lower lower bounds MAY be permitted to support limited operation over links with MTUs that are smaller than permitted by the IP specifications.
検出されたブラックホールに対する応答は、Search_lowとEFF_PMTUの現在の値に依存します。eff_pmtuがsearch_lowよりも大きい場合、eff_pmtuをsearch_lowに設定します。それ以外の場合は、eff_pmtuとsearch_lowの両方をSearch_lowの初期値に設定します。追加のタイムアウトでは、Search_LowとEFF_PMTUを半分にし、IPv4では68バイト、IPv6で1280バイトの下限を備えています。IP仕様で許可されているよりも小さいMTUとのリンク上の制限された操作をサポートするために、下限でさえも許可される場合があります。
It is possible for a flow to simultaneously traverse multiple paths, but an implementation will only be able to keep a single path representation for the flow. If the paths have different MTUs, storing the minimum MTU of all paths in the flow's path representation will result in correct behavior. If ICMP PTB messages are delivered, then classical PMTUD will work correctly in this situation.
フローが複数のパスを同時に通過する可能性がありますが、実装はフローの単一のパス表現のみを維持することができます。パスに異なるMTUがある場合、フローのパス表現内のすべてのパスの最小MTUを保存すると、正しい動作が生じます。ICMP PTBメッセージが配信されると、この状況では古典的なPMTUDが正しく機能します。
If ICMP delivery fails, breaking classical PMTUD, the connection will rely solely on PLPMTUD. In this case, PLPMTUD may fail as well since it assumes a flow traverses a path with a single MTU. A probe with a size greater than the minimum but smaller than the maximum of the Path MTUs may be successful. However, upon raising the flow's effective PMTU, the loss rate will significantly increase. The flow may still make progress, but the resultant loss rate is likely to be unacceptable. For example, when using two-way round-robin striping, 50% of full-sized packets would be dropped.
ICMPの配信が失敗した場合、古典的なPMTUDを破ると、接続はPLPMTUDのみに依存します。この場合、PLPMTUDは、フローが単一のMTUでパスを通過すると仮定するため、同様に失敗する可能性があります。最小値よりも大きいがパスMTUの最大よりも小さいサイズのプローブが成功する可能性があります。ただし、フローの効果的なPMTUを上げると、損失率は大幅に増加します。流れは依然として進歩するかもしれませんが、結果の損失率は受け入れられない可能性があります。たとえば、双方向ラウンドロビンストライプを使用する場合、フルサイズのパケットの50％が削除されます。
Striping in this manner is often operationally undesirable for other reasons (e.g., due to packet reordering) and is usually avoided by hashing each flow to a single path. However, to increase robustness, an implementation SHOULD implement some form of MTU verification, such that if increasing eff_pmtu results in a sharp increase in loss rate, it will fall back to using a lower MTU.
この方法でのストライピングは、多くの場合、他の理由で操作的に望ましくありません（たとえば、パケットの再注文による）、通常、各フローを単一のパスにハッシュすることで回避されます。ただし、堅牢性を高めるために、実装は何らかの形のMTU検証を実装する必要があります。そのため、EFF_PMTUを増やすと損失率が急激に増加すると、より低いMTUの使用に戻ります。
A RECOMMENDED strategy would be to save the value of eff_pmtu before raising it. Then, if loss rate rises above a threshold for a period of time (e.g., loss rate is higher than 10% over multiple retransmission timeout (RTO) intervals), then the new MTU is considered incorrect. The saved value of eff_pmtu SHOULD be restored, and search_high reduced in the same manner as in a probe failure. PLPMTUD implementations SHOULD implement MTU verification.
推奨される戦略は、eff_pmtuを上げる前にeff_pmtuの価値を節約することです。次に、損失率が一定期間のしきい値を上回る場合（たとえば、複数の再送信タイムアウト（RTO）間隔で損失率が10％を超える）、新しいMTUは間違っていると見なされます。EFF_PMTUの保存された値を復元する必要があり、検索障害と同じ方法でSearch_Highが減少する必要があります。PLPMTUDの実装は、MTU検証を実装する必要があります。
Packetization Layers SHOULD avoid sending messages that will require fragmentation [Kent87] [frag-errors]. However, entirely preventing fragmentation is not always possible. Some Packetization Layers, such as a UDP application outside the kernel, may be unable to change the size of messages it sends, resulting in datagram sizes that exceed the Path MTU.
パケット化レイヤーは、フラグメンテーション[Kent87] [フラグエラー]を必要とするメッセージの送信を避ける必要があります。ただし、完全に断片化を防ぐことは常に可能ではありません。カーネルの外側のUDPアプリケーションなどの一部のパケット化レイヤーは、送信するメッセージのサイズを変更できず、Path MTUを超えるデータグラムのサイズになります。
IPv4 permitted such applications to send packets without the DF bit set. Oversized packets without the DF bit set would be fragmented in the network or sending host when they encountered a link with an MTU smaller than the packet. In some case, packets could be fragmented more than once if there were cascaded links with progressively smaller MTUs. This approach is NOT RECOMMENDED.
IPv4は、このようなアプリケーションがDFビットセットなしでパケットを送信することを許可しました。DFビットセットのない特大のパケットは、ネットワークで断片化されたり、パケットよりも小さいMTUとのリンクに遭遇したときにホストを送信します。場合によっては、徐々に小さいMTUとカスケードされたリンクがある場合、パケットを複数回断片化することができます。このアプローチは推奨されません。
It is RECOMMENDED that IPv4 implementations use a strategy that mimics IPv6 functionality. When an application sends datagrams that are larger than the effective Path MTU, they SHOULD be fragmented to the Path MTU in the host IP layer even if they are smaller than the MTU of the first link, directly attached to the host. The DF bit SHOULD be set on the fragments, so they will not be fragmented again in the network. This technique will minimize the likelihood that applications will rely on IPv4 fragmentation in a way that cannot be implemented in IPv6. At least one major operating system already uses this strategy. Section 9 describes some exceptions to this rule when the application is sending oversized packets for probing or diagnostic purposes.
IPv4実装は、IPv6機能を模倣する戦略を使用することをお勧めします。アプリケーションが効果的なパスMTUよりも大きいデータグラムを送信する場合、ホストに直接接続された最初のリンクのMTUよりも小さい場合でも、ホストIPレイヤーのパスMTUに断片化する必要があります。DFビットはフラグメントに設定する必要があるため、ネットワークで再び断片化されません。この手法は、アプリケーションがIPv6で実装できない方法でIPv4断片化に依存する可能性を最小限に抑えます。少なくとも1つの主要なオペレーティングシステムは、すでにこの戦略を使用しています。セクション9では、アプリケーションが調査または診断の目的で特大のパケットを送信している場合、このルールのいくつかの例外について説明します。
Since protocols that do not implement PLPMTUD are still subject to problems due to ICMP black holes, it may be desirable to limit to these protocols to "safe" MTUs likely to work on any path (e.g., 1280 bytes). Allow any protocol implementing PLPMTUD to operate over the full range supported by the lower layer.
PLPMTUDを実装していないプロトコルは、ICMPブラックホールによる問題の対象となるため、これらのプロトコルをどのパスで動作する可能性がある「安全な」MTUに制限することが望ましい場合があります（たとえば、1280バイト）。PLPMTUDを実装するプロトコルが、下層でサポートされている全範囲で動作するようにします。
Note that IP fragmentation divides data into packets, so it is minimally a Packetization Layer. However, it does not have a mechanism to detect lost packets, so it cannot support a native implementation of PLPMTUD. Fragmentation-based PLPMTUD requires an adjunct protocol as described in Section 10.3.
IPフラグメンテーションはデータをパケットに分割するため、最小限のパケット化レイヤーであることに注意してください。ただし、失われたパケットを検出するメカニズムはないため、PLPMTUDのネイティブ実装をサポートすることはできません。断片化ベースのPLPMTUDには、セクション10.3で説明されているように、補助プロトコルが必要です。
All implementations MUST include a mechanism where applications using connectionless protocols can send their own probes. This is necessary to implement PLPMTUD in an application protocol as described in Section 10.4 or to implement diagnostic tools for debugging problems with PMTUD. There MUST be a mechanism that permits an application to send datagrams that are larger than eff_pmtu, the operating systems estimate of the Path MTU, without being fragmented. If these are IPv4 packets, they MUST have the DF bit set.
すべての実装には、ConnectionLessプロトコルを使用したアプリケーションが独自のプローブを送信できるメカニズムを含める必要があります。これは、セクション10.4で説明されているようにアプリケーションプロトコルにPLPMTUDを実装するか、PMTUDで問題をデバッグするための診断ツールを実装するために必要です。断片化することなく、PATH MTUのオペレーティングシステム推定であるEFF_PMTUよりも大きいデータグラムを送信するアプリケーションを許可するメカニズムが必要です。これらがIPv4パケットの場合、DFビットを設定する必要があります。
At this time, most operating systems support two modes for sending datagrams: one that silently fragments packets that are too large, and another that rejects packets that are too large. Neither of these modes is suitable for implementing PLPMTUD in an application or diagnosing problems with Path MTU Discovery. A third mode is REQUIRED where the datagram is sent even if it is larger than the current estimate of the Path MTU.
現時点では、ほとんどのオペレーティングシステムは、データグラムを送信するための2つのモードをサポートしています。1つは、大きすぎるパケットを静かに断片化し、もう1つは大きすぎるパケットを拒否するものです。これらのモードはどちらも、アプリケーションにPLPMTUDを実装したり、PATH MTU発見の問題を診断したりするのに適していません。PATH MTUの現在の推定値よりも大きい場合でも、データグラムが送信される場合、3番目のモードが必要です。
Implementing PLPMTUD in an application also requires a mechanism where the application can inform the operating system about the outcome of the probe as described in Section 7.6, or directly update search_low, search_high, and eff_pmtu, described in Section 7.1.
アプリケーションでPLPMTUDを実装するには、セクション7.6で説明されているようにプローブの結果についてオペレーティングシステムに通知できるメカニズムも必要です。
Diagnostic applications are useful for finding PMTUD problems, such as those that might be caused by a defective router that returns ICMP PTB messages with incorrect size information. Such problems can be most quickly located with a tool that can send probes of any specified size, and collect and display all returned ICMP PTB messages.
診断アプリケーションは、誤ったサイズの情報を持つICMP PTBメッセージを返す欠陥のあるルーターによって引き起こされる可能性のあるPMTUD問題を見つけるのに役立ちます。このような問題は、指定されたサイズのプローブを送信し、返されたすべてのICMP PTBメッセージを収集および表示できるツールを使用して、最も迅速に配置できます。
All Packetization Layer protocols must consider all of the issues discussed in Section 6. For many protocols, it is straightforward to address these issues. This section discusses specific details for implementing PLPMTUD with a couple of protocols. It is hoped that the descriptions here will be sufficient illustration for implementers to adapt to additional protocols.
すべてのパケット化レイヤープロトコルは、セクション6で説明されているすべての問題を考慮する必要があります。多くのプロトコルについて、これらの問題に対処するのは簡単です。このセクションでは、PLPMTUDをいくつかのプロトコルで実装するための特定の詳細について説明します。ここでの説明は、実装者が追加のプロトコルに適応するのに十分な図になることが期待されています。
TCP has no mechanism to distinguish in-band data from padding. Therefore, TCP must generate probes by appropriately segmenting data. There are two approaches to segmentation: overlapping and non-overlapping.
TCPには、インバンドデータをパディングと区別するメカニズムはありません。したがって、TCPはデータを適切にセグメント化することにより、プローブを生成する必要があります。セグメンテーションには2つのアプローチがあります。オーバーラップと非重複です。
In the non-overlapping method, data is segmented such that the probe and any subsequent segments contain no overlapping data. If the probe is lost, the "probe gap" will be a full probe size minus headers. Data in the probe gap will need to be retransmitted with multiple smaller segments.
非重複方法では、データはプローブと後続のセグメントに重複するデータが含まれていないようにセグメント化されています。プローブが失われた場合、「プローブギャップ」はフルプローブサイズからヘッダーを差し引いてヘッダーになります。プローブギャップのデータは、複数の小さなセグメントで再送信する必要があります。
TCP sequence number
TCPシーケンス番号
t <---->
i <--------> (probe)
m <---->
e
.
. (probe lost)
.
<----> (probe gap retransmitted)
<-->
Figure 2
図2
An alternate approach is to send subsequent data overlapping the probe such that the probe gap is equal in length to the current MSS. In the case of a successful probe, this has added overhead in that it will send some data twice, but it will have to retransmit only one segment after a lost probe. When a probe succeeds, there will likely be some duplicate acknowledgments generated due to the duplicate data sent. It is important that these duplicate acknowledgments not trigger Fast Retransmit. As such, an implementation using this approach SHOULD limit the probe size to three times the current MSS (causing at most 2 duplicate acknowledgments), or appropriately adjust its duplicate acknowledgment threshold for data immediately after a successful probe.
別のアプローチは、プローブのギャップが現在のMSSに等しくなるように、プローブのオーバーラップの後続データを送信することです。プローブが成功した場合、これによりいくつかのデータが2回送信されるという点でオーバーヘッドが追加されましたが、失われたプローブの後に1つのセグメントのみを再送信する必要があります。プローブが成功すると、送信されたデータが重複しているため、いくつかの重複した謝辞が生成される可能性があります。これらの重複した謝辞が高速な再送信をトリガーしないことが重要です。そのため、このアプローチを使用した実装は、プローブサイズを現在のMSSの3倍（最大2つの重複謝辞を引き起こす）に制限するか、プローブが成功した直後にデータの重複した概念しきい値を適切に調整する必要があります。
TCP sequence number
TCPシーケンス番号
t <---->
i <--------> (probe)
m <---->
e <---->
. . (probe lost) .
。。（プローブの紛失）。
<----> (probe gap retransmitted)
Figure 3
図3
The choice of which segmentation method to use should be based on what is simplest and most efficient for a given TCP implementation.
使用するセグメンテーション方法の選択は、特定のTCP実装で最も単純で効率的なものに基づいている必要があります。
In the Stream Control Transmission Protocol (SCTP) [RFC2960], the application writes messages to SCTP, which divides the data into smaller "chunks" suitable for transmission through the network. Each chunk is assigned a Transmission Sequence Number (TSN). Once a TSN has been transmitted, SCTP cannot change the chunk size. SCTP multi-path support normally requires SCTP to choose a chunk size such that its messages to fit the smallest PMTU of all paths. Although not required, implementations may bundle multiple data chunks together to make larger IP packets to send on paths with a larger PMTU. Note that SCTP must independently probe the PMTU on each path to the peer.
Stream Control Transmission Protocol（SCTP）[RFC2960]では、アプリケーションはSCTPにメッセージを書き込み、データをネットワークを介した送信に適した小さな「チャンク」に分割します。各チャンクには、伝送シーケンス番号（TSN）が割り当てられます。TSNが送信されると、SCTPはチャンクサイズを変更できません。SCTPマルチパスサポートでは、通常、SCTPがすべてのパスの最小PMTUに適合するメッセージがチャンクサイズを選択する必要があります。必須ではありませんが、実装は複数のデータチャンクをまとめて、より大きなIPパケットを作成して、より大きなPMTUのパスを送信する場合があります。SCTPは、各パスでPMTUをピアへのPMTUを独立して調査する必要があることに注意してください。
The RECOMMENDED method for generating probes is to add a chunk consisting only of padding to an SCTP message. The PAD chunk defined in [RFC4820] SHOULD be attached to a minimum length HEARTBEAT (HB) chunk to build a probe packet. This method is fully compatible with all current SCTP implementations.
プローブを生成するための推奨される方法は、SCTPメッセージへのパディングのみで構成されるチャンクを追加することです。[RFC4820]で定義されたパッドチャンクは、プローブパケットを構築するために最小長さのハートビート（HB）チャンクに取り付けている必要があります。この方法は、現在のすべてのSCTP実装と完全に互換性があります。
SCTP MAY also probe with a method similar to TCP's described above, using inline data. Using such a method has the advantage that successful probes have no additional overhead; however, failed probes will require retransmission of data, which may impact flow performance.
SCTPは、インラインデータを使用して、上記のTCPと同様の方法でプローブする場合があります。このような方法を使用すると、成功したプローブには追加のオーバーヘッドがないという利点があります。ただし、障害のあるプローブには、データの再送信が必要になるため、フローパフォーマンスに影響を与える可能性があります。
There are a few protocols and applications that normally send large datagrams and rely on IP fragmentation to deliver them. It has been known for a long time that this has some undesirable consequences [Kent87]. More recently, it has come to light that IPv4 fragmentation is not sufficiently robust for general use in today's Internet. The 16-bit IP identification field is not large enough to prevent frequent mis-associated IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted data from being delivered to higher protocol layers [frag-errors].
通常、大きなデータグラムを送信し、IPフラグメンテーションに依存してそれらを提供するプロトコルとアプリケーションがいくつかあります。これには望ましくない結果があることは長い間知られています[Kent87]。最近では、IPv4の断片化が今日のインターネットで一般的に使用するために十分に堅牢ではないことが明らかになりました。16ビットIP識別フィールドは、頻繁に誤った関連のIPフラグメントを防ぐのに十分な大きさではなく、TCPおよびUDPチェックサムは、結果として生じる破損したデータがより高いプロトコル層に配信されるのを防ぐために不十分です[フラグエラー]。
As mentioned in Section 8, datagram protocols (such as UDP) might rely on IP fragmentation as a Packetization Layer. However, using IP fragmentation to implement PLPMTUD is problematic because the IP layer has no mechanism to determine whether the packets are ultimately delivered to the far node, without direct participation by the application.
セクション8で述べたように、データグラムのプロトコル（UDPなど）は、パケット化レイヤーとしてIP断片化に依存する可能性があります。ただし、IPレイヤーには、アプリケーションによる直接参加なしにパケットが最終的にFARノードに配信されるかどうかを判断するメカニズムがないため、IP断片化を使用するためにPLPMTUDを実装することは問題があります。
To support IP fragmentation as a Packetization Layer under an unmodified application, an implementation SHOULD rely on the Path MTU sharing described in Section 5.2 plus an adjunct protocol to probe the Path MTU. There are a number of protocols that might be used for the purpose, such as ICMP ECHO and ECHO REPLY, or "traceroute" style UDP datagrams that trigger ICMP messages. Use of ICMP ECHO and ECHO REPLY will probe both forward and return paths, so the sender will only be able to take advantage of the minimum of the two. Other methods that probe only the forward path are preferred if available.
変更されていないアプリケーションでのパケット化レイヤーとしてのIPフラグメンテーションをサポートするには、実装は、セクション5.2で説明されているPATH MTU共有に加えて、パスMTUをプローブする補助プロトコルに依存する必要があります。ICMPエコーやエコーの応答、またはICMPメッセージをトリガーする「Traceroute」スタイルのUDPデータグラムなど、目的に使用される可能性のあるプロトコルが多数あります。ICMPエコーとエコーの応答を使用すると、パスと戻りパスの両方をプローブするため、送信者は2つの最低値を利用できるようになります。使用可能な場合は、フォワードパスのみをプローブする他の方法が推奨されます。
All of these approaches have a number of potential robustness problems. The most likely failures are due to losses unrelated to MTU (e.g., nodes that discard some protocol types). These non-MTU-related losses can prevent PLPMTUD from raising the MTU, forcing IP fragmentation to use a smaller MTU than necessary. Since these failures are not likely to cause interoperability problems they are relatively benign.
これらのアプローチはすべて、多くの潜在的な堅牢性の問題を抱えています。最も可能性の高い障害は、MTUとは関係のない損失によるものです（たとえば、一部のプロトコルタイプを破棄するノード）。これらの非MTU関連の損失は、PLPMTUDがMTUの上昇を防ぐことができ、IP断片化により必要以上に小さなMTUを使用するように強制します。これらの障害は相互運用性の問題を引き起こす可能性が低いため、比較的良性です。
However, other more serious failure modes do exist, such as might be caused by middle boxes or upper-layer routers that choose different paths for different protocol types or sessions. In such environments, adjunct protocols may legitimately experience a different Path MTU than the primary protocol. If the adjunct protocol finds a larger MTU than the primary protocol, PLPMTUD may select an MTU that is not usable by the primary protocol. Although this is a potentially serious problem, this sort of situation is likely to be viewed as incorrect by a large number of observers, and thus there will be strong motivation to correct it.
ただし、さまざまなプロトコルタイプまたはセッションで異なるパスを選択する中央ボックスまたは上層ルーターによって引き起こされる可能性があるなど、他のより深刻な障害モードが存在します。このような環境では、補助プロトコルは、一次プロトコルとは異なるパスMTUを合法的に経験する場合があります。補助プロトコルがプライマリプロトコルよりも大きなMTUを見つけた場合、PLPMTUDはプライマリプロトコルで使用できないMTUを選択できます。これは潜在的に深刻な問題ですが、この種の状況は多数のオブザーバーによって間違っていると見なされる可能性が高いため、それを修正する強い動機があります。
Since connectionless protocols might not keep enough state to effectively diagnose MTU black holes, it would be more robust to err on the side of using too small of an initial MTU (e.g., 1 kByte or less) prior to probing a path to measure the MTU. For this reason, implementations that use IP fragmentation SHOULD use an initial eff_pmtu, which is selected as described in Section 7.2, except using a separate global control for the default initial eff_mtu for connectionless protocols.
コネクションレスプロトコルは、MTUブラックホールを効果的に診断するのに十分な状態を維持できない可能性があるため、MTUを測定するパスを調べる前に、初期のMTU（たとえば1 kbyte以下）を使用することの側面でエラーを誤解させる方が堅牢です。このため、IPフラグメンテーションを使用する実装は、コネクションレスプロトコルのデフォルトの初期EFF_MTUに別のグローバルコントロールを使用する場合を除き、セクション7.2で説明されているように選択される初期EFF_PMTUを使用する必要があります。
Connectionless protocols also introduce an additional problem with maintaining the path information cache: there are no events corresponding to connection establishment and tear-down to use to manage the cache itself. A natural approach would be to keep an immutable cache entry for the "default path", which has a eff_pmtu that is fixed at the initial value for connectionless protocols. The adjunct Path MTU Discovery protocol would be invoked once the number of fragmented datagrams to any particular destination reaches some configurable threshold (e.g., 5 datagrams). A new path cache entry would be created when the adjunct protocol updates eff_pmtu, and deleted on the basis of a timer or a Least Recently Used cache replacement algorithm.
Connectionless Protocolは、パス情報キャッシュの維持に関する追加の問題も導入します。接続の確立に対応するイベントはありません。自然なアプローチは、「デフォルトパス」の不変のキャッシュエントリを維持することです。「デフォルトパス」には、Connectionless Protocolsの初期値で修正されたEFF_PMTUがあります。特定の宛先への断片化されたデータグラムの数が構成可能なしきい値（5つのデータグラムなど）に達すると、補助パスMTU Discoveryプロトコルが呼び出されます。補助プロトコルがEFF_PMTUを更新すると、新しいパスキャッシュエントリが作成され、タイマーまたは最近使用されたキャッシュ置換アルゴリズムに基づいて削除されます。
The disadvantages of relying on IP fragmentation and an adjunct protocol to perform Path MTU Discovery can be overcome by implementing Path MTU Discovery within the application itself, using the application's own protocol. The application must have some suitable method for generating probes and have an accurate and timely mechanism to determine whether the probes were lost.
IP断片化と補助プロトコルに依存することの欠点は、PATH MTU発見を実行することで克服できます。アプリケーション自体のプロトコルを使用して、アプリケーション自体内にPATH MTU発見を実装することで克服できます。アプリケーションには、プローブを生成するための適切な方法があり、プローブが失われたかどうかを判断するための正確でタイムリーなメカニズムが必要です。
Ideally, the application protocol includes a lightweight echo function that confirms message delivery, plus a mechanism for padding the messages out to the desired probe size, such that the padding is not echoed. This combination (akin to the SCTP HB plus PAD) is RECOMMENDED because an application can separately measure the MTU of each direction on a path with asymmetrical MTUs.
理想的には、アプリケーションプロトコルには、メッセージ配信を確認する軽量エコー関数に加えて、パディングがエコーされないように、目的のプローブサイズにメッセージをパディングするメカニズムが含まれています。この組み合わせ（SCTP HB Plus Padに似ています）が推奨されます。これは、アプリケーションが非対称MTUを搭載したパス上の各方向のMTUを個別に測定できるためです。
For protocols that cannot implement PLPMTUD with "echo plus pad", there are often alternate methods for generating probes. For example, the protocol may have a variable length echo that effectively measures minimum MTU of both the forward and return path's, or there may be a way to add padding to regular messages carrying real application data. There may also be alternate ways to segment application data to generate probes, or as a last resort, it may be feasible to extend the protocol with new message types specifically to support MTU discovery.
「Echo Plus Pad」でPLPMTUDを実装できないプロトコルの場合、プローブを生成するための代替方法がしばしばあります。たとえば、プロトコルには、フォワードパスとリターンパスの両方の最小MTUを効果的に測定する可変長さエコーがある場合があります。または、実際のアプリケーションデータを運ぶ通常のメッセージにパディングを追加する方法がある場合があります。アプリケーションデータをセグメント化してプローブを生成する代替方法もある場合もあれば、最後のリゾートとして、MTU発見をサポートするために特別に新しいメッセージタイプを使用してプロトコルを拡張することも可能です。
Note that if it is necessary to add new message types to support PLPMTUD, the most general approach is to add ECHO and PAD messages, which permit the greatest possible latitude in how an application-specific implementation of PLPMTUD interacts with other applications and protocols on the same end system.
PLPMTUDをサポートするために新しいメッセージタイプを追加する必要がある場合、最も一般的なアプローチはエコーとパッドメッセージを追加することです。同じエンドシステム。
All application probing techniques require the ability to send messages that are larger than the current eff_pmtu described in Section 9.
すべてのアプリケーション調査手法では、セクション9で説明されている現在のEFF_PMTUよりも大きいメッセージを送信する機能が必要です。
Under all conditions, the PLPMTUD procedures described in this document are at least as secure as the current standard Path MTU Discovery procedures described in RFC 1191 and RFC 1981.
すべての条件下では、このドキュメントで説明されているPLPMTUD手順は、少なくともRFC 1191およびRFC 1981で説明されている現在の標準パスMTU発見手順と同じくらい安全です。
Since PLPMTUD is designed for robust operation without any ICMP or other messages from the network, it can be configured to ignore all ICMP messages, either globally or on a per-application basis. In such a configuration, it cannot be attacked unless the attacker can identify and cause probe packets to be lost. Attacking PLPMTUD reduces performance, but not as much as attacking congestion control by causing arbitrary packets to be lost. Such an attacker might do far more damage by completely disrupting specific protocols, such as DNS.
PLPMTUDは、ネットワークからのICMPまたはその他のメッセージなしで堅牢な操作用に設計されているため、グローバルまたはアプリケーションごとにすべてのICMPメッセージを無視するように構成できます。このような構成では、攻撃者がプローブパケットを識別して紛失しない限り、攻撃することはできません。PLPMTUDを攻撃するとパフォーマンスが低下しますが、任意のパケットが失われることで混雑制御を攻撃するほどではありません。このような攻撃者は、DNSなどの特定のプロトコルを完全に混乱させることにより、はるかに多くのダメージを与える可能性があります。
Since packetization protocols may share state with each other, if one packetization protocol (particularly an application) were hostile to other protocols on the same host, it could harm performance in the other protocols by reducing the effective MTU. If a packetization protocol is untrusted, it should not be allowed to write to shared state.
パケット化プロトコルは状態を互いに共有する可能性があるため、1つのパケット化プロトコル（特にアプリケーション）が同じホストの他のプロトコルに対して敵対的である場合、効果的なMTUを減らすことにより、他のプロトコルのパフォーマンスに害を及ぼす可能性があります。パケット化プロトコルが信頼されていない場合、共有状態に書き込むことを許可されるべきではありません。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、Conta、A.、Carpenter、B。、およびS. Deering、「IPv6フローラベル仕様」、RFC 3697、2004年3月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820] Tuexen、M.、Stewart、R。、およびP. Lei、「ストリーム制御伝送プロトコル（SCTP）のパディングチャンクとパラメーター」、RFC 4820、2007年3月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Tran、D.、Henderson、T.、Heidemann、J.、Touch、J.、Kruse、H.、Ostermann、S.、Scott、K。、およびJ. Semke、「衛星に関連する進行中のTCP研究」、RFC 2760、2000年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
[Kent87] Kent、C。およびJ. Mogul、「断片化は有害と考えられている」、Proc。Sigcomm '87 Vol。17、No。5、1987年10月。
[tcp-friendly] Mahdavi, J. and S. Floyd, "TCP-Friendly Unicast Rate-Based Flow Control", Technical note sent to the end2end-interest mailing list , January 1997, <http:/ /www.psc.edu/networking/papers/tcp_friendly.html>.
[TCPフレンドリー] Mahdavi、J.およびS. Floyd、「TCPフレンドリーユニキャストレートベースのフロー制御」、1997年1月、End2end-Interestメーリングリストに送信された技術ノート、<http： / /www.psc.edu/networking/papers/tcp_friendly.html>。
[frag-errors] Heffner, J., "IPv4 Reassembly Errors at High Data Rates", Work in Progress, December 2007.
[frag-errors] Heffner、J。、「高データレートでのIPv4再組み立てエラー」、2007年12月、進行中の作業。
Many ideas and even some of the text come directly from RFC 1191 and RFC 1981.
多くのアイデアやテキストの一部でさえ、RFC 1191およびRFC 1981から直接来ています。
Many people made significant contributions to this document, including: Randall Stewart for SCTP text, Michael Richardson for material from an earlier ID on tunnels that ignore DF, Stanislav Shalunov for the idea that pure PLPMTUD parallels congestion control, and Matt Zekauskas for maintaining focus during the meetings. Thanks to the early implementors: Kevin Lahey, John Heffner, and Rao Shoaib, who provided concrete feedback on weaknesses in earlier versions. Thanks also to all of the people who made constructive comments in the working group meetings and on the mailing list. We are sure we have missed many deserving people.
多くの人々がこのドキュメントに多大な貢献をしました。これには、SCTPテキストのRandall Stewart、DFを無視するトンネルの以前のIDのマイケルリチャードソン、Stanislav Shalunovが純粋なPLPMTUDが混雑制御を照合するという考え、Matt Zekauskasがフォーカスを維持するためにMatt Zekauskas会議。初期の実装者に感謝します：Kevin Lahey、John Heffner、およびRao Shoaibは、以前のバージョンの弱点について具体的なフィードバックを提供しました。ワーキンググループの会議やメーリングリストで建設的なコメントをしてくれたすべての人々にも感謝します。私たちは多くの人々にふさわしい人々を逃したと確信しています。
Matt Mathis and John Heffner are supported in this work by a grant from Cisco Systems, Inc.
Matt MathisとJohn Heffnerは、Cisco Systems、Inc。からの助成金によってこの作業でサポートされています。
Authors' Addresses
著者のアドレス
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 USA
マットマティスピッツバーグスーパーコンピューティングセンター4400フィフスアベニューピッツバーグ、ペンシルバニア州15213 USA
Phone: 412-268-3319 EMail: mathis@psc.edu
電話：412-268-3319メール：mathis@psc.edu
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ジョン・W・ヘフナー・ピッツバーグ・スーパーコンピューティング・センター4400フィフス・アベニュー・ピッツバーグ、ペンシルバニア州15213米国
Phone: 412-268-2329 EMail: jheffner@psc.edu
電話：412-268-2329メール：jheffner@psc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。