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]