RFC relevance of datagram

As per Relevance of the word datagram, we have this rfc below:

Network Working Group J.
Request for Comments: 1191
Obsoletes: RFC 1063 S.
Stanford
November 1990

Path MTU

Status of this

This RFC specifies a protocol on the IAB Standards Track for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited

Table of

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

List of

Table 7-1: Common MTUs in the Internet 17

Mogul & Deering [page 1]

RFC 1191 Path MTU Discovery November 1990

This memo describes a technique for dynamically discovering
maximum transmission unit (MTU) of an arbitrary internet path.
specifies a small change to the way routers generate one type of
message. For a path that passes through a router that has not
so changed, this technique might not discover the correct Path MTU
but it will always choose a Path MTU as accurate as, and in
cases more accurate than, the Path MTU that would be chosen
current practice

This proposal is a product of the 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
Working Group months to reinvent

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
preferable that these datagrams be of the largest size that does
require fragmentation anywhere along the path from the source to
destination. (For the case against fragmentation, see [5].)
datagram size is referred to as the Path MTU (PMTU), and it is
to the minimum of the MTUs of each hop in the path. A shortcoming
the current Internet protocol suite is the lack of a
mechanism for a host to discover the PMTU of an arbitrary path

Note: The Path MTU is what in [1] is called the "Effective
for sending" (EMTU_S). A PMTU is associated with a path
which is a particular combination of IP source and
address and perhaps a Type-of-service (TOS).

The current practice [1] is to use the lesser of 576 and
first-hop MTU as the PMTU for any destination that is not
to the same network or subnet as the source. In many cases,
results in the use of smaller datagrams than necessary, because
paths have a PMTU greater than 576. A host sending datagrams
smaller than the Path MTU allows is wasting Internet resources
probably getting suboptimal throughput. Furthermore,
practice does not prevent fragmentation in all cases, since there
some paths whose PMTU is less than 576.

Mogul & Deering [page 2]

RFC 1191 Path MTU Discovery November 1990

It is expected that future routing protocols will be able to
accurate PMTU information within a routing area, although perhaps
across multi-level routing hierarchies. It is not clear how
that will be ubiquitously available, so for the next several
the Internet needs a simple mechanism that discovers PMTUs
wasting resources and that works before all hosts and routers
modified

2. Protocol

In this memo, we describe a technique for using the Don't
(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
of a path is the (known) MTU of its first hop, and sends
datagrams on that path with the DF bit set. If any of the
are too large to be forwarded without fragmentation by some
along the path, that router will discard them and return
Destination Unreachable messages with a code meaning "
needed and DF set" [7]. Upon receipt of such a message (
called a "Datagram Too Big" message), the source host reduces
assumed PMTU for the path

The PMTU discovery process ends when the host's estimate of the
is low enough that its datagrams can be delivered
fragmentation. Or, the host may elect to end the discovery
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
some circumstances. Normally, the host continues to set DF in
datagrams, so that if the route changes and the new PMTU is lower,
will be discovered

Unfortunately, the Datagram Too Big message, as currently specified
does not report the MTU of the hop for which the rejected
was too big, so the source host cannot tell exactly how much
reduce its assumed PMTU. To remedy this, we propose that a
unused header field in the Datagram Too Big message be used to
the MTU of the constricting hop. This is the only change
for routers in support of PMTU Discovery

The PMTU of a path may change over time, due to changes in
routing topology. Reductions of the PMTU are detected by
Too Big messages, except on paths for which the host has
setting the DF bit. To detect increases in a path's PMTU, a
periodically increases its assumed PMTU (and if it had stopped
resumes setting the DF bit). This will almost always result
datagrams being discarded and Datagram Too Big messages

Mogul & Deering [page 3]

RFC 1191 Path MTU Discovery November 1990

generated, because in most cases the PMTU of the path will not
changed, so it should be done infrequently

Since this mechanism essentially guarantees that host will
receive any fragments from a peer doing PMTU Discovery, it may aid
interoperating with certain hosts that (improperly) are unable
reassemble fragmented datagrams

3. Host

When a host receives a Datagram Too Big message, it MUST reduce
estimate of the PMTU for the relevant path, based on the value of
Next-Hop MTU field in the message (see section 4). We do not
the precise behavior of a host in this circumstance, since
applications may have different requirements, and since
implementation architectures may favor different strategies

We do require that after receiving a Datagram Too Big message, a
MUST attempt to avoid eliciting more such messages in the
future. The host may either reduce the size of the datagrams it
sending along the path, or cease setting the Don't Fragment bit
the headers of those datagrams. Clearly, the former strategy
continue to elicit Datagram Too Big messages for a while, but
each of these messages (and the dropped datagrams they respond to
consume Internet resources, the host MUST force the PMTU
process to converge

Hosts using PMTU Discovery MUST detect decreases in Path MTU as
as possible. Hosts MAY detect increases in Path MTU, but
doing so requires sending datagrams larger than the current
PMTU, and because the likelihood is that the PMTU will not
increased, this MUST be done at infrequent intervals. An attempt
detect an increase (by sending a datagram larger than the
estimate) MUST NOT be done less than 5 minutes after a Datagram
Big message has been received for the given destination, or less
1 minute after a previous, successful attempted increase.
recommend setting these timers at twice their minimum values (10
minutes and 2 minutes, respectively).

Hosts MUST be able to deal with Datagram Too Big messages that do
include the next-hop MTU, since it is not feasible to upgrade all
routers in the Internet in any finite time. A Datagram Too
message from an unmodified router can be recognized by the
of a zero in the (newly-defined) Next-Hop MTU field. (This
required by the ICMP specification [7], which says that "unused
fields must be zero.) In section 5, we discuss possible

Mogul & Deering [page 4]

RFC 1191 Path MTU Discovery November 1990

for a host to follow in response to an old-style Datagram Too
message (one sent by an unmodified router).

A host MUST never reduce its estimate of the Path MTU below 68
octets

A host MUST not increase its estimate of the Path MTU in response
the contents of a Datagram Too Big message. A message purporting
announce an increase in the Path MTU might be a stale datagram
has been floating around in the Internet, a false packet injected
part of a denial-of-service attack, or the result of having
paths to the destination

3.1. TCP MSS

A host doing PMTU Discovery must obey the rule that it not send
datagrams larger than 576 octets unless it has permission from
receiver. For TCP connections, this means that a host must not
datagrams larger than 40 octets plus the Maximum Segment Size (MSS
sent by its peer

Note: The TCP MSS is defined to be the relevant IP
size minus 40 [9]. The default of 576 octets for the
IP datagram size yields a default of 536 octets for the
MSS

Section 4.2.2.6 of "Requirements for Internet Hosts --
Layers" [1] says

Some TCP implementations send an MSS option only if
destination host is on a non-connected network. However,
general the TCP layer may not have the appropriate
to make this decision, so it is preferable to leave to the
layer the task of determining a suitable MTU for the
path

Actually, many TCP implementations always send an MSS option, but
the value to 536 if the destination is non-local. This behavior
correct when the Internet was full of hosts that did not follow
rule that datagrams larger than 576 octets should not be sent
non-local destinations. Now that most hosts do follow this rule,
is unnecessary to limit the value in the TCP MSS option to 536
non-local peers

Moreover, doing this prevents PMTU Discovery from discovering
larger than 576, so hosts SHOULD no longer lower the value they

Mogul & Deering [page 5]

RFC 1191 Path MTU Discovery November 1990

in the MSS option. The MSS option should be 40 octets less than
size of the largest datagram the host is able to reassemble (MMS_R
as defined in [1]); in many cases, this will be the
limit of 65495 (65535 - 40) octets. A host MAY send an MSS
derived from the MTU of its connected network (the maximum MTU
its connected networks, for a multi-homed host); this should
cause problems for PMTU Discovery, and may dissuade a broken
from sending enormous datagrams

Note: At the moment, we see no reason to send an MSS
than the maximum MTU of the connected networks, and
recommend that hosts do not use 65495. It is quite
that some IP implementations have sign-bit bugs that would
tickled by unnecessary use of such a large MSS

4. Router

When a router is unable to forward a datagram because it exceeds
MTU of the next-hop network and its Don't Fragment bit is set,
router is required to return an ICMP Destination Unreachable
to the source of the datagram, with the Code
"fragmentation needed and DF set". To support the Path MTU
technique specified in this memo, the router MUST include the MTU
that next-hop network in the low-order 16 bits of the ICMP
field that is labelled "unused" in the ICMP specification [7].
high-order 16 bits remain unused, and MUST be set to zero. Thus,
message has the following format

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The value carried in the Next-Hop MTU field is

The size in octets of the largest datagram that could
forwarded, along the path of the original datagram,
being fragmented at this router. The size includes the
header and IP data, and does not include any lower-
headers

Mogul & Deering [page 6]

RFC 1191 Path MTU Discovery November 1990

This field will never contain a value less than 68, since
router "must be able to forward a datagram of 68 octets
fragmentation" [8].

5. Host processing of old-style

In this section we outline several possible strategies for a host
follow upon receiving a Datagram Too Big message from an
router (i.e., one where the Next-Hop MTU field is zero).
section is not part of the protocol specification

The simplest thing for a host to do in response to such a message
to assume that the PMTU is the minimum of its currently-assumed
and 576, and to stop setting the DF bit in datagrams sent on
path. Thus, the host falls back to the same PMTU as it would
under current practice (see section 3.3.3 of "Requirements
Internet Hosts -- Communication Layers" [1]). This strategy has
advantage that it terminates quickly, and does no worse than
practice. It fails, however, to avoid fragmentation in some cases
and to make the most efficient utilization of the internetwork
other cases

More sophisticated strategies involve "searching" for an
PMTU estimate, by continuing to send datagrams with the DF bit
varying their sizes. A good search strategy is one that obtains
accurate estimate of the Path MTU without causing many packets to
lost in the process

Several possible strategies apply algorithmic functions to
previous PMTU estimate to generate a new estimate. For example,
could multiply the old estimate by a constant (say, 0.75). We do
recommend this; it either converges far too slowly, or
substantially underestimates the true PMTU

A more sophisticated approach is to do a binary search on the
size. This converges somewhat faster, although it still takes 4 or 5
steps to converge from an FDDI MTU to an Ethernet MTU. A
disadvantage is that it requires a complex implementation in order
recognize when a datagram has made it to the other end (
that the current estimate is too low). We also do not recommend
strategy

One strategy that appears to work quite well starts from
observation that there are, in practice, relatively few MTU values
use in the Internet. Thus, rather than blindly searching
arbitrarily chosen values, we can search only the ones that

Mogul & Deering [page 7]

RFC 1191 Path MTU Discovery November 1990

likely to appear. Moreover, since designers tend to chose MTUs
similar ways, it is possible to collect groups of similar MTU
and use the lowest value in the group as our search "plateau". (
is clearly better to underestimate an MTU by a few per cent than
overestimate it by one octet.)

In section 7, we describe how we arrived at a table of
MTU plateaus for use in PMTU estimation. With this table
convergence is as good as binary search in the worst case, and is
better in common cases (for example, it takes only two round-
times to go from an FDDI MTU to an Ethernet MTU). Since the
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.

Any search strategy must have some "memory" of previous estimates
order to chose the next one. One approach is to use
currently-cached estimate of the Path MTU, but in fact there
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
Total Length of the datagram that was too big to be forwarded
fragmentation. Since this Total Length may be less than the
PMTU estimate, but is nonetheless larger than the actual PMTU, it
be a good input to the method for choosing the next PMTU estimate

Note: routers based on implementations derived from 4.2
Unix send an incorrect value for the Total Length of
original IP datagram. The value sent by these routers is
sum of the original Total Length and the original
Length (expressed in octets). Since it is impossible for
host receiving such a Datagram Too Big message to know if
sent by one of these routers, the host must be
and assume that it is. If the Total Length field returned
not less than the current PMTU estimate, it must be reduced
4 times the value of the returned Header Length field

The strategy we recommend, then, is to use as the next PMTU
the greatest plateau value that is less than the returned
Length field (corrected, if necessary, according to the Note above).

6. Host

In this section we discuss how PMTU Discovery is implemented in
software. This is not a specification, but rather a set
suggestions

The issues include

Mogul & Deering [page 8]

RFC 1191 Path MTU Discovery November 1990

- 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

6.1.

In the IP architecture, the choice of what size datagram to send
made by a protocol at a layer above IP. We refer to such a
as a "packetization protocol". Packetization protocols are
transport protocols (for example, TCP) but can also be higher-
protocols (for example, protocols built on top of UDP).

Implementing PMTU Discovery in the packetization layers
some of the inter-layer issues, but has several drawbacks:
implementation may have to be redone for each packetization protocol
it becomes hard to share PMTU information between
packetization layers, and the connection-oriented state maintained
some packetization layers may not easily extend to save
information for long periods

We therefore believe that the IP layer should store PMTU
and that the ICMP layer should process received Datagram Too
messages. The packetization layers must still be able to respond
changes in the Path MTU, by changing the size of the datagrams
send, and must also be able to specify that datagrams are sent
the DF bit set. We do not want the IP layer to simply set the DF
in every packet, since it is possible that a packetization layer
perhaps a UDP application outside the kernel, is unable to change
datagram size. Protocols involving intentional fragmentation,
inelegant, are sometimes successful (NFS being the primary example),
and we do not want to break such protocols

To support this layering, packetization layers require an
of the IP service interface defined in [1]:

A way to learn of changes in the value of MMS_S, the "
send transport-message size", which is derived from the
MTU by subtracting the minimum IP header size

Mogul & Deering [page 9]

RFC 1191 Path MTU Discovery November 1990

6.2. Storing PMTU

In general, the IP layer should associate each PMTU value that it
learned with a specific path. A path is identified by a
address, a destination address and an IP type-of-service. (
implementations do not record the source address of paths; this
acceptable for single-homed hosts, which have only one
source address.)

Note: Some paths may be further distinguished by
security classifications. The details of such
are beyond the scope of this memo

The obvious place to store this association is as a field in
routing table entries. A host will not have a route for
possible destination, but it should be able to cache a per-host
for every active destination. (This requirement is already
by the need to process ICMP Redirect messages.)

When the first packet is sent to a host for which no per-host
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
entries should be initialized to be the MTU of the
first-hop data link, and must never be changed by the PMTU
process. (PMTU Discovery only creates or changes entries
per-host routes). Until a Datagram Too Big message is received,
PMTU associated with the initially-chosen route is presumed to
accurate

When a Datagram Too Big message is received, the ICMP
determines a new estimate for the Path MTU (either from a non-
Next-Hop MTU value in the packet, or using the method described
section 5). If a per-host route for this path does not exist,
one is created (almost as if a per-host ICMP Redirect is
processed; the new route uses the same first-hop router as
current route). If the PMTU estimate associated with the per-
route is higher than the new estimate, then the value in the
entry is changed

The packetization layers must be notified about decreases in
PMTU. Any packetization layer instance (for example, a
connection) that is actively using the path must be notified if
PMTU estimate is decreased

Note: even if the Datagram Too Big message contains
Original Datagram Header that refers to a UDP packet, the
layer must be notified if any of its connections use the

Mogul & Deering [page 10]

RFC 1191 Path MTU Discovery November 1990

path

Also, the instance that sent the datagram that elicited the
Too Big message should be notified that its datagram has
dropped, even if the PMTU estimate has not changed, so that it
retransmit the dropped datagram

Note: The notification mechanism can be analogous to
mechanism used to provide notification of an ICMP
Quench message. In some implementations (such
4.2BSD-derived systems), the existing notification
is not able to identify the specific connection involved,
so an additional mechanism is necessary

Alternatively, an implementation can avoid the use of
asynchronous notification mechanism for PMTU decreases
postponing notification until the next attempt to send
datagram larger than the PMTU estimate. In this approach
when an attempt is made to SEND a datagram with the DF
set, and the datagram is larger than the PMTU estimate,
SEND function should fail and return a suitable
indication. This approach may be more suitable to
connectionless packetization layer (such as one using UDP),
which (in some implementations) may be hard to "notify"
the ICMP layer. In this case, the normal timeout-
retransmission mechanisms would be used to recover from
dropped datagrams

It is important to understand that the notification of
packetization layer instances using the path about the change in
PMTU is distinct from the notification of a specific instance that
packet has been dropped. The latter should be done as soon
practical (i.e., asynchronously from the point of view of
packetization layer instance), while the former may be delayed
a packetization layer instance wants to create a packet
Retransmission should be done for only for those packets that
known to be dropped, as indicated by a Datagram Too Big message

6.3. Purging stale PMTU

Internetwork topology is dynamic; routes change over time. The
discovered for a given destination may be wrong if a new route
into use. Thus, PMTU information cached by a host can become stale

Because a host using PMTU Discovery always sets the DF bit, if
stale PMTU value is too large, this will be discovered

Mogul & Deering [page 11]

RFC 1191 Path MTU Discovery November 1990

immediately once a datagram is sent to the given destination.
such mechanism exists for realizing that a stale PMTU value is
small, so an implementation should "age" cached values. When a
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-
MTU, and the packetization layers should be notified of the change
This will cause the complete PMTU Discovery process to take
again

Note: an implementation should provide a means for
the timeout duration, including setting it to "infinity".
example, hosts attached to an FDDI network which is
attached to the rest of the Internet via a slow serial
are never going to discover a new non-local PMTU, so
should not have to put up with dropped datagrams every 10
minutes

An upper layer MUST not retransmit datagrams in response to
increase in the PMTU estimate, since this increase never comes
response to an indication of a dropped datagram

One approach to implementing PMTU aging is to add a timestamp
to the routing table entry. This field is initialized to
"reserved" value, indicating that the PMTU has never been changed
Whenever the PMTU is decreased in response to a Datagram Too
message, the timestamp is set to the current time

Once a minute, a timer-driven procedure runs through the
table, and for each entry whose timestamp is not "reserved" and
older than the timeout interval

- The PMTU estimate is set to the MTU of the associated
hop

- Packetization layers using this route are notified of
increase

PMTU estimates may disappear from the routing table if the per-
routes are removed; this can happen in response to an ICMP
message, or because certain routing-table daemons delete old
after several minutes. Also, on a multi-homed host a topology
may result in the use of a different source interface. When
happens, if the packetization layer is not notified then it
continue to use a cached PMTU value that is now too small.
solution is to notify the packetization layer of a possible
change whenever a Redirect message causes a route change,
whenever a route is simply deleted from the routing table

Mogul & Deering [page 12]

RFC 1191 Path MTU Discovery November 1990

Note: a more sophisticated method for detecting PMTU
is described in section 7.1.

6.4. TCP layer

The TCP layer must track the PMTU for the destination of
connection; it should not send datagrams that would be larger
this. A simple implementation could ask the IP layer for this
(using the GET_MAXSIZES interface described in [1]) each time
created a new segment, but this could be inefficient. Moreover,
implementations that follow the "slow-start" congestion-
algorithm [4] typically calculate and cache several other
derived from the PMTU. It may be simpler to receive
notification when the PMTU changes, so that these variables may
updated

A TCP implementation must also store the MSS value received from
peer (which defaults to 536), and not send any segment larger
this MSS, regardless of the PMTU. In 4.xBSD-derived implementations
this requires adding an additional field to the TCP state record

Finally, when a Datagram Too Big message is received, it implies
a datagram was dropped by the router that sent the ICMP message.
is sufficient to treat this as any other dropped segment, and
until the retransmission timer expires to cause retransmission of
segment. If the PMTU Discovery process requires several steps
estimate the right PMTU, this could delay the connection by
round-trip times

Alternatively, the retransmission could be done in immediate
to a notification that the Path MTU has changed, but only for
specific connection specified by the Datagram Too Big message.
datagram size used in the retransmission should, of course, be
larger than the new PMTU

Note: One MUST not retransmit in response to every
Too Big message, since a burst of several oversized
will give rise to several such messages and hence
retransmissions of the same data. If the new estimated
is still wrong, the process repeats, and there is
exponential growth in the number of superfluous segments sent

This means that the TCP layer must be able to recognize when
Datagram Too Big notification actually decreases the PMTU
it has already used to send a datagram on the
connection, and should ignore any other notifications

Mogul & Deering [page 13]

RFC 1191 Path MTU Discovery November 1990

Modern TCP implementations incorporate "congestion advoidance"
"slow-start" algorithms to improve performance [4]. Unlike
retransmission caused by a TCP retransmission timeout,
retransmission caused by a Datagram Too Big message should not
the congestion window. It should, however, trigger the slow-
mechanism (i.e., only one segment should be retransmitted
acknowledgements begin to arrive again).

TCP performance can be reduced if the sender's maximum window size
not an exact multiple of the segment size in use (this is not
congestion window size, which is always a multiple of the
size). In many system (such as those derived from 4.2BSD),
segment size is often set to 1024 octets, and the maximum window
(the "send space") is usually a multiple of 1024 octets, so
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
may need to change the transmission window size when PMTU
changes the PMTU value. The maximum window size should be set to
greatest multiple of the segment size (PMTU - 40) that is less
or equal to the sender's buffer space size

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,
may be using an unrelated PMTU value

6.5. Issues for other transport

Some transport protocols (such as ISO TP4 [3]) are not allowed
repacketize when doing a retransmission. That is, once an attempt
made to transmit a datagram of a certain size, its contents cannot
split into smaller datagrams for retransmission. In such a case,
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
no larger than allowed by the Path MTU, and should have the DF
set

The Sun Network File System (NFS) uses a Remote Procedure Call (RPC
protocol [11] that, in many cases, sends datagrams that must
fragmented even for the first-hop link. This might
performance in certain cases, but it is known to cause
and performance problems, especially when the client and server
separated by routers

We recommend that NFS implementations use PMTU Discovery

Mogul & Deering [page 14]

RFC 1191 Path MTU Discovery November 1990

routers are involved. Most NFS implementations allow the
datagram size to be changed at mount-time (indirectly, by
the effective file system block size), but might require
modification to support changes later on

Also, since a single NFS operation cannot be split across several
datagrams, certain operations (primarily, those operating on
names and directories) require a minimum datagram size that may
larger than the PMTU. NFS implementations should not reduce
datagram size below this threshold, even if PMTU Discovery suggests
lower value. (Of course, in this case datagrams should not be
with DF set.)

6.6. Management

We suggest that an implementation provide a way for a system
program to

- Specify that PMTU Discovery not be done on a given route

- Change the PMTU value associated with a given route

The former can be accomplished by associating a flag with the
entry; when a packet is sent via a route with this flag set, the
layer leaves the DF bit clear no matter what the upper
requests

These features might be used to work around an anomalous situation
or by a routing protocol implementation that is able to obtain
MTU values

The implementation should also provide a way to change the
period for aging stale PMTU information

7. Likely values for Path

The algorithm recommended in section 5 for "searching" the space
Path MTUs is based on a table of values that severely restricts
search space. We describe here a table of MTU values that, as
this writing, represents all major data-link technologies in use
the Internet

In table 7-1, data links are listed in order of decreasing MTU,
grouped so that each set of similar MTUs is associated with
"plateau" equal to the lowest MTU in the group. (The table

Mogul & Deering [page 15]

RFC 1191 Path MTU Discovery November 1990

includes some entries not currently associated with a data link,
gives references where available). Where a plateau represents
than one MTU, the table shows the maximum inaccuracy associated
the plateau, as a percentage

We do not expect that the values in the table, especially for
MTU levels, are going to be valid forever. The values given here
an implementation suggestion, NOT a specification or requirement
Implementors should use up-to-date references to pick a set
plateaus; it is important that the table not contain too many
or the process of searching for a PMTU might waste
resources. Implementors should also make it convenient for
without source code to update the table values in their systems (
example, the table in a BSD-derived Unix kernel could be
using a new "ioctl" command).

Note: It might be a good idea to add a few table entries
values equal to small powers of 2 plus 40 (for the IP and
headers), where no similar values exist, since this seems
be a reasonably non-arbitrary way of choosing
values

The table might also contain entries for values slightly
than large powers of 2, in case MTUs are defined near
values (it is better in this case for the table entries to
low than to be high, or else the next lowest plateau may
chosen instead).

7.1. A better way to detect PMTU

Section 6.3 suggests detecting increases in the PMTU value
periodically increasing the PTMU estimate to the first-hop MTU
Since it is likely that this process will simply "rediscover"
current PTMU estimate, at the cost of several dropped datagrams,
should not be done often

A better approach is to periodically increase the PMTU estimate
the next-highest value in the plateau table (or the first-hop MTU,
that is smaller). If the increased estimate is wrong, at most
round-trip time is wasted before the correct value is rediscovered
If the increased estimate is still too low, a higher estimate will
attempted somewhat later

Because it may take several such periods to discover a
increase in the PMTU, we recommend that a short timeout period
be used after the estimate is increased, and a longer timeout be

Mogul & Deering [page 16]

RFC 1191 Path MTU Discovery November 1990

Plateau MTU Comments
------ --- -------- ---------
65535 Official maximum MTU RFC 791
65535 Hyperchannel RFC 1044
65535
32000 Just in
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

after the PTMU estimate is decreased because of a Datagram Too
message. For example, after the PTMU estimate is decreased,
timeout should be set to 10 minutes; once this timer expires and
larger MTU is attempted, the timeout can be set to a much
value (say, 2 minutes). In no case should the timeout be
than the estimated round-trip time, if this is known

Mogul & Deering [page 17]

RFC 1191 Path MTU Discovery November 1990

8. Security

This Path MTU Discovery mechanism makes possible two denial-of
service attacks, both based on a malicious party sending
Datagram Too Big messages to an Internet host

In the first attack, the false message indicates a PMTU much
than reality. This should not entirely stop data flow, since
victim host should never set its PMTU estimate below the
minimum, but at 8 octets of IP data per datagram, progress could
slow

In the other attack, the false message indicates a PMTU greater
reality. If believed, this could cause temporary blockage as
victim sends datagrams that will be dropped by some router.
one round-trip time, the host would discover its mistake (
Datagram Too Big messages from that router), but frequent
of this attack could cause lots of datagrams to be dropped. A host
however, should never raise its estimate of the PMTU based on
Datagram Too Big message, so should not be vulnerable to this attack

A malicious party could also cause problems if it could stop a
from receiving legitimate Datagram Too Big messages, but in this
there are simpler denial-of-service attacks available

[1] R. Braden, ed. Requirements for Internet Hosts --
Layers. RFC 1122, SRI Network Information Center, October, 1989.

[2] Geof Cooper. IP Datagram Sizes. Electronic distribution of
TCP-IP Discussion Group, Message-
<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.
'88 Symposium on Communications Architectures and Protocols,
314-329. Stanford, CA, August, 1988.

[5] C. Kent and J. Mogul. Fragmentation Considered Harmful. In Proc
SIGCOMM '87 Workshop on Frontiers in Computer
Technology. August, 1987.

[6] Drew Daniel Perkins. Private Communication

Mogul & Deering [page 18]

RFC 1191 Path MTU Discovery November 1990

[7] J. Postel. Internet Control Message Protocol. RFC 792,
Network Information Center, September, 1981.

[8] J. Postel. Internet Protocol. RFC 791, SRI Network
Center, September, 1981.

[9] J. Postel. The TCP Maximum Segment Size and Related Topics.
879, SRI Network Information Center, November, 1983.

[10] Michael Reilly. Private Communication

[11] Sun Microsystems, Inc. RPC: Remote Procedure Call Protocol.
1057, SRI Network Information Center, June, 1988.

Authors'

Jeffrey
Digital Equipment Corporation Western Research
100 Hamilton
Palo Alto, CA 94301

Phone: (415) 853-6643
EMail: mogul@decwrl.dec.

Steve
Xerox Palo Alto Research
3333 Coyote Hill
Palo Alto, CA 94304

Phone: (415) 494-4839
EMail: deering@xerox.

Mogul & Deering [page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX