RFC1191 日本語訳
1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990. (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT STANDARD)
RFC一覧
英語原文
Network Working Group J. Mogul
Request for Comments: 1191 DECWRL
Obsoletes: RFC 1063 S. Deering
Stanford University
November 1990
Path MTU Discovery
経路 MTU 探索
Status of this Memo
このメモの位置づけ
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 は、Internet community のための IAB Standards Track でのプロ
トコルを明細に記述し、改良のための議論と提案を要求するものである。この
プロトコルの標準化状態と状態について "IAB Official Protocol Standards"
の最新版を参照してもらいたい。このメモの配布は、無制限である。
-------------------------------------------------------------------------
Table of Contents
目次
Status of this Memo 1
Abstract 2
Acknowledgements 2
1. Introduction 2
2. Protocol overview 3
3. Host specification 4
3.1. TCP MSS Option 5
4. Router specification 6
5. Host processing of old-style messages 7
6. Host implementation 8
6.1. Layering 9
6.2. Storing PMTU information 10
6.3. Purging stale PMTU information 11
6.4. TCP layer actions 13
6.5. Issues for other transport protocols 14
6.6. Management interface 15
7. Likely values for Path MTUs 15
7.1. A better way to detect PMTU increases 16
8. Security considerations 18
References 18
Authors' Addresses 19
このメモの位置づけ 1
要約 2
謝辞 2
1. 序論 2
2. プロトコルの概観 3
3. ホスト仕様書 4
3.1. TCP MSS オプション 5
4. ルータ仕様書 6
5. 古いスタイルメッセージのホストでの処理 7
6. ホストでの実装 8
6.1. 層 9
6.2. PMTU 情報の保存 10
6.3. 古い PMTU 情報の追放 11
6.4. TCP 層のふるまい 13
6.5. 他のトランスポート層についての問題 14
6.6. 管理インターフェイス 15
7. 経路 MTUs の適当な値 15
7.1 PMTU 増加を発見するための良い方法 16
8. セキュリティに関する考察 18
参考文献 18
著者のアドレス 19
List of Tables
表目次
Table 7-1: Common MTUs in the Internet 17
表 7-1: Internet での一般 MTUs
-------------------------------------------------------------------------
Abstract
概要
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.
このメモは、気まぐれな internet 経路の最大転送単位 (MTU) を動的に探索
するためのテクニックを記述する。これは、ルータが ICMP メッセージの一つ
のタイプを生成する方法への少しの変更を詳細に記述する。変更されないルー
タを通過する経路について、このテクニックは正しい Path MTU を探索できな
いかもしれない。しかしこれは、現在の実行によって選ばれるだろう Path
MTU と同じぐらい正確な Path MTU をいつも選ぶだろうし、多くのケースでよ
り正確である。
-------------------------------------------------------------------------
Acknowledgements
謝辞
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 Gruop の月だけかかる基礎アイデアを二つの短いパラ
グラフで説明した。
-------------------------------------------------------------------------
1. Introduction
1. 序論
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 datagrams の連続として送信される。これら datagrams がどこか始
点から終点経路に fragmentation (分割) を必要としないことが、たいてい望
ましい。(fragmentation に対するケースについて、[5] を参照しなさい。)
この datagram サイズは、Path MTU (PMTU) として参照され、その経路でそれ
ぞれの hop の MTUs の最小値に等しい。現在の Internet Protocol 体系の欠
点は、気まぐれな経路の 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).
注意: Path MTU は、[1] で "Effective MTU for sending" (EMTU_S)
と呼ばれていたものである。PMTU は経路と関連し、そしてそれは特定
の IP 始点アドレスと終点アドレスの組み合わせとたぶん
Type-of-service (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.
現在の慣習は、576 byte より小さいのと、同じ network に接続されていない
どんな終点についてもか、始点としての subnet について PMTU として最初の
hop MTU を使用することである。多くのケースで、これは必要とするよりもさ
らに小さい datagrams の使用という結果となる。なぜなら多くの経路は、576
byte より大きい PMTU を持っているからである。割り当てた PMTU よりも非
常に小さい datagrams を送信しているホストは、Internet resources を浪費
し、たぶん最適以下の throughput を得る。それだけでなく、576 byte より
小さい PMTU の経路があるので、現在の慣習はすべてのケースで
fragmentation を防がない。
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.
将来の経路制御プロトコルは、routing area 内で正確な PMTU 情報を提供す
ることが出来ることを期待される。しかしたぶん multi-level routing 階層
は横切らない。すぐにそれが同時に至るところで利用可能にする方法は明らか
ではない。それで resources を浪費せずに PMTU を探索し、すべてのホスト
とルータが変更される前にはたらく単純なメカニズムをこれから何年かの間に
Internet は必要とする。
-------------------------------------------------------------------------
2. Protocol overview
2. プロトコルの概観
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.
このメモで、われわれは IP ヘッダの Don't Fragment (DF) の使用が、経路
上の PMTU を動的に探索することのテクニックを記述する。基礎アイデアは、
始点ホストが、最初に経路の PMTU が最初の hop の (知られた) MTU と当然
思い、その経路に DF bit をセットしたすべての datagrams を送信すること
である。もしなんらかの datagrams のサイズが大変大きく経路のあるルータ
によって fragmentation なしに転送できないなら、そのルータはそれらを捨
て、"fragmentation が必要だが DF がセットされている" [7] を意味してい
るコード ICMP Destination Unreachable message を返す。そのような
message (これからは "Datagram Too Big" message と呼ぶ) を受け取って、
始点ホストはその経路について想定された 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.
datagrams が fragmentation なしに転送できるぐらいホストの PMTU の見積
りが十分に小さくなった時、PMTU 探索プロセスは終了する。もしくは、ホス
トは datagram ヘッダに DF bit のセットをやめることにより探索プロセスを
終了することを選ぶだろう。もし route が変更したり新しい PMTU が小さく
なるなら、PMTU が探索されるように、通常ホストはすべての datagrams に
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 message は拒否
された datagram が大変大きい時の hop の MTU を報告しない。それで始点ホ
ストは、その想定された PMTU をどれだけ減らせばよいか正確にわかることが
出来ない。これを改善するために、Datagram Too Big message で現在使用し
ていないヘッダ field を狭い hop の MTU を報告するために使用することを
われわれは提案する。これは、PMTU Discovery のサポートでのルータに指定
された唯一の変更である。
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.
routing topology の変化のために、経路の PMTU は通信時間の間、変化する
かもしれない。ホストが DF bit のセットをやめる経路を除いて、PMTU の縮
小は Datagram Too Big messages により発見される。経路の PMTU の増加を
発見するために、ホストは周期的にその想定された PMTU を増加する (そして
もしそれが停止していたなら、DF bit のセットを再び始める)。これは、ほと
んどいつも datagrams が捨てられ、Datagram Too Big messages が生成され
るという結果となるだろう。なぜなら多くのケースで、経路の PMTU は変更し
ないだろうし、これはまれにおこなわれるだろうからである。
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 Discovery をおこなう peer からど
んな fragments を受信しないということを保証するので、(不正確に) 分割さ
れた datagrams を再構成することが出来ない確実なホストで内部処理するの
を助けるかもしれない。
-------------------------------------------------------------------------
3. Host specification
3. ホスト仕様書
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 messages を受信した時、message 内の Next-Hop
MTU field の値に基づく、関連する経路について PMTU の見積りを減らさなけ
ればならない (MUST) (section 4 を参照しなさい)。異なった applications
が異なった要求を持つかもしれなく、また異なった実装 architectures が異
なった戦略を支持するかもしれないので、われわれはこの環境での正確なホス
トのふるまいを明細に述べない。
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 messages を受信した後、ホストは近い将来に、多くのその
ような messages を引き出すことを避けることを試みなければならない
(MUST) ことを、われわれはぜひ要求する。ホストは、その経路で送信してい
る datagrams のサイズを減らすか、それら datagrams のヘッダに Don't
Fragment bit をセットするのをやめるかもしれない。明らかに、前者の戦略
は、しばらくの間 Datagram Too Big messages を引き出し続けるかもしれな
いが、これら messages のそれぞれ (とそれらに応答する落とされる
datagrams) は Internet resources を消費するので、ホストは PMTU
Discovery プロセスに集中することを強いる。
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 Discovery を使用するホストは、出来るだけ速く Path MTU での減少を
発見しなければならない (MUST)。ホストは、Path MTU の増加を発見するかも
しれない。しかし、そのようにすることは現在想定された PMTU より大きい
datagrams 送信することを要求するという理由と PMTU が増加しないだろうと
いう可能性という理由で、これはまれな間隔でおこなわれなければならない
(MUST)。(現在の想定より大きい datagrams を送信することによって) 増加を
発見する試みは、Datagram Too Big messages が与えられた終点に対して受信
された後で、5 分たたぬうちに決しておこなってはならない (MUST NOT)。ま
たは前の成功した試みた増加の後で、1 分たたぬうちに決しておこなってはな
らない (MUST NOT)。われわれは、それら最小値の 2 倍 (それぞれ 10 分と 2
分) これらの timer をセットすることを推奨する。
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).
有限時間で Internet のすべてのルータを upgrade することは実行可能でな
いので、ホストは、next-hop MTU を含まない Datagram Too Big messages を
扱うことが出来なければならない (MUST)。変更されないルータから Datagram
Too Big message は、(新しく定義された) Next-Hop MTU field での zero の
存在によって認識されることが出来る。(これは ICMP 仕様書 [7] によって要
求され、そしてそれは zero でなければならない "unused" field と言う。)
section 5 で、(変更されないルータによって送信される一つの) 古いスタイ
ルの Datagram Too Big message の応答に従うホストについて可能な戦略を、
われわれは議論する。
A host MUST never reduce its estimate of the Path MTU below 68
octets.
ホストは、68 octets より以下の Path MTU の見積もりを、決して減らしては
ならない (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 message の中身への応答の Path MTU の見積も
りを増加してはならない (MUST)。Path MTU の増加を知らせる意味の message
は、Internet で漂流している古い datagram か、denial-of-service attack
の部分として導入された偽りの packet か、終点に複数経路を持つ結果かもし
れない。
3.1. TCP MSS Option
3.1. TCP MSS オプション
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 Discovery をおこなうホストは
576 octets より大きい IP datagrams を送信しない規則に従わなければなら
ない。TCP 接続について、これは、その peer によって送信される Maximum
Segment Size (MSS) を加えての 40 octets より大きい datagrams をホスト
は送信してはならないことを意味する。
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 は、40 を引いた関連する IP datagram size であるよ
うに定義される [9]。最大 IP datagram サイズの 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] の
Section 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 実装は、もし終点ホストが接続されていない network で
あるなら、MSS option のみを送信する。しかしながら、一般に TCP
層は、この決定を作る適した情報を持っていないだろう。それで
Internet 経路について適当な MTU を決定する IP 層 task を残すこ
とがより望ましい。
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 option を送信するが、もし終点が
local でないなら、536 に値をセットする。576 octets より大きい
datagrams が local でない終点に送信されるべきでない規則に従わないホス
トで Internet がいっぱいである時、このふるまいは正しい。いまやたいてい
のホストは、この規則にほんとに従っているから、local でない peer につい
て 536 に TCP MSS option で値を制限する必要はない。
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.
その上、これをすることは 576 より大きい PMTUs の発見から PMTU
Discovery を妨げる。それでホストは、もはや MSS option で送信する値より
も小さくない。MSS option はホストが再構成 ([[1] で定義されるとして
MSS_R) 出来るもっとも大きい datagram のサイズより小さい 40 octets にす
べきである; 多くのケースで、これは 65495 (65535 - 40) octets の
architectural 制限である。ホストは接続された network の MTU
(multi-homed ホストについて、その接続された network の最大 MTU) から派
生された MSS 値を送信するかもしれない (MAY); これは、PMTU Discovery に
ついて問題の原因となるべきでなく、分散した peer に非常に大きい
datagrams を送信しないように説得するかもしれない。
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.
注意: ちょうど今は、接続された network の最大 MTU より大きな
MSS を送信する理由はないように判断する。それと、われわれはホス
トが 65495 を使用しないことを推奨する。そのような大きな MSS の
必要でない使用によっておもしろがらせる sign-bit bug を、一部の
IP 実装が持つことは実際可能である。
-------------------------------------------------------------------------
4. Router specification
4. ルータ仕様書
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:
datagram が next-hop network の MTU を越えて、それに Don't Fragment
bit がセットされているという理由で、ルータが datagram を forward する
ことが出来ない時、ルータは "fragmentation needed and DF set" を指し示
している Code をその datagram の始点に ICMP Destination Unreachable
message を返すことが必要とされる。このメモで明細に述べられる Path MTU
Discovery 技術をサポートするために、ICMP 仕様書 [7] で "unused" にラベ
ルされた ICMP ヘッダ field の low-order 16 bits に next-hop network の
MTU を、ルータは含まなければならない (MUST)。high-order 16 bits は
unused のままで、zero にセットされなければならない (MUST)。したがって
message は次の書式を持つ:
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 | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet ヘッダ + もともとの Datagram Data の 64 bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value carried in the Next-Hop MTU field is:
Next-Hop 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.
このルータで分割されることなしに、もともとの datagram の経路で
forward されることが出来るもっとも大きな datagram の octets で
のサイズ。このサイズは、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 octets の datagram を forward 出来るよ
うにしなければならない" ので、この field は 68 より小さい値を決して含
まない。
-------------------------------------------------------------------------
5. Host processing of old-style messages
5. 古いスタイルメッセージのホストでの処理
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.
このセクションで、変更されないルータ (すなわち Next-Hop MTU field が
zero であるもの) から Datagram Too Big message を受信して理解するホス
トについて、われわれはいくつかの可能な戦略の概要を述べる。このセクショ
ンは、プロトコル仕様書の一部分ではない。
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.
そのような message に応答するホストについてもっとも簡単なことは、PMTU
はその現在想定された PMTU と 576 の最小値であると思うことと、その経路
で送信される datagrams に DF bit をセットすることをやめることである。
したがってホストは、現在の慣習のもとで選ばれるとして、同じ PMTU に後退
する ("Requirements for Internet Hosts -- Communication Layers" [1] の
section 3.3.3 を参照しなさい)。この戦略は、すばやく終結され存在する慣
習より悪くないという長所を持つ。しかしながら、一部のケースで
fragmentation を避けることと、他のケースでのもっとも多くの
internetwork の効果的な利用をすることは失敗する。
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.
datagrams のサイズが変化する間、DF bit を持つ datagrams を送信し続ける
ことにより、正確な PMTU 見積もりのために "searching" を、多くの洗練さ
れた戦略は必然的に含む。よい検索戦略は、プロセスで多くのパケットに失わ
させることなしに、Path 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 見積も
りに algorithmic 機能を適用する。たとえば、一定 (たとえば 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.
多くの洗練された方法は、パケットサイズで binary search をすることであ
る。それでも FDDI MTU から Ethernet MTU に集まるために 4 か 5 ステップ
かかるけれども、これはいくぶん速く集まる。datagram が他方に (現在の見
積もりが大変小さいことを指し示して) それをおこなう時、重大な障害は認識
するために複雑な実装を必要とすることである。われわれも、この戦略を推奨
しない。
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.)
実際よく働くように見える一つの戦略は、実際に Internet で使用するのに、
比較的少ない MTU の監視から始める。したがって、気ままに選ばれた値を通
して向こうみずに検索するよりも、われわれはたぶんそう見えるだろう値のみ
を検索することが出来る。その上、設計者は同じような方法で MTUs を選ぶ傾
向があるので、同じような MTU 値のグループを集めることは可能であり、わ
れわれの検索 "plateau" としてグループのもっとも小さい値を使用すること
は可能である。(1 octet によって MTU を過大評価するより、数パーセントに
よって低く見積もるほうが、明らかによりよい。)
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 plateaus
table に、われわれがこの結論にどのように到達したかを議論する。この
table で、収束は、最悪のケースの binary search と同じほどよく、一般の
ケースではるかによりよい (たとえば、FDDI MTU から Ethernet MTU に行く
ために 2 round-trip 時間のみかかる)。plateaus は 2 の階乗に近い状態で
あるので、もし MTU がこの table に表さないなら、アルゴリズムは 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" を持たなければならない。一つの方法は、Path MTU の現在
cache された想定を使用することである。しかし実際、Datagram Too Big
message それ自身に利用出来る、よりよい情報がある。この message を含む
すべての ICMP Destination Unreachable message は、もともとの datagram
の IP ヘッダを含み、それは fragmentation なしに forward される大変大き
い datagram の Total Length を含む。この 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 の Total Length について誤った値を送信する。これらルー
タによって送信された値は、(octet で表現された) もともとの Total
Length ともともとの Header Length の合計である。そのような
Datagram Too Big message を受信するホストが、それら誤ったルータ
から送信されたかどうかを知るのは不可能であるので、ホストは慎重
でなければならなく、そのようなことを当然だと思わなければならな
い。もし返された Total Length field が現在の PMTU 見積もりより
小さくないなら、返された Header Length field の 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 見積もりとして (もし必要なら、上
の Note に従って訂正された) 返された Total Length field より小さいもっ
とも大きな plateau 値を使用することである。
-------------------------------------------------------------------------
6. Host implementation
6. ホストでの実装
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 Discovery がホスト
software で実装されるかを、議論する。これは仕様書ではなく、それどころ
か提案の set である。
The issues include:
問題点として含まれているもの:
- What layer or layers implement PMTU Discovery?
- Where is the PMTU information cached?
- How is stale PMTU information removed?
- What must transport and higher layers do?
- どの層、もしくはどのいくつかの層が PMTU Discovery を実装するか ?
- どこで PMTU 情報を cache するか ?
- どのように古い PMTU 情報を取り除くか ?
- トランスポート層や上位層は何をしなければならないか ?
6.1. Layering
6.1. 層
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 architecture で、送信される datagram でどれほどのサイズを選択するか
は、IP の上位層プロトコルによっておこなわれる。われわれは、そのような
プロトコルを "packetization protocol" として参照する。packetization
protocols は、たいていトランスポートプロトコル (たとえば、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.
packetization 層での PMTU Discovery の実装は、いくつかの内部層問題を単
純化するが、いくつかの欠点を持つ: 実装はそれぞれの packetization
protocol をやり直さなければならないかもしれなく、異なった
packetization 層と、長い期間に PMTU 情報を保存するように簡単に拡張して
はならない一部の packetization 層によって維持されるコネクション指向状
態の間で 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 情報を保存するだろうことと ICMP 層
が受信した Datagram Too Big messages を処理するだろうことを信じる。
packetization 層も 送信した datagrams のサイズの変更による Path MTU の
変更に応答出来なければならなく、DF bit のセットで送信された datagrams
も特定出来るようにしなければならない。packetization 層、たぶん kernel
の外側の UDP application が datagram サイズを変更できないことがありう
るので、すべてのパケットにただ DF bit をセットするだけの IP 層を、われ
われは望まない。優雅ではないが、故意な fragmentation を必然的に含むプ
ロトコルは、ときどき成功し (主要な例で NFS)、われわれはこのようなプロ
トコル壊すことを望まない。
To support this layering, packetization layers require an extension
of the IP service interface defined in [1]:
この層をサポートするため、packetization 層は [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.
MSS_S の値の変更を知る方法 "maximum send transport-message
size" は、最小の IP ヘッダサイズを減らすことによって Path MTU
から派生される。
6.2. Storing PMTU information
6.2. PMTU 情報の保存
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 type-of-service を指し
示す。(一部の実装は、経路の始点アドレスを記録しない; これは
single-homed ホストのために容認でき、たった一つの可能な始点アドレスの
みを持つ。
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.)
この関連性を格納する明白な場所は、routing table エントリの field とし
てである。ホストは、すべての可能な終点についての経路を持たないだろう。
しかしすべての active な終点についてホストごとの route を cache 出来る
ようにすべきである。(この要求は、すでに ICMP Redirect messages を処理
する必要により課せられる。)
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.
最初のパケットがホストごとの route が存在しないホストに送信される時、
route は network ごとの route のセットからか default route のセットか
ら選ばれる。それら route エントリの PMTU field は、関連された最初の
hop data link の MTU に初期化されるだろう。そして PMTU Discovery プロ
セスにより決して変更されない。(PMTU Discovery はホストごとの route の
みを生成し変更する。) Datagram Too Big message が受信されるまで、最初
に選ばれた route に関連された 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 message が受信された時、ICMP 層は (パケットの zero で
ない Next-Hop MTU 値か、section 5 で記述された方法を用いて) Path MTU
について新しい見積もりを決定する。もしこの経路についてホストごとの
route が存在しないなら、それからそれは作成される (ほとんど、あたかもホ
ストごとの ICMP Redirect が処理されたかのように; 新しい route は、現在
の route として同じ最初の hop を使用する)。もしホストごとの route に関
連された PMTU 見積もりが新しい見積もりよりも大きいなら、それから
routing エントリの値は変更される。
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.
packetization 層は、PMTU の減少について通知されなければならない。もし
PMTU 見積もりが減少されたなら、経路を活発に使用しているどんな
packetization 層 instance (たとえば、TCP connection) も通知されなけれ
ばならない。
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 message が UDP パケットを参照する
もともとの Datagram ヘッダを含んでいたとしても、もし何らかの
connection が与えられた経路を使用するなら、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 message を引き出した datagram を送信した
instance は、たとえ PMTU 見積もりが変更されないとしても、落とされた
datagram が再送するように、その datagram が落とされたことを通知される
べきである。
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 Quench message の通知を提供するよ
うに使用されるメカニズムに似ているように出来る。(4.2BSD に派生
されたシステムのような) 一部の実装で、存在する通知メカニズムは
特定の複雑な connection を見分けることが出来なく、それで追加の
メカニズムが必要である。
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 見積もりより大きい datagram を送信する
ことを試みるまで、実装は通知を延期することによる PMTU 減少につ
いて非同期通知メカニズムの使用を避けることが出来る。この方法で
試みは DF bit がセットして datagram が送信 (SEND) され datagram
が PMTU 見積もりより大きい時、SEND 機能は失敗して、ふさわしいエ
ラー指摘が返されるべきである。この方法は (UDP を使用するような)
connectionless packetization 層によりふさわしいだろうし、そして
それは (一部の実装で) ICMP 層から "notify" するのに困難かもしれ
ない。このケースで、通常の timeout に基づく再送メカニズムは、落
とされた datagrams から回復するのに使用されるだろう。
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 の変更について経路を使用する packetization 層 instance の通知は、
パケットが落とされた特定の instance の通知から全然異なっていること理解
するために重要である。packetization 層 instance がパケットを作り出した
いことを望むまで、前者は遅れるかもしれないが、後者は実際的なパケットの
生成をする (すなわち、pakcetization 層 instance の始点から非同期に) と
すぐにされるべきである。Datagram Too Big message により指し示された時
落とされたことが知られたそれらパケットについてのみ、再送はされるべきで
ある。(???)
6.3. Purging stale PMTU information
6.3. 古い PMTU 情報の追放
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.
Internetwork topology は動的である; routes は時間がたつと変化する。も
し新しい route が使用されはじめるなら、与えられた終点について探索され
る PMTU は悪いかもしれない。したがって、ホストによって cache される
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 Discovery を使用しているホストはいつも DF bit をセットするという
理由で、もし古い PMTU 値が大変大きいなら、いったん datagram が与えられ
た終点に送信されると、これはほとんどただちに探索されるだろう。古い
PMTU 値が大変小さいことを理解するそのようなメカニズムは存在しなく、そ
れで実装は cache された値を "age (ふけさせる)" べきである。PMTU 値がし
ばらくの間 (約 10 分程) 減らされない時、PMTU 見積もりは最初の hop の
data-link MTU にセットされるべきであり、packetization 層は変更を通知さ
れるべきである。これは、完全な PMTU Discovery プロセスに再び起こさせる
だろう。
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 (無限)" にそれをセットすることを含む、
timeout 接続時間を変更するための手段を提供すべきである。たとえ
ば、遅い serial line 経由で Internet の残り (?) に後で取り付け
られる、FDDI network に取り付けられたホストは、新しい local で
ない PMTU を決して探索するつもりはなく、それで 10 分ごとに落と
される datagram に耐えなければならなくは、ないべきである。
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.
この増加は決して落とされた datagram の表示に応答にならないので、上位層
は PMTU 見積もりの増加への応答に datagram を再送しなければならないこと
はない (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 が年を取ることの実装の一つの方法は、routing table エントリに
timestamp field を追加することである。この field は、PMTU が決して変更
されないことを指し示す、"reserved" 値に初期化される。Datagram Too Big
message の応答に PMTU が減らされるたびに、timestamp は現在の時間にセッ
トされる。
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 分に一度、timer 駆動 procedure は、routing table と "reserved" でな
いのと timeout 間隔より古い timpstamp のそれぞれのエントリをざっと調べ
る。
- The PMTU estimate is set to the MTU of the associated first
hop.
- Packetization layers using this route are notified of the
increase.
- PMTU 見積もりは、関連された最初の hop の MTU にセットされる。
- この route を使用する packetization 層は、増加を知らせる。
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.
もしホストごとの routes が取り除かれるなら、PMTU 見積もりは routing
table から現れないだろう; これは、ICMP Redirect message への応答に起こ
ることがありうる。または数分後に、確実な routing-table daemons が古い
route を削除するという理由で。また multi-homed では、topology 変化は異
なった始点インターフェイスの使用という結果となる。これが起こった時、も
し packetization 層が通知されないなら、それから現在大変小さい cache さ
れた PMTU 値を使用され続けるかもしれない。一つの解決法は、Redirect
message が route 変化の原因となるたびに、そして route が単に routing
table から削除されるたびに、可能な PMTU 変化の packetization 層を通知
することである。
Note: a more sophisticated method for detecting PMTU increases
is described in section 7.1.
注意: PMTU 増加を発見するための多くの洗練された方法は、section
7.1 で記述される。
6.4. TCP layer actions
6.4. TCP 層のふるまい
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 層は、connection の終点について PMTU を追跡しなければならない; こ
の datagram より大きいのは送信されるべきではない。単純な実装は、新しい
segment を作成したそれぞれの時間に、([1] で記述された GET_MAXSIZES イ
ンターフェイスを使用して) この値について IP 層に尋ねる。しかしこれは、
能率的でない。その上、"slow-start" 輻輳回避アルゴリズム [4] に従う TCP
実装は、典型的に PMTU から派生されたいくつかの他の値を計算し cache す
る。これら変数が更新されるように、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 実装も、その peer から受信した (536 に default の) MSS 値を格納し
なければならなく、PMTU に関係なく、この MSS より大きなどんな segment
も送信してはならない。4.xBSD 派生実装で、これは TCP state record に追
加の field を加えることを要求する。
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 message が受信された時、ICMP message
を送信したルータによって datagram は落とされることを意味する。他のどん
な落とされた segment としてこのことを扱うのに十分であり、再送 timer
process が segment の再送を引き起こすのに期限が切れるまで待つ。もし
PMTU Discovery process が正しい PMTU を見積もるために何ステップかを要
求するなら、これは多くの round-trip times により connection を遅らせう
る。
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.
二者択一的に、Datagram Too Big message により特定された特定の
connection のみを除いて、再送は Path MTU が変更した通知にただちに応答
しておこなわれることが出来る。もちろん、再送に使用される datagram のサ
イズは、新しい MTU より大きくはない。
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!
注意: いくつかの特大の segment の burst がいくつかのそのような
messages に対し増加を与え、これゆえ同じ data のいくつかの再送に
対し増加を与えるので、すべての Datagram Too Big message に応答
して再送してはならない (MUST)。もし新しい見積もられた PMTU も悪
いなら、process は繰り返し、不必要な送信される segment 数の急激
な増加がある。
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.
これは、Datagram Too Big 通知が実際には、与えられた connection
で datagram を送信するのにすでに使用する PMTU を減らす時、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 実装は、パフォーマンスを改良するために "congenstion avoidan
ce" と "slow-start" アルゴリズムを取り入れる [4]。TCP 再送 timeout に
より原因となる再送と違って、Datagram Too Big message により原因となる
再送は、輻輳 window を変更すべきでない。しかしながら、slow-start メカ
ニズムのきっかけとなるだろう (すなわち、再び acknowledgements が到着し
始めるまで、たった一つの segment は再送されるべきである)。
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.
もし送信側の最大 window サイズが使用されている segment サイズの正確な
倍数でないなら、TCP パフォーマンスは減少することになりうる (これは輻輳
window サイズではなく、いつも segment サイズの倍数である)。(4.2BSD か
ら派生されたような) 多くのシステムで、segment サイズはしばしば 1024
octets にセットされ、最大 window サイズ ("send space") はたいてい 1024
octets の倍数であり、それで適した関係は default に保管する。しかしなが
ら、もし PMTU Discovery が使用されるなら、segment サイズは send space
の倍数以下であるないかもしれないし、connection の間、変更するかもしれ
ない; これは、PMTU Discovery が PMTU 値を変更した時、TCP 層は転送
window サイズを変更することを必要とするかもしれないことを意味する。最
大 window サイズは、送信側の buffer space サイズより小さいか等しい
segment サイズ (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 Discovery は TCP MSS option の送信された値のふりをしない。なぜな
ら、その値は connection の他方によって使用され、関係されない PMTU 値を
使用するだろうからである。
6.5. Issues for other transport protocols
6.5. 他のトランスポートプロトコルについての問題
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] のような) 一部のトランスポートプロトコルは、再送をする時
に、再パケットするように割り当てられない。すなわち、いったん試みが確か
なサイズの datagram が転送されると、その内容は再送のためにもっと小さい
datagrams に分割することが出来ない。そのようなケースで、もともとの
datagram は、その終点に到達するのに必要としてそれが分割されるように割
り当てて、DF bit をセットしないで再送されるべきである。最初の時間に送
信された時、次の datagram は、Path MTU によって割り当てられたよりも大
きくあるべきではなく、DF bit をセットしておくべきである。
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) は Remote Procedure Call (RPC) プロトコ
ル [11] を使用し、多くのケースで、最初の hop link ついてでさえ分割され
なければならない datagrams を送信する。これは確実なケースでパフォーマ
ンスを改良されるかもしれない。しかし client と server がルータによって
分離される時、特に、信頼性とパフォーマンス問題の原因となることが知られ
る。
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 Discovery を使
用することを、われわれは推奨する。たいていの NFS 実装は、(間接に、効果
的な file system ブロックサイズを変更することによって) mount 時間で変
化される RPC datagram サイズを割り当てるが、これから後で変更をサポート
するためにいくつかの変更を必要とするかもしれない。
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 operation はいくつかの UDP datagrams を分割でき
ないので、確かな operation (おもに、file names と directories でのそれ
ら operating) は PMTU より大きいかもしれない最小 datagram サイズを必要
とする。たとえ PMTU Discovery がより小さい値を提案したとしても、NFS 実
装は、この threshold より下の datagram サイズを減らすべきでない。(もち
ろん、このケースで datagrams は DF をセットして送信されるべきでない。)
6.6. Management interface
6.6. 管理インターフェイス
We suggest that an implementation provide a way for a system utility
program to:
実装は system utility program のための方法を提供することを、われわれは
提案する:
- Specify that PMTU Discovery not be done on a given route.
- Change the PMTU value associated with a given route.
- PMTU Discovery は与えられた route 上でおこなわれないことを詳細に
記述。
- 与えられた route に関連された PMTU 値を変更。
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.
前者は、routing エントリで flag を関連することにより成し遂げられること
が出来る; パケットがこの flag をセットして route 経由で送信される時、
IP 層は、たとえ上位層が何かを要求しても、DF bit を明確にしておく。
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.
これらの面は、例外的な状況で働くようにや、Path MTU 値を得ることが出来
る routing プロトコル実装により使用されるかもしれない。
The implementation should also provide a way to change the timeout
period for aging stale PMTU information.
実装も、古い PMTU 情報に年を取らせることについて、timeout 期間を変更す
る方法を提供すべきである。
-------------------------------------------------------------------------
7. Likely values for Path MTUs
7. 経路 MTUs の適当な値
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.
Path MTUs の空間を "searching" のために section 5 で推奨されたアルゴリ
ズムは、検索空間をきびしく制限する値の table に基づく。この執筆から、
Internet で使用されるすべての主要な data-link technologies を表す MTU
値の table を、われわれはここで記述する。
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.
table 7-1 で、data links は MTU が減少する順序でリストされ、グループで
もっとも低い MTU に等しい "plateau" で関連される同じような MTU のそれ
ぞれのセットにグループ化される。(table も今は data link で関連されない
一部のエントリを含み、どこでも利用できる参照を与える。) plateau はある
MTU よりも多くを表す点では、table は割合として、plateau に関連された最
大の不正確を示す。
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 levels について table での値を、われ
われは期待しない。ここで与えられた値は、実装提案であり、仕様書でも要求
でもない (NOT)。実装者は、plateaus のセットを選ぶために、最新の参考を
使用すべきである; 大変多くのエントリを含まない table や Internet
resources を浪費するだろう PMTU 検索のプロセスは重要なことである。実装
者も、それらのシステムに table 値を更新するために source code なしに、
顧客について、それを便利にさせるべきである (たとえば、BSD 派生 Unix
kernel の table は、新しい "ioctl" command の使用で変更することが出来
る。)
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.
注意: これは気まぐれな値を選んでいるもっともな理由で気まぐれで
ない方法のように見えるので、同じような値が存在しない場合に、(IP
と TCP ヘッダのために) 40 を加えての 2 の小さい階乗に等しい値に
ついて、小数の table エントリを追加することは、よいアイデアかも
しれない。
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).
それらの値に近いように定義された MTU のケースで、table も大きな
2 の階乗より少しばかり小さい値のエントリを含むかもしれない (こ
のケースで、table エントリが高いよりも小さいことであることは、
よりよい。さもないと、次のもっとも小さい plateau がその代わりと
して選ばれるかもしれない。)
7.1. A better way to detect PMTU increases
7.1 PMTU 増加を発見するための良い方法
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.
section 6.3 は、最初の hop MTU に周期的に PMTU 見積もりを増加すること
により PMTU の増加を発見することを提案した。いくつかの落とされた
datagram の損失で、この process はたぶん単に現在の 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.
よりよい方法は、周期的に、plateau table での次のもっとも高い値 (または
は、もしそれが小さいなら、最初の hop MTU) に対して PMTU を増加すること
である。もし増加された見積もりが悪いなら、正しい値が再探索される前に、
多くて、round-trip time は浪費される。もし増加された見積もりがまだ小さ
いなら、さらに大きい見積もりが多少後で試みられるだろう。
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
PMTU の重要な増加を発見するために、いくつかのそのような期間がとられる
かもしれないという理由で、見積もりが増やされた後で、短い timeout 期間
が使用されるべきであることと、
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
表 7-1: Internet での一般 MTUs
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.
Datagram Too Big message の理由で PMTU 見積もりが減らされた後で、より
長い timeout が使用されるべきであることを、われわれは推奨する。たとえ
ば、PMTU 見積もりが減らされた後で、timeout は 10 分にセットされるべき
である; いったん、この timer の期限が切れてさらに大きな MTU が試みられ
たなら、timeout は非常に小さい値 (たとえば、2 分) にセットされることが
出来る。もしこれが知られなければ、決して想定された round-trip time よ
り小さい timeout にすべきではない。
-------------------------------------------------------------------------
8. Security considerations
8. セキュリティに関する考察
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.
この Path MTU Discovery メカニズムは、二つの、両方とも Internet ホスト
に偽造の Datagram Too Big messages を送信する悪意のある party に基づく
denial-of-service attack をさせることがありうる。
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.
最初の attack で、偽造の message は、事実より非常に小さい PMTU を指し
示す。被害ホストは決して確実な最小より下の PMTU 見積もりにセットされな
いので、完全に data flow を止めないだろう。しかし datagram ごとの IP
data の 8 octet で進行は遅くなりうる。
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.
もう一方の attack で、偽造の message は、事実より大きい PMTU を指し示
す。もし信じられたなら、これは一部のルータによって落とされるだろう
datagram を被害ホストは送信するとして、一時的な閉鎖の原因となりうる。
ある round-trip time 内で、ホストはその誤りを (ルータから Datagram Too
Big messages を受信して) 発見するだろう。しかしこの attack のひんぱん
な反復は、たくさんの落とされる datagram の原因となる。しかしながら、
Datagram Too Big message に基づく PMTU の見積もりをホストは決して上げ
るべきでなく、それでこの attack に弱くはないだろう。
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 messages の受信から犠牲を止めることが出
来るなら、悪意のある party も問題の原因となる。しかしこのケースで、よ
り簡単な利用できる denial-of-service attacks がある。
-------------------------------------------------------------------------
References
参考文献
[1] R. Braden, ed. Requirements for Internet Hosts -- Communication
Layers. RFC 1122, SRI Network Information Center, October, 1989.
[2] Geof Cooper. IP Datagram Sizes. Electronic distribution of the
TCP-IP Discussion Group, Message-ID
<8705240517.AA01407@apolling.imagen.uucp>.
[3] ISO. ISO Transport Protocol Specification: ISO DP 8073. RFC 905,
SRI Network Information Center, April, 1984.
[4] Van Jacobson. Congestion Avoidance and Control. In Proc. SIGCOMM
'88 Symposium on Communications Architectures and Protocols, pages
314-329. Stanford, CA, August, 1988.
[5] C. Kent and J. Mogul. Fragmentation Considered Harmful. In Proc.
SIGCOMM '87 Workshop on Frontiers in Computer Communications
Technology. August, 1987.
[6] Drew Daniel Perkins. Private Communication.
[7] J. Postel. Internet Control Message Protocol. RFC 792, SRI
Network Information Center, September, 1981.
[8] J. Postel. Internet Protocol. RFC 791, SRI Network Information
Center, September, 1981.
[9] J. Postel. The TCP Maximum Segment Size and Related Topics. RFC
879, SRI Network Information Center, November, 1983.
[10] Michael Reilly. Private Communication.
[11] Sun Microsystems, Inc. RPC: Remote Procedure Call Protocol. RFC
1057, SRI Network Information Center, June, 1988.
-------------------------------------------------------------------------
Authors' Addresses
著者のアドレス
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
一覧
スポンサーリンク
