INTERNET-DRAFT Soohong Daniel Park
Expires: September 2003 Hakgoo Lee
SAMSUNG Electronics
March 2003
The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header
<draft-park-pmtu-ipv6-option-header-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
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 presents a new method for the PMTU discovery for IPv6.
To discover the PMTU of a path, a source node measures its actual PMTU
using the newly defined Hop-by-Hop Option header, whereas a source
node initially assumes that the PMTU of a path is the known MTU of
the first hop in the path in the previous one [1981]. In order to
measure the actual PMTU, the source node sends the IP packet with the
newly defined Hop-by-Hop Option header to the destination node with
the first data packet when node is beginning. This can eliminate the
chance of occurrence of several iterations of the somewhat complex
discovery cycle (sending a packet, receiving a Packet Too Big message,
reducing a packet size). Most of all, since existing PMTU has a weak
point for security and denial-of-service attacks, this document
suggests a security function when PMTU is going on.
All IPv6 nodes, including both hosts and routers, must implement newly
Options as defined in this specification.
Park,Lee Expires September 2003 [Page 1]
INTERNET-DRAFT March 2003
Table of Contents
Abstract
1. Introduction
2. Terminology
3. Proposed Method : Overview
3.1 Request MAP Option Format
3.2 Response MAP Option Format
4. Node Requirements for Discoverying PMTU
4.1 Source Node and Destination Node
4.2 Nodes on Routing Path
4.3 Operation Procedure
5. Mode Requirements for Detecting PMTU
5.1 Source Node and Destination Node
5.2 Nodes on Routing Path
5.3 Operation Procedure
6. Comparison with [1981]
7. Security Considerations
8. Normative Reference
9. Informative References
10. Acknowledgements
11. Authors' Addresses
12. Intellectual Property
13. Copyright
1. Introduction
The discovery of the Path MTU (PMTU) is described in [1981]. The basic
idea of [1981] is that a source node initially assumes that the a
path's PMTU is the known MTU of the first hop in the path. If any of
the packets sent on that path are too large to be forwarded by some
node along the path, that node will discard them and return ICMPv6
Packet Too Big messages [2463]. Upon receipt of such a message, the
source node reduces its assumed PMTU for the path based on the MTU of
the constricting hop as reported in the Packet Too Big message. The
PMTU Discovery process ends when packets arrive at the destination
node.
However, in [1981], there may be several iterations of the somewhat
complex discovery cycle (sending a packet, receiving a Packet Too Big
message, reducing a packet size), before the actual PMTU is obtained.
In the worst case, the number of interactions becomes the number of
hops in the path. This method might be somewhat inefficient.
Therefore, a new method for the PMTU discovery is suggested in this
document. In this new method, to discover the PMTU of a path, the
source node measures its actual PMTU using the newly defined
Hop-by-Hop Option header. To measure the actual PMTU, the source node
sends the IP packet with the newly defined Hop-by-Hop Option header
to the destination node with the first data packet which should be the
its link MTU when node is beginning. After then, the measured PMTU is
used to send the subsequent packets.
Park,Lee Expires September 2003 [Page 2]
INTERNET-DRAFT March 2003
Now, another problem can be considered in PMTU Discovery [1981]. Due
to changes in the routing topology, the PMTU of a path may change over
time. In [1981], to detect increases of the PMTU of a path, the source
node periodically increases its assumed PMTU although this is done
infrequently (10 minutes in general). However, in this method, the
assumed PMTU is increased by the source node's link MTU
unconditionally. This may also result in several iterations of the
discovery cycle. This problem can be also resolved by the proposed
method.
Therefore, in both discovering PMTU and detecting PMTU's increases,
the proposed method can eliminate the chance of occurrence of several
iterations of the somewhat complex discovery cycle. Thus, the proposed
method in this document can be helpful for the best-conditioned
network environment because the actual PMTU is measured dynamically
for changes in the routing topology.
Finally, existing PMTU [1981] mechanism makes possible some denial-of-
service attacks, most of all, both are based on a malicious party
sending false Packet Too Big messages to a victim. Accordingly both
weak points, it will result in suboptimal performance and availability
of denial-of-service attacks. This document suggests the secure PMTU
method. It is described in section 7.
2. Terminology
o PMTU is the minimum link MTU of all the links
in a path between a source node and a
destination node.
o MTU is stands for Maximum Transmission Unit.
i.e., maximum packet size in octets,
that can be conveyed in one piece over
a link.
o Detection Timer Nodes may send PMTU packet at infrequent
intervals in order to detect an increase.
The recommended setting for this timer
is same value as [1981]. (10 minutes)
o Response Timer If the source node does not receive the
packet with Response MAP Option until
the Response Timer expires, the source
node initially assumes that the PMTU
of a path is the MTU of the first hop
in the path as [1981].
o MAP is stands for Measuring Actual PMTU. In
order to perform MAP, newly MAP Option
must be done.
o Discoverying PMTU When node is beginning, node should
perform PMTU to discovery its own value.
Park,Lee Expires September 2003 [Page 3]
INTERNET-DRAFT March 2003
o Detecting PMTU's Increase
Nodes may detect increases in PMTU.
o Request MAP Option is used to request MAP information to
destination. See section 3.1
o Response MAP Option is used to response MAP information to
source. See section 3.2
3. Proposed Method : Overview
This section gives a brief overview of the new method for the
discoverying and detecting PMTU mechanisms.
A router on routing path examines only IP header, Hop-by-Hop Option
header and routing header in extension header. Other extension headers
and data are examined only by a source node and destination node.
In the new method, Hop-by-Hop Option header is used to measure
increases in a path's PMTU
The Hop-by-Hop Option header and Option is defined as below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Figure 1 Hop-by-Hop Option Header>
Currently, Hop-by-Hop Option headers are Pad1, PadN, Jumbo Payload,
and Router Alert Options. This document defines a new Option. It is
called 'Measuring Actual PMTU (MAP Option)'. Then, the IP packet
including Hop-by-Hop Option header with MAP Option has the following
format.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
Park,Lee Expires September 2003 [Page 4]
INTERNET-DRAFT March 2003
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | 0 | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Data(PMTU) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit identifier of the type of Option.
Opt Data Len 8-bit unsigned integer. Length of the Option
Data field of this Option, in octets.
Option Data(PMTU) Measured PMTU value with 4 bytes
<Figure 2 IP Packet with MAP Option>
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken when
the router does not recognize the Option Type. The third highest
order bit of the Option Type specifies whether or not the Option
Data (PMTU) of that Option can change en-route to the packet's
final destination. The other five bits are defined arbitrarily.
The MAP Option has two Option Types. The one is Request MAP Option
and the other is Response MAP Option, which will be shown in
following subsections. If any of the routers en-route cannot
recognize the Option Types, it skips over or discards the packet
silently. It depends on operator policy.
o The highest-order two bits of the Option type is 00
If routers are not understand MAP Options, this packet
must be skipped over this Option and continue processing
the header. When this Option meets with possible router,
this PMTU must be modified. When source node receives
this response, it is not actual PMTU because all routers
are not understand. If received MTU is larger than its
own value, this MTU should be ignored.
Note : In initiation case, node must use "00" value
because of response error message
(Packet Too Big message).
o The highest-order two bits of the Option type is 01
If routers are not understand MAP Options, this packet
must be discarded, at this case, source node has its
waiting time. When this time is expired without any
response, this node should perform original PMTU as
[1981].
Park,Lee Expires September 2003 [Page 5]
INTERNET-DRAFT March 2003
This document suggests that if specific link should be performed with
small PMTU value, at this point, MAP Options should be applied.
3.1 Request MAP Option Format
The Request MAP Option format is defined to measure real PMTU as
shown in Figure 3. The source node sends the IP packet with this
Request MAP Option format to the destination node.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 x 1|1 0 0 0 0|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P M T U |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Highest-order two bits
00 - Skip over this Option and continue processing the header
01 - discard the packet
The third-highest-order bit
1 - Option Data may change en-route
Option Type - 112 (temporary value)
Option Length - 4
PMTU - 4 Octets
<Figure 3 Request MAP Option Format>
3.2 Response MAP Option Format
The Response MAP Option format is defined to response measured
real PMTU as shown in Figure 3. The destination node sends the IP
packet with this Response MAP Option format to the source node.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 x 0|1 1 0 0 0|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P M T U |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Highest-order two bits
00 - Skip over this Option and continue processing the header
01 - discard the packet
The third-highest-order bit
0 - Option Data does not change en-route
Park,Lee Expires September 2003 [Page 6]
INTERNET-DRAFT March 2003
Option Type - 88 (temporary value)
Option Length - 4
PMTU - 4 Octets
<Figure 4 Response MAP Option Format>
3.3 Discoverying PMTU with MAP Options
The source node sends IP packet with Request MAP Option to the
destination node when node is beginning to communicate. Initial MTU
value should be its link MTU of the source node. After node receives
Response MAP Option with PMTU, the subsequent packets will be sent of
course using obtained PMTU. If the first packet with the IPv6 minimum
link MTU don't go through the next-hop, its node must not reduce its
estimate of the PMTU below the IPv6 minimum link MTU. At this case,
node may receive a Packet Too Big message reporting a next-hop MTU
that is less than IPv6 minimum link MTU. Then, node must include a
Fragment header in those packets. This packet should be composed of
the following headers:
IPv6 Header
Hop-by-Hop Options with Request/Response MAP Option
Fragment
...
While the packet is passing through nodes en-route, the following
action occurs.
- Compare PMTU in Request MAP Option and Link MTU of next hop.
- Store the smaller value between them on PMTU field of the packet.
By doing the same action on routers en-route, PMTU field of the IP
packet with Request MAP Option is updated to have minimum PMTU.
This is the actual PMTU value. The destination node that receives
the IP packet returns back this value to the source node using
Response MAP Option. The source node that receives the actual PMTU
value determines the transmission length of a packet. However, if
all routers don't recognize MAP Options, responsed MTU is not actual
PMTU.
3.4 Detecting PMTU with MAP Options
As described on Path MTU Discovery [1981], a source node sends IP
packet with Request MAP Option to a destination node before the
Detection Timer expires so that it wants to increase PMTU value.
Default MTU value is link MTU of the source node. This packet
should be composed of the following headers:
IPv6 Header
Hop-by-Hop Options with Request/Response MAP Option
Park,Lee Expires September 2003 [Page 7]
INTERNET-DRAFT March 2003
While the packet is passing through nodes en-route, the actions are
the same as section 3.3
By doing the same action on routers en-route, PMTU field of the IP
packet with Response MAP Option is updated to have minimum PMTU.
This is the optimal PMTU value. The destination node that receives
the IP packet returns back this value to the source node using
Response MAP Option. The source node that receives the optimal PMTU
value determines the transmission length of a packet. This method can
reduce the number of ICMP-Packet Too Big Error message, otherwise
happens more frequently. This also reduce waste of network resource.
4. Node Requirements for Discoverying PMTU
4.1 Source Node and Destination Node
When the IPv6 source node has a large amount of packets to send to the
destination node, the source node sends the IP packet with Request MAP
Option to the destination when node is beginning. The PMTU field of
Request MAP Option of the packet initialized by the value of its link
MTU of the source node. If router does not understand the MAP Options,
the packet is skipped over this Option and continue processing the
header (See section 3.). When node receives the Packet Too Big message
this node should be performed existing PMTU as [1981].
Whenever the destination node receives the IP packet with Request MAP
Option, it must response the IP packet with Response MAP Option
immediately. By the Option Type, this packet cannot be modified by
routers on routing path.
4.2 Nodes on Routing Path
Nodes on a routing path are routers. When the IP packet with Request
MAP Option arrives on these routers, they compare the PMTU in Request
MAP Option and link MTU of the next hop. They select a smaller value
between them and forward the packet with a PMTU value. After doing
the same procedure, the final destination node comes to know minimum
PMTU. If the IP packet with Response MAP Option arrives on theses
routers, they forward the packet without any modification. If routers
can not recognize two MAP Options, it skips over this Option and
continue processing the header since the first two bits of the MAP
Option is 00. (See section 3.).
4.3 Operation Procedure
When the IPv6 source node sends to the destination node, the source
node sends the IP packet with Request MAP Option and its link MTU of
the source node to a destination. In this case, the Option Type in
Request MAP Option is 112 (temporary value). While the packet is
Park,Lee Expires September 2003 [Page 8]
INTERNET-DRAFT March 2003
en-route, intermediate routers compare the PMTU in Request MAP Option
and link MTU of the next hop. They select a smaller value between
them, store the value to PMTU field of Request MAP Option and forward
the packet with the updated PMTU. PMTU of the packet arrived at the
destination node becomes minimum PMTU. The destination node sends the
IP packet Response MAP Option to inform the source node. In this case,
the Option Type in Request MAP Option is 88 (temporary value). After
then, the source node sends packets using new PMTU. If routers
implements only previous PMTU Discovery [1981] on routing path, in
this case the router can skip over this Option and continue processing
the header. If node receives the Packet Too Big message, the source
node should be performed existing PMTU as [1981]. If node receives
Response MAP Option, the source node must compare with its own MTU
value. The source node selects a smaller value between them and store.
Therefore, in discovering PMTU, the proposed method can eliminate
the chance of occurrence of several iterations of the discovery
cycle.
5. Node Requirements for Detecting PMTU
5.1 Source Node and Destination Node
A source node does not change the PMTU value for some amount of time
after it comes to know PMTU based on PMTU Discovery [1981]. When the
source node wants to increase PMTU by the Detection Timer, it sends
the IP packet with MAP Options to a destination. The PMTU field of
MAP Options of the packet contains the value of link MTU of the
source node and the data. Whenever a destination node receives the
IP packet with Request MAP Option, it must response the IP packet
with Response MAP Option immediately. By the Option Type, this packet
cannot be modified by routers on routing path. Also, it can use both
type "00" and "01". It depends on operator policy. In order to use
type "01", source node must have its timer, Response Timer.
5.2 Nodes on Routing Path
This processing is same as section 4.2
5.3 Operation Procedure
When the source node wants to increase PMTU by the Detection Timer,
it sends the IP packet with Request MAP Option to a destination.
In this case, the Option Type in Request MAP Option is 112 (temporary
value). While the packet is en-route, intermediate routers compare the
PMTU in MAP Option and link MTU of the next hop. They select a smaller
value between them, store the value to PMTU field of MAP Option and
forward the packet with the updated PMTU. PMTU of the packet arrived
at the destination node becomes minimum PMTU. The destination node
sends the IP packet Response MAP Option to inform the source node. In
Park,Lee Expires September 2003 [Page 9]
INTERNET-DRAFT March 2003
this case, the Option Type in Response MAP Option is 88 (temporary
value). After then, the source node sends packets using new PMTU.if
routers implements only previous PMTU Discovery [1981] on routing
path, in this case the router can silently discard the packet
without response error message by the highest-order two bits, 01,
in Option Type field or skip over this Option and continue processing
the header with MAP Options by the highest-order two bits, 00, in
Option Type field. If the source node does not receive the IP packet
with Response MAP Option until the Response Timer expires, the source
node initially assumes that the PMTU of a path is the MTU of the first
hop in the path as [1981].
6. Comparison with [1981]
This section should be discussed more detail.
o In order to perform PMTU, [1981] uses ICMPv6, but MAP uses
only basic IPv6 protocol and extension header with newly
Option. We assure that it should be implemented very easy in
host and router as well.
o In the aspect of implementation, all IPv6 nodes, including
both hosts and routers, must implement newly Options as
defined in this specification.
o As described in [1981], MAP should consider all
implementation issues.
7. Security Considerations
As we knew, existing PMTU [1981] mechanism makes possible two denial
-of-service attacks, most of all, both are based on a malicious
party sending false Packet Too Big messages to a victim.
Accordingly both weak points, it will result in suboptimal
performance and availability of denial-of-service attacks.
MAP mechanism is not likely to do denial-of-service attacks. However
when malicious node sends false MAP response with its correct type,
there are still simpler denial-of-service attacks available.
This document considers the protection method from various attacks.
In order to avoid spoofing or attacking with incorrect response,
MAP mechanisms can use the 64-bit Nonce field. Its value in a MAP
Option is always copied from the corresponding Request MAP by the
responder. This method is an Optional, therefore the usage of this
method depends on operator. However this document recommends this
method is implemented with MAP Options for the secure PMTU.
Park,Lee Expires September 2003 [Page 10]
INTERNET-DRAFT March 2003
+... +
| Original IPv6 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | 1 |MAP Option Typ |0 0 0 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nonce |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Data(PMTU) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Figure 5 Secure PMTU with MAP Option>
The Nonce should be a random or good pseudo-random value to foil
spoofed replied. An implementation which allows multiple independent
processes to send MAP Option may use the Nonce value to deliver MAP
Option to the correct process. Nonetheless, such processes must
check the received Nonce and ignore extraneous response.
8. Normative Reference
[1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
9. Informative References
[2460] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6)", RFC 2460, December 1998.
[2463] A. conta, S. Deering, "Internet Control message Protocol
(ICMP) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
9. Acknowledgements
The authors would like to thank Robert Hinden for his careful reviews
of this draft.
10. Authors' Addresses
Soohong Daniel Park
SAMSUNG Electronics
Digital Media R&D Center
Tel : +82-31-200-3728
Fax : +82-31-200-3147
E-mail : soohong.park@samsung.com
Park,Lee Expires September 2003 [Page 11]
INTERNET-DRAFT March 2003
Hakgoo Lee
SAMSUNG Electronics
Digital Media R&D Center
Tel : +82-31-200-9309
Fax : +82-31-200-3147
E-mail : solited@samsung.co.kr
11. Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society July 12, 2001. 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 implementation 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.
Park,Lee Expires September 2003 [Page 12]
INTERNET-DRAFT March 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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.
Park,Lee Expires September 2003 [Page 13]