Network Working Group F. Templin Internet-Draft Nokia Expires: May 20, 2004 November 20, 2003 Dynamic MTU Determination for IPv6-in-IPv4 Tunnels draft-templin-tunnelmtu-04.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 20, 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 20, 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. Probing with Router Solicitation Messages . . . . . . . . . . 6 6. Mixed Static/Dynamic MTU Determination . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Templin Expires May 20, 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. 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]. This means that path MTU discovery will need to be done on a per-flow (not per- destination) basis. 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 on-demand path probing 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 may consume too much state in routers that serve many flows.) 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 attempt for the network layer to divine such information without the Templin Expires May 20, 2004 [Page 3] Internet-Draft Tunnel MTU November 2003 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, IPv4 fragments are dropped by some middleboxes, and the minimum supported packet size for IPv4 is only 576 bytes. Templin Expires May 20, 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. Additionally: 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. Robust implementations will normally use the larger value. 4.2 Sending Packets When the tunnel interface sends an IPv6 packet, it first determines through a routing table lookup the IPv4 interface that will send the IPv4-encapsulated packet. Next, the following actions are taken based on whether the IPv6 packet header contains an ECN codepoint ([RFC3168], section 5): 4.2.1 Packets with ECN Codepoints If 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. If the packet was not dropped due to congestion and is no larger than the IPv4 interface MTU value (minus 20 bytes) it is encapsulated in IPv4 with the DF bit set and sent over IPv4. Otherwise, it is silently dropped. 4.2.2 Packets without ECN Codepoints If the packet is no larger than 1280 bytes, it is encapsulated with the DF bit NOT set and sent over IPv4. Else, if the packet is no larger than the IPv4 interface MTU (minus 20 bytes) it is encapsulated with the DF bit set and sent over IPv4. Else, the packet is dropped and an ICMPv6 "packet too big" message is sent back to the source. 4.3 Maintaining State IP-layer MTU state MAY be maintained for flows that do not include ECN codepoints in constituent packets, as this MAY be necessary to avoid black holes caused by the inability to translate ICMPv4 "fragmentation needed" messages into ICMPv6 "packet too big" Templin Expires May 20, 2004 [Page 5] Internet-Draft Tunnel MTU November 2003 messages. IP layer MTU state is NOT REQUIRED for flows that include ECN codepoints in constituent packets, those flows do not require ICMP messages. End nodes with tunnel interfaces MAY record transport layer per-flow MTU values that are used by applications/transports to determine packet sizes before a packet is sent to the tunnel interface. (This does not apply to intermediate routing nodes with tunneling interfaces, since application state is kept only in the end-nodes.) 4.4 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 enough state information from the original IPv6 packet is available. IPv6 "packet too big" messages with MTU values smaller than 1280 bytes SHOULD NOT be sent to the source. 5. Probing with Router Solicitation Messages When the IPv6 next-hop is a router, applications MAY upon startup (or periodically thereafter) send IPv6 Router Solicitation messages [RFC2461] that are artificially inflated in size ([MECH], section 3.6, second-to-last paragraph) in order to probe the minimum link size on the path to the router. If the router receives such a Router Solicitation, it will send back a Router Advertisement message with the size of the Router Solicitation used for probing encoded in an MTU option. 6. Mixed Static/Dynamic MTU Determination If a completely stateless solution is desired, the static method specified in Section 3 can be used for flows that do not set an ECN codepoint in constituent packets and the dynamic method specified in Section 4 can be used for flows that set an ECN codepoint. Stateless operation is especially important for low-end routers with tunnel interfaces that need to handle many flows. 7. IANA Considerations This document contains no IANA considerations. 8. 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 Templin Expires May 20, 2004 [Page 6] Internet-Draft Tunnel MTU November 2003 in [RFC3168]. 9. 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 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 Templin Expires May 20, 2004 [Page 7] Internet-Draft Tunnel MTU November 2003 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, "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 Templin Expires May 20, 2004 [Page 8] Internet-Draft Tunnel MTU November 2003 Appendix A. Changelog Changes from -03 to -04: o Removed checks for IPv6 fragment header. Tunnel no longer emulates an IPv6/IPv4 translator. o Added Router Solicitation/Router Advertisement probing option. Changes from -02 to -03: o Removed support for IPv4 fragmentation to save state; eliminate control message overhead. Changes from -01 to -02: 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 20, 2004 [Page 9] 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 20, 2004 [Page 10] 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 20, 2004 [Page 11]