Network Working Group M. Mathis
Request for Comments: 4821 J. Heffner
Category: Standards Track PSC
March 2007
Packetization Layer Path MTU Discovery
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）IETFトラスト（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または漸進的に大きなパケットをインターネットパスを探るためにいくつかの他のパケット化レイヤに依存しているパスMTUディスカバリ（PMTUD）のための堅牢な方法を説明します。この方法は、それぞれIPバージョン4および6のためのICMPによる経路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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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のパスMTUディスカバリ（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）は動的に次第に大きなパケットでプローブすることによって経路のMTUを発見するTCP又は他のパケットのプロトコルのための方法です。これは、RFC 1191およびRFC 1981で指定されたICMPベースのパス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およびパケット境界を選択する責任があり、他のtransport-またはアプリケーションレベルのプロトコルに適用可能であり、送信側にパケットが失われたの正確でタイムリーな表示を実現し、確認応答構造を有しています。
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は、パス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を持つ複数の物理チャネルにまたがってストライピングされている場合、プローブは、それが物理チャネルの一部に対して大きすぎる場合にも配信されることも可能です。このような場合には、プローブのサイズにパス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.
パケットレイヤPMTUD（PLPMTUD）古典パスMTUディスカバリの実装にある程度の柔軟性を紹介します。古典的なパスMTUディスカバリの堅牢性を向上させるだけでICMPブラックホール・リカバリを実行するように構成することができ、または他の極端で、すべての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）メッセージが配信またはいくつかの理由[RFC2923]のために処理されていない場合、古典経路MTUディスカバリプロトコル障害（接続ハング）を受けます。 PLPMTUDでは、古典パス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はパス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の独自の実装を持っている必要があります。さらに、同時または後続の接続との間の経路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.
このドキュメントで説明する実装の詳細の大半は、パス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への移行将来の問題を最小限にするために、IPv6機能を模倣構成でIPv4の断片化を使用することをお勧めします。
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を実装するためのプログラミング・インタフェースについて説明し、ツールのパス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上に「トンネリング」されています。
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,
リンク：ノードが、リンク層で通信を行う通信設備または媒体、直ちにIP以下、すなわち、層。例としては、イーサネット（単純又は架橋）されています。 PPPリンク。 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.
フレームリレー、または非同期転送モード（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：最大伝送単位、リンクを介して一体的に搬送することができるバイト数、すなわち、最大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.
パス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ディスカバリ：ノードはパスのMTUを学ぶためにICMPパケット過大（PTB）のメッセージに依存するRFC 1191およびRFC 1981に記載のプロセス。
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.
フロー：MTUディスカバリーアルゴリズムを呼び出すことができるコンテキスト。これは、例えば、天然にパケット化プロトコルのインスタンスである、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の輻輳制御のための最悪の場合の損失率よりも起こるように制限しなければなりません]）。これは、輻輳ウィンドウによって許可各パケットに対して1つのラウンドトリップ時間に等しく、次の試みプローブ、（失敗によるプローブに）抑制輻輳調整の間の最小車間を要求することによって実施されるべきです。これは、第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が発生するたびに（秒あたりのバイト数やデータレート）バイト単位のウィンドウサイズを上げないように、輻輳状態変数は、再スケーリングされなければなりません。
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より小さいパケットを送信するアプリケーションのためのメカニズムを含まなければなりません。これは、アプリケーション内でコネクションレスのプロトコルを使用してPLPMTUDを実装するとパス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をサポートしていないコネクションレスのプロトコルおよびプロトコルはPLPMTUDによく適しているTCPおよび他のプロトコルで使用される初期値よりも保守的な（小さい）値に設定することができ、最初の効果的なパスMTU、のために独自のデフォルト値を持つべきである（SHOULD） 。最初の有効なパスMTU（eff_pmtu）と上部検索限界（search_high）上のプロトコル単位および経路の制限があるべきです。さらなる議論については、セクション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及びパケットレイヤ（含む）の間のすべての層でヘッダサイズを会計するための機構が必要となります。非プローブパケットを送信する場合、現在の有効なパスMTUを超えないように、最終的な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.
このメモはパスMTUディスカバリーアルゴリズムの範囲を定義するために、「フロー」の概念を使用しています。多くの実装のために、流れは当然、各プロトコル（すなわち、各接続又はセッション）のインスタンスに対応します。そのような実装では、本書で説明したアルゴリズムは、各プロトコルのために、各セッション内で実行されます。観察された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は、その完全な状態は、パス表現に関連付けられているように実施することができます。このような実装では、各プローブ配列のために複数の接続またはセッションを使用することができます。このアプローチは、パス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つのアプローチのいずれかを使用することができます。異なるパケット化レイヤプロトコルはPLPMTUD状態を共有するためのプローブ（セクション6.2）とMTUの検索アルゴリズム（セクション7.3）を生成するの制約で、プロトコル固有の違いに、それは実現可能ではないかもしれません。これは、いくつかのプロトコルは、状態をプロービング共有することが可能であることを示唆しているが、他のプロトコルにのみ観察された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層は、ICMP PTBメッセージによって報告されたMTU値としてキャッシュPMTU値と他の共有状態を格納するために使用されるべきです。理想的には、この共有状態は、送信元ノードと宛先ノードとの間で交換されるパケットが横断する特定のパスに関連付けられなければなりません。しかし、ほとんどの場合、ノードは、完全かつ正確にそのようなパスを識別するのに十分な情報を持っていないであろう。むしろ、ノードは経路の一部局所表現と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]に記載されているようにホストの概念モデルとうまく統合されます：PMTU値は、宛先キャッシュ内の対応するエントリに格納することができます。ネットワークは、翻訳器（NAT）と中央ボックスの他の形態は、単一のIPアドレスに同時にPMTUs異なる示し得るアドレスので、最小値が保存されるべきです。
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）または厳密なソースとレコードルート（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のフローが使用されている場合、実装は、パスのローカル表現としてフローラベルと送信元アドレスと宛先アドレス[RFC2460]、[RFC3697]の3組を使用するかもしれません。そのようなアプローチは、理論的に当たり、先に基づいて維持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パケット化層との間に座っているIPセキュリティ（IPSec）[RFC2401]、の配置上の立場を取ることはありません。 PLPMTUDの実装は限り会計は、実装内で一貫しているとして、IPの一部として、またはパケット化レイヤの一部としてIPsecを扱うことができます。 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は、マルチキャストツリーを構成する全てのパスのパス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.
パケット化プロトコルは、並べ替えられたデータから実際の損失を区別するためにそのような選択的確認応答（SACK）スコアボード[RFC3517]またはACKベクトル[RFC4340]として明示的損失検出機構を使用する場合、そのようなTCPリノスタイル重複確認応答がカウントとして暗黙的なメカニズムであるが、それは、最良であります十分。
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のPADチャンク（セクション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節で説明し、このアプローチの少なくとも二つの変種があります。
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 ECHO（「ピング」）などの補助プロトコルに依存することも可能です。このアプローチのさらなる議論については、セクション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.
このセクションでは、パス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はsearch_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より大きい非プローブパケットを送信するために許可されています。このようなパケットが確認された場合、それが効果的に「暗黙のプローブ」であるとsearch_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ディスカバリーアルゴリズムによって計算され、最初のパス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.
当初は環境の非常に広い範囲で動作する可能性があるMTUサイズに設定することsearch_lowことをお勧めします。今日の技術を考えると、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.
保守的な構成はsearch_highするeff_pmtuを設定し、必要に応じてeff_pmtuを下にICMP PTBメッセージに依存するであろう。この構成では、古典的な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_highする範囲search_low内の任意の値とすることができることに注意してください。それは、インターネットでのパスの大多数のために今日すべての一般的なネットワーク機器の上に、ほぼすべてのトンネルのための安全、および最適なMTUにまだ近くになるので1400バイトの初期eff_pmtuは良い妥協点かもしれません。これは、他の最近の流れのいくつかの統計を使用することによって改善される可能性があります。例えば、フローの初期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ブラックホールの明確な指示を受けることができないコネクションレスプロトコル及び他のプロトコルは、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状態変数の初期値を上書きするために、プロトコルごとおよびルートがあるはずです。
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.
最適化として、例えば、特定の共通のまたは予想されるMTUサイズでトンネルプロトコルの標準イーサネットの1500バイトまたは1500バイトマイナスヘッダサイズをプローブするために適切であり得ます。
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.
プロービングが収束したとき、各パケット化レイヤが決定する必要があり、それは、プローブの大きさの範囲がさらにプロービングは、そのコストに見合うもはやであることを十分に小さいとき、です。プロービングが収束した場合には、タイマーを設定する必要があります。タイマが満了するとプロービングを再開できるように、search_highは、（上述の）初期値にリセットされなければなりません。パスはパス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.
タイムアウトエラー：プロトコル機構は、プローブが失われたことを示しており、主要ウィンドウにはパケットが失われなかったが、後続のウィンドウ内の任意のパケットが失われたかどうかを決定することができません。例えば、損失はタイムアウトによって検出され、そして行くバック-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.
唯一のプローブが失われた場合には、パス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).
他の適応症が存在しない場合には、プローブサイズのマイナス1にsearch_highを設定します。それは他のいくつかの制限があるため、流れは、このような対話型セッションで利用可能なデータとして、経路の完全なMTUを使用していない場合eff_pmtuは、プローブのサイズよりも大きいかもしれません。 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メッセージがプローブパケットに一致する受信された場合、その後search_highとeff_pmtuは、メッセージに示されているMTU値から設定されるかもしれません。 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.
損失がタイムアウトで検出し、ゴーバック-nの再送で修復された場合には、輻輳ウィンドウの削減が必要になります。この場合、失敗したプローブの比較的高い価格が次のプローブまでに長い時間間隔に値することがあります。 5回非タイムアウトエラーの場合（セクション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制限に失われたことを示すことができます。この場合、状態変数は、search_low、およびsearch_highを更新しないeff_pmtu、と同じサイズのプローブは、すぐにプロービング前提条件が満たされているとして再度試みるべきである（すなわち、パケット化層は、未解決の未回収損失を持っていません一度）。フローの輻輳ウィンドウは、うっ血性損失の可能性を最小限に抑え、その最低点になりますので、この時点では、再プローブに特に適しています。
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].
フルストップのタイムアウトがあるとの理由（PTB、ネット到達不能など、またはICMPメッセージが何らかの理由で無視された）を示す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よりも大きい場合は、search_lowするeff_pmtuを設定します。それ以外の場合は、search_lowのための初期値にeff_pmtuと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だけに依存します。それは流れが単一MTUのパスを横切る前提とするので、この場合、PLPMTUDは同様に失敗する可能性があります。最小値よりも大きく、パス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.
このようにストライピングは、他の理由（例えば、原因パケットの並び替えに）のためにしばしば運用望ましくなく、通常、単一のパスに各フローをハッシュすることによって回避されます。しかし、ロバスト性を高めるために、インプリメンテーションは、損失率の急激な増加にeff_pmtu結果を増やす場合は、腰MTUを使用することに落ちるように、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の値を保存することです。損失率は、時間の期間にわたって閾値を超えて上昇する場合、新しいMTUが不正であると考えられる（例えば、損失率は、複数の再送タイムアウト（RTO）間隔にわたってより高い10％です）。 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] [FRAG-エラー]を必要としますメッセージを送信することは避けてください。しかし、完全に断片化を防止することが常に可能ではありません。そのようなカーネルの外部UDPアプリケーションなどのいくつかのパケット化層は、パス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よりも大きいデータグラムを送信するとき、彼らはホストに直接取り付けられた第1のリンクのMTUよりも小さい場合でも、ホストのIPレイヤにおけるパスMTUに断片化であるべきです。 DFビットが断片で設定する必要があり、そう、彼らはネットワークで再び断片化されることはありません。この手法は、アプリケーションがIPv6で実装することができない方法でのIPv4の断片化に依存する可能性を最小限に抑えることができます。少なくとも一つの主要なオペレーティング・システムは、既にこの戦略を使用しています。第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.
すべての実装は、コネクションレスのプロトコルを使用するアプリケーションは、独自のプローブを送ることができるメカニズムを含まなければなりません。これは、セクション10.4で説明したようにアプリケーションプロトコルでPLPMTUDを実装するか、PMTUDの問題をデバッグするための診断ツールを実装する必要があります。断片化されず、パス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.
大きすぎるパケットを拒否静かに大きすぎるパケットをフラグメント1、および他：この時点では、ほとんどのオペレーティングシステムは、データグラムを送信するための2つのモードをサポートしています。これらのモードのいずれもアプリケーションでPLPMTUDを実装またはパスMTUディスカバリの問題を診断するのに適しています。データグラムが、それは、パスMTUの現在の推定値よりも大きい場合であっても送信される第三のモードが要求されます。
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で説明したように、プローブの結果についてのオペレーティング・システムに通知する、または直接セクション7.1に記載search_low、search_high、及びeff_pmtuを更新することができる機構が必要です。
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に長さが等しくなるようにプローブを重ね後続のデータを送信することです。成功したプローブの場合、これはそれが二回いくつかのデータを送信することでオーバーヘッドを追加しましたが、それは失われたプローブの後に一つだけのセグメントを再送する必要があります。プローブが成功した場合、可能性が送られた重複データに起因して発生するいくつかの重複確認応答があるでしょう。これらの重複確認応答が高速再送信をトリガしないことが重要です。このように、このアプローチを使用して実装では三回現在のMSS（最大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.
ストリーム制御伝送プロトコル（SCTP）[RFC2960]において、アプリケーションは、ネットワークを介した伝送に適した小さい「チャンク」にデータを分割SCTP、にメッセージを書き込みます。各チャンクは、送信シーケンス番号（TSN）が割り当てられます。 TSNが送信されると、SCTPは、チャンクサイズを変更することはできません。 SCTPのマルチパスのサポートは、通常、そのメッセージは、すべてのパスの最小PMTUに合うようになるようにチャンクサイズを選択するSCTPが必要です。必須ではないが、実装はより大きなPMTUを持つ経路に送信するために、より大きなIPパケットを作るために一緒に複数のデータチャンクをバンドルすることができます。 SCTPは、独立して、ピアへの各経路に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]で定義されたPADチャンクは、プローブパケットを構築するための最小の長さハートビート（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のインラインデータを用いて、上記と同様の方法でプローブMAY。このような方法を使用して成功したプローブは追加のオーバーヘッドがないという利点を有します。しかし、失敗したプローブは、フローのパフォーマンスに影響を与える可能性があり、データの再送を必要とします。
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チェックサムは、より高いプロトコル層[FRAG-エラー]に配信さから生じる破損したデータを防止するには不十分です。
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層は、パケットが最終的にアプリケーションによって直接参加することなく、遠いノードに配信されるかどうかを決定するメカニズムを持っていないためしかし、PLPMTUDを実装するためにIPフラグメンテーションを使用する問題があります。
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断片化をサポートするために、実装は、パスMTUを調べるために、5.2節で説明したパスMTUの共有に加え、付属のプロトコルに依存すべきです。このようICMP ECHOやエコー応答、またはICMPメッセージをトリガーする「トレースルート」スタイルUDPデータグラムなどの目的のために使用されるかもしれないプロトコルの数があります。 ICMP ECHOとECHO REPLYを使用すると、前方の両方をプローブとパスを返すので、送信者は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関連の損失は、必要以上に小さいMTUを使用するようにIPフラグメンテーションを強制的に、MTUを上げからPLPMTUDを防ぐことができます。これらの障害は、相互運用性の問題を引き起こす可能性はないので、それらは比較的良性です。
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キロバイト以下）の小さすぎるを使用しての側に誤るために、より堅牢になります。この理由のため、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.
コネクションレスのプロトコルはまた、経路情報のキャッシュを維持しながら、追加の問題を紹介：キャッシュ自体を管理するために使用する接続の確立とティアダウンに対応するイベントはありません。自然なアプローチは、コネクションレス型プロトコルのための初期値に固定されてeff_pmtuを持っている「デフォルトパス」、のための不変のキャッシュエントリを維持するだろう。任意の特定の宛先への断片化したデータグラムの数は、いくつかの設定可能なしきい値（例えば5グラム）に達したら、補助パスMTUディスカバリプロトコルが呼び出されることになります。新しいパスのキャッシュエントリは、付属のプロトコルの更新が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.
パスMTUディスカバリを実行するためにIPフラグメンテーションと補助プロトコルに頼るの欠点は、アプリケーション独自のプロトコルを使用して、アプリケーション自体の中にパス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.
理想的には、アプリケーションプロトコルは、メッセージの配信を確認軽量エコー機能に加え、パディングが画面表示されないように所望のプローブサイズにメッセージをパディングするための機構を備えています。アプリケーションが別々に非対称のMTUのパス上の各方向のMTUを測定することができるので（SCTPのHBプラスPADに類似）は、この組み合わせが推奨されます。
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.
「エコープラスパッド」と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をサポートするために、新しいメッセージタイプを追加する必要がある場合、最も一般的なアプローチはPLPMTUDのアプリケーション固有の実装は上の他のアプリケーションやプロトコルとどのように相互作用するかで可能な限り最大の自由度を許容ECHOとパッドのメッセージを、追加することであることに注意してください同じエンドシステム。
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]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、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.、コンタ、A.、大工、B.、およびS.デアリング、 "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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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.、スチュワート、R.、およびP.レイ、 "パディングチャンクおよびストリーム制御伝送プロトコル（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]オールマン、M.、ドーキンス、S.、グローバー、D.、Griner、J.、トラン、D.、ヘンダーソン、T.、Heidemann、J.、タッチ、J.、クルーズ、H.、Ostermann、 S.、スコット、K.、およびJ. Semke、 "継続的なTCPの研究衛星に関連する"、RFC 2760、2000年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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.シンプソン、 "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]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、 "保守的な選択的確認応答（SACK）はTCPのために損失回復アルゴリズムをベース"、RFC 3517、2003年4月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
【Kent87]ケント、C.及びJ.モーグルは、PROC、 "断片化は、有害と考え"。 SIGCOMM '87巻。 17、第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.フロイド、「TCPフレンドリーユニキャストレートベースのフロー制御」、end2end金利メーリングリストに送られたテクニカルノート、1997年1月、<の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-エラー] Heffner、J.、 "高速データレートでのIPv4の再構築エラー"、進歩、2007年12月に作業。
Appendix A. Acknowledgments
付録A.謝辞
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.
時のフォーカスを維持するため、純粋なPLPMTUDが輻輳制御に匹敵するという考えのためにDF、スタニスラフ・シャルノブを無視し、トンネルの上に以前のIDからの材料のためのSCTPテキストのランドール・スチュワート、マイケル・リチャードソン、そしてマット・Zekauskas：多くの人々には、このドキュメントに多大な貢献をしました会議。ケビン・レイヒー、ジョンHeffner、及びラオShoaib、以前のバージョンの弱点について、具体的なフィードバックを提供する：初期の実装者に感謝します。また、ワーキンググループの会合でメーリングリスト上で建設的なコメントをした人々のすべてに感謝します。我々は、多く値する人々を見逃していることを確認しています。
Matt Mathis and John Heffner are supported in this work by a grant from Cisco Systems, Inc.
マット・マシスとジョンHeffnerは、Cisco Systems、Inc.の助成金によって、この作品ではサポートされています。
Authors' Addresses
著者のアドレス
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 USA
マット・マシスピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213 USA
Phone: 412-268-3319 EMail: mathis@psc.edu
電話：412-268-3319 Eメール：mathis@psc.edu
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
ジョン・W. Heffnerピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213米国
Phone: 412-268-2329 EMail: jheffner@psc.edu
電話：412-268-2329 Eメール：jheffner@psc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。