RFC4821 日本語訳
4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT=75665 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mathis
Request for Comments: 4821 J. Heffner
Category: Standards Track PSC
March 2007
コメントを求めるワーキンググループM.マシス要求をネットワークでつないでください: 4821年のJ.ヘフナーカテゴリ: 2007年の標準化過程PSC行進
Packetization Layer Path MTU Discovery
Packetization層の経路MTU発見
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.
このドキュメントはTCPを当てにするPath MTUディスカバリー(PMTUD)かある他のPacketization Layerがインターネット経路を次第に調べる強健な方法を説明します。より大きいパケット。 この方法はそれぞれRFC1191とRFC1981への拡大として記述されています。(RFCはIPバージョン4と6にICMPベースのPath MTUディスカバリーを指定します)。
Mathis & Heffner Standards Track [Page 1] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[1ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 6 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 9 5。 レイヤリング. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1。 ヘッダーサイズ. . . . . . . . . . . . . . . 10 5.2を説明します。 PMTU情報. . . . . . . . . . . . . . . . . 11 5.3を格納します。 IPsec. . . . . . . . . . . . . . . . . . . 12 5.4の原因になります。 マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . . 12 6。 一般的なPacketizationの特性. . . . . . . . . . . . . . . 13 6.1。 損失. . . . . . . . . . . . . . . . . 13 6.2を検出するメカニズム。 探測装置. . . . . . . . . . . . . . . . . . . . 13 7を発生させます。 調べ方法. . . . . . . . . . . . . . . . . . . . . . 14 7.1。 パケットサイズは.147.2に及びます。 初期の値. . . . . . . . . . . . . . . . . 16 7.3を選択します。 徹底的調査サイズ. . . . . . . . . . . . . . . . . . . 17 7.4を選択します。 前提条件. . . . . . . . . . . . . . . . . . 18 7.5を調べます。 徹底的調査. . . . . . . . . . . . . . . . . . . . 18 7.6を行います。 .1に結果. . . . . . . . . . . . . . . . 19 7.6を調べる応答 成功. . . . . . . . . . . . . . . . . . . . 19 7.6.2を調べてください。 失敗. . . . . . . . . . . . . . . . . . . . 19 7.6.3を調べてください。 タイムアウト失敗. . . . . . . . . . . . . . . . 20 7.6.4を調べてください。 決定的でない.207.7を調べてください。 終止符タイムアウト. . . . . . . . . . . . . . . . . . . . 20 7.8。 MTU検証. . . . . . . . . . . . . . . . . . . . . 21 8。 断片化. . . . . . . . . . . . . . . . . . . . . . 22 9を主催してください。 アプリケーションの調べ. . . . . . . . . . . . . . . . . . . . . 23 10。 特定のPacketizationは.23 10.1を層にします。 TCP. . . . . . . . . . . . . . . . . 23 10.2を使用することで方法を調べます。 SCTP. . . . . . . . . . . . . . . . 25 10.3を使用することで方法を調べます。 IP断片化. . . . . . . . . . . 26 10.4のための方法を調べます。 アプリケーション. . . . . . . . . . . . 27 11を使用することで方法を調べます。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 28 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1。 引用規格. . . . . . . . . . . . . . . . . . . 28 12.2。 有益な参照. . . . . . . . . . . . . . . . . . 29付録A.承認. . . . . . . . . . . . . . . . . . . 31
Mathis & Heffner Standards Track [Page 2] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[2ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
1. Introduction
1. 序論
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.
このドキュメントはPacketization Layer Path MTUディスカバリー(PLPMTUD)のために方法を説明します。(それは、[RFC1191]と[RFC1981]で説明された既存のPath MTUディスカバリー方法への拡大です)。 ICMPメッセージがないとき、適切なMTUは小型小包から始まることによって断固としていて相次ぎより大きいパケットで調べます。 アルゴリズムの大半がIPの上で実行されます、パケット境界を決定するのに原因となるトランスポート層(例えば、TCP)か他の「Packetizationプロトコル」で。
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.
このドキュメントはRFC1191かRFC1981をアップデートしません。 しかしながら、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
This document is a product of the Path MTU Discovery (PMTUD) working group of the IETF and draws heavily on RFC 1191 and RFC 1981 for terminology, ideas, and some of the text.
このドキュメントは、IETFのPath MTUディスカバリー(PMTUD)ワーキンググループの製品であり、テキストの用語、考え、およびいくつかに大いにRFC1191とRFC1981を利用します。
2. Overview
2. 概観
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.
Packetization Layer Path MTUディスカバリー(PLPMTUD)はTCPか他のPacketizationプロトコルが調べるのによる経路のMTUをダイナミックに次第に発見する方法です。より大きいパケット。 それは、RFC1191とRFC1981の指定されるとしてのICMPベースのPath MTUディスカバリーメカニズムに関連して使用されると最も効率的ですが、ICMPメッセージの配送によらないので、古典的なテクニックの丈夫さ問題の多くを解決します。
This method is applicable to TCP and other transport- or application- level protocols that are responsible for choosing packet boundaries (e.g., segment sizes) and have an acknowledgment structure that
この方法はパケット境界(例えば、セグメントサイズ)を選ぶのに責任があって、承認がそれを構造化するTCPと他の輸送かアプリケーションレベルプロトコルに適切です。
Mathis & Heffner Standards Track [Page 3] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[3ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
delivers to the sender accurate and timely indications of which packets were lost.
パケットが失われた送付者の正確でタイムリーな指摘に配送します。
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.
一般的な戦略が適切なPath MTUを見つけるPacketization Layerのために経路を調べることによって次第にある、 より大きいパケット。 首尾よく徹底的調査パケットを届けるなら、徹底的調査サイズに有効なPath 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 Packet Too Bigメッセージのあるなしにかかわらず)の孤立している損失は混雑インディケータではなく、MTU限界のしるしとして扱われます。 この場合、単独で、Packetizationプロトコルが混雑ウィンドウを調整しないでどんな欠測値も再送することが許可されます。
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.
タイムアウトがあるか、または追加パケットが調べの過程の間、失われているなら、徹底的調査が決定的でないと考えられます(例えば、無くなっている徹底的調査は、徹底的調査がPath MTUを超えていたのを必ず示すというわけではありません)。 その上、損失はいかなる他の混雑指示のようにも扱われます: 窓か料金の調整が関連混雑制御基準[RFC2914]単位で義務的です。 調べは検出された失敗の本質で決定する遅れの後に再開できます。
PLPMTUD uses a searching technique to find the Path MTU. Each conclusive probe narrows the MTU search range, either by raising the lower limit on a successful probe or lowering the upper limit on a failed probe, converging toward the true Path MTU. For most transport layers, the search should be stopped once the range is narrow enough that the benefit of a larger effective Path MTU is smaller than the search overhead of finding it.
PLPMTUDは、Path MTUを見つけるのに探すことのテクニックを使用します。 それぞれの決定的な徹底的調査はMTU検索範囲を狭くします、うまくいっている徹底的調査のときに下限を提起するか、または失敗した徹底的調査に上限を下ろすことによって、本当のPath MTUに向かって一点に集まって。 ほとんどのトランスポート層において、範囲がいったんより大きい有効なPath 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.
最もありそうで(最も重大でない)の徹底的調査失敗は調べている間に混雑関連の損失を経験するリンクのためです。 この場合、Packetization Layerが混雑に完全に順応して、損失から回復するとすぐに同じサイズの徹底的調査を再試行するのは適切です。 他の場合では、追加損失かタイムアウトがリンクかPacketization Layerに関する問題を示します。 これらの状況で、誤りの厳しさに依存するより長い遅れを使用するのは望ましいです。
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を上げるとパケット損失率が上げられる状況を検出するのに任意の検証の過程を使用できます。 例えば、リンクが矛盾したMTUsの複数の物理的なチャンネルの向こう側にしまをつけられるなら、何人かの物理的なチャンネルには、それが大き過ぎても探測装置を届けるのは可能です。 そのような場合、徹底的調査サイズにPath MTUを上げると、厳しいパケット損失と底知れない性能は引き起こされる場合があります。 MTUを上げた後に、損失率をモニターすることによって、新しいMTUサイズについて確かめることができます。
Mathis & Heffner Standards Track [Page 4] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[4ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
Packetization Layer PMTUD (PLPMTUD) introduces some flexibility in the implementation of classical Path MTU Discovery. It can be configured to perform just ICMP black hole recovery to increase the robustness of classical Path MTU Discovery, or at the other extreme, all ICMP processing can be disabled and PLPMTUD can completely replace classical Path MTU Discovery.
Packetization Layer PMTUD(PLPMTUD)は古典的なPath MTUディスカバリーの実現における何らかの柔軟性を導入します。 それとは正反対に、すべてのICMP処理を無効にすることができます、そして、PLPMTUDは古典的なPath MTUディスカバリーの丈夫さを増加させるようにまさしくICMPブラックホール回復を実行するのが構成できるか、または古典的なPath 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.
ある理由で[RFC2923]ICMP Packet Too Big(PTB)メッセージを送りもしませんし、処理もしないなら、古典的なPath MTUディスカバリーはプロトコル失敗(接続は掛かっている)を被りやすいです。 PLPMTUDと共に、追加チェックの偽りの失敗のため接続ハングの危険を増加させないで追加一貫性チェックを含むように古典的なPath MTUディスカバリーを変更できます。 古典的なPath 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メッセージを無視するかもしれません、そして、Path MTUを発見する唯一の方法としてPLPMTUDを使用できます。 この構成では、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を実行することにおける苦労の大部分は起こります。 一般に、それぞれのPacketizationプロトコルはそれ自身のPLPMTUDの実現を必要とします。 その上、同時発生の、または、その後の接続の間のPath MTU情報を共有する自然なメカニズムはIP層の経路情報キャッシュです。 様々なPacketizationプロトコルはIP層の中で共有されたキャッシュにアクセスして、アップデートする手段を必要とします。 完全にそれらがどう組み立てられるかを完全な実現に説明するというわけではなくて、このメモは第一のサブシステムでPLPMTUDについて説明します。
The vast majority of the implementation details described in this document are recommendations based on experiences with earlier versions of Path MTU Discovery. These recommendations are motivated by a desire to maximize robustness of PLPMTUD in the presence of less than ideal network conditions as they exist in the field.
本書では説明された実現の詳細のかなりの大部分がPath MTUディスカバリーの以前のバージョンの経験に基づく推薦です。 これらの推薦はその分野に存在するとき理想的なネットワーク状態以下の面前でPLPMTUDの丈夫さを最大にする願望によって動機づけられています。
This document does not contain a complete description of an implementation. It only sketches details that do not affect interoperability with other implementations and have strong externally imposed optimality criteria (e.g., the MTU searching and
このドキュメントは実現の完全な記述を含んでいません。 そしてそれが他の実現で相互運用性に影響して、外部的に課された強い最適評価基準を持っていない詳細についてスケッチするだけである、(例えば、MTUの探す。
Mathis & Heffner Standards Track [Page 5] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[5ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
caching heuristics). Other details are explicitly included because there is an obvious alternative implementation that doesn't work well in some (possibly subtle) case.
発見的教授法をキャッシュします) いつかの(ことによると微妙)の場合でうまくいかない明白な代替の実現があるので、他の詳細は明らかに含まれています。
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を実行する必要があった一般的なPacketization Layerについて説明します。
Section 7 describes how to use probes to search for the Path MTU.
セクション7はPath 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を実行して、Path MTUディスカバリーを妨げる経路問題を診断できるツールのためにプログラミングインターフェースについて説明します。
Section 10 discusses implementation details for specific protocols, including TCP.
セクション10はTCPを含む特定のプロトコルのための実現の詳細について論じます。
3. Terminology
3. 用語
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のすぐ下の層でどのノードの上で交信できるか。 例はEthernets(簡単であるか橋を架けられた)です。 PPPはリンクします。 X.25
Mathis & Heffner Standards Track [Page 6] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[6ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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.
Relay、またはAsynchronous Transfer Mode(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: 最大のTransmission Unit(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をリンクしてください: Maximum Transmission Unit、無事にリンクの上に伝えることができるすなわち、バイトで表現される最大の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を学ぶRFC1191とRFC1981で説明された(PTB)メッセージを処理してください。そこでは、ノードがICMP Packet Too Bigを当てにします。
Packetization Layer: The layer of the network stack that segments
data into packets.
Packetizationは層にします: ネットワークの層はそのセグメントデータをパケットに積み重ねます。
Mathis & Heffner Standards Track [Page 7] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[7ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
Effective PMTU: The current estimated value for PMTU used by a
Packetization Layer for segmentation.
有効なPMTU: 分割にPacketization Layerによって使用されたPMTUのための現在の見積価格。
PLPMTUD: Packetization Layer Path MTU Discovery, the method
described in this document, which is an extension to classical
PMTU Discovery.
PLPMTUD: Packetization Layer Path 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(パケットToo Big)メッセージ: IPパケットが進めることができないくらい大きいと報告するICMPメッセージ。 これは「必要である断片化とDFはセットした」というIPv4 ICMPメッセージに対応する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ディスカバリーアルゴリズムで文脈を呼び出すことができるか。 これは自然にそうです。Packetizationプロトコルの例、例えば、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 Maximum Segment Size[RFC0793]、TCP層に有効な最大積載量サイズ。 通常、これはIPとTCPヘッダーのサイズを引いたPath MTUです。
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.
戦略を捜してください: 発見的教授法は、適切なPath MTUに集まるように以前はセクション7.3で説明されるようによく連続した徹底的調査サイズを選んでいました。
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で説明されます。
Mathis & Heffner Standards Track [Page 8] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[8ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
4. Requirements
4. 要件
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 MUSTより大きいパケットを届けるかもしれない一貫して非決定論的にリンクがそのようなパケットを捨てます。
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.
すべてのホストSHOULDがIPv6の機能性をまねるモードでIPv4断片化を使用します。 ホスト、および断片を含むすべてのIPv4パケットですべての断片化SHOULDをして、SHOULDは、それらが(再び)ネットワークで断片化されないように、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を使用するために、Packetization Layerには、パケットがネットワークで失われたタイムリーで正確な指摘を送付者に提供する損失報告メカニズムがなければなりません。
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.
正常な輻輳制御アルゴリズムは孤立している徹底的調査パケットだけが失われているように検出される時以外のすべての状態の下で有効なままで残らなければなりません。 この場合、単独である、通常の混雑(窓かデータ信号速度)減少SHOULD、抑圧されてください。 他のデータの損失が検出されるなら、標準の輻輳制御は行われなければなりません。
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輻輳制御の最悪の場合損失率よりどんな頻繁にも起こりません。 このSHOULDが抑圧された混雑調整(失敗した徹底的調査による)と次の試みられた徹底的調査の間の最小の前進を必要とすることによって実施されて、どれが各パケットあたり往復の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が高くしているときはいつも、バイト(または、1秒あたりのバイトで表現されるデータ信号速度)で表現されるウィンドウサイズを上げないように混雑州の変数を再スケーリングしなければなりません。
Mathis & Heffner Standards Track [Page 9] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[9ページ]RFC4821Packetizationは2007年の経路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メッセージを処理するとき)ときはいつも、混雑は、可変SHOULDがパケットでウィンドウサイズを上げないように再スケーリングされると述べます。
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をアップデートするなら、SHOULDが新しいMTUの使用をするように通知されて、必要な混雑をする経路表現(セクション5.2で説明されるように)を共有するすべてのPacketization Layerセッションが調整を制御します。
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.
すべての実現がアプリケーションが選択的に現在の有効なPath MTUより大きいパケットを伝えるメカニズム、しかし、最初に、ホップより小さいリンクMTUを含まなければなりません。 これが、アプリケーションの中でコネクションレスプロトコルを使用することでPLPMTUDを実行して、オペレーティングシステムのPath MTUディスカバリーの実現に依存しない診断用道具を実行するのに必要です。 さらなる議論に関してセクション9を見てください。
Implementations MAY use different heuristics to select the initial effective Path MTU for each protocol. Connectionless protocols and protocols that do not support PLPMTUD SHOULD have their own default value for the initial effective Path MTU, which can be set to a more conservative (smaller) value than the initial value used by TCP and other protocols that are well suited to PLPMTUD. There SHOULD be per-protocol and per-route limits on the initial effective Path MTU (eff_pmtu) and the upper searching limit (search_high). See Section 7.2 for further discussion.
実現は、各プロトコルのために初期の有効なPath MTUを選択するのに異なった発見的教授法を使用するかもしれません。 PLPMTUD SHOULDを支持しないコネクションレスプロトコルとプロトコルが初期の有効なPath MTUのためのそれら自身のデフォルト値を持っています。(Path MTUはTCPによって使用された初期の値とPLPMTUDによく合っている他のプロトコルより保守的な(より小さい)値に用意ができることができます)。 そこでは、1プロトコルあたりSHOULDがそうです、そして、初期の有効なPath MTU(効率_pmtu)と上側の探すことにおける1ルートあたりの限界が(検索_高値)を制限します。 さらなる議論に関してセクション7.2を見てください。
5. Layering
5. レイヤリング
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.
Packetization Layer Path MTUディスカバリーは、層の間の機能を分けることによって、最も容易に実行されます。 IP層は共有された状態を維持して、ICMPメッセージを集めて、IPヘッダーサイズを追跡して、リンクレイヤインタフェースによって提供されたMTU情報を管理する最も良い場所です。 しかしながら、PLPMTUDがPath MTUの調べと検証に用いる手順は非常にしっかりPacketization Layersの特徴と結合されます、データ回復や輻輳制御州のマシンのように。
Note that this layering approach is a direct extension of the advice in the current PMTUD specifications in RFC 1191 and RFC 1981.
このレイヤリングアプローチがRFC1191とRFC1981の現在のPMTUD仕様に基づき、アドバイスの直接的拡張であることに注意してください。
5.1. Accounting for Header Sizes
5.1. ヘッダーサイズのための会計
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
PLPMTUDが複数の層の向こう側に作動する方法はIPとPacketization Layer(包括的な)の間のすべての層の会計ヘッダーサイズのためにメカニズムを必要とします。 非徹底的調査パケットを伝えるとき、Packetization Layerが最終的なIPパケットサイズで上限を確実にするのは、十分です、電流を超えないように
Mathis & Heffner Standards Track [Page 10] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[10ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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.
有効なPath MTU。 古典的なPath MTUディスカバリーに参加するすべてのPacketization Layersが既にこの要件を持ちます。 徹底的調査を行うとき、Packetization LayerはIPヘッダーを含む徹底的調査パケットの最終的なサイズを決定しなければなりません。 この要件はPLPMTUDに特定です、そして、それを満たすのは既存の実現における追加相互層のコミュニケーションを必要とするかもしれません。
5.2. Storing PMTU Information
5.2. PMTU情報を格納します。
This memo uses the concept of a "flow" to define the scope of the Path MTU Discovery algorithms. For many implementations, a flow would naturally correspond to an instance of each protocol (i.e., each connection or session). In such implementations, the algorithms described in this document are performed within each session for each protocol. The observed PMTU (eff_pmtu in Section 7.1) MAY be shared between different flows with a common path representation.
このメモは、Path MTUディスカバリーアルゴリズムの範囲を定義するのに「流れ」の概念を使用します。多くの実現のために、流れは自然にそれぞれのプロトコル(すなわち各接続かセッション)の例に対応しているでしょう。 そのような実現では、本書では説明されたアルゴリズムは各プロトコルのための各セッション以内に実行されます。 観測されたPMTU(セクション7.1における効率_pmtu)は異なった流れの間で共通路表現と共有されるかもしれません。
Alternatively, PLPMTUD could be implemented such that its complete state is associated with the path representations. Such an implementation could use multiple connections or sessions for each probe sequence. This approach is likely to converge much more quickly in some environments, such as where an application uses many small connections, each of which is too short to complete the Path MTU Discovery process.
あるいはまた、PLPMTUDを実行できたので、完全な状態は経路表現に関連しています。 そのような実現は各プローブ配列に複数の接続かセッションを使用するかもしれません。 このアプローチはいくつかの環境ではるかに急速に一点に集まりそうです、アプリケーションがそれのそれぞれがPath MTUディスカバリーの過程を完了できないくらい不足している多くの小さい接続を使用するところのように。
Within a single implementation, different protocols can use either of these two approaches. Due to protocol specific differences in constraints on generating probes (Section 6.2) and the MTU searching algorithm (Section 7.3), it may not be feasible for different Packetization Layer protocols to share PLPMTUD state. This suggests that it may be possible for some protocols to share probing state, but other protocols can only share observed PMTU. In this case, the different protocols will have different PMTU convergence properties.
ただ一つの実現の中では、異なったプロトコルはこれらの2つのアプローチのどちらかを使用できます。 探測装置(セクション6.2)を発生させて、MTU探すアルゴリズム(セクション7.3)で規制の種差について議定書の中で述べるのにおいて当然です、異なったPacketization LayerプロトコルがPLPMTUD状態を共有するのは、可能でないかもしれません。 これは、いくつかのプロトコルが共有されるのが、状態を調べながら可能であるかもしれませんが、他のプロトコルが観測されたPMTUを共有できるだけであるのを示します。 この場合、異なったプロトコルには、異なったPMTU集合の特性があるでしょう。
The IP layer SHOULD be used to store the cached PMTU value and other shared state such as MTU values reported by ICMP PTB messages. Ideally, this shared state should be associated with a specific path traversed by packets exchanged between the source and destination nodes. However, in most cases a node will not have enough information to completely and accurately identify such a path. Rather, a node must associate a PMTU value with some local representation of a path. It is left to the implementation to select the local representation of a path.
IPはMTUなどのキャッシュされたPMTUが評価する店に中古で他の共有された州がICMP PTBメッセージによって報告された値であったならSHOULDを層にします。 理想的に、この共有された状態はソースと目的地ノードの間で交換されたパケットによって横断される特定の経路に関連しているべきです。 しかしながら、多くの場合、ノードには、完全に正確にそのような経路を特定できるくらいの情報がないでしょう。 むしろ、ノードは経路の何らかのローカルの表現に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
実現は経路のローカルの表現として送付先アドレスを使用するかもしれません。 目的地に関連しているPMTU値はその目的地に使用中のすべての経路のセットの向こう側に学習された最小のPMTUでしょう。 aに使用中の経路のセット
Mathis & Heffner Standards Track [Page 11] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[11ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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.
多くの場合、ただ一つの経路から成って、特定の目的地が小さいと予想されます。 このアプローチは、1目的地あたり1個のベースで最適に大きさで分けられたパケットの使用をもたらして、[RFC2461]で説明されるようにうまくホストの概念モデルと統合されます: 目的地キャッシュに対応するエントリーでPMTU値を格納できました。 Network Address Translators(NATs)と他の形式の中央箱以来、同時の単一のIPのPMTUsが記述する展示品相違、最小値SHOULDが格納されますように。
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 Loose SourceとRecord Route(LSRR)かStrict SourceとRecord Route(SSRR)オプション)では、送信元経路はさらに経路のローカルの表現に資格を与えるかもしれません。 実現は経路のローカルの表現にソース経由地案内を使用するかもしれません。
If IPv6 flows are in use, an implementation MAY use the 3-tuple of the Flow label and the source and destination addresses [RFC2460][RFC3697] as the local representation of a path. Such an approach could theoretically result in the use of optimally sized packets on a per-flow basis, providing finer granularity than MTU values maintained on a per-destination basis.
IPv6流れが使用中であるなら、実現は経路のローカルの表現としてFlowラベル、ソース、および送付先アドレス[RFC2460][RFC3697]の3-tupleを使用するかもしれません。 そのようなアプローチは理論的に1流れあたり1個のベースにおける最適に大きさで分けられたパケットの使用をもたらすかもしれません、1目的地あたり1個のベースで維持されたMTU値よりすばらしい粒状を提供して。
5.3. Accounting for IPsec
5.3. IPsecのための会計
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 Security(IPsec)[RFC2401]のプレースメントのときに立場をとりません。(SecurityはIPとPacketization Layerの間に論理的に座ります)。 PLPMTUD実現はIPの一部として、または、Packetization Layerの一部としてIPsecを扱うことができます、会計が実現の中で一貫している限り。 IPsecがIP層の一部として扱われるなら、遠隔ノードへのそれぞれのセキュリティ協会は、別々の経路として扱われる必要があるかもしれません。 IPsecがPacketization Layerの一部として扱われるなら、Packetization Layerのヘッダーサイズ計算にIPsecヘッダーサイズを含まなければなりません。
5.4. Multicast
5.4. マルチキャスト
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.
マルチキャスト送付先アドレスの場合では、パケットのコピーは、多くの異なったノードに達するように多くの異なった経路を横断するかもしれません。 事実上、マルチキャストの目的地への「経路」のローカルの表現は潜在的に大きいセットの経路を表さなければなりません。
Mathis & Heffner Standards Track [Page 12] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[12ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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 SHOULD、マルチキャスト木を包括しながらすべての経路のPath MTUより少ないと予想されます。 MTUは構成されたマルチキャスト以下のPath MTUであるならユニキャスト手段で学習されます、マルチキャストMTU MAY。この値に減少します。 このアプローチは多くの経路に必要とするより小さいパケットの使用をもたらしそうです。
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 MAY、マルチキャストプロトコルでは、グループの向こう側に学習された最も小さい経路MTUがそのグループのための有効なMTUになるように、実行されてください。
6. Common Packetization Properties
6. 一般的なPacketizationの特性
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.
このセクションは一般的なPacketization Layerの特性とPLPMTUDを実行するのに必要である特性について説明します。 また、それはすべてのPacketization Layersに共通のいくつかの導入問題について説明します。
6.1. Mechanism to Detect Loss
6.1. 損失を検出するメカニズム
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.
Packetization Layerには損失を検出して、報告するためのタイムリーで強健なメカニズムがあるのは、重要です。 PLPMTUDは検出されることのベースにおけるMTU調整を損失にします。 損失通知におけるどんな遅れや不正確も不正確なMTU決定か遅い集合をもたらしそうです。 メカニズムがまさしく徹底的調査の主で引きずっている窓の徹底的調査と他の損失の孤立している損失を強壮に見分けることができるのは、重要です。
It is best if Packetization Protocols use an explicit loss detection mechanism such as a Selective Acknowledgment (SACK) scoreboard [RFC3517] or ACK Vector [RFC4340] to distinguish real losses from reordered data, although implicit mechanisms such as TCP Reno style duplicate acknowledgments counting are sufficient.
Packetizationプロトコルが再命令されたデータと本当の損失を区別するのにSelective Acknowledgment(SACK)スコアボード[RFC3517]かACK Vector[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を実行できます。 しかしながら、タイムアウトSHOULD NOT、一次機構として、損失指示には、他の代替手段が全くない場合、使用されてください。
6.2. Generating Probes
6.2. 探測装置を発生させます。
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
探測装置を発生させるようにPacketization Layersを変更するいくつかの可能な方法があります。 異なったテクニックは3つの領域における異なったオーバーヘッドを被ります: 徹底的調査パケットを発生させることにおける苦労、(Packetization Layer実現の複雑さと余分なデータ
Mathis & Heffner Standards Track [Page 13] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[13ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
motion), possible additional network capacity consumed by the probes, and the overhead of recovering from failed probes (both network and protocol overheads).
動き) 追加ネットワーク容量が徹底的調査、および失敗した徹底的調査から回復するオーバーヘッドを消費したのが(両方が、オーバーヘッドについてネットワークでつないで、議定書の中で述べます)可能です。
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.
多くのPacketization Layerプロトコルが純粋なコントロールメッセージ(より高いプロトコル層からの少しもデータのない)を伝えることができます。(任意の長さにメッセージを水増しできます)。 例えば、この様に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で議論したこのアプローチの少なくとも2つの異形があります。
In a few cases, there may be no reasonable mechanisms to generate
probes within the Packetization Layer protocol itself. As a last
resort, it may be possible to rely on an adjunct protocol, such as
ICMP ECHO ("ping"), to send probe packets. See Section 10.3 for
further discussion of this approach.
いくつかの場合には、Packetization Layerプロトコル自体の中で探測装置を発生させるどんな妥当なメカニズムもないかもしれません。 最後の手段として、付属物プロトコルを当てにするのは可能であるかもしれません、徹底的調査パケットを送るためにICMP ECHOなどのように(「確認してください」)。 このアプローチのさらなる議論に関してセクション10.3を見てください。
7. The Probing Method
7. 調べ方法
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調べ方法の詳細について説明します、Path MTUを捜し求めるのに必要な指摘を徹底的調査と過程誤りに送る方法を含んでいて。
7.1. Packet Size Ranges
7.1. パケットサイズは及びます。
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.
_低く探してください: 1を引いた最も小さい役に立つ徹底的調査サイズ。 ネットワークが低くサイズ検索_のパケットを届けることができると予想されます。
search_high: The greatest useful probe size. Packets of size
search_high are expected to be too large for the network to
deliver.
_高く探してください: 最大級の役に立つ徹底的調査サイズ。 サイズ検索_高値のパケットがネットワークが渡すことができないくらい大きいと予想されます。
Mathis & Heffner Standards Track [Page 14] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[14ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
eff_pmtu: The effective PMTU for this flow. This is the largest
non-probe packet permitted by PLPMTUD for the path.
_効率pmtu: これのための有効なPMTUは流れます。 これはPLPMTUDによって経路に可能にされた中で最も大きい非徹底的調査パケットです。
search_low eff_pmtu search_high
| | |
...------------------------->
_低い効率_pmtu検索_を高く捜してください。| | | ...------------------------->。
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.
非探測装置を送るとき、Packetization Layer SHOULDはaサイズより効率_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.
探測装置を送るとき、Packetization Layerは検索_安値と検索より_より高く大きい徹底的調査サイズを選択しなければなりません。
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.
上向きに調べるとき、効率_pmtuはいつも低く検索_と等しいです。 初期条件などの他の州では、別のもののICMP PTBメッセージ処理か次のPLPMTUDが同じ経路表現を共有しながら流れた後に効率_pmtuが検索_と低く異なっているかもしれません。 通常、効率_pmtuは検索より_安値と以下を_高く捜すためにことになるでしょう。 一般に予想されますが、徹底的調査サイズが効率_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.
経路の情報が全くないとき、初期条件に、効率_pmtuは_低く探すよりすばらしいかもしれません。 _検索の低いSHOULDの初期の値は保守的にそうです。低く、効率_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).
効率_pmtuが検索_より低く大きいなら、低く検索_より大きい非徹底的調査パケットを送ることが明らかに許可されます。 そのようなパケットによる承認されていて、事実上、それが「暗黙の徹底的調査」であり、検索_が低いSHOULDであるということであるときには、承認されたパケットのサイズに上げられてください。 しかしながら、本当の徹底的調査は徹底的調査失敗として扱われないでしょうが、「暗黙の徹底的調査」が無くなるなら、それは無くならなければなりません。 効率_pmtuが大き過ぎるなら、この状態はICMP PTBメッセージかブラックホール発見で検出されるだけでしょう(セクション7.7を見てください)。
Mathis & Heffner Standards Track [Page 15] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[15ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
7.2. Selecting Initial Values
7.2. 初期の値を選択します。
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.
初期の値、_検索の高いSHOULDのために、流れによって支持されるかもしれない可能な限り大きいパケットはそうです。 これは局所界面MTU、TCP MSSオプションなどの明白なプロトコルメカニズム、またはプロトコル長さの分野のサイズなどの本質的な限界で制限されるかもしれません。 さらに、検索_高値のための初期の値は、何らかの最大サイズより上で調べるのを防ぐために設定オプションで制限されるかもしれません。 検索_高値は古典的なPath MTUディスカバリーアルゴリズムによって計算される初期のPath 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サイズに設定されるのは、RECOMMENDEDです。 今日の技術を考えて、1024バイトの値はたぶん十分安全です。 初期は検索のために_低いSHOULDを評価します。構成可能であってください。
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.
適切に機能しているPath MTUディスカバリーはインターネットの強健で効率的な操作に重要です。 どんな大きな変化(本書では説明されるように)にも、何かプロトコルの振舞いにおける意外な変化を引き起こすなら、非常に破壊的になる可能性があります。 効率_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.
保存している構成は効率_pmtuに_を高く捜して、適宜_効率pmtuを置くICMP PTBメッセージを当てにするように設定するだろうことです。 この構成では、古典的なPMTUDは完全に機能的です、そして、PLPMTUDは、ICMPブラックホールからセクション7.7で説明された手順で回復するために呼び出されるだけです。
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メッセージが例えば行政上安全保障上の理由で無効にされるなら)知られているところで小さい初期の効率_pmtuを使用すると、ブラックホール検出に必要である高価なタイムアウトは避けられるでしょう。 トレードオフは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.
_高く探すために初期の効率_pmtuが範囲検索_安値であらゆる値であるかもしれないことに注意してください。 それは今日ほとんどすべての一般的なネットワーク機器の上のすべてのトンネルにもかかわらず、インターネットの経路の大部分の最適のMTUの近くで安全でしょう、したがって、1400バイトの初期の効率_pmtuは良い妥協であるかもしれません。 これは他の最近の流れのいくつかの統計を使用することによって、改良されるかもしれません: 例えば、流れのための初期の効率_pmtuはすべての最近のうまくいっている徹底的調査のための徹底的調査サイズのメディアンに用意ができるかもしれません。
Mathis & Heffner Standards Track [Page 16] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[16ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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の費用が探測装置を発生して、処理するプロトコルの特定のオーバーヘッドによって支配されるので、各プロトコルには初期の効率_pmtuを選択するそれ自身の発見的教授法があるのは、たぶん望ましいです。 ICMPブラックホールの明確なしるしを受けないかもしれないコネクションレスプロトコルと他のプロトコルが効率_pmtuに保守的な(より小さい)初期の値を使用するのは、特に重要です、セクション10.3で説明されるように。
There SHOULD be per-protocol and per-route configuration options to override initial values for eff_pmtu and other PLPMTUD state variables.
そこでは、1プロトコルあたりSHOULDがそうです、そして、くつがえす1ルートあたりの設定オプションが効率_pmtuと他のPLPMTUD州の変数のために値に頭文字をつけます。
7.3. Selecting Probe Size
7.3. 徹底的調査サイズを選択します。
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などのいくつかのプロトコルにおいて、失敗した徹底的調査はうまくいっているものより高価です、失敗した徹底的調査におけるデータが、再送される必要があるので。 そのようなプロトコルのために、よりわずかな増分における徹底的調査サイズを上げる戦略は低いオーバーヘッドを持っているかもしれません。 Packetization Layerと多くのプロトコルと、Packetization Layerの上では、増加するMTUサイズの利益が階段関数に続くかもしれないので、全く一定の地域の中で調べるのは有利ではありません。
As an optimization, it may be appropriate to probe at certain common or expected MTU sizes, for example, 1500 bytes for standard Ethernet, or 1500 bytes minus header sizes for tunnel protocols.
最適化として、例えば、トンネルプロトコルのためのヘッダーサイズを引いて標準のイーサネット、または1500バイトのためにある一般的であるか予想されたMTUサイズで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.
いくつかのプロトコルが、徹底的調査サイズを選ぶのに他のメカニズムを使用するかもしれません。 例えば、ある自然なデータブロック・サイズを持っているプロトコルは単に多くの総サイズが検索_より高く小さくなるまでのブロック、およびできれば検索より大きい_安値からのメッセージを組み立てるかもしれません。
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.
各Packetization Layerは、調べがいつ一点に集まったかを決定しなければなりません、すなわち、徹底的調査サイズ範囲が一層の調べがもう費用の価値がないほど小さいときに。 いつ、調べが一点に集められたaタイマSHOULDをあるかはセットしました。 タイマが期限が切れるとき、検索_高値は、調べが再開できるように、初期の値(上で、説明される)にリセットされるべきです。 したがって、Path MTUを増加させて、経路が変化すると、流れは結局、それを利用するでしょう。 このタイマのための値は、5分未満であってはいけなく、10分であることが推薦されます、RFC1981単位で。
Mathis & Heffner Standards Track [Page 17] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[17ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
7.4. Probing Preconditions
7.4. 前提条件を調べます。
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.
さらに、ほとんどのプロトコルのタイムリーな損失検出アルゴリズムには、探測装置を送る前にSHOULDが満足しているというプレ条件があります。 例えば、探測装置に続いて、十分なセグメントがない場合、TCP Fast Retransmitは強健ではありません。 すなわち、送付者SHOULDには、探測装置を送ることができるくらいのデータの列に並ばせられて十分な受信機ウィンドウと少なくとも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.
プロトコルは、調べるための前提条件を満たすことができるくらいのデータを蓄積するために非探測装置を送るのを遅らせるかもしれません。 遅れた送付アルゴリズムSHOULDはデータが遅れる時に適切に制限する何らかの自己尺度構成法を使用します。 例えば、窓が徹底的調査に必要であるデータ量以上で落ちるのを防ぐのに戻っているACKsを使用できます。
7.5. Conducting a Probe
7.5. 徹底的調査を行います。
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:
いったん適切な範囲の徹底的調査サイズが選択されて、上の前提条件が満たされると、Packetization Layerは徹底的調査を行うかもしれません。 一番はずれのIPヘッダーを含むサイズが徹底的調査サイズと等しいように徹底的調査パケットを作成して、するために。 探測装置を送った後に、応答を待ちます:(応答には、以下の結果の1つがあるでしょう)。
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.
失敗: プロトコルメカニズムは、徹底的調査が失われましたが、主であるか引きずっている窓のパケットは全く失われなかったのを示します。
Mathis & Heffner Standards Track [Page 18] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[18ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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.
決定的ではありません: 徹底的調査は主であるか引きずっている窓の他のパケットに加えて失われました。
7.6. Response to Probe Results
7.6. 調べる応答は結果として生じます。
When a probe has completed, the result SHOULD be processed as follows, categorized by the probe's result type.
完成していて、結果SHOULDが以下の通り処理されて、分類されて、徹底的調査がタイプしたときには徹底的調査の結果でタイプしてください。
7.6.1. Probe Success
7.6.1. 成功を調べてください。
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.
探測装置を届けるとき、それはPath MTUが徹底的調査サイズと少なくとも同じくらい大きいという指示です。 低く徹底的調査サイズに検索_を設定してください。 徹底的調査サイズが_効率pmtuより大きいなら、効率_pmtuを徹底的調査サイズに上げてください。 それはある他の制限を受けることがあるので流れが経路の完全なMTUを使用していないなら、徹底的調査サイズは_効率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がある経路の上に発送されるなら、単一の徹底的調査パケットの配送が、そのサイズのすべてのパケットが届けられるのを示さないことに注意してください。 このような場合には強健に、なるように、Packetization Layer SHOULDはセクション7.8で説明されるようにMTU検証を行います。
7.6.2. Probe Failure
7.6.2. 失敗を調べてください。
When only the probe is lost, it is treated as an indication that the Path MTU is smaller than the probe size. In this case alone, the loss SHOULD NOT be interpreted as congestion signal.
徹底的調査だけが無くなるとき、それはPath MTUが徹底的調査サイズより小さいという指示として扱われます。 この場合、単独である、損失SHOULD NOT、混雑信号として、解釈されてください。
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を引いて高く徹底的調査サイズに検索_を設定してください。 それはある他の制限を受けることがあるので流れが経路の完全なMTUを使用していないなら、効率_pmtuは徹底的調査サイズより大きいかもしれません、対話的なセッションにおける利用可能なデータなどのように。 効率_pmtuが徹底的調査サイズ、効率_pmtuでなければならないより検索_より大きい高値、およびどんなSHOULDにも変えられなかった状態で大きいなら、_低く探すために減少してください、効率_pmtuが無効であると決心しているとき、終止符タイムアウトの後に同様です(セクション7.7を見てください)。
Mathis & Heffner Standards Track [Page 19] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[19ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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メッセージが徹底的調査パケットを合わせるのにおいて受信されているなら、_高く探してください。そうすれば、効率_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.
徹底的調査失敗出来事はPacketization Layer SHOULDが混雑信号として損失を無視する1つの状況です。 輻輳制御を抑圧するのにおいて思いがけない結果(個人的には、損失を隔離さえする)があるかもしれないという何らかの低いリスクがあるので、徹底的調査失敗出来事が正常な期間ほど標準の輻輳制御の下における損失で頻繁でないことは、REQUIREDです。 明確に、徹底的調査失敗出来事と抑圧された混雑が制御された後にPLPMTUD MUST NOTは再び混雑コントロールイベントの予想された間隔より大きい間隔まで調べます。 詳細に関してセクション4を見てください。 次の混雑出来事への間隔の最も簡単な見積りはパケットの現在の混雑ウィンドウと同じ数の周遊旅行です。
7.6.3. Probe Timeout Failure
7.6.3. タイムアウト失敗を調べてください。
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を支持しに行っている「再-トランスミッション」で修理されたなら、混雑窓の減少は必要になるでしょう。 この場合、失敗した徹底的調査の比較的高い価格は次の徹底的調査まで、より長い時間間隔に値するかもしれません。 非タイムアウト失敗事件(セクション7.6.2)の5倍である時間間隔はRECOMMENDEDです。
7.6.4. Probe Inconclusive
7.6.4. 徹底的調査決定的ではありません。
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制限のためというよりむしろ混雑のため失われたのを示すかもしれません。 この場合、調べ前提条件が満たされると(すなわち、packetization層にどんな傑出している非回復している損失もいったんないと)すぐに、再び試みられて、州の変数効率_はアップデートされて、同じサイズの徹底的調査がSHOULDであったならpmtuして、低く_を捜して、_高いSHOULD NOTを捜します。 流れの混雑ウィンドウが最も低いポイントにあるので、ここに再調べるのは特に適切です、充血性の損失の確率を最小にして。
7.7. Full-Stop Timeout
7.7. 終止符タイムアウト
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.
すべての状態、終止符タイムアウト、(また、他のドキュメント) SHOULDの「しつこいタイムアウト」として知られていて、ネットワークのいくつかのかなり破壊的な出来事のしるしとして取ってください、より小さいMTUがある経路へのルータ失敗やルーティング変化のように。 TCPに関しては、[RFC1122]によって説明されたR1タイムアウト敷居が期限が切れると、これは起こります。
Mathis & Heffner Standards Track [Page 20] RFC 4821 Packetization Layer Path MTU Discovery March 2007
マシスとヘフナー標準化過程[20ページ]RFC4821Packetizationは2007年の経路MTU発見行進のときに層にします。
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].
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].
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.
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.
7.8. MTU Verification
7.8. MTU Verification
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.
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.
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.
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.
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.
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.
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
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
Mathis & Heffner Standards Track [Page 21] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 21] RFC 4821 Packetization Layer Path MTU Discovery March 2007
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.
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.
8. Host Fragmentation
8. Host Fragmentation
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Mathis & Heffner Standards Track [Page 22] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 22] RFC 4821 Packetization Layer Path MTU Discovery March 2007
9. Application Probing
9. Application Probing
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.
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.
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.
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.
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.
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.
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.
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.
10. Specific Packetization Layers
10. Specific Packetization Layers
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.
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.
10.1. Probing Method Using TCP
10.1. Probing Method Using TCP
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 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.
Mathis & Heffner Standards Track [Page 23] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 23] RFC 4821 Packetization Layer Path MTU Discovery March 2007
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.
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 sequence number
t <---->
t <---->
i <--------> (probe)
m <---->
e
.
. (probe lost)
.
i <--------> (probe) m <----> e . . (probe lost) .
<----> (probe gap retransmitted)
<-->
<----> (probe gap retransmitted) <-->
Figure 2
Figure 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.
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.
Mathis & Heffner Standards Track [Page 24] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 24] RFC 4821 Packetization Layer Path MTU Discovery March 2007
TCP sequence number
TCP sequence number
t <---->
i <--------> (probe)
m <---->
t <----> i <--------> (probe) m <---->
e <---->
e <---->
.
. (probe lost)
.
. . (probe lost) .
<----> (probe gap retransmitted)
<----> (probe gap retransmitted)
Figure 3
Figure 3
The choice of which segmentation method to use should be based on what is simplest and most efficient for a given TCP implementation.
The choice of which segmentation method to use should be based on what is simplest and most efficient for a given TCP implementation.
10.2. Probing Method Using SCTP
10.2. Probing Method Using SCTP
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.
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.
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.
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 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 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.
Mathis & Heffner Standards Track [Page 25] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 25] RFC 4821 Packetization Layer Path MTU Discovery March 2007
10.3. Probing Method for IP Fragmentation
10.3. Probing Method for IP Fragmentation
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].
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].
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.
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.
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.
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.
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.
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.
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.
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.
Mathis & Heffner Standards Track [Page 26] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 26] RFC 4821 Packetization Layer Path MTU Discovery March 2007
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.
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.
Connectionless protocols also introduce an additional problem with maintaining the path information cache: there are no events corresponding to connection establishment and tear-down to use to manage the cache itself. A natural approach would be to keep an immutable cache entry for the "default path", which has a eff_pmtu that is fixed at the initial value for connectionless protocols. The adjunct Path MTU Discovery protocol would be invoked once the number of fragmented datagrams to any particular destination reaches some configurable threshold (e.g., 5 datagrams). A new path cache entry would be created when the adjunct protocol updates eff_pmtu, and deleted on the basis of a timer or a Least Recently Used cache replacement algorithm.
Connectionless 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.
10.4. Probing Method Using Applications
10.4. Probing Method Using Applications
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.
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.
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.
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.
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.
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.
Mathis & Heffner Standards Track [Page 27] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 27] RFC 4821 Packetization Layer Path MTU Discovery March 2007
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.
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.
All application probing techniques require the ability to send messages that are larger than the current eff_pmtu described in Section 9.
All application probing techniques require the ability to send messages that are larger than the current eff_pmtu described in Section 9.
11. Security Considerations
11. Security Considerations
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.
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.
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.
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.
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.
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.
12. References
12. References
12.1. Normative References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Mathis & Heffner Standards Track [Page 28] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 28] RFC 4821 Packetization Layer Path MTU Discovery March 2007
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
Deering, "IPv6 Flow Label Specification", RFC 3697,
March 2004.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control
Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk
and Parameter for the Stream Control Transmission
Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
12.2. Informative References
12.2. Informative References
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J.,
Tran, D., Henderson, T., Heidemann, J., Touch, J.,
Kruse, H., Ostermann, S., Scott, K., and J. Semke,
"Ongoing TCP Research Related to Satellites",
RFC 2760, February 2000.
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP", RFC 3517,
April 2003.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
Mathis & Heffner Standards Track [Page 29] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 29] RFC 4821 Packetization Layer Path MTU Discovery March 2007
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered
harmful", Proc. SIGCOMM '87 vol. 17, No. 5,
October 1987.
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
[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-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>.
[frag-errors] Heffner, J., "IPv4 Reassembly Errors at High Data
Rates", Work in Progress, December 2007.
[frag-errors] Heffner, J., "IPv4 Reassembly Errors at High Data Rates", Work in Progress, December 2007.
Mathis & Heffner Standards Track [Page 30] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 30] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Appendix A. Acknowledgments
Appendix A. Acknowledgments
Many ideas and even some of the text come directly from RFC 1191 and RFC 1981.
Many ideas and even some of the text come directly from RFC 1191 and 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.
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.
Matt Mathis and John Heffner are supported in this work by a grant from Cisco Systems, Inc.
Matt Mathis and John Heffner are supported in this work by a grant from Cisco Systems, Inc.
Authors' Addresses
Authors' Addresses
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 USA
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 USA
Phone: 412-268-3319 EMail: mathis@psc.edu
Phone: 412-268-3319 EMail: mathis@psc.edu
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
Phone: 412-268-2329 EMail: jheffner@psc.edu
Phone: 412-268-2329 EMail: jheffner@psc.edu
Mathis & Heffner Standards Track [Page 31] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Mathis & Heffner Standards Track [Page 31] RFC 4821 Packetization Layer Path MTU Discovery March 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Mathis & Heffner Standards Track [Page 32]
マシスとヘフナー標準化過程[32ページ]
一覧
スポンサーリンク
