Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Expires: April 6, 2006 October 3, 2005
Requirements for IP-in-IP Tunnel MTU Assurance
draft-templin-mtuassurance-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IP-in-IP tunnels present a Maximum Transmission Unit (MTU) to layer 3
via static prearrangements and/or dynamic MTU determination based on
layer 2 ICMP messages, but these methods have known operational
limitations that can fail to enforce an assured MTU resulting in
degraded performance and communications failures. A method for
providing an assured MTU to layer 3 over IP-in-IP tunnels is needed.
Templin Expires April 6, 2006 [Page 1]
Internet-Draft Requirements for MTU Assurance October 2005
1. Introduction
IP-in-IP tunnels span multiple layer 2 network hops yet are seen by
layer 3 as ordinary links that must support an assured MTU, e.g.,
1280 bytes for the IPv6 minimum MTU). Common tunneling mechanisms
(e.g., [RFC2529][RFC3056][ISATAP][MECH][TEREDO]) meet this
requirement through conservative static prearrangements at the
expense of degraded performance and/or communications failures over
some paths due to excessive layer 2 network-based fragmentation.
Optional dynamic MTU determination methods based on layer 2 ICMP
"packet too big" messages are also available, but can result in
communication failures due to the unreliable and untrustworthy nature
of layer 2 ICMP messages generated by network middleboxes. This
document discusses operational issues with the MTU determination
schemes used by common tunneling mechanisms and outlines requirements
for a new method that can present an assured MTU to layer 3.
2. Problems with Network-Based Fragmentation
Common IP-in-IP tunneling mechanism encapsulators set a static layer
3 tunnel MTU (e.g., 1280 bytes or slightly larger for IPv6) and do
not set the DF bit in the layer 2 IP headers of tunneled packets such
that packets that are too large to traverse the path before reaching
the decapsulator will be fragmented by the network. Unfortunately,
network-based IP fragmentation has well-known issues
[FRAG1][FRAG2][FRAG3] that can result in degraded performance and/or
communications failures along some paths. In particular, firewalls
and NAT boxes typically discard fragments other than the first
fragment of fragmented IP datagrams resulting in communications
failure potential for tunnels that span such devices.
3. Problems with Path MTU Discovery
IP-in-IP tunneling mechanisms can use Path MTU Discovery by setting
the DF bit in the layer 2 IP headers of tunneled packets, but this
method relies on layer 2 ICMP "packet too big" messages coming from
untrusted network middleboxes along the path. A well-known issue is
that ICMP messages are often dropped by firewalls and/or NATs
resulting in MTU-related black holes along some paths [RFC2923].
Additionally, the untrusted middlebox paradigm opens the possibility
for various spoofing attacks via fabricated ICMP messages inserted by
on-path or off-path adversaries. [ICMPATK] and [PMTUD] discuss
possible mitigations for dealing with fabricated ICMP messages, but
no mitigations are possible when legitimate middleboxes fail to send/
forward the ICMP's.
Templin Expires April 6, 2006 [Page 2]
Internet-Draft Requirements for MTU Assurance October 2005
4. Requirements for IP-in-IP Tunnel MTU Assurance
Due to the operational issues with both layer 2 network-based IP
fragmentation and Path MTU discovery, a new mechanism is needed to
assure efficient and reliable use of the available MTU over IP-in-IP
tunnels. In particular, a mechanism is needed to present an assured
MTU to layer 3 such that packets no larger than the MTU will be
accepted by the tunnel or a suitable layer 3 "packet too big" message
will be returned.
The following subsections present requirements for IP-in-IP tunnel
MTU assurance:
4.1. Tunnel Endpoint Negotiation
The MTU assurance scheme must provide a means for the encapsulating
and decapsulating tunnel endpoints to determine that the scheme is
implemented at both ends. When only one (or neither) of the tunnel
endpoints implements the scheme, behavior must revert back to that
specified by the current tunneling mechanisms.
4.2. Compatible with IP Mechanisms
The MTU assurance scheme must be compatible with both layer 2
network-based IP fragmentation/reassembly and layer 2 ICMP "packet
too big" messages from Path MTU Discovery that may occur from within
the tunnel. In particular, any packets prepared by the MTU assurance
scheme must not be disrupted by any layer 2 network-based IP
fragmentation that occurs along the path. An encapsulating node that
implements the MTU assurance scheme must also be prepared to deal
with any layer 2 ICMP "packet too big" messages it may receive in
response to tunneled packets, e.g. as outlined in [ICMPATK][PMTUD].
4.3. Host-based Segmentation at the Encapsulator
The MTU assurance scheme must provide a means for the encapsulating
tunnel endpoint to split layer 3 payloads into segments that are
small enough to traverse the tunnel. The segmentation must occur
below layer 3 and prior to layer 2 IP encapsulation.
4.4. Reassembly at the Decapsulator
The MTU assurance scheme must provide a means for the decapsulating
tunnel endpoint to reassemble layer 3 payloads that were conveyed in
multiple segments from the encapsulator. The reassembly must occur
after layer 2 IP reassembly (and prior to layer 3 delivery), since it
is possible that the segments may have also incurred fragmentation
along the path.
Templin Expires April 6, 2006 [Page 3]
Internet-Draft Requirements for MTU Assurance October 2005
4.5. Means for Detecting Packet Splicing Errors
The MTU assurance scheme must provide a means for the decapsulating
tunnel endpoint to detect packet splicing errors as it reassembles
the segments of layer 3 payloads.
4.6. Means for Accommodating Out-of-Order Delivery
The MTU assurance scheme must provide a means for the decapsulating
tunnel endpoint to accommodate out-of-order delivery for the segments
it receives while reassembling the segments of layer 3 payloads.
4.7. Path Probing by the Encapsulator
The MTU assurance scheme must provide a means for the encapsulator to
send "probe" segments used to determine whether segments of a certain
size can traverse the tunnel. The scheme should allow for in-of-band
path probing (i.e., when the probe segment is a segment of an actual
tunneled packet) and must allow for out-of-band path probing.
4.8. Authenticated Probe Response from the Decapsulator
The MTU assurance scheme must provide a means for the decapsulator to
send an authenticated probe response message back to the encapsulator
to acknowledge the receipt of a probe segment.
4.9. Proactive Path Probing
The MTU assurance scheme should perform proactive path probing to
quickly determine the most efficient segment size to use for a
particular tunnel. The scheme should also periodically re-probe the
path to determine whether path MTU reductions due to route
fluctuations have occurred.
4.10. Decapsulator MRU Discovery
The MTU assurance scheme must provide a means for an encapsulator to
discover the maximum receive unit (MRU) for each decapsulator.
5. IANA Considerations
This document does not introduce any IANA considerations.
6. Security Considerations
This document does not introduce any security considerations.
Templin Expires April 6, 2006 [Page 4]
Internet-Draft Requirements for MTU Assurance October 2005
7. Acknowledgments
This document represents the mindshare of many contributors.
8. Informative References
[FRAG1] Mogul, J. and C. Kent, "Fragmentation Considered Harmful,
In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology.", August 1987.
[FRAG2] Mathis, M., Heffner, J., and B. Chandler, "Fragmentation
Considered Very Harmful", draft-mathis-frag-harmful (work
in progress), July 2004.
[FRAG3] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", draft-savola-mtufrag-network-tunneling
(work in progress), May 2005.
[ICMPATK] Gont, F., "ICMP Attacks Against TCP",
draft-gont-tcpm-icmp-attacks (work in progress),
September 2005.
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap (work in progress),
January 2005.
[MECH] Nordmark, E. and R. Gilligan, "Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2 (work in
progress), March 2005.
[PMTUD] Mathis, M., Heffner, J., and K. Lahey, "Path MTU
Discovery", draft-ietf-pmtud-method (work in progress),
February 2005.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo (work in progress),
April 2005.
Templin Expires April 6, 2006 [Page 5]
Internet-Draft Requirements for MTU Assurance October 2005
Author's Address
Fred Lambert Templin (editor)
Boeing Phantom Works
P.O. Box 3707
Seattle, WA 98124
USA
Email: fred.l.templin@boeing.com
Templin Expires April 6, 2006 [Page 6]
Internet-Draft Requirements for MTU Assurance October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Templin Expires April 6, 2006 [Page 7]