One document matched: draft-welzl-pmtud-options-01.txt
Differences from draft-welzl-pmtud-options-00.txt
INTERNET-DRAFT Michael Welzl
draft-welzl-pmtud-options-01.txt University of Innsbruck
Institute of Computer Science
Experimental 9. February 2003
PMTU-Options: Path MTU Discovery Using Options
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes an experimental enhancement of Path MTU
Discovery for special scenarios (e.g., tunnels, or to detect PMTU
increases). It has the potential of reducing loss, speeding up
convergence, reducing load in routers which would otherwise need to
generate a large amount of ICMP messages, and alleviating certain
additional problems (interactions with tunnels, Black Hole
Detection). The idea is to use an IP Option which queries routers for
their MTU before starting a Path MTU Discovery process. The result
retrieved in this manner is used as an upper limit for Path MTU
Discovery. To this end, it is fed back to the source either at the
packetization layer (recommended) or at the IP layer.
Changes from draft-welzl-pmtud-options-00.txt:
Michael Welzl Expires: September 2004 [Page 1]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
o The addition of a "TTL-Check" field.
o The addition of a section on packet drops due to options.
o Update of section 5.1 on the impact of Slow Path processing.
o Update of references.
Table of Contents
Status of this Memo ....................................... 1
1. Definitions ....................................... 2
2. Introduction ...................................... 2
3. Specification ..................................... 3
3.1. Probe MTU Option Format for IPv4 ................ 3
3.2. Feedback Format ................................. 4
3.2.1 IP ............................................ 4
3.2.2 TCP ........................................... 5
3.2.3 SCTP .......................................... 5
3.2.4 DCCP .......................................... 6
3.3. Host Operation .................................. 7
3.4. IPv6 Usage ...................................... 8
3.4.1 Probe MTU Option Format for IPv6 .............. 8
3.4.2 Feedback Format: IP ........................... 9
3.4.3 Feedback Format: TCP .......................... 11
3.4.4 Feedback Format: SCTP ......................... 11
3.4.5 Feedback Format: DCCP ......................... 12
3.5. IP Tunnels ...................................... 12
4. Potential Advantages .............................. 13
4.1. Reducing Packet Loss ............................ 13
4.2. Circumventing Black Hole Detection .............. 13
4.3. Other Problems with ICMP Fragmentation Needed ... 14
4.4. Circumventing Problems with IP Tunnels .......... 14
5. Discussion of Issues .............................. 15
5.1. Slow Path Processing ............................ 15
5.2. Dropped Packets ................................. 16
5.2. Placing Additional Burden on Routers ............ 16
5.3. Motivating Deployment ........................... 17
6. Discussion of Usage Scenarios ..................... 17
6.1. Detecting PMTU Increases ........................ 17
6.2. RTT-Robust Transport Protocols .................. 18
6.3. Tunnels ......................................... 18
7. Related Work ...................................... 18
8. Security Considerations ........................... 18
9. IANA Considerations ............................... 19
10. Normative References .............................. 20
11. Informative References ............................ 20
Michael Welzl Expires: September 2004 [Page 2]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
12. Acknowledgements .................................. 21
13. Author's Address .................................. 22
14. Full Copyright Statement .......................... 23
1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Throughout this document, "Path MTU Discovery" (PMTUD) refers to the
mechanism described in RFC 1191 [RFC1191] and "Packetization Layer
Path MTU Discovery" (PLPMTUD) refers to the mechanism described in
[draft-PLPMTUD]. The mechanism described in this document is called
"Path MTU Discovery using Options" (PMTU-Options).
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).
2. Introduction
This memo specifies how options can be used as an enhancement for
PMTUD and PLPMTUD. The method resembles the mechanism described in
[RFC1063]: a sender includes an IP Option containing the MTU of its
outgoing link. Upon forwarding, each router compares the value with
the MTUs of the links which are traversed by the datagram and updates
the field if one of the MTUs of its links is smaller. If all routers
support this scheme, the receiver has the correct MTU in the option
and can communicate it back to the sender (preferably at the
packetization layer instead of the IP layer as specified in
[RFC1063]).
The main difference is that the mechanism described in this document
does not rely on all routers along a path to support the IP option.
Instead, when this scheme is carried out just before doing PMTUD or
PLPMTUD, the result is used as an upper limit for the MTU of the path
(i.e. the Path MTU will definitely not exceed the value obtained with
this mechanism), no matter how many routers support it. This method
has several potential advantages over standard PMTUD or PLPMTUD
(listed in section 4) but also some issues (listed in section 5).
Being an experimental specification, it is mainly intended for
Michael Welzl Expires: September 2004 [Page 3]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
special usage scenarios, some of which are described in section 6.
3. Specification
3.1. Probe MTU Option Format for IPv4
The "Probe MTU Option" for IPv4 that has routers update the MTU value
(IP option number 11) is specified as in [RFC1063], with the
exception of additional "TTL-Check" and "MTU Nonce" fields:
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 = 11 | Size = 8 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Check | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option always contains the lowest MTU of all the links that have
been traversed so far by the datagram.
A host that sends this option must initialize the MTU field to be the
MTU of the directly-connected network. If the host is multi-homed,
this should be for the first-hop network. Also, the host MUST set
the TTL-Check field to a random value. It also also calculates and
remembers TTL-Diff, the difference between the TTL value and the
value of TTL-Check in the transmitted packet, as follows:
TTL Diff = ( TTL - TTL-Check ) mod 256
The purpose of this calculation is to detect whether all routers
along the path supported the option.
Each router that receives a datagram containing this option MUST
compare the MTU field with the MTUs of the inbound and outbound links
for the datagram. If either MTU is lower than the value in the MTU
field of the option, the MTU field MUST be set to the lower MTU.
(Note that routers conforming to RFC-1812 may not know either the
inbound interface or the outbound interface at the time that IP
options are processed. Accordingly, support for this option may
require major router software changes). Additionally, a router MUST
decrement the TTL-Check field on forwarding.
Any host receiving a datagram which contains this option should
confirm that the value of the MTU field of the option is less than or
equal to that of the inbound link, and if necessary, reduce the MTU
field value, before processing the option.
Michael Welzl Expires: September 2004 [Page 4]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
If the receiving host is not able to accept datagrams as large as
specified by the value of the MTU field of the option, then it should
reduce the MTU field to the size of the largest datagram it can
accept.
The MTU Nonce field is a means to prevent attackers from hiding the
fact that a router has updated the MTU field and provide some
protection against broken downstream routers. It MUST be initialized
with a random non-zero 24-bit number by the sender. The number MUST
be kept for later comparison with the Nonce value which is fed back
to the sender. A router which updates the MTU field in the option
MUST set the MTU Nonce field to 0.
3.2. Feedback Format
IP Option processing is known to be a costly operation. To avoid
placing this burden on routers along the backward path, feedback
SHOULD be stored at the packetization layer; it MAY be stored at the
IP layer in special cases (e.g. if PMTU-Options is used by a UDP
based application). Header extensions are specified for IP, TCP,
SCTP and DCCP. A host implementing PMTU-Options SHOULD react to this
feedback in all of the supported protocols and provide the MTU value
to the local PMTUD or PLPMTUD instance. The PMTUD or PLPMTUD instance
MUST NOT increase a cached PMTU value in response to PMTU-Options
feedback. If the MTU value from this feedback is greater than or
equal to the cached MTU value and the MTU Nonce is set to 0, there is
a chance that an intermediate node or the receiver misbehaved (due to
broken software or because of an attack).
3.2.1. IP
The Reply MTU Option for IPv4 (IP option number 12) is specified as
in [RFC1063], with the exception of additional "TTL-Diff" and "MTU
Nonce" fields:
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 = 12 | Size = 8 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option is used to return the value learned from a Probe MTU
Michael Welzl Expires: September 2004 [Page 5]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
Option to the sender of the Probe MTU Option at the IP level. Since
it causes unnecessary processing overhead in routers along the
backward path, its usage is only recommended for rare special cases.
In particular, it may be helpful for UDP-based applications which
utilize PMTU-Options.
The first octet of this option contains the option type, identifying
the IP option. The second octet of this option contains the size
field, specifying the option length in octets. The size field is set
to 8. The next three fields (two, one and three octets, respectively)
contain the result of the MTU-Options process, TTL-Diff and the MTU
Nonce; the MTU and MTU Nonce fields must be copied from the IPv4
Probe MTU Option by the receiver. The receiver must set the TTL-Diff
field to ( TTL - TTL-Check ) mod 256, where "TTL" is the TTL field in
the IP header.
3.2.2. TCP
The Reply MTU Option format for TCP over IPv4 is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length = 8 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first octet of this option contains the option kind, identifying
the TCP option (to be specified by IANA). The second octet of this
option contains the length field, specifying the option length in
octets. The length field is set to 8. The MTU, TTL-Diff and MTU Nonce
fields are similar to the specification in section 3.2.1.
3.2.3. SCTP
In SCTP [RFC2960], the sender is informed by the receiver about PMTU-
Options feedback by including the Reply MTU chunk. This chunk looks
as follows:
Michael Welzl Expires: September 2004 [Page 6]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Flags=00000000| Chunk Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Nonce (continued) | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Reply MTU chunk is considered a Control chunk.
The Chunk Type field identifies the chunk; it consists of two high-
order bits "11", indicating that a processing SCTP node which does
not recognize this chunk type must skip this chunk and continue
processing, but report in an ERROR Chunk using the "Unrecognized
Chunk Type" cause of error. The sender of the Reply MTU chunk SHOULD
send the MTU feedback via some other means (via a different active
protocol or an IP option) in response to this ERROR Chunk. The
trailing six bits are currently undefined (to be specified by IANA).
Since this chunk has no specific flags, the Flags field is set to 0.
The Chunk Length field is set to 12 (the length of the chunk
including the Chunk Type, Flags and Length fields).
The MTU, TTL-Diff and MTU Nonce fields are similar to the
specification in section 3.2.1; since the length of a SCTP chunk must
be a multiple of 4 octets, the last octet is filled with 0 (padding).
3.2.4. DCCP
The Feedback MTU Option format for DCCP over IPv4 is:
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 | Length = 8 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field indentifies the option (number to be specified by
IANA). The rest of the option is similar to the TCP option defined in
section 3.2.2.
Michael Welzl Expires: September 2004 [Page 7]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
3.3 Host Operation
Generally, the PMTU-Options process is carried out before initiating
a regular PMTUD or PLPMTUD process.
Since IP options require processing at every router along a path, it
is important to ensure that no packets unnecessarily include IP
options. Thus, a host implementing PMTU-Options must keep state in
routing table entries and only initiate a PMTUD or PLPMTUD (and
accompanying PMTU-Options) process when this information becomes
stale. The process of purging stale PMTU information is specified in
[RFC1191], sections 6.2 and 6.3. Additionally, the number of
datagrams carrying IP options should be restricted with a fixed
percentage of total datagrams that are sent by a host to ensure
scalability. It can also be reduced by using PMTU-Options in special
situations only; a discussion of such potential usage scenarios is
provided in section 6.
It is assumed that the datagram size used when doing PMTU-Options is
already some sensible value (e.g., the result of a recent PMTU
process or the first-hop data-link MTU). When a Probe MTU Option is
added to a datagram, it is prolonged by 8 octets (16 octets with
IPv6). This number must therefore be taken into account when
generating a datagram -- when doing PMTU-Options, the size of the
datagram including the Probe MTU Option must not exceed the recent
PMTU value. The correct size must be communicated to the
packetization layer protocol (see [RFC1191], section 6.4, for a
suggestion of how such communication could be implemented).
A host receiving a packet that carries the Probe MTU Option MUST feed
back the information to the sender by copying the MTU and MTU Nonce
fields and TTL-Diff as specified in section 3.2 to the next return
datagram. To this end, it SHOULD inform a packetization layer
protocol which is communicating with the originator of the Probe MTU
Option. Alternatively, a host receiving a packet that carries the
Probe MTU Option MAY use the MTU Reply IP Option; this method is not
recommended because it involves unnecessary processing overhead in
routers on the return path.
A host MUST be able to accept MTU feedback from IP and SHOULD be able
to accept feedback from all packetization layer protocols. This
feedback contains a MTU Nonce value which either has the same value
as the MTU Nonce field in the original Probe MTU Option (a random
number initialized by the sender), meaning that the initial MTU value
in the Probe MTU Option was not changed by routers, or 0, meaning
that the initial MTU value in the Probe MTU Option was changed by
routers. If the PMTU upper limit from PMTU-Options feedback is
Michael Welzl Expires: September 2004 [Page 8]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
greater than the initial PMTU value stored at the sender, the latter
value MUST be used. If, in such a case, the MTU Nonce was changed,
there is a chance that an intermediate node or the receiver
misbehaved (due to broken software or because of an attack).
The resulting PMTU upper limit at the PMTU-Options sender MUST be
communicated to the local PMTUD or PLPMTUD instance. Note that
because the options are placed on unreliable datagrams, the original
sender will have to resend probes (possibly once per window of data)
until it receives feedback.
If the value of TTL-Diff in the reply packet is equal to the stored
value of TTL-Diff, all routers along the path supported the option.
This means that the MTU value in the reply packet is not an upper
limit for the PMTU but the actual end result; this fact SHOULD be
communicated to the local PMTUD or PLPMTUD instance, which MAY then
terminate immediately using the value from the packet carrying the
MTU feedback.
A host that implements PMTU-Options SHOULD wait for feedback to
arrive before initiating the subsequent PMTUD or PLPMTUD process,
which remains unchanged except for one difference: the MTU during the
process SHOULD not exceed the value received from PMTU-Options.
Feedback from PMTU-Options SHOULD not be kept any longer -- it is
only intended as an aid for the subsequent PMTUD or PLPMTUD process.
Since packet drops can substantially delay the reception of feedback,
a host MAY use a timer to initiate PTMUD or PLPMTUD even when no
feedback has arrived; if such a timer is implemented, a means to
configure this timer MUST be provided.
3.4. IPv6 Usage
Path MTU Discovery for IPv6 is specified in [RFC1981]. PMTU-Options
can be combined with this PMTUD variant just like regular PMTUD or
PLPMTUD; the mechanism should work with IPv6 without requiring any
substantial changes. The following sections describe the IPv6 formats
for the Probe MTU Option and feedback -- these formats differ from
the IPv4 variants in that the MTU field is larger (4 instead of 2
octets) to support IPv6 jumbograms [RFC2675] and the MTU Nonce field
is larger (8 instead of 4 octets) to ensure 8-octet alignment without
wasting space for padding octets. Also, the TTL field in the IPv4
header, which is used for calculations related to TTL-Check, is the
Hop Limit field in the case of IPv6.
3.4.1. Probe MTU Option Format for IPv6
Michael Welzl Expires: September 2004 [Page 9]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
The option format specified in section 3.1 is a Hop-by-Hop Options
header in the IPv6 case. The PMTU-Options Hop-by-Hop Options header
is identified by a Next Header value of 0 in the IPv6 header, and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Check | |
+-+-+-+-+-+-+-+-+ 7-octet MTU Nonce field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Option Type field identifies the option; it consists of two high-
order bits "00", indicating that a processing IPv6 node which does
not recognize this option type must skip over this option and
continue processing the header. The following bit "1" indicates that
the Option Data field (MTU, TTL-Check and MTU Nonce) may change en-
route. The trailing five bits are currently undefined (to be
specified by IANA). The MTU field was stretched to 4 octets to
support IPv6 jumbograms [RFC2675].
Since it may be assumed that, when either of the option-bearing
headers are present, they carry a very small number of options --
usually only one [RFC2460] -- the MTU Nonce field was stretched to
fit the 8-octet alignment (otherwise, a PadN Option of 6 octets would
have to be used in most cases). This way, the security of PMTU-
Options is enhanced. A complete Hop-by-Hop Options header containing
this one option would look as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=1 | Option Type |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Check | |
+-+-+-+-+-+-+-+-+ 7-octet MTU Nonce field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4.2. Feedback Format: IP
Michael Welzl Expires: September 2004 [Page 10]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
The option format specified in section 3.2.1 is a Destination Options
header in the IPv6 case. The PMTU-Options Destination Options header
is identified by a Next Header value of 60 in the immediately
preceding header, and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | |
+-+-+-+-+-+-+-+-+ 7-octet MTU Nonce field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Option Type field identifies the option; it consists of two high-
order bits "00", indicating that a processing IPv6 node which does
not recognize this option type must skip over this option and
continue processing the header. The following bit "0" indicates that
the Option Data field (MTU, TTL-Diff and MTU Nonce) does not change
en-route. The trailing five bits are currently undefined (to be
specified by IANA).
The second octet of this option contains the Opt Data Len field,
specifying the length of the Option Data field in octets. The Opt
Data Len field is set to 12. The next three fields (four, one and
seven octets, respectively) contain the result of the MTU-Options
process, TTL-Diff and the MTU Nonce; the MTU and MTU Nonce fields
must be copied from the IPv6 Probe MTU Option by the receiver. The
receiver must set the TTL-Diff field to ( TTL - Hop Limit ) mod 256,
where "Hop Limit" is the Hop Limit field in the IPv6 header.
A complete Destination Options header containing this one option
would look as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=1 | Option Type |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | |
+-+-+-+-+-+-+-+-+ 7-octet MTU Nonce field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael Welzl Expires: September 2004 [Page 11]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
3.4.3. Feedback Format: TCP
The Reply MTU Option format for TCP over IPv6 is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length = 14 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU (continued) | TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Nonce (continued) | MTU Nonce (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Nonce (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first octet of this option contains the option kind, identifying
the TCP option. The second octet of this option contains the length
field, specifying the total option length in octets. The length field
is set to 14. The MTU, TTL-Diff and MTU Nonce fields are similar to
the specification in section 3.4.2.
3.4.4. Feedback Format: SCTP
In SCTP [RFC2960], the sender is informed by the receiver about PMTU-
Options feedback by including the Reply MTU chunk. For IPv6, this
chunk looks as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Flags=00000000| Chunk Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL-Diff | |
+-+-+-+-+-+-+-+-+ 7-octet MTU Nonce field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Reply MTU chunk is considered a Control chunk.
The Chunk Type field identifies the chunk; it consists of two high-
Michael Welzl Expires: September 2004 [Page 12]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
order bits "11", indicating that a processing SCTP node which does
not recognize this chunk type must skip this chunk and continue
processing, but report in an ERROR Chunk using the "Unrecognized
Chunk Type" cause of error. The sender of the Reply MTU chunk SHOULD
send the MTU feedback via some other means (via a different active
protocol or an IP option) in response to this ERROR Chunk. The
trailing six bits are currently undefined (to be specified by IANA).
Since this chunk has no specific flags, the Flags field is set to 0.
The Chunk Length field is set to 16 (the length of the chunk
including the Chunk Type, Flags and Length fields).
The MTU, TTL-Diff and MTU Nonce fields are similar to the
specification in section 3.4.2.
3.4.5. Feedback Format: DCCP
The Reply MTU Option format for DCCP over IPv6 is:
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 | Length = 14 | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU (continued) | TTL-Diff | MTU Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Nonce (continued) | MTU Nonce (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU Nonce (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field indentifies the option (number to be
specified by IANA). The rest of the option is similar
to the TCP option defined in section 3.4.3.
3.5. IP Tunnels
If a network node that performs IP-in-IP tunneling (be it because
of IPsec, IPv6 or for any other purpose) encapsulates a datagram
carrying the Probe MTU Option, it should copy this option to
the outer IP header, no matter how many headers there are
in between. If the network node at the "other side of the tunnel"
(the node that unpackages an IP datagram by removing the outer
header) receives a datagram carrying the Probe MTU Option in the
(outer) IP header, it should subtract the length of the outer and
Michael Welzl Expires: September 2004 [Page 13]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
all intermediate headers from the value in the (outer header) option
and then copy it into the inner header option on unpackaging.
Such nodes SHOULD NOT change the MTU Nonce field.
4. Potential Advantages
The PMTU-Options mechanism has a number of potential advantages:
4.1. Reducing Packet Loss
Probing for the Path MTU means that at some point, a datagram with
a size exceeding the Path MTU must be sent with the DF bit set to 1.
Such a datagram will be dropped, which normally requires the
data it carried to be retransmitted. This retransmission is
additional traffic which is caused by PMTUD or PLPMTUD.
The result of PMTU-Options is to be interpreted as an upper limit
for the Path MTU. If it turns out to be the Path MTU during the
subsequent PMTUD or PLPMTUD process, the Path MTU is detected
without causing packet loss.
4.2. Circumventing Black Hole Detection
PMTUD is known to have a problem called "Black Hole Detection"
[RFC2923], which happens when a PMTU sender does not receive an
ICMP Fragmentation Needed message even though the size of a
datagram with DF set to 1 has exceeded the MTU of a link. This
may happen if, for instance, routers or firewalls are misconfigured.
PLPMTUD is robust against this failure because it does not rely
on ICMP.
Since the information from PMTU-Options is explicit even when
the size of a datagram has not exceeded the MTU of a link, the
"Black Hole Detection" problem of PMTUD could be circumvented
in a special case that is best explained by means of a simple
example:
MTU A ------ MTU B ------ MTU C ------ MTU A
Sender --------| R1 |---------| R2 |---------| R3 |--------- Receiver
------ ------ ------
In this example, a datagram traverses routers R1, R2 and R3, and MTU
A > MTU B > MTU C. PMTUD has converged a long time ago, and a path
Michael Welzl Expires: September 2004 [Page 14]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
change has occured. Not having noticed any problems, the host now
probes for a larger MTU. Routers R1 and R2 are misconfigured not to
send ICMP "Fragmentation Needed" messages -- the size is increased
and exceeds MTU B, but the sender never notices this because R1
simply drops the datagram.
Now let us assume that PTMU-Options is used. The sender first submits
a datagram carrying a Probe MTU Option; R3, which is properly
configured, updates the value in the option (originally A) with C.
Since PMTUD uses this value as an upper limit, it never exceeds the
MTU of the link between routers R1 and R2, and Black Hole Detection
does not occur.
4.3. Other Problems with ICMP Fragmentation Needed
In addition to the danger of leading to the Black Hole Detection
problem, utilizing ICMP Fragmentation Needed messages has the
following additional problems:
o Generating an ICMP packet requires memory to be allocated, header
fields to be initialized etc., which is a costly operation for a
router.
o An ICMP message is additional signaling traffic that consumes
network capacity.
o An ICMP message can be dropped, e.g. as the result of congestion
on the return path.
By replacing the generation of an ICMP Fragmentation Needed message
with a simple option field update, PMTU-Options circumvents these
problems.
4.4. Circumventing Problems with IP Tunnels
Sometimes, the DF bit is ignored by network nodes that encapsulate IP
packets: the total length of a packet with additional headers may
exceed the Path MTU of the tunnel even if this is not the case
without the extra headers. Also, the inner nodes of a tunnel are
often invisible to the data flow that is carried through the tunnel.
It would therefore be up to the network nodes at the edge of the
tunnel to perform PMTUD or PLPMTUD and fragment a packet
appropriately, if necessary. Simply ignoring the DF bit is an
attractive alternative.
If the PMTU-Options mechanism is supported by routers along a tunnel
Michael Welzl Expires: September 2004 [Page 15]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
path and IP Options are copied to the outer IP header, it is possible
to detect a potentially smaller MTU in the tunnel, thereby decreasing
the chance of fragmentation in the tunnel.
5. Discussion of Issues
In what follows, we discuss some obvious problems with PMTU-Options:
5.1. Slow Path Processing
IP packets carrying options are known to be processed in the "Slow
Path" (software, as opposed to the hardware-only "Fast Path") in most
normal IP router. This means that packets carrying the Probe MTU
Option will experience a notable delay along the forward path. It is
therefore not recommended to use datagrams that belong to a PMTU-
Options process for round-trip time estimation; this makes it
questionable whether PMTU-Options should be used at the beginning of
a TCP connection.
In IETF and IRTF mailing lists, the impact of option processing has
been claimed to be immense (e.g., slowing down packets by factor 100)
on several occasions. While this may be true for packet processing in
a single router, a recent measurement study has shown that the impact
on end-to-end delay can be much less severe [WeRo]. The study
encompassed two separate tests -- one in July/August 2002 and one in
August/September 2003. In each of these tests, a ping carrying a NOP
IP Option was sent to a host from the list at [TBIT], followed by a
ping without the option; this process was repeated 100 times per
host, and there was a pause of 1 second in between all pings -- thus,
these measurements do not say anything about the (possibly different)
behavior of routers when they are flooded with a large number of
packets that contain IP options. Additionally, a traceroute was
carried out for each host.
4427 and 4401 hosts reacted to pings with options, with a number of
hops ranging from 6 to 34 (most hosts were in the range of 14 - 25
hops). The pings traversed 5726 unique router addresses (not
necessarily as many different machines because different interfaces
on a single router may show up as different addresses in traceroute)
in 2002 and 5194 in 2003. The measurements from hosts that answered
with options (approximately 1/4) were ignored in the final statistics
because the backward path is unknown. The rest of the data was
weighted based on the frequency of occurence (a router which shows up
100 times in the measurements is 100 times less important than a
router which shows up only once), path length and variance (to
Michael Welzl Expires: September 2004 [Page 16]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
diminish the effect of queuing delay).
The final result was that on average, slow path processing in routers
caused an additional delay of 10% (2002) and 7% (2003) along the
forward path if a packet contains a NOP option. These results appear
to concur with the results reported in [FrJo], where similar
measurements are described.
5.2. Dropped Packets
In addition to the resulting impact that slow path processing has on
the round-trip time, the measurements reported in [WeRo] revealed an
alarming fact: in the 2003 test run, 3507 out of 7908 hosts reacted
to regular pings but did not react when a NOP option was used. At
this point, it is unclear who dropped the pings that carried options:
routers along the paths to the hosts, firewalls, the hosts
themselves, or routers along the backward paths (because the hosts
may have included the option in their responses). Also, the reaction
to different types of packets (e.g., TCP SYN) is unknown.
For PMTU-Options, this means that the mechanism can easily lead to
packet drops, in particular if the receiver is not known to support
it. This may have adverse effects on the packetization layer if these
drops are interpreted as a sign of congestion. This is one particular
reason to consider PMTU-Options as experimental and propose its usage
for special scenarios only.
5.3. Placing Additional Burden on Routers
PMTUD and PLPMTUD only require the "problematic" router (router
attached to a link with an MTU that was just exceeded) to do
substantial extra work (notably, all the routers on the return path
from the "problematic" router to the sender are involved in
forwarding an ICMP Fragmentation Needed message in the case of
standard PMTUD [RFC1191]). PMTU-Options involves all routers along
the path by having them process IP options. In other words, while the
burden for an individual router is smaller (processing of the Probe
MTU Option is probably a less costly operation than generating an
ICMP Fragmentation Needed message), the burden for the whole network
is perhaps greater.
Since the processing overhead caused by the Probe MTU option in
routers is unknown, it is important to limit the amount of such
packets in a network; clearly, PMTU-Options should not be used for
each and every new TCP connection but in special scenarios only.
Michael Welzl Expires: September 2004 [Page 17]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
5.4. Motivating Deployment
From the perspective of a single node, there is no immediate gain
when deploying PMTU-Options; at least the sender, receiver and a
router (ideally attached to the link with the Path MTU -- otherwise
the only benefit of PMTU-Options could be faster PMTUD convergence
because it starts with a smaller value) must participate for the
mechanism to be beneficial. However, the same is true for Explicit
Congestion Notification (ECN) [RFC3168], a deployment overview of
which is given at [ECN].
PMTU-Options has the following motivating deployment factor: a router
with a particularly small MTU will typically need to send a large
number of ICMP packets. This is where PMTU-Options deployment would
be most beneficial because it might lead to reduced CPU load. From
the perspective of an end host where PMTU-Options is used, such
routers are exactly the ones that should be updated because they have
small MTUs.
6. Discussion of Usage Scenarios
Since the Probe MTU Option places an additional burden on routers via
IP option processing and the additional delay from Slow Path
processing can falsify a round-trip time estimation, it is
questionable whether the mechanism should be used at the beginning of
a standard TCP connection. Being an experimental PMTUD enhancement,
PMTU-Options is rather intended to be used under special
circumstances -- depending on the importance of the aforementioned
advantages as opposed to the gravity of the aforementioned issues
with the mechanism. In what follows, some examples of potential usage
scenarios are given:
6.1. Detecting PMTU Increases
Since the PMTU may change (e.g., when a routing change occurs) and
even become larger while a long-lasting connection is active,
[RFC1191] describes a method to probe for increased MTUs (which
should be done rarely). The recommended method increases the packet
size according to a table specified in [RFC1191]; alternatively, the
"aged" cached PMTU values may be reset to the first-hop data-link
MTU. Since chances are high that the PMTU did not change and either
of these process will therefore immediately exceed the current PMTU,
it may be recommendable to use PMTU-Options before increasing a
cached PMTU value.
Michael Welzl Expires: September 2004 [Page 18]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
6.2. RTT-robust Transport Protocols
Transport protocols that do not rely on round-trip time estimates as
heavily as TCP or SCTP may be a good fit for PMTU-Options. In
particular, this includes DCCP [draft-DCCP], where the importance of
round-trip time estimates depends on the Congestion Control ID
(CCID), and UDP, where no round-trip time estimation is specified.
Currently, PMTUD is unavailable for applications that utilize UDP --
it is up to such applications to find out about the ideal size of a
datagram. PMTUD or PLPMTUD may however be provided to such
applications in the future (the issue has been discussed in the PMTUD
Working Group). Assuming that it is available to applications running
on top of UDP, it may be recommendable for such an application to use
PMTU-Options depending on its requirements.
6.3. Tunnels
The operation of PMTU-Options across tunnels is specified in section
3.5, the potential advantage of this kind of operation is described
in section 4.4. In addition to the viewpoint of an application
traversing a tunnel without wanting PMTUD to fail, the endpoints of a
tunnel may sometimes also need to determine the MTU in between them
(the viewpoint being a tunnel with endpoints which do not care about
actual application endpoints) [draft-TunnelMTU]. In such a case,
using PMTU-Options may be recommendable due to the potentially
controlled (or known) tunnel environment and sporadic MTU
determination at tunnel endpoints.
7. Related Work
This work can be seen as an extension of the basic idea in [RFC1063].
A related document is [draft-PMTUDv6], where the idea of utilizing
options for PMTUD is described for IPv6. This is the only other text
that the author is aware of where a Probe MTU option is combined with
regular PMTUD. Some of the design choices in this document (e.g., the
MTU Nonce) were based on [RFC3168] and [draft-QS].
8. Security Considerations
Since MTU-Options requires routers to change a value in packets and
must therefore always be placed in the outermost IP header to remain
functioning, it cannot be fully protected with IPsec; however, as the
explicit MTU update to the sender originates from the receiver of an
end-to-end connection and not an intermediate router as with ICMP
Fragmentation Needed messages, the receiver can be authenticated
Michael Welzl Expires: September 2004 [Page 19]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
using the Encapsulation Security Payload (ESP) header [RFC2406] or
the Authentication Header (AH) [RFC2402]. For this purpose, the
Probe MTU Option is classified as mutable and the Reply MTU Option is
classified as immutable. The mutable header field (MTU field in the
Probe MTU Option) is where IPsec cannot help -- it cannot prevent
intermediate attackers from sending false data. The following attacks
from such a malicious node must be considered:
o Sending a MTU value that is too large:
A host MUST ignore feedback containing an MTU that is larger than
the MTU it initially wrote into the option. If a router reduces
the MTU value, it MUST set the MTU Nonce to 0 -- to hide this
fact, a malicious node would have to guess the original MTU Nonce,
which has a 1/(2^32) chance of success (1/2^128 with IPv6). If a
malicious node ignores the MTU Nonce and still increases the MTU
value, the attacker can only succeed if the new value is smaller
than the (unknown) original value from the sender. Even then, the
value received from this option is only used as an upper limit for
PMTUD and PLPMTUD, which will still work in case of such an
attack. Only the benefit of PMTU-Options can be lost.
o Sending a MTU value that is too small:
This attack, which is similar to an attack with ICMP
"Fragmentation needed" messages carrying a value that is too
small, can degrade the performance of a sender. PMTU-Options does
not provide a mechanism to prevent this attack. This is one of the
most important reasons to consider it experimental: the result of
PMTU-Options should merely be used as a hint.
o Lying about the number of routers that supported the option:
The number of routers that supported the option can be faked by
altering TTL-Check or TTL-Diff. The only plausible attack based on
this value would be to claim that all routers along the path
supported the option, as this might cause the sender to use the
MTU value in the reply packet right away without starting a PMTUD
or PLPMTUD process. However, since the initial value of TTL-Check
is a random number, the chance of a malicious node guessing the
right value of TTL-Check is at most 1/256.
9. IANA Considerations
This specification reuses the obsolete IPv4 option numbers 11 and 12.
It requires two IPv6 Option Type numbers (with leading bits "001" and
"000"), a TCP option number, a SCTP Chunk Type number (with leading
Michael Welzl Expires: September 2004 [Page 20]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
bits "00") and a DCCP option number.
10. Normative References
[RFC1191] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC
1191, November 1990.
[RFC1981] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[draft-PLPMTUD] Mathis, M., Heffner, J. and Lahey, K., "Path MTU
Discovery", Internet-draft draft-ietf-pmtud-method-00.txt, October
19, 2003.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery.", RFC 1435, March 1993.
[RFC2460] Deering, S., and Hinden, R., "Internet Protocol, Version 6
(IPv6)", RFC 2460, December 1998.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and
Paxson, V., "Stream Control Transmission Protocol", RFC 2960, October
2000.
[draft-DCCP] Kohler, E., Handley, M., Floyd, S., and Padhye, J.,
"Datagram Congestion Control Protocol (DCCP)", Internet-draft draft-
ietf-dccp-spec-05.txt, October 2003.
[RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
2402, November 1998
11. Informative References
[RFC1063] Mogul, J.C., Kent, C.A., Partridge, C., and McCloghrie, K.,
"IP MTU discovery options.", RFC 1063, July, 1988.
[WeRo] Welzl, M., and Rossi, M., "On The Impact of IP Option
Processing", Preprint-Reihe des Fachbereichs Mathematik-Informatik
(technical report), No. 15, 2003. Available from
http://www.welzl.at/ip-options
Michael Welzl Expires: September 2004 [Page 21]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
[FrJo] Fransson, P., and Jonsson, A., "The Need for an Alternative to
IPv4-Options", RVK (RadioVetenskap och Kommunikation), Stockholm,
Sweden, pp. 162-166, June 2002.
[RFC2675] Borman, D., Deering, S., and Hinden, R., "IPv6 Jumbograms",
RFC 2675, August 1999.
[draft-TunnelMTU] Templin, F., "Dynamic MTU Determination for
IPv6-in-IPv4 Tunnels", Internet-draft draft-ietf-templin-
tunnelmtu-06.txt, November 2003. Currently available from:
http://www.geocities.com/osprey67/tunnelmtu-06.txt
[RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC 3168, September
2001.
[ECN] The ECN website, http://www.icir.org/floyd/ecn.html
[draft-PMTUDv6] Park, S. D., and Lee, H., "The PMTU Discovery for
IPv6 Using Hop-by-Hop Option Header", Internet-draft draft-park-pmtu-
ipv6-option-header-00.txt, March 2003 (expired).
[draft-QS] Jain, A., and Floyd, S., "Quick-Start for TCP and IP",
Internet-draft draft-amit-quick-start-02.txt, October 2002 (expired).
Available from http://www.icir.org/floyd/quickstart.html
[TBIT] The TBIT website, http://www.icir.org/tbit/
[RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
12. Acknowledgements
The author would like to thank everybody who contributed to this
document via helpful discussions. In particular, this includes: Eddie
Kohler, Simon Leinen, Matt Mathis, Michael Richardson and Fred
Templin.
Michael Welzl Expires: September 2004 [Page 22]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
13. Author's Address
Michael Welzl
University of Innsbruck
Institute fuer Informatik
Technikerstr. 25/7
A-6020 Innsbruck, Austria
Phone: +43 (512) 507-6110
Fax: +43 (5122) 507-2977
Email: michael.welzl@uibk.ac.at
Web: http://www.welzl.at
Michael Welzl Expires: September 2004 [Page 23]
Internet Draft draft-welzl-pmtud-options-01.txt February 2004
14. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Michael Welzl Expires: September 2004 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-22 06:33:25 |