Internet DRAFT - draft-templin-linkadapt-reqts
draft-templin-linkadapt-reqts
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Expires: April 3, 2006 September 30, 2005
Requirements for Link Adaptation over IP-in-IPv4 Tunnels
draft-templin-linkadapt-reqts-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 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IP-in-IPv4 tunnel endpoints present a Maximum Transmission Unit (MTU)
to layer 3 via static prearrangements and/or dynamic MTU
determination based on ICMPv4 messages, but these methods have known
operational limitations that can cause degraded performance and
communications failures. A new method for providing link adaptation
over IP-in-IPv4 tunnels is needed.
Templin Expires April 3, 2006 [Page 1]
Internet-Draft Requirements for Link Adaptation September 2005
1. Introduction
IP-in-IPv4 tunnels span multiple IPv4 network hops yet are seen by
layer 3 as ordinary links that must support a minimum MTU (e.g., 1280
bytes for IPv6). 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 IPv4 network-based fragmentation. Optional dynamic
MTU determination methods based on ICMPv4 "fragmentation needed"
messages are also available, but can result in communication failures
due to the unreliable and untrustworthy nature of ICMPv4 messages
generated by network middleboxes. This document discusses
operational issues with the MTU determination schemes used by
tunneling mechanisms and outlines requirements for a link adaptation
method that can present an assured MTU to layer 3.
2. Problems with IPv4 Fragmentation
Common IP-in-IPv4 tunneling mechanism encapsulators set a tunnel MTU
(e.g., 1280 bytes or slightly larger for IPv6) and do not set the DF
bit in the IPv4 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, IPv4 fragmentation
has well-known issues [FRAG1][FRAG2][FRAG2] resulting in degraded
performance and/or communications failures along some paths. In
particular, IPv4 firewalls and NAT boxes typically discard fragments
other than the first fragment of fragmented IPv4 datagrams resulting
in communications failure potential for tunnels that span such
devices.
3. Problems with IPv4 Path MTU Discovery
IP-in-IPv4 tunneling mechanisms can use IPv4 Path MTU Discovery by
setting the DF bit in the IPv4 headers of tunneled packets, but this
method relies on ICMPv4 "fragmentation needed" messages coming from
untrusted middleboxes along the path. A well-known issue is that
ICMPv4 messages are often dropped by IPv4 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 ICMPv4 "fragmentation
needed" messages inserted by on-path or off-path adversaries.
[ICMPATK] and [PMTUD] discuss possible mitigations for dealing with
fabricated ICMPv4 "fragmentation needed" messages, but no mitigations
are possible when legitimate middleboxes fail to send/forward the
ICMP's.
Templin Expires April 3, 2006 [Page 2]
Internet-Draft Requirements for Link Adaptation September 2005
4. Requirements for Link Adaptation over IP-in-IPv4 Tunnels
Due to the operational issues with both IPv4 fragmentation and IPv4
Path MTU discovery, a new mechanism is needed to support efficient
and reliable use of the available MTU over IP-in-IPv4 tunnels. Since
no other mechanisms are available to IPv4, and since all tunnel MTU
mitigations must occur below layer 3, the only remaining option is to
provide a link adaptation scheme that operates at a logical "layer
2.5" below IP as layer 3 and above IPv4 as layer 2.
The following subsections present requirements for link adaptation:
4.1. Tunnel Endpoint Negotiation
The link adaptation 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 IPv4 Mechanisms
The link adaptation scheme must be compatible with both IPv4
fragmentation/reassembly and ICMPv4 "fragmentation needed" messages
from IPv4 Path MTU Discovery. In particular, any packets prepared by
the link adaptation scheme must not be disrupted by any IPv4
fragmentation that occurs on the path. The encapsulating node that
performs link adaptation must also be prepared to deal with any
ICMPv4 "fragmentation needed" messages it may receive in response to
link adaptation packets, e.g. as outlined in [ICMPATK][PMTUD].
4.3. Host-based Segmentation at the Encapsulator
The link adaptation scheme must provide a means for the encapsulating
tunnel endpoint to split upper layer payloads (ULPs) into segments
that are small enough to traverse the tunnel. The segmentation must
occur prior to IPv4 encapsulation.
4.4. Reassembly at the Decapsulator
The link adaptation scheme must provide a means for the decapsulating
tunnel endpoint to reassemble ULPs that were conveyed in multiple
segments from the encapsulator. The reassembly must occur after IPv4
reassembly, since it is possible that the segments may have also
incurred IPv4 fragmentation along the path.
Templin Expires April 3, 2006 [Page 3]
Internet-Draft Requirements for Link Adaptation September 2005
4.5. Means for Detecting Packet Splicing Errors
The link adaptation scheme must provide a means for the decapsulating
tunnel endpoint to detect packet splicing errors as it reassembles
the segments of ULPs.
4.6. Means for Accommodating Out-of-Order Delivery
The link adaptation 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 ULPs.
4.7. Path Probing by the Encapsulator
The link adaptation scheme must provide a means for the encapsulator
to mark a segment as a "probe" segment used to determine whether
segments of a certain size can traverse the tunnel. The scheme must
allow for out-of-band path probing (i.e., when the probe segment is
not a segment of an actual tunneled packet) and should also allow for
in-band path probing.
4.8. Authenticated Probe Response from the Decapsulator
The link adaptation 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 link adaptation 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. Assured MTU to Upper Layers
The link adaptation scheme must provide an assured MTU to upper
layers such that packets no larger than the MTU will be accepted by
the tunnel or a suitable "packet too big" message will be returned.
4.11. Decapsulator MRU Discovery
The link adaptation scheme must provide a means for the encapsulator
to discover the maximum receive unit (MRU) for each decapsulator.
Templin Expires April 3, 2006 [Page 4]
Internet-Draft Requirements for Link Adaptation September 2005
5. IANA Considerations
This document does not introduce any IANA considerations.
6. Security Considerations
This document does not introduce any security considerations.
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.
Templin Expires April 3, 2006 [Page 5]
Internet-Draft Requirements for Link Adaptation September 2005
[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 3, 2006 [Page 6]
Internet-Draft Requirements for Link Adaptation September 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 3, 2006 [Page 7]
Internet-Draft Requirements for Link Adaptation September 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 3, 2006 [Page 8]
