Network Working Group F. Templin Internet-Draft Nokia Expires: May 18, 2004 November 18, 2003 Dynamic MTU Determination for IPv6-in-IPv4 Tunnels draft-templin-tunnelmtu-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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. This Internet-Draft will expire on May 18, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a means for IPv6-in-IPv4 tunnel endpoints to support dynamic maximum transmission unit (MTU) determination. It provides a means for the local end to recognize when a packet should be forwarded to the far end, and when it should be dropped. Templin Expires May 18, 2004 [Page 1] Internet-Draft Tunnel MTU November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Static MTU Determination . . . . . . . . . . . . . . . . . . . . 4 4. Dynamic MTU Determination . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . 9 Templin Expires May 18, 2004 [Page 2] Internet-Draft Tunnel MTU November 2003 1. Introduction IPv6-in-IPv4 tunnel interfaces (referred to hereafter as "tunnel interfaces" or simply "tunnels") use an IPv4 [RFC0791] internetwork as the link layer for IPv6 [RFC2461]. The local and remote tunnel endpoints are IPv6 neighbors, but packets inside the tunnel may traverse multiple IPv4 forwarding hops. Packets that are too large to traverse the tunnel are discarded with an ICMPv6 "packet too big" message returned to the source, as for any IPv6 interface [RFC1981]. IPv4 path MTU discovery [RFC1191] is normally used to determine the MTU of an IPv4 path. However, IPv4 path MTU discovery uses ICMPv4 "fragmentation needed" messages which in some cases do not provide enough bytes from the original IPv6 packet header for stateless translation to ICMPv6 "packet too big" messages ([RFC1812], section 4.3.2.3). Additionally, ICMPv4 messages can be spoofed, filtered, or not sent at all by some forwarding nodes resulting in black holes that are difficult to diagnose [RFC2923]. When designing an alternate path MTU discovery scheme, it is important to note that for IPv6 the representation of a path consists of the 3-tuple of the Flow Label and the Source and Destination address fields in the IPv6 header [FLOWSPEC]. It is also observed that the problem of black hole detection when an IPv4 path changes to include a restricting link is difficult if not impossible to solve as a network layer problem. Past attempts to do so have included: o the current IPv4 Path MTU discovery scheme. (But, in addition to the operational issues described above, IPv4 path MTU discovery is inefficient due to extra control messages and slow to converge.) o probing the path with large data messages. (But, probing requires queueing packets for an indeterminant time in the sender while waiting for the probe to complete.) o sensing fragmentation at the receiver. (But, this requires special instrumentation in the receiver - also, forwarding nodes that do not support IPv4 fragmentation may occur along some paths and middleboxes that drop IPv4 fragments are seen in operational deployments.) o maintaining flow state in the tunnel interface. (But, this consumes resources and requires probe acknowledgement messages from a trusted neighbor.) The dominating issue with any approach implemented solely at the network layer is that it is not possible for the network layer to anticipate the packet transmission strategy of the application. Any Templin Expires May 18, 2004 [Page 3] Internet-Draft Tunnel MTU November 2003 attempt for the network layer to divine such information without the explicit guidance of the application amounts to nothing more than an educated guess that is likely to be wrong - a result predicted by the End-to-End Principle. Thus, alternate mechanisms to support dynamic MTU determination for IPv6-in-IPv4 tunnel interfaces are required. 2. Terminology The terminology of [RFC2460], [RFC2461], and [RFC3168] applies to this document. The following terms used in those documents are also defined here for clarity: MTU: same definition as in [RFC1122], section 1.3.3): "the maximum transmission unit, i.e., the size of the largest packet that can be transmitted". LinkMTU: same definition as "link MTU" in [RFC2460][RFC2461], which is also the same definition as "LinkMTU" in ([RFC2461], section 6.3.2). The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Static MTU Determination Tunnel interfaces that do not participate in the dynamic MTU determination scheme MUST set LinkMTU to at least 1280 bytes, i.e., the minimum IPv6 MTU ([RFC2460], section 5). If a larger MTU is used, the value chosen SHOULD be: 1. no larger than the smallest known IPv4 Effective MTU to Receive (EMTU_R) ([RFC1122], section 3.3.2) for all potential receivers 2. no larger than the smallest known IPv4 LinkMTU in the network 3. small enough to allow room for nested link-layer encapsulations (e.g., VPN) that may be inserted by middleboxes. Tunnel interfaces that use only static MTU determination send IPv6 packets that are no larger than LinkMTU with the DF bit NOT set in the encapsulating IPv4 header. The IPv6 layer discards packets larger than LinkMTU and sends an ICMPv6 "packet too big" message to the sender, as for any IPv6 interface. Even so, black holes may still occur along some paths since IPv4 fragmentation is not universally supported by all forwarding nodes, and the minimum supported packet size for IPv4 is only 576 bytes. Templin Expires May 18, 2004 [Page 4] Internet-Draft Tunnel MTU November 2003 4. Dynamic MTU Determination Tunnel interfaces that use this scheme implement IPv6 Neighbor Discovery [RFC2461] except as otherwise noted in this document or in documents describing specific tunneling mechanisms, e.g., [RFC3056], [MECH], [ISATAP], etc. 4.1 Tunnel Interface MTU A tunnel interface that implements the dynamic scheme sets LinkMTU to a value between 1280 and 65515 bytes (i.e., the maximum IPv4 packet size minus 20 bytes for encapsulation). The value selected may be chosen relative to the MTU of the largest IPv4 link covered by the tunnel, but robust implementations will normally use the larger value. 4.2 Sending Packets Packets are sent on the tunnel interface using IPv6-in-IPv4 encapsulation as specified by the various tunneling mechanisms with the following additional specification for MTU handling: When the tunnel interface sends a packet, it determines through a routing table lookup the IPv4 interface that will send the IPv4 encapsulated packet. If the packet contains an ECN codepoint ([RFC3168], section 5) in the IPv6 header, and the IPv4 interface is congested (e.g., if it has a large queue of packets waiting to be transmitted) the packet is either marked as CE or it is silently dropped. Next, if the IPv6 packet is no larger than the IPv4 interface MTU value (minus 20 bytes) it is encapsulated in IPv4 with the DF bit set in the encapsulating header and sent over IPv4. If the packet is larger than the IPv4 interface MTU, the packet is dropped. If the packet contained an ECN codepoint, it is dropped silently; else an ICMPv6 "packet too big" message is sent back to the source. As an exception to the above, if the packet is 1280 bytes or less in length and it contains an IPv6 fragment header with Fragment Offset and M set to 0 ([RFC2460], sections 4.5 and 5), the tunnel interface encapsulates the packet in IPv4 then uses IPv4 fragmentation to split the packet into 256 byte-maximum pieces. Each of the resulting fragments will add a 20 byte IPv4 fragment header making each fragment 276 bytes. Thus, each fragment will fit within the ~200msec human perceptible delay budget for the lowest-common denominator link that may occur over the tunnel, which is 296 bytes for a 9.6kbps link ([RFC3150], section 2.3). Templin Expires May 18, 2004 [Page 5] Internet-Draft Tunnel MTU November 2003 Note that upper layers may record MTU values (e.g., in the conceptual destination cache) that are used when possible to determine packet sizes before the packet arrives at the tunnel for processing. 4.3 Processing IPv4 Errors ICMPv4 "fragmentation needed" messages MAY be translated into IPv6 "packet too big" messages and sent to the source of the original packet if the ICMPv4 message contains enough header bytes from the original IPv6 packet, as this might help the packetization layer reach convergence more quickly. 5. IANA Considerations This document contains no IANA considerations. 6. Security considerations Security issues for sending and receiving packets on tunnel interfaces are found in the various tunneling mechanism documents. Security issues related to the setting of the ECN codepoint are found in [RFC3168]. 7. Acknowledgements Most of the ideas expressed in this document are not new and borrow to a certain extent from the TCP-IP and Path MTU Discovery mailing list discussions beginning as early as 1987. Other ideas in the draft may have borrowed to some extent from discussions on the IETF MTU Discovery WG mailing list from November 1989 - February 1995, on the IETF NGTRANS WG mailing list in August 2002 and on the IETF IPv6 WG mailing list in October 2003. The author would like to acknowledge certain individuals for helpful discussion on this subject, including Jari Arkko, Iljitsch van Beijnum, Jim Bound, Ralph Droms, Alain Durand, Tim Gleeson, Jun-ichiro itojun Hagino, Brian Haberman, Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis, Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave Thaler, Michael Welzl, Lixia Zhang and the members of the Nokia NRC/COM Mountain View team. "...and I'm one step ahead of the shoe shine, Two steps away from the county line, Just trying to keep my customers satisfied, Satisfi-i-ied!" - Simon and Garfunkel Templin Expires May 18, 2004 [Page 6] Internet-Draft Tunnel MTU November 2003 Normative References [FLOWSPEC] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label (work in progress), October 2003. [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2 (work in progress), October 2003. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001. [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Informative References [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, Templin Expires May 18, 2004 [Page 7] Internet-Draft Tunnel MTU November 2003 "Intra-Site Automatic Tunnel Addressing Protocol", draft-ietf-ngtrans-isatap (work in progress), October 2003. [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. Author's Address Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 US Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminate control message overhead. o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Templin Expires May 18, 2004 [Page 8] Internet-Draft Tunnel MTU November 2003 Intellectual Property Statement 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 of the 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 implementors 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. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. 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 Templin Expires May 18, 2004 [Page 9] Internet-Draft Tunnel MTU November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin Expires May 18, 2004 [Page 10]