サイト内関連リンク：
RFC 768 UDP (日本語訳)
RFC 791 IP (日本語訳)
RFC 792 ICMP (日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
サイト内関連リンク：
RFC 768 UDP (日本語訳)
RFC 791 IP (日本語訳)
RFC 792 ICMP (日本語訳)
This RFC specifies a protocol on the IAB Standards Track for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. 本 RFC はインターネットコミュニティのための IAB Standards Track に関するプロトコルに付いて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "IAB Official Protocol Standards" を参照してほしい。この文書の配布に制限はない。
This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. 本文書は任意のインターネットパスの最大転送単位(MTU)を動的に発見する方法を説明する。本文書はルータがある種類の ICMP メッセージを生成する方法に小さな変更を規定する。そのような変更を加えられていないルータを通過するパスの場合にはこの方法は正しいパス MTU を見つけられないかもしれないが、現行の習慣によって選ばれるパス MTU と同程度に正しい(多くの場合、より正しい)パス MTU を常に選択する。
This proposal is a product of the IETF MTU Discovery Working Group. この提案は IETF MTU Discovery Working Group の成果物である。
The mechanism proposed here was first suggested by Geof Cooper [2], who in two short paragraphs set out all the basic ideas that took the Working Group months to reinvent. ここで提案されているメカニズムは最初に Geof Cooper によって提案された [2]。彼は二つの短い段落において、Working Group が再発明するのに数ヶ月を要した基本的なアイデアのすべてを設計した。
When one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. (For the case against fragmentation, see [5].) This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path. A shortcoming of the current Internet protocol suite is the lack of a standard mechanism for a host to discover the PMTU of an arbitrary path. ある IP ホストが他のホストに送信するべき大量のデータを持っているとき、そのデータは一連の IP データグラムとして送信される。通常それらのデータグラムは、送信元から宛先までのパス上でフラグメンテーションを必要としない最大サイズであることが望ましい。(フラグメンテーションに反対する事例に付いては [5] を参照してほしい。) このデータグラムサイズはパス MTU (PMTU)と呼ばれ、パス上の各ホップの MTU の最小値に等しい。現在のインターネットプロトコル一式の欠点は、ホストが任意のパスの PMTU を発見するためのメカニズムが存在しないことである。
Note: The Path MTU is what in [1] is called the "Effective MTU for sending" (EMTU_S). A PMTU is associated with a path, which is a particular combination of IP source and destination address and perhaps a Type-of-service (TOS). 注意：パス MTU は [1] において "Effective MTU for sending" (EMTU_S) と呼ばれているものである。PMTU はパスに対応し、パスは IP の送信元・宛先アドレスと、場合によってはサービス種別(TOS)との特定の組み合わせである。
The current practice [1] is to use the lesser of 576 and the first-hop MTU as the PMTU for any destination that is not connected to the same network or subnet as the source. In many cases, this results in the use of smaller datagrams than necessary, because many paths have a PMTU greater than 576. A host sending datagrams much smaller than the Path MTU allows is wasting Internet resources and probably getting suboptimal throughput. Furthermore, current practice does not prevent fragmentation in all cases, since there are some paths whose PMTU is less than 576. 現在の習慣 [1] は、送信元と同じネットワークまたはサブネットに接続していないすべての宛先の PMTU として、576 と第一ホップの MTU とのうち小さい方の値を使用する。ほとんどのパスは 576 より大きい PMTU を持つため、多くの場合これは必要以上に小さいデータグラムを使用する結果になる。パス MTU が許すよりずっと小さいデータグラムを送信するホストは、インターネットリソースを浪費し、おそらくは次善のスループットしか得られない。しかも一部のパスは 576 より小さい PMTU を持つため、現在の習慣はすべての場合にフラグメンテーションを防ぐわけではない。
It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area, although perhaps not across multi-level routing hierarchies. It is not clear how soon that will be ubiquitously available, so for the next several years the Internet needs a simple mechanism that discovers PMTUs without wasting resources and that works before all hosts and routers are modified. たとえ複数レベルのルーティング階層をまたがらないとしても、将来のルーティングプロトコルがルーティング分野の範囲内で正確な PMTU 情報を提供できるようになることが期待される。それが普遍的に利用可能になるのがいつになるかは不明であるため、それまでの今後数年間、インターネットはリソースを浪費せずに PMTU を発見し、すべてのホストとルータとが修正される前でも正しく動作する単純なメカニズムを必要とする。
In this memo, we describe a technique for using the Don't Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path. The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set" [7]. Upon receipt of such a message (henceforth called a "Datagram Too Big" message), the source host reduces its assumed PMTU for the path. 本文書において私たちは、パスの PMTU を動的に探索するために IP ヘッダの Don't Fragment (DF) ビットを使用する方法を説明する。基本的なアイデアは、送信元ホストが最初に第一ホップの(既知の) MTU をパスの PMTU であると仮定し、そのパス上で DF ビットをセットしてすべてのデータグラムを送信するというものである。いずれかのデータグラムが経路上のルータによってフラグメンテーションなしには転送できないほど大きい場合、そのルータはデータグラムを破棄し、 "fragmentation needed and DF set(フラグメント化が必要だが DF がセットされている)" を意味するコードを持つ ICMP Destination Unreachable メッセージを返すだろう。そのようなメッセージ(これ以降 "Datagram Too Big" メッセージと呼ぶ)の受け取り後、送信元ホストはそのパスの推定 PMTU を減らす。
The PMTU discovery process ends when the host's estimate of the PMTU is low enough that its datagrams can be delivered without fragmentation. Or, the host may elect to end the discovery process by ceasing to set the DF bit in the datagram headers; it may do so, for example, because it is willing to have datagrams fragmented in some circumstances. Normally, the host continues to set DF in all datagrams, so that if the route changes and the new PMTU is lower, it will be discovered. PMTU 探索のプロセスは、ホストによる PMTU の推定値がデータグラムをフラグメンテーションなしで配送できるほど十分に小さい値になったときに終了する。または、ホストはデータグラムのヘッダ内の DF ビットを外すことでこの探索プロセスを終了してもよい。これは例えばある種の環境においてデータグラムをフラグメント化させたい場合に行うことができる。経路が変化し新しい PMTU がより小さい場合にそれを発見できるように、ホストは通常すべてのデータグラムに DF をセットし続ける。
Unfortunately, the Datagram Too Big message, as currently specified, does not report the MTU of the hop for which the rejected datagram was too big, so the source host cannot tell exactly how much to reduce its assumed PMTU. To remedy this, we propose that a currently unused header field in the Datagram Too Big message be used to report the MTU of the constricting hop. This is the only change specified for routers in support of PMTU Discovery. 残念ながら現在規定されている Datagram Too Big メッセージはデータグラムを拒否したホップの MTU を報告しないため、推測値をどれだけ減らせばよいかを送信元が正確に知ることができない。これを改善するために、Datagram Too Big メッセージ内の現在未使用のヘッダフィールドを使用して、転送を妨げたホップの MTU を報告することを提案する。これが PMTU 探索のサポートにおいてルータに規定される唯一の変更である。
The PMTU of a path may change over time, due to changes in the routing topology. Reductions of the PMTU are detected by Datagram Too Big messages, except on paths for which the host has stopped setting the DF bit. To detect increases in a path's PMTU, a host periodically increases its assumed PMTU (and if it had stopped, resumes setting the DF bit). This will almost always result in datagrams being discarded and Datagram Too Big messages being generated, because in most cases the PMTU of the path will not have changed, so it should be done infrequently. パスの PMTU はルーティングトポロジーの変化により時間とともに変化する可能性がある。ホストが DF ビットをセットするのを止めたパスを除いて、PMTU の減少は Datagram Too Big メッセージによって検出される。パスの PMTU の増加を検出するために、ホストは仮定した PMTU を定期的に増加させる(それが DF ビットのセットを止めていたパスなら、DF ビットをセットを再開する)。パスの PMTU はたいてい変化しないため、ほとんどの場合これはデータグラムが破棄され、Datagram Too Big メッセージが生成される結果となる。そのためこれは低頻度で行われるべきである。
Since this mechanism essentially guarantees that host will not receive any fragments from a peer doing PMTU Discovery, it may aid in interoperating with certain hosts that (improperly) are unable to reassemble fragmented datagrams. このメカニズムは PMTU 探索を行うピアからのフラグメントをホストが受信しないことを本質的に保証するため、フラグメント化されたデータグラムを再構築できない(不適切な)ホストとの相互運用を促進するだろう。
When a host receives a Datagram Too Big message, it MUST reduce its estimate of the PMTU for the relevant path, based on the value of the Next-Hop MTU field in the message (see section 4). We do not specify the precise behavior of a host in this circumstance, since different applications may have different requirements, and since different implementation architectures may favor different strategies. Datagram Too Big メッセージを受信したとき、ホストはそのメッセージの Next-Hop MTU フィールド(セクション 4 参照)の値に基づいて、対応するパスの PMTU の推測値を減らさなければならない(MUST)。異なるアプリケーションは異なる要件を持つ可能性があり、異なる実装アーキテクチャは異なる戦略を好む可能性があるため、私たちはこの状況におけるホストの厳密な振る舞いを規定しない。
We do require that after receiving a Datagram Too Big message, a host MUST attempt to avoid eliciting more such messages in the near future. The host may either reduce the size of the datagrams it is sending along the path, or cease setting the Don't Fragment bit in the headers of those datagrams. Clearly, the former strategy may continue to elicit Datagram Too Big messages for a while, but since each of these messages (and the dropped datagrams they respond to) consume Internet resources, the host MUST force the PMTU Discovery process to converge. Datagram Too Big メッセージの受信後、ホストは近い将来さらにそのようなメッセージを生じることを避けるよう試なければならない。ホストはそのパス上で送信するデータグラムのサイズを減らしてもよいし、それらのデータグラムのヘッダ内の Don't Fragment ビットを止めてもよい。明らかに前者の戦略は Datagram Too Big メッセージをしばらくのあいだ生じさせ続ける可能性があるが、そのようなメッセージ(およびそれらが応じた元の破棄されたデータグラム)はインターネットリソースを消費するため、ホストは PMTU 探索プロセスを強制的に収束させなければならない(MUST)。
Hosts using PMTU Discovery MUST detect decreases in Path MTU as fast as possible. Hosts MAY detect increases in Path MTU, but because doing so requires sending datagrams larger than the current estimated PMTU, and because the likelihood is that the PMTU will not have increased, this MUST be done at infrequent intervals. An attempt to detect an increase (by sending a datagram larger than the current estimate) MUST NOT be done less than 5 minutes after a Datagram Too Big message has been received for the given destination, or less than 1 minute after a previous, successful attempted increase. We recommend setting these timers at twice their minimum values (10 minutes and 2 minutes, respectively). PMTU 探索を使用するホストはパス MTU の減少をできるだけ早く検出しなければならない(MUST)。ホストはパス MTU の増加を検出してもよい(MAY)が、それを行うには現在の推定 PMTU より大きいデータグラムを送信する必要があり、また PMTU は増加しない可能性が高いため、低頻度で行わなければならない(MUST)。(現在の推定値より大きいデータグラムを送信することで)増加を検出する試みは、Datagram Too Big メッセージを受信してから 5 分未満であったり、直前の増加検出の試みが成功してから 1 分未満であってはならない(MUST NOT)。私たちはこれらのタイマーを最低値の 2 倍に設定することを推奨する(それぞれ 10 分、2分)。
Hosts MUST be able to deal with Datagram Too Big messages that do not include the next-hop MTU, since it is not feasible to upgrade all the routers in the Internet in any finite time. A Datagram Too Big message from an unmodified router can be recognized by the presence of a zero in the (newly-defined) Next-Hop MTU field. (This is required by the ICMP specification [7], which says that "unused" fields must be zero.) In section 5, we discuss possible strategies for a host to follow in response to an old-style Datagram Too Big message (one sent by an unmodified router). インターネット上のすべてのルータを有限時間内に更新することは不可能なため、ホストは next-hop MTU を含まない Datagram Too Big メッセージを扱えなければならない(MUST)。修正されていないルータからの Datagram Too Big メッセージは、(新たに定義された)Next-Hop MTU フィールドにゼロが現れることで識別できる。(これは ICMP 仕様 [7] の要件であり、"未使用(unused)" のフィールドはゼロでなければならないと述べている。) セクション 5 において私たちは、古いスタイルの Datagram Too Big メッセージ(修正されていないルータによって送信される)に従うためにホストが取り得る戦略に付いて議論する。
A host MUST never reduce its estimate of the Path MTU below 68 octets. ホストはパス MTU の推定値を 68 オクテット未満に減らしてはならない(MUST)。
A host MUST not increase its estimate of the Path MTU in response to the contents of a Datagram Too Big message. A message purporting to announce an increase in the Path MTU might be a stale datagram that has been floating around in the Internet, a false packet injected as part of a denial-of-service attack, or the result of having multiple paths to the destination. ホストは Datagram Too Big メッセージの内容に応えてパス MTU の推定値を増やしてはならない(MSUT)。パス MTU の増加を知らせる意味のメッセージは、インターネット内を漂った古いデータグラムや、サービス不能攻撃の一部として投入された偽装パケット、宛先への経路が複数存在するためである可能性がある。
A host doing PMTU Discovery must obey the rule that it not send IP datagrams larger than 576 octets unless it has permission from the receiver. For TCP connections, this means that a host must not send datagrams larger than 40 octets plus the Maximum Segment Size (MSS) sent by its peer. PMTU 探索を実行するホストは、受信側が許可しない限り 576 オクテットより大きい IP データグラムを送信しないという規則に従わなければならない。TCP 接続の場合、これは 40 オクテットにピアから送信された最大セグメントサイズ(MSS)を加えたサイズより大きいデータグラムをホストが送信してはならないということを意味する。
Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [9]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. 注意： TCP の MSS は関連する IP データグラムサイズから 40 を引いたものであると定義される[9]。最大 IP データグラムサイズのための 576 オクテットというデフォルトから、TCP MSS のための 536 オクテットというデフォルトが得られる。
Section 4.2.2.6 of "Requirements for Internet Hosts -- Communication Layers" [1] says: "Requirements for Internet Hosts -- Communication Layers" [1] のセクション 4.2.2.6 は以下のように述べている：
Some TCP implementations send an MSS option only if the destination host is on a non-connected network. However, in general the TCP layer may not have the appropriate information to make this decision, so it is preferable to leave to the IP layer the task of determining a suitable MTU for the Internet path. 一部の TCP 実装は宛先が直接接続していないネットワーク上にある場合にのみ MSS オプションを送信する。しかしながら一般に TCP レイヤはそれを判断するための適切な情報を持たないため、インターネットパスのための適切な MTU を決定する仕事は IP レイヤに任せるのが望ましい。
Actually, many TCP implementations always send an MSS option, but set the value to 536 if the destination is non-local. This behavior was correct when the Internet was full of hosts that did not follow the rule that datagrams larger than 576 octets should not be sent to non-local destinations. Now that most hosts do follow this rule, it is unnecessary to limit the value in the TCP MSS option to 536 for non-local peers. 実際のところ多くの TCP 実装は常に MSS オプションを送信するが、宛先が非ローカルの場合には 536 をセットする。この振る舞いは、576 オクテットを超えるデータグラムを非ローカルの宛先に送るべきではないという規則に従わないホストがインターネットに満ちていたときには正しかった。現在では大部分のホストがこの規則に従うため、非ローカルのピアのために TCP MSS オプションの値を 536 に制限する必要はない。
Moreover, doing this prevents PMTU Discovery from discovering PMTUs larger than 576, so hosts SHOULD no longer lower the value they send in the MSS option. The MSS option should be 40 octets less than the size of the largest datagram the host is able to reassemble (MMS_R, as defined in [1]); in many cases, this will be the architectural limit of 65495 (65535 - 40) octets. A host MAY send an MSS value derived from the MTU of its connected network (the maximum MTU over its connected networks, for a multi-homed host); this should not cause problems for PMTU Discovery, and may dissuade a broken peer from sending enormous datagrams. さらに、これを行うと PMTU 探索が 576 より大きい PMTU を発見できなくなるため、ホストは自身が MSS オプションで送信する値を下げないべきである(SHOULD)。MSS オプションは、ホストが再構築できる最大のデータグラムサイズより 40 オクテット小さいべきである(MMS_R, [1] で定義されている)。多くの場合、これは 65495 (65535 - 40) オクテットという設計上の制限になるだろう。ホストは自身の接続するネットワークの MTU (マルチホームホストの場合は最大 MTU)から算出される MSS 値を送信してもよい(MAY)。これは PMTU 探索に問題を起こさせないはずであり、故障したピアに巨大なデータグラムの送信を断念させるだろう。
Note: At the moment, we see no reason to send an MSS greater than the maximum MTU of the connected networks, and we recommend that hosts do not use 65495. It is quite possible that some IP implementations have sign-bit bugs that would be tickled by unnecessary use of such a large MSS. 注意： 現在のところ、接続しているネットワークの最大 MTU より大きい MSS を送信する理由はないため、ホストが 65495 を使用しないことを推奨する。一部の実装がそのような大きな MSS の不必要な使用により発現する符号ビットバグを持つ可能性は十分にある。
When a router is unable to forward a datagram because it exceeds the MTU of the next-hop network and its Don't Fragment bit is set, the router is required to return an ICMP Destination Unreachable message to the source of the datagram, with the Code indicating "fragmentation needed and DF set". To support the Path MTU Discovery technique specified in this memo, the router MUST include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labelled "unused" in the ICMP specification [7]. The high-order 16 bits remain unused, and MUST be set to zero. Thus, the message has the following format: データグラムが次ホップネットワークの MTU を超えており、かつその Don't Fragment ビットがセットされているためにルータがデータグラムを転送できない場合、そのルータはデータグラムの送信元に "fragmentation needed and DF set(フラグメント化が必要だが DF がセットされている)" を表すコードを持つ ICMP の Destination Unreachable メッセージを返す必要がある。本文書で規定されるパス MTU 探索をサポートするために、ルータは ICMP 仕様 [7] において "未使用(unused)" とラベル付けされている ICMP ヘッダフィールドの下位 16 ビットに、その次ホップネットワークの MTU を含めなければならない(MUST)。上位 16 ビットは未使用のままであり、ゼロをセットしなければならない(MUST)。したがって、そのメッセージは以下のフォーマットを持つ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ = 3 | コード = 4 | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 未使用 = 0 | 次ホップ MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 元のデータグラムデータの 64 ビット |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value carried in the Next-Hop MTU field is: 次ホップ MTU フィールドで運ばれる値：
The size in octets of the largest datagram that could be forwarded, along the path of the original datagram, without being fragmented at this router. The size includes the IP header and IP data, and does not include any lower-level headers. このルータで元のデータグラムのパス上をフラグメント化されずに転送可能な、オクテット単位の最大データグラムサイズ。このサイズは IP ヘッダと IP データを含み、下位レベルのヘッダを含まない。
This field will never contain a value less than 68, since every router "must be able to forward a datagram of 68 octets without fragmentation" [8]. すべてのルータは "68 オクテットのデータグラムをフラグメント化せずに転送できなければならない(must be able to forward a datagram of 68 octets without fragmentation)" [8] ため、このフィールドが 68 より小さい値を持つことはない。
In this section we outline several possible strategies for a host to follow upon receiving a Datagram Too Big message from an unmodified router (i.e., one where the Next-Hop MTU field is zero). This section is not part of the protocol specification. 本セクションでは、未修正のルータからの Datagram Too Big メッセージ(つまり次ホップ MTU フィールドがゼロのメッセージ)を受信するためにホストが取り得るいくつかの戦略の概要を述べる。本セクションはプロトコル仕様の一部ではない。
The simplest thing for a host to do in response to such a message is to assume that the PMTU is the minimum of its currently-assumed PMTU and 576, and to stop setting the DF bit in datagrams sent on that path. Thus, the host falls back to the same PMTU as it would choose under current practice (see section 3.3.3 of "Requirements for Internet Hosts -- Communication Layers" [1]). This strategy has the advantage that it terminates quickly, and does no worse than existing practice. It fails, however, to avoid fragmentation in some cases, and to make the most efficient utilization of the internetwork in other cases. そのようなメッセージに応えてホストが実行するもっとも単純なことは、PMTU が現在仮定されている PMTU と 576 とのうち小さい方の値であると仮定することと、そのパス上で送信されるデータグラム内の DF ビットをセットするのを止めることである。したがってホストは、現在の習慣("Requirements for Internet Hosts -- Communication Layers" [1] のセクション 3.3.3 参照)の下で選択するのと同じ PMTU に戻る。この戦略には、すぐに終了し、既存の習慣より悪くないという長所がある。しかしながら場合によってはフラグメント化を避けることに失敗し、ネットワーク間のもっとも効率的な利用に失敗する場合もある。
More sophisticated strategies involve "searching" for an accurate PMTU estimate, by continuing to send datagrams with the DF bit while varying their sizes. A good search strategy is one that obtains an accurate estimate of the Path MTU without causing many packets to be lost in the process. より洗練された戦略では、DF ビットをセットしたデータグラムをサイズを変えながら送信し続けることで、正確な PMTU 推定値の "検索(searching)" を行う。優れた検索戦略とは、その処理の過程で多くのパケットを失うことなくパス MTU の正確な推定値を得られるものである。
Several possible strategies apply algorithmic functions to the previous PMTU estimate to generate a new estimate. For example, one could multiply the old estimate by a constant (say, 0.75). We do NOT recommend this; it either converges far too slowly, or it substantially underestimates the true PMTU. いくつかの考えられる戦略は、新しい推定値を生成するために以前の PMTU 推定値に対してアルゴリズム的関数を適用する。例えば古い推定値に定数(例えば 0.75)を掛ける。これは非常にゆっくりとしか収束しないか、本当の PMTU を大幅に低く見積もってしまうため、推奨されない。
A more sophisticated approach is to do a binary search on the packet size. This converges somewhat faster, although it still takes 4 or 5 steps to converge from an FDDI MTU to an Ethernet MTU. A serious disadvantage is that it requires a complex implementation in order to recognize when a datagram has made it to the other end (indicating that the current estimate is too low). We also do not recommend this strategy. より洗練されたアプローチは、パケットサイズの二分探索を実行することである。これは FDDI の MTU からイーサネットの MTU に収束するのに 4 または 5 ステップを要するものの、いくらか早く収束する。深刻な欠点は、データグラムが相手側に到達したとき(現在の推定値が低すぎることを表す)を認識するために複雑な実装を必要とすることである。この戦略も推奨されない。
One strategy that appears to work quite well starts from the observation that there are, in practice, relatively few MTU values in use in the Internet. Thus, rather than blindly searching through arbitrarily chosen values, we can search only the ones that are likely to appear. Moreover, since designers tend to chose MTUs in similar ways, it is possible to collect groups of similar MTU values and use the lowest value in the group as our search "plateau". (It is clearly better to underestimate an MTU by a few per cent than to overestimate it by one octet.) かなりうまく動作すると思われる戦略は、インターネットにおいて実際には比較的少数の MTU 値しか使用されていないという観測から始める。つまり、任意に選択された値を無分別に検索するよりも、現れそうな値のみを検索することができるということである。さらに、設計者は似た方法で MTU を選ぶ傾向があるため、似た MTU 値のグループを収集し、グループ内の最小値を検索の "プラトー(plateau)" として使用することが可能である。(MTU を数パーセント過小評価する方が 1 オクテットでも過大評価するより明らかに優れている。)
In section 7, we describe how we arrived at a table of representative MTU plateaus for use in PMTU estimation. With this table, convergence is as good as binary search in the worst case, and is far better in common cases (for example, it takes only two round-trip times to go from an FDDI MTU to an Ethernet MTU). Since the plateaus lie near powers of two, if an MTU is not represented in this table, the algorithm will not underestimate it by more than a factor of 2. セクション 7 において、PMTU の推測に使用するための代表 MTU 値のテーブルに到達した方法を説明する。このテーブルにより、収束は最悪の場合の二分探索と同程度になり、通常よりかなり優れたものになる(例えば FDDI の MTU からイーサネットの MTU までたどり着くのに 2 往復しか必要としない)。プラトーは 2 の累乗近辺に位置するため、このテーブルに MTU が現れない場合でも、このアルゴリズムが 2 の倍数より大きく過小評価することはないだろう。
Any search strategy must have some "memory" of previous estimates in order to chose the next one. One approach is to use the currently-cached estimate of the Path MTU, but in fact there is better information available in the Datagram Too Big message itself. All ICMP Destination Unreachable messages, including this one, contain the IP header of the original datagram, which contains the Total Length of the datagram that was too big to be forwarded without fragmentation. Since this Total Length may be less than the current PMTU estimate, but is nonetheless larger than the actual PMTU, it may be a good input to the method for choosing the next PMTU estimate. どのような検索戦略も、次の推定値を選ぶために以前の推定値の "記憶(memory)" を持たなければならない。現時点でキャッシュされているパス MTU を使用するのがひとつのアプローチだが、実際には利用可能なより優れた情報が Datagram Too Big メッセージ自体の中にある。このメッセージを含むすべての ICMP Destination Unreachable メッセージは元のデータグラムの IP ヘッダを含み、そこにはフラグメントせずに転送するには大きすぎたデータグラムの全長(Total Length)が含まれる。この全長は現在の PMTU の推定値より小さいかもしれないが、それでも実際の PMTU よりは大きいため、次の PMTU 推定値を選択する方法への優れた入力になる可能性がある。
Note: routers based on implementations derived from 4.2BSD Unix send an incorrect value for the Total Length of the original IP datagram. The value sent by these routers is the sum of the original Total Length and the original Header Length (expressed in octets). Since it is impossible for the host receiving such a Datagram Too Big message to know if it sent by one of these routers, the host must be conservative and assume that it is. If the Total Length field returned is not less than the current PMTU estimate, it must be reduced by 4 times the value of the returned Header Length field. 注意：4.2BSD Unix から派生した実装に基づくルータは、元の IP データグラムの全長に不正な値を送信する。そのようなルータが送信する値は元の全長と元のヘッダ長との合計(オクテット単位)である。そのような Datagram Too Big メッセージを受信したホストはそれがその種のルータから送信されたものかどうかを知ることができないため、ホストは保守的でなければならず、そうである(つまり不正な値である)と仮定しなければならない。返された全長フィールドが現在の PMTU 推定値以上の場合、返されたヘッダ長フィールドの値の 4 倍を減らさなければならない。
The strategy we recommend, then, is to use as the next PMTU estimate the greatest plateau value that is less than the returned Total Length field (corrected, if necessary, according to the Note above). 私たちの推奨する戦略は、(必要なら上記の注意に従って訂正後の)返された全長フィールドより小さい最大のプラトーの値を次の PMTU 推定値として使用することである。
In this section we discuss how PMTU Discovery is implemented in host software. This is not a specification, but rather a set of suggestions. 本セクションではホストソフトウェア内に PMTU 探索を実装する方法を議論する。これは仕様ではなく、提案である。
The issues include: この議題は以下の内容を含む：
In the IP architecture, the choice of what size datagram to send is made by a protocol at a layer above IP. We refer to such a protocol as a "packetization protocol". Packetization protocols are usually transport protocols (for example, TCP) but can also be higher-layer protocols (for example, protocols built on top of UDP). IP アーキテクチャの場合、送信するデータグラムサイズの選択は IP の上位プロトコルによって行われる。私たちはそのようなプロトコルを "パケット化プロトコル(packetization protocol)" と呼ぶ。通常、パケット化プロトコルはトランスポートプロトコル(例えば TCP)だが、より上位レイヤのプロトコル(例えば UDP 上に構築されるプロトコル)であってもよい。
Implementing PMTU Discovery in the packetization layers simplifies some of the inter-layer issues, but has several drawbacks: the implementation may have to be redone for each packetization protocol, it becomes hard to share PMTU information between different packetization layers, and the connection-oriented state maintained by some packetization layers may not easily extend to save PMTU information for long periods. パケット化レイヤ内に PMTU 探索を実装するとレイヤ間の問題の一部を単純化できるが、いくつかの欠点がある：各パケット化プロトコルのために実装を作り替えなければならない。異なるパケット化レイヤ間の PMTU 情報を共有することが困難になる。一部のパケット化レイヤによって維持される接続向けの状態を、長期間にわたって PMTU 情報を保持するように拡張するのは簡単ではない可能性がある。
We therefore believe that the IP layer should store PMTU information and that the ICMP layer should process received Datagram Too Big messages. The packetization layers must still be able to respond to changes in the Path MTU, by changing the size of the datagrams they send, and must also be able to specify that datagrams are sent with the DF bit set. We do not want the IP layer to simply set the DF bit in every packet, since it is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change its datagram size. Protocols involving intentional fragmentation, while inelegant, are sometimes successful (NFS being the primary example), and we do not want to break such protocols. そのため私たちは、IP レイヤが PMTU 情報を保存するべきであり、受信した Datagram Too Big メッセージを ICMP レイヤが処理するべきであると考える。それでもパケット化レイヤは送信するデータグラムサイズを変更することでパス MTU の変化に対応できなければならず、また DF ビットをセットしてデータグラムが送信されるように指定できるべきである。パケット化レイヤ(おそらくカーネル外部の UDP アプリケーション)はそのデータグラムサイズを変更できない可能性があるため、私たちは IP レイヤが単純にすべてのパケットに DF ビットをセットすることを望まない。意図的にフラグメンテーションにかかわるプロトコルが(洗練されていないが)うまく行く場合もある(NFS が主な例である)ため、私たちはそのようなプロトコルを壊したくない。
To support this layering, packetization layers require an extension of the IP service interface defined in [1]: この階層化をサポートするために、パケット化レイヤは [1] で定義される IP サービスインターフェイスの拡張を必要とする：
A way to learn of changes in the value of MMS_S, the "maximum send transport-message size", which is derived from the Path MTU by subtracting the minimum IP header size. 最小 IP ヘッダサイズを差し引くことでパス MTU から導き出される MMS_S ("最大転送メッセージサイズ(maximum send transport-message size)")の値の変化を知る手段。
In general, the IP layer should associate each PMTU value that it has learned with a specific path. A path is identified by a source address, a destination address and an IP type-of-service. (Some implementations do not record the source address of paths; this is acceptable for single-homed hosts, which have only one possible source address.) 一般に IP レイヤは学習した各 PMTU 値を特定のパスに関連付ける。パスは送信元アドレス・宛先アドレス・IP サービス種別によって識別される。(一部の実装はパスの送信元アドレスを記録しない。これは送信元アドレスがひとつしかないシングルホームホストの場合に受け入れられる。)
Note: Some paths may be further distinguished by different security classifications. The details of such classifications are beyond the scope of this memo. 注意：一部のパスは異なるセキュリティ分類によってさらに区別される。そのような分類の詳細は本文書の範囲外である。
The obvious place to store this association is as a field in the routing table entries. A host will not have a route for every possible destination, but it should be able to cache a per-host route for every active destination. (This requirement is already imposed by the need to process ICMP Redirect messages.) この関連付けを保存する明白な場所が、フィールドとしてルーティングテーブルエントリ内にある。ホストがすべての考えられる宛先への経路を持つことはないだろうが、すべてのアクティブな宛先へのホストごとの経路をキャッシュできるべきである。(この要求事項は ICMP Redirect メッセージの処理の必要性によってすでに課されている。)
When the first packet is sent to a host for which no per-host route exists, a route is chosen either from the set of per-network routes, or from the set of default routes. The PMTU fields in these route entries should be initialized to be the MTU of the associated first-hop data link, and must never be changed by the PMTU Discovery process. (PMTU Discovery only creates or changes entries for per-host routes). Until a Datagram Too Big message is received, the PMTU associated with the initially-chosen route is presumed to be accurate. ホスト経路の存在しないホストに最初のパケットを送信するとき、ネットワーク経路またはデフォルト経路から経路を選択する。これらの経路エントリ内の PMTU フィールドは対応する第 1 ホップデータリンクの MTU で初期化されるべきであり、PMTU 探索によって変更されてはならない。(PMTU 探索はホスト経路のみを生成/変更する。) Datagram Too Big メッセージを受信するまで、初期選択された経路に対応する PMTU を正しいと仮定する。
When a Datagram Too Big message is received, the ICMP layer determines a new estimate for the Path MTU (either from a non-zero Next-Hop MTU value in the packet, or using the method described in section 5). If a per-host route for this path does not exist, then one is created (almost as if a per-host ICMP Redirect is being processed; the new route uses the same first-hop router as the current route). If the PMTU estimate associated with the per-host route is higher than the new estimate, then the value in the routing entry is changed. Datagram Too Big メッセージを受信したとき、ICMP レイヤはパス MTU の新しい推定値を決定する(そのパケットの非ゼロの次ホップ MTU の値から、またはセクション 5 で説明されている手段を使用して)。そのパスのホスト経路が存在しなければ生成する(これはホストごとの ICMP Redirect が処理されたかのように行われ、新しい経路は現在の経路と同じ第 1 ホップを使用する)。そのホスト経路に対応する PMTU 推定値が新しい推定値より高い場合、ルーティングエントリ内の値が変更される。
The packetization layers must be notified about decreases in the PMTU. Any packetization layer instance (for example, a TCP connection) that is actively using the path must be notified if the PMTU estimate is decreased. パケット化レイヤは PMTU の減少を通知されなければならない。パスを積極的に使用するパケット化レイヤのインスタンス(例えば TCP 接続)は、PMTU 推定値が減少した場合に通知されなければならない。
Note: even if the Datagram Too Big message contains an Original Datagram Header that refers to a UDP packet, the TCP layer must be notified if any of its connections use the given path. 注意：Datagram Too Big メッセージ内の元のデータグラムのヘッダが UDP パケットの場合でも、いずれかの TCP 接続がその特定のパスを使用するなら、TCP レイヤに通知されなければならない。
Also, the instance that sent the datagram that elicited the Datagram Too Big message should be notified that its datagram has been dropped, even if the PMTU estimate has not changed, so that it may retransmit the dropped datagram. Datagram Too Big メッセージを引き起こした元のデータグラムを送信したインスタンスは、破棄されたデータグラムを再送信できるように、たとえ PMTU 推定値が変更されなかったとしても、そのデータグラムが破棄されたことを通知されるべきである。
Note: The notification mechanism can be analogous to the mechanism used to provide notification of an ICMP Source Quench message. In some implementations (such as 4.2BSD-derived systems), the existing notification mechanism is not able to identify the specific connection involved, and so an additional mechanism is necessary. 注意：この通知メカニズムは ICMP Source Quench メッセージを通知するために使用されるメカニズムに似させることができる。一部の実装(例えば 4.2BSD から派生したシステム)では既存のメカニズムが特定の接続を識別できないため、追加のメカニズムが必要となる。
Alternatively, an implementation can avoid the use of an asynchronous notification mechanism for PMTU decreases by postponing notification until the next attempt to send a datagram larger than the PMTU estimate. In this approach, when an attempt is made to SEND a datagram with the DF bit set, and the datagram is larger than the PMTU estimate, the SEND function should fail and return a suitable error indication. This approach may be more suitable to a connectionless packetization layer (such as one using UDP), which (in some implementations) may be hard to "notify" from the ICMP layer. In this case, the normal timeout-based retransmission mechanisms would be used to recover from the dropped datagrams. 代案として、PMTU 推定値より大きいデータグラムの送信が次に試行されるまで通知を遅延することで、実装は PMTU の減少のために非同期通知メカニズムを使用することを避けられる。このアプローチでは、DF ビットをセットされたデータグラムの SEND が試行され、かつそのデータグラムが PMTU 推定値より大きい場合、SEND 機能は失敗し、適切なエラーを返さなければならない。このアプローチは、(一部の実装において)ICMP レイヤからの "通知(notify)" が困難な可能性のあるコネクションレスのパケット化レイヤ(例えば UDP を使用するもの)により適しているかもしれない。この場合、データグラムの破棄から復旧するためには通常のタイムアウトベースの再送信メカニズムが使用されるだろう。
It is important to understand that the notification of the packetization layer instances using the path about the change in the PMTU is distinct from the notification of a specific instance that a packet has been dropped. The latter should be done as soon as practical (i.e., asynchronously from the point of view of the packetization layer instance), while the former may be delayed until a packetization layer instance wants to create a packet. Retransmission should be done for only for those packets that are known to be dropped, as indicated by a Datagram Too Big message. PMTU における変化に関するパスを使用するパケット化レイヤのインスタンスの通知と、パケットが破棄された特定のインスタンスの通知とが異なることを理解することは重要である。後者は実行可能になればすぐに実行されるべきである(つまり、パケット化レイヤのインスタンスの観点とは非同期である)一方で、前者はパケット化レイヤのインスタンスがパケットを生成しようとするまで遅延することができる。再送信は、Datagram Too Big メッセージにより破棄されたと分かっているパケットに対してのみ行われるべきである。
Internetwork topology is dynamic; routes change over time. The PMTU discovered for a given destination may be wrong if a new route comes into use. Thus, PMTU information cached by a host can become stale. ネットワーク間のトポロジーは動的であり、経路は時間とともに変化する。ある特定の宛先のために見つけられた PMTU は、新しい経路が使われ始めると不正になる可能性がある。そのためホストがキャッシュした PMTU 情報は古くなる可能性がある。
Because a host using PMTU Discovery always sets the DF bit, if the stale PMTU value is too large, this will be discovered almost immediately once a datagram is sent to the given destination. No such mechanism exists for realizing that a stale PMTU value is too small, so an implementation should "age" cached values. When a PMTU value has not been decreased for a while (on the order of 10 minutes), the PMTU estimate should be set to the first-hop data-link MTU, and the packetization layers should be notified of the change. This will cause the complete PMTU Discovery process to take place again. PMTU 探索を使用するホストは常に DF ビットをセットするため、古い PMTU 値が大きすぎる場合、特定の宛先にデータグラムが送信されると、ほぼ即座にそれが分かるだろう。古い PMTU 値が小さすぎることを知るためのこのようなメカニズムは存在しないため、実装はキャッシュされた値を "劣化(age)" させるべきである。PMTU 値がしばらく(約 10 分)のあいだ減少しなかったとき、PMTU 推定値に第 1 ホップデータリンクの MTU をセットするべきであり、パケット化レイヤにその変更を通知するべきである。これにより完全な PMTU 探索のプロセスが再び行われることになる。
Note: an implementation should provide a means for changing the timeout duration, including setting it to "infinity". For example, hosts attached to an FDDI network which is then attached to the rest of the Internet via a slow serial line are never going to discover a new non-local PMTU, so they should not have to put up with dropped datagrams every 10 minutes. 注意：実装はタイムアウト間隔("無限大(infinity)" も含む)を変更する手段を提供するべきである。例えば、低速シリアル回線でインターネットに接続している FDDI ネットワークに参加しているホストは新しい非ローカルの PMTU を決して見つけることがないため、10 分ごとのデータグラムの破棄に我慢する必要はないはずである。
An upper layer MUST not retransmit datagrams in response to an increase in the PMTU estimate, since this increase never comes in response to an indication of a dropped datagram. 上位レイヤは PMTU 推定値の増加に対してデータグラムを再送信してはならない(MUST)。増加のためにデータグラムの破棄が起こることは決してないためである。
One approach to implementing PMTU aging is to add a timestamp field to the routing table entry. This field is initialized to a "reserved" value, indicating that the PMTU has never been changed. Whenever the PMTU is decreased in response to a Datagram Too Big message, the timestamp is set to the current time. PMTU の劣化を実装するためのひとつのアプローチは、ルーティングテーブルのエントリにタイムスタンプフィールドを追加することである。このフィールドは、その PMTU がまったく変更されていないことを表す "予約済み(reserved)" の値で初期化される。Datagram Too Big メッセージに応えて PMTU が減らされた場合には常に、このタイムスタンプに現在の時刻をセットする。
Once a minute, a timer-driven procedure runs through the routing table, and for each entry whose timestamp is not "reserved" and is older than the timeout interval: 1 分ごとにタイマー駆動の手続きがルーティングテーブルを走査し、タイムスタンプが "予約済み(reserved)" ではなく、かつタイムアウト間隔より古いエントリごとに：
PMTU estimates may disappear from the routing table if the per-host routes are removed; this can happen in response to an ICMP Redirect message, or because certain routing-table daemons delete old routes after several minutes. Also, on a multi-homed host a topology change may result in the use of a different source interface. When this happens, if the packetization layer is not notified then it may continue to use a cached PMTU value that is now too small. One solution is to notify the packetization layer of a possible PMTU change whenever a Redirect message causes a route change, and whenever a route is simply deleted from the routing table. ホスト経路が削除されると PMTU 推定値はルーティングテーブルから消えてよい。これは ICMP Redirect メッセージに応えて、またはある種のルーティングテーブルデーモンが数分経過後に古い経路を削除することで発生し得る。またマルチホームホストの場合、トポロジーの変化により異なる送信元インターフェイスを使用するようになる可能性がある。これが発生したときにパケット化レイヤに通知されないと、現時点では小さすぎるキャッシュされた PMTU 値を使用し続ける可能性がある。ひとつの解決策は、Redirect メッセージにより経路が変更されたとき、およびルーティングテーブルから経路が単純に削除されたときに、考えられる PMTU の変化をパケット化レイヤに常に通知することである。
Note: a more sophisticated method for detecting PMTU increases is described in section 7.1. 注意：PMTU の増加を検出するためのより洗練された手法がセクション 7.1 で説明されている。
The TCP layer must track the PMTU for the destination of a connection; it should not send datagrams that would be larger than this. A simple implementation could ask the IP layer for this value (using the GET_MAXSIZES interface described in [1]) each time it created a new segment, but this could be inefficient. Moreover, TCP implementations that follow the "slow-start" congestion-avoidance algorithm [4] typically calculate and cache several other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be updated. TCP レイヤは接続の宛先のための PMTU を追跡しなければならず、それより大きいデータグラムを送信しないべきである。単純な実装は新しいセグメントを生成するたびに IP レイヤに([1] で説明されている GET_MAXSIZES インターフェイスを使用して) PMTU 値を問い合わせることができるが、これは非効率である。さらに、"スロースタート(slow-start)" の輻輳回避アルゴリズム [4] に従う TCP 実装は、一般に PMTU に由来する他の値を計算およびキャッシュする。これらの変数が変化してもよいように、PMTU が変化したときに非同期に通知を受信する方がより簡単かもしれない。
A TCP implementation must also store the MSS value received from its peer (which defaults to 536), and not send any segment larger than this MSS, regardless of the PMTU. In 4.xBSD-derived implementations, this requires adding an additional field to the TCP state record. TCP 実装はピアから受信した MSS 値(デフォルトは 536)も保存しなければならず、PMTU に関係なくその MSS より大きいセグメントを送信してはならない。4.xBSD から派生した実装の場合、これには TCP の状態レコードにフィールドを追加する必要がある。
Finally, when a Datagram Too Big message is received, it implies that a datagram was dropped by the router that sent the ICMP message. It is sufficient to treat this as any other dropped segment, and wait until the retransmission timer expires to cause retransmission of the segment. If the PMTU Discovery process requires several steps to estimate the right PMTU, this could delay the connection by many round-trip times. 最後に、Datagram Too Big メッセージを受信したとき、それは ICMP メッセージを送信したルータによってデータグラムが破棄されたことを意味する。これは他の破棄されたセグメントと同様に扱い、セグメントの再送信を引き起こすための再送信タイマーの期限切れまで待機すれば十分である。PMTU 探索のプロセスが正しい PMTU を推定するためにいくつかのステップを必要とする場合、これは多くの往復時間により接続を遅延させる可能性がある。
Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU has changed, but only for the specific connection specified by the Datagram Too Big message. The datagram size used in the retransmission should, of course, be no larger than the new PMTU. 代案として、パス MTU の変化の通知に応えてすぐに再送信を行うが、Datagram Too Big メッセージによって特定される接続の場合に限定することもできる。当然ながら、再送信で使用されるデータグラムサイズは新しい PMTU より大きくないべきである。
Note: One MUST not retransmit in response to every Datagram Too Big message, since a burst of several oversized segments will give rise to several such messages and hence several retransmissions of the same data. If the new estimated PMTU is still wrong, the process repeats, and there is an exponential growth in the number of superfluous segments sent! 注意：複数の大きすぎるセグメントのバーストは複数の Datagram Too Big メッセージとそれによる同じデータの複数の再送信とを引き起こすため、すべての Datagram Too Big メッセージに対して再送信を行ってはならない(MUST)。新しく推測された PMTU がまだ間違っていた場合、このプロセスが繰り返され、余分なセグメントの送信数が急激に増加する。
This means that the TCP layer must be able to recognize when a Datagram Too Big notification actually decreases the PMTU that it has already used to send a datagram on the given connection, and should ignore any other notifications. これは、特定の接続上でデータグラムを送信するのにすでに使用された PMTU を Datagram Too Big 通知が実際に減らしたときを TCP レイヤが認識できなければならず、他の通知を無視するべきであることを意味する。
Modern TCP implementations incorporate "congestion advoidance" and "slow-start" algorithms to improve performance [4]. Unlike a retransmission caused by a TCP retransmission timeout, a retransmission caused by a Datagram Too Big message should not change the congestion window. It should, however, trigger the slow-start mechanism (i.e., only one segment should be retransmitted until acknowledgements begin to arrive again). 最新の TCP 実装はパフォーマンスを改善するために "輻輳回避(congestion advoidance)" および "スロースタート(slow-start)" のアルゴリズムを組み込んでいる[4]。TCP の再送信タイムアウトによって引き起こされる再送信とは異なり、Datagram Too Big メッセージよって引き起こされる再送信は輻輳ウィンドウを変更しないべきである。しかしながらスロースタートメカニズムは始動させるべきである(つまり肯定応答が再び到着し始めるまで、ただひとつのセグメントが再送信されるべきである)。
TCP performance can be reduced if the sender's maximum window size is not an exact multiple of the segment size in use (this is not the congestion window size, which is always a multiple of the segment size). In many system (such as those derived from 4.2BSD), the segment size is often set to 1024 octets, and the maximum window size (the "send space") is usually a multiple of 1024 octets, so the proper relationship holds by default. If PMTU Discovery is used, however, the segment size may not be a submultiple of the send space, and it may change during a connection; this means that the TCP layer may need to change the transmission window size when PMTU Discovery changes the PMTU value. The maximum window size should be set to the greatest multiple of the segment size (PMTU - 40) that is less than or equal to the sender's buffer space size. 送信側の最大ウィンドウサイズが使用中のセグメントの正確な整数倍ではない場合、TCP のパフォーマンスが下がる可能性がある(これは輻輳ウィンドウサイズではない。輻輳ウィンドウサイズは常にセグメントサイズの倍数である)。多くのシステム(例えば 4.2BSD から派生したシステム)では、セグメントサイズがしばしば 1024 オクテットに設定され、最大ウィンドウサイズ("送信空間(send space)")は通常 1024 オクテットの倍数であるため、デフォルトで適切な関係を持つ。しかしながら PMTU 探索が使用される場合、セグメントサイズが送信空間の約数ではない可能性があり、かつ接続中に変化する可能性がある。これは PMTU 探索が PMTU 値を変更したとき、TCP レイヤが送信ウィンドウサイズを変更する必要があるかもしれないということを意味する。最大ウィンドウサイズは送信者のバッファサイズ以下、かつセグメントサイズ(PMTU - 40)の最大の倍数にセットされるべきである。
PMTU Discovery does not affect the value sent in the TCP MSS option, because that value is used by the other end of the connection, which may be using an unrelated PMTU value. PMTU 探索は TCP の MSS オプションにおいて送信される値に影響を与えない。その値は関係のない PMTU 値を使用しているであろう接続の相手側が使用する値であるためである。
Some transport protocols (such as ISO TP4 [3]) are not allowed to repacketize when doing a retransmission. That is, once an attempt is made to transmit a datagram of a certain size, its contents cannot be split into smaller datagrams for retransmission. In such a case, the original datagram should be retransmitted without the DF bit set, allowing it to be fragmented as necessary to reach its destination. Subsequent datagrams, when transmitted for the first time, should be no larger than allowed by the Path MTU, and should have the DF bit set. 一部のトランスポートプロトコル(ISO TP4 [3] など)は、再送信の際の再パケット化を許されていない。つまりいったん特定サイズのデータグラムの送信を試みると、再送信のためにその内容をより小さいデータグラムに分割することができない。そのような場合、宛先に到達するために必要なフラグメント化を許可するために、DF ビットをセットせずに元のデータグラムを再送信するべきである。後続のデータグラムは最初の送信時にパス MTU が許すサイズより大きくないべきであり、また DF ビットをセットされるべきである。
The Sun Network File System (NFS) uses a Remote Procedure Call (RPC) protocol [11] that, in many cases, sends datagrams that must be fragmented even for the first-hop link. This might improve performance in certain cases, but it is known to cause reliability and performance problems, especially when the client and server are separated by routers. Sun Network File System (NFS) は、多くの場合に第 1 ホップリンクであってもフラグメント化されなければならないデータグラムを送信する Remote Procedure Call (RPC) プロトコルを使用する。これはある特定のケースでパフォーマンスを改善する可能性があるが、特にクライアントとサーバーとがルータによって分断されている場合に、信頼性とパフォーマンスの問題を引き起こすことが知られている。
We recommend that NFS implementations use PMTU Discovery whenever routers are involved. Most NFS implementations allow the RPC datagram size to be changed at mount-time (indirectly, by changing the effective file system block size), but might require some modification to support changes later on. 私たちはルータが関与する場合には常に NFS 実装が PMTU 探索を使用することを推奨する。大部分の NFS 実装はマウント時に RPC のデータグラムサイズを(有効なファイルシステムのブロックサイズを変更することで間接的に)変更することを許しているが、それ以降の変更をサポートするには何らかの修正を必要とする可能性がある。
Also, since a single NFS operation cannot be split across several UDP datagrams, certain operations (primarily, those operating on file names and directories) require a minimum datagram size that may be larger than the PMTU. NFS implementations should not reduce the datagram size below this threshold, even if PMTU Discovery suggests a lower value. (Of course, in this case datagrams should not be sent with DF set.) また、単一の NFS 操作を複数の UDP データグラムに分割することはできないため、特定の操作(主にファイル名とディレクトリとに関する操作)は最小データグラムサイズを必要とし、それが PMTU より大きい可能性がある。たとえ PMTU 探索が小さい値を示したとしても、NFS はデータグラムサイズをこの閾値未満に減らしてはならない。(当然ながら、この場合のデータグラムは DF ビットをセットされてはならない。)
We suggest that an implementation provide a way for a system utility program to: 私たちは任意のシステムユーティリティプログラムに対し実装が以下の手段を提供することを推奨する：
The former can be accomplished by associating a flag with the routing entry; when a packet is sent via a route with this flag set, the IP layer leaves the DF bit clear no matter what the upper layer requests. 前者はルーティングエントリにフラグを結びつけることで実現される。そのフラグをセットされた経路を通してパケットが送信されるとき、IP レイヤは上位レイヤのリクエストに関係なく DF ビットをクリアしたままにする。
These features might be used to work around an anomalous situation, or by a routing protocol implementation that is able to obtain Path MTU values. これらの機能は異常な状況を回避するために使用されるか、パス MTU 値を取得する能力を持つルーティングプロトコル実装によって使用される可能性がある。
The implementation should also provide a way to change the timeout period for aging stale PMTU information. 実装は古い PMTU 情報を劣化させるためのタイムアウト期間を変更する手段も提供するべきである。
The algorithm recommended in section 5 for "searching" the space of Path MTUs is based on a table of values that severely restricts the search space. We describe here a table of MTU values that, as of this writing, represents all major data-link technologies in use in the Internet. パス MTU の空間を "検索する(searching)" ためにセクション 5 で推奨されているアルゴリズムは、検索空間を大幅に限定する値のテーブルに基づいている。ここで私たちは、(これを書いている時点で)インターネットにおいて使用されている主なデータ回線技術を代表する MTU 値の一覧を記載する。
In table 7-1, data links are listed in order of decreasing MTU, and grouped so that each set of similar MTUs is associated with a "plateau" equal to the lowest MTU in the group. (The table also includes some entries not currently associated with a data link, and gives references where available). Where a plateau represents more than one MTU, the table shows the maximum inaccuracy associated with the plateau, as a percentage. 表 7-1 は、データリンクを MTU の降順で、類似の MTU の各集合をグループ内で最小の MTU に等しい "プラトー(plateau)" に対応するようにグループ化して示している。(この表には現時点でデータ回線に対応していないエントリもいくつか含まれており、入手可能な場合には参照も示されている。) プラトーがひとつ以上の MTU を表す場合、そのプラトーに対応する最大誤差をパーセンテージで示している。
We do not expect that the values in the table, especially for higher MTU levels, are going to be valid forever. The values given here are an implementation suggestion, NOT a specification or requirement. Implementors should use up-to-date references to pick a set of plateaus; it is important that the table not contain too many entries or the process of searching for a PMTU might waste Internet resources. Implementors should also make it convenient for customers without source code to update the table values in their systems (for example, the table in a BSD-derived Unix kernel could be changed using a new "ioctl" command). 私たちは、この表の中の値(特に高い水準の MTU の値)が永久に有効であり続けるとは思っていない。ここに示されている値は実装への提案であり、仕様または要求事項ではない。実装者はプラトーの集合を選ぶために最新の資料を使用するべきである。この表がエントリを多く含みすぎていないことは重要である。さもなければ PMTU を検索する行為がインターネットリソースを浪費するだろう。また実装者は、ソースコードを持たない顧客が彼らのシステムのテーブル値を更新しやすくするべきである(例えば BSD から派生した Unix カーネル内のテーブルは、新しい "ioctl" コマンドを使用して変更することができる)。
Note: It might be a good idea to add a few table entries for values equal to small powers of 2 plus 40 (for the IP and TCP headers), where no similar values exist, since this seems to be a reasonably non-arbitrary way of choosing arbitrary values. 注意：類似値が存在しない場合、2 の小さい累乗に(IP および TCP のヘッダのための) 40 を加えた値に等しい少数のテーブルエントリを追加するのはよい考えだろう。任意の値を選択する合理的で独断的でない方法と思われるためである。
The table might also contain entries for values slightly less than large powers of 2, in case MTUs are defined near those values (it is better in this case for the table entries to be low than to be high, or else the next lowest plateau may be chosen instead). このテーブルは 2 の大きな累乗よりわずかに小さい値のエントリを、そのような値の近辺で MTU が定義された場合に備えて含んでもよい(この場合、テーブルエントリが大きいより小さいほうが優れている。さもないと、代わりに次に小さいプラトーが選択される可能性がある)。
Section 6.3 suggests detecting increases in the PMTU value by periodically increasing the PTMU estimate to the first-hop MTU. Since it is likely that this process will simply "rediscover" the current PTMU estimate, at the cost of several dropped datagrams, it should not be done often. セクション 6.3 は、第 1 ホップへの PMTU 推定値を定期的に増やすことで PMTU 値の増加を検出することを提案している。この手順はいくつかのデータグラムの破棄を犠牲にして現在の PMTU 推定値を単純に "再発見(rediscover)" することになると考えられるため、頻繁に行われないべきである。
A better approach is to periodically increase the PMTU estimate to the next-highest value in the plateau table (or the first-hop MTU, if that is smaller). If the increased estimate is wrong, at most one round-trip time is wasted before the correct value is rediscovered. If the increased estimate is still too low, a higher estimate will be attempted somewhat later. より優れたアプローチは、プラトーテーブル内の次に高い値(または第 1 ホップの MTU の方が小さければその値)まで PMTU 推定値を定期的に増加させることである。増加させた推定値が誤っている場合、正しい値を再発見する前に多くとも 1 往復だけ無駄にする。増加させた推定値がまだ小さい場合、しばらく後により高い推定値が試行される。
Because it may take several such periods to discover a significant increase in the PMTU, we recommend that a short timeout period should be used after the estimate is increased, and a longer timeout be used after the PTMU estimate is decreased because of a Datagram Too Big message. For example, after the PTMU estimate is decreased, the timeout should be set to 10 minutes; once this timer expires and a larger MTU is attempted, the timeout can be set to a much smaller value (say, 2 minutes). In no case should the timeout be shorter than the estimated round-trip time, if this is known. PMTU の大幅な増加を見つけるためにはそのような期間をいくつか必要とするため、推定値が増加した後には短いタイムアウト期間を使用し、Datagram Too Big メッセージにより PMTU 推定値が減少した後には長いタイムアウトを使用することを推奨する。例えば PMTU 推定値が減少した後、タイムアウトを 10 分に設定するべきであり、そのタイマーの期限が切れてより大きい MTU が試行された後、タイムアウトをずっと小さい値(例えば 2 分)に設定することができる。これが周知されていれば、タイムアウトは推定される往復時間より短くならないはずである。
Plateau MTU Comments Reference
------ --- -------- ---------
65535 Official maximum MTU RFC 791
65535 Hyperchannel RFC 1044
65535
32000 Just in case
17914 16Mb IBM Token Ring ref. [6]
17914
8166 IEEE 802.4 RFC 1042
8166
4464 IEEE 802.5 (4Mb max) RFC 1042
4352 FDDI (Revised) RFC 1188
4352 (1%)
2048 Wideband Network RFC 907
2002 IEEE 802.5 (4Mb recommended) RFC 1042
2002 (2%)
1536 Exp. Ethernet Nets RFC 895
1500 Ethernet Networks RFC 894
1500 Point-to-Point (default) RFC 1134
1492 IEEE 802.3 RFC 1042
1492 (3%)
1006 SLIP RFC 1055
1006 ARPANET BBN 1822
1006
576 X.25 Networks RFC 877
544 DEC IP Portal ref. [10]
512 NETBIOS RFC 1088
508 IEEE 802/Source-Rt Bridge RFC 1042
508 ARCNET RFC 1051
508 (13%)
296 Point-to-Point (low delay) RFC 1144
296
68 Official minimum MTU RFC 791
Table 7-1: Common MTUs in the Internet
プラトー MTU コメント 参照
-------- --- -------- ---------
65535 公式な最大 MTU RFC 791
65535 Hyperchannel RFC 1044
65535
32000 念のために
17914 16Mb IBM Token Ring ref. [6]
17914
8166 IEEE 802.4 RFC 1042
8166
4464 IEEE 802.5 (最大 4Mb) RFC 1042
4352 FDDI (改訂された) RFC 1188
4352 (1%)
2048 Wideband Network RFC 907
2002 IEEE 802.5 (4Mb 推奨) RFC 1042
2002 (2%)
1536 Exp. Ethernet Nets RFC 895
1500 Ethernet Networks RFC 894
1500 Point-to-Point (デフォルト) RFC 1134
1492 IEEE 802.3 RFC 1042
1492 (3%)
1006 SLIP RFC 1055
1006 ARPANET BBN 1822
1006
576 X.25 Networks RFC 877
544 DEC IP Portal ref. [10]
512 NETBIOS RFC 1088
508 IEEE 802/Source-Rt Bridge RFC 1042
508 ARCNET RFC 1051
508 (13%)
296 Point-to-Point (低遅延) RFC 1144
296
68 公式な最小 MTU RFC 791
表 7-1： インターネットにおける一般的な MTU
This Path MTU Discovery mechanism makes possible two denial-of- service attacks, both based on a malicious party sending false Datagram Too Big messages to an Internet host. このパス MTU 探索のメカニズムは、二つのサービス不能攻撃(共にインターネットに不正な Datagram Too Big メッセージを送信する悪意ある集団に基づく)を可能にする。
In the first attack, the false message indicates a PMTU much smaller than reality. This should not entirely stop data flow, since the victim host should never set its PMTU estimate below the absolute minimum, but at 8 octets of IP data per datagram, progress could be slow. ひとつ目の攻撃では、不正なメッセージが実際よりずっと小さい PMTU を提示する。犠牲となったホストが絶対的な最小値未満の値を PMTU にセットすることはないため、これにより完全にデータフローが止められることはないはずである。しかしデータグラムごとに 8 オクテットの IP データでは進行が遅くなるだろう。
In the other attack, the false message indicates a PMTU greater than reality. If believed, this could cause temporary blockage as the victim sends datagrams that will be dropped by some router. Within one round-trip time, the host would discover its mistake (receiving Datagram Too Big messages from that router), but frequent repetition of this attack could cause lots of datagrams to be dropped. A host, however, should never raise its estimate of the PMTU based on a Datagram Too Big message, so should not be vulnerable to this attack. もう一方の攻撃では、不正なメッセージが実際より大きい PMTU を提示する。これが信用されると、犠牲者はどこかのルータによって破棄されるであろうデータグラムを送信することになり、一時的な妨害を引き起こす。1 往復内にホストは自身の間違いを(ルータから Datagram Too Big メッセージを受信することで)見つけるだろうが、この攻撃を頻繁に繰り返すことで多数のデータグラムを破棄させることができるだろう。しかしながらホストは Datagram Too Big メッセージに基づいて PMTU の推定値を上げるべきではないため、この攻撃に対して脆弱ではないはずである。
A malicious party could also cause problems if it could stop a victim from receiving legitimate Datagram Too Big messages, but in this case there are simpler denial-of-service attacks available. 悪意ある集団は正当な Datagram Too Big メッセージを被害者が受信するのを阻止することでも問題を引き起こすことができるだろう。しかしその場合、有効なより簡単なサービス不能攻撃が存在する。
Jeffrey Mogul Digital Equipment Corporation Western Research Laboratory 100 Hamilton Avenue Palo Alto, CA 94301 Phone: (415) 853-6643 EMail: mogul@decwrl.dec.com Steve Deering Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: (415) 494-4839 EMail: deering@xerox.com