Internet-Draft Dheeraj Sanghi
Expires August 1997 Sameer Shah
IIT, Kanpur
March 1997
Extended Path MTU Discovery for IP version 6
draft-sanghi-pmtudisc-ext-00.txt
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
This draft discusses extensions to the present Path MTU Discovery
mechanism [PMTUDISC]. It provides applications finer control over
the delay and losses incurred during the PMTU Discovery process. The
document proposes two extension header options that allow PMTU
Discovery with minimal overheads.
1. Introduction
In the existing mechanism [PMTUDISC], a node starts with an initial
estimate of PMTU equal to the next hop link mtu, receives Packet Too
Big (PTB) messages until it discovers the correct PMTU; or decides
to stop the process and use a minimum MTU value. Several iterations
of the packet-sent/PTB message cycle may occur before actual data
transfer begins.
This method has two disadvantages. First there is an initial variable
delay before actual data transfer. Second network resources are
wasted due to loss of packets in the discovery process. The latter
Expires August 1997 [Page 1]
Internet Draft Extended Path MTU Discovery for IPv6 March 1997
effect is offset by using a better MTU estimate for subsequent
packets, but the exact measure directly depends upon the amount of
data sent subsequently.
Clearly this imposes a significant overhead in the case where hosts
communicate infrequently (such as request-response kind of transfers)
as it is likely that knowledge of Path MTU will not exist when data
tranfer starts and will have to be discovered. With the variety of
link technologies that can interoperate in IPv6 such as wireless
links (very small MTU) to IP over SMDS (MTU of 9180 bytes), this
overhead can be large.
The tolerance to such overheads can be defined in the context of an
application. Many applications have restrictions on the tolerable
delay. Additionally many applications can determine the total amount
of data to be transferred before actual tranfer begins. If an
application has stringent delay requirements and/or has very less
data to send, it can as well do without the PMTU Discovery.
We recommend providing applications a finer control from applications
over the PMTU discovery process. Based on tolerable loss and delays,
applications should be able to decide on an optimal MTU value. We
also propose two extension header options to discover the PMTU value.
The PMTU Detection Option is present in the Hop-by-Hop extension
header and records the PMTU value on packets sent from source to
destination. The PMTU Indication Option is present in the Destination
extension header and is used by the destination of a PMTU Detection
Option to indicate the PMTU value to the source.
2. Finer Control from Applications
[PMTUDISC] suggests that an implementation provide a way to specify
whether Path MTU Discovery not be done on a given path. This should
be extended to the level of individual applications.
Applications should be able to specify a 'desired MTU' value to the
transport layer. This means that the MTU to be used for packets from
that application should not exceed this value and if the network
layer notifies a Path MTU greater than this value, the MTU should be
clamped to the desired value for the particular application.
Selection of a desired MTU depends upon the application and this
value determines the amount of overhead due to PMTU Discovery. In
the extreme case, this can be equal to 576 bytes meaning the least
delay and no loss.
2.1. Upper Layer Issues
For applications on top of TCP, the desired value can be indicated
to the TCP layer using a socket option. The TCP layer uses this
value when packetizing data from the application.
Applications on top of UDP are responsible for the packetization.
They indicate the desired value to the UDP layer. This value can be
used to decide if an application should be notified of a PMTU change.
For applications which do not respond to PMTU change notifications,
this value should be used by the source IP level fragmentation.
Expires August 1997 [Page 2]
Internet Draft Extended Path MTU Discovery for IPv6 March 1997
3. Extension Header Options
The aim of PMTU Discovery is to use the largest possible MTU estimate
so that the bandwidth utilized to transfer data is relatively larger
than that used to transfer headers and other overheads.
But as previously mentioned this benefit is offset due to loss of
packets during PMTU Discovery. We propose two extension headers that
allow PMTU Discovery with minimal losses and delay. Note that this
mechanism should be used alongwith the mechanism in [PMTUDISC]. The
proposed method is applicable only in the case of unicast destination
addresses.
We propose a hop-by-hop option that records the minimum mtu on a path
from source to destination. A source sets this option and fills the
next hop link mtu in an 'Affirmative MTU' field. Each router compares
the Affirmative MTU value in this option with the link mtu for the next
hop. If the link mtu for the next hop is smaller, it replaces the
Affirmative MTU with the link MTU for the next hop.
In the existing MTU discovery algorithm, loss of packets can occur at
two instances:
- Initial detection of PMTU
- Attempting to discover increases in PMTU
This option can be used at both these instances. When a node starts
transmission to a destination for which a pmtu estimate is not
available, it starts with a PMTU estimate of 576 bytes and sets this
option in the Hop-by-Hop extension header for the first few packets.
The destination node stores the received Affirmative PMTU value in
the local representation of a path to the sender. It indicates the
received Affirmative MTU value to the source using a new Destination
Option.
Similarly this option can be set to find increases in the PMTU.
3.1. PMTU Detection Option
This option is present in the Hop-by-Hop extension header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Type=TBD|Opt Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Affirmative PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires August 1997 [Page 3]
Internet Draft Extended Path MTU Discovery for IPv6 March 1997
"TBD" The Hop-by-Hop Option Type number allocated by
IANA for this option.
Affirmative PMTU This field is set by the sender node to be the
next hop MTU. Each router sets this value to
the minimum of the current value and the next
hop MTU
Routers that do not recognize this option should discard the packet
and send an ICMP Parameter Problem message to the packet's Source
Address. This option can be changed en-route.
3.2. PMTU Indication Option
This option is present in the Destination extension header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Type=TBD|Opt Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Affirmative PMTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"TBD" The Destination Option Type number allocated by
IANA for this option.
Affirmative PMTU The affirmative PMTU value received in the PMTU
Indication Option on a packet from the
destination node
The option data does not change en-route.
3.3. Discussion
A likely usage scenario is described here.
Applications indicate their willingness to set these options to the
transport layer.
When a willing application sends data to a destination with a unicast
address, it uses the available PMTU only if it is Affirmative i.e.
it has been previously discovered using the PMTU Detection and PMTU
Indication Options. Otherwise it uses a PMTU of 576 bytes. The PMTU
Detection Option is set in the sent packets. Related state
information such as the time when probe started and the number of
Expires August 1997 [Page 4]
Internet Draft Extended Path MTU Discovery for IPv6 March 1997
packets sent with the option set, can be stored in the local
representation of a path to the destination e.g. the destination
cache. When a PMTU Indication Option is received from the destination
within a maximum timeout period or the round trip time (if
available), the Affirmative MTU is indicated to the transport layers.
Additionally the PMTU to the destination can be set equal to the
received Affirmative MTU in the local representation of the
destination. If a PMTU Indication Option is not received within the
threshold time interval or a ICMP Parameter Problem message is
received for a packet sent with the PMTU Detection Option, then PMTU
Discovery proceeds using the method in [PMTUDISC].
When an increase in PMTU is to be discovered, the PMTU estimate is
not changed for willing applications initially, but the PMTU
Detection Option is set in sent packets. If the received PMTU
Indication Option indicates a change in the Affirmative PMTU value,
the new PMTU for the destination is notified to the packetization
layers. Again if a timeout occurs and a PMTU Indication Option is
not received or a ICMP Parameter Problem message is received, then it
reverts to the default PMTU Discovery algorithm.
A node receiving the PMTU Detection Option sets the PMTU Indication
Option in packets sent from willing applications to the initial
sender. [PMTUDISC] recommends a timeout of 10 minutes before trying
to discover an increased PMTU, but we expect the proposed extensions
can be used with a higher frequency based on actual link conditions
and previous feedbacks. If this option is used only once in 5 - 10
minutes, then the overhead is minimal.
4. Security Considerations
The PMTU Detection Option is vulnerable to similar denial-of-service
attacks as described in [PMTUDISC].
The PMTU Detection Option is zeroed for AH calculations as it can
change along the path. The PMTU Indication Option is included in the
IPv6 Authentication Header and is not zeroed for AH calculations.
5. References
[PMTUDISC] J. McCann, S. Deering & J. Mogul, "Path MTU Discovery for
IP version 6", RFC-1981, Internet Engineering Task Force, August 1996.
Expires August 1997 [Page 5]
Internet Draft Extended Path MTU Discovery for IPv6 March 1997
Authors' Addresses:
Dheeraj Sanghi
Department of CSE
Indian Institute of Technology
Kanpur, India
Phone: +91 (512) 25-7077
Email: dheeraj@iitk.ernet.in
Sameer Shah
Department of CSE
Indian Institute of Technology
Kanpur, India
Phone: +91 (512) 25-7653
Email: ocrds@iitk.ernet.in
Expires August 1997 [Page 6]