Network Working Group S. Vaarala Internet-Draft N. Kotivuori Expires: August 10, 2004 Netseal February 10, 2004 Fragmentation MTU Extension for Mobile IPv4 draft-vaarala-mip4-fragmtu-00 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 July 11, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies a vendor specific extension which allows a Mobile IPv4 node (MN, FA, or HA) to indicate its preferred maximum packet size for receiving encapsulated data packets. The intent is to work around problems in firewall configuration and implementation which prevent use of fragmentation and may arbitrarily limit maximum working packet size without useful error indications. The extension applies especially to UDP encapsulation where fragmentation occurs before encapsulation. Vaarala & Kotivuori Expires July 11, 2004 [Page 1] Internet-Draft Fragmentation MTU Extension January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Fragmentation MTU Extension . . . . . . . . . . . . . . . . 3 2.1 Extension format . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Determining effective-MTU for sending . . . . . . . . . . . 5 2.3 Implementation issues . . . . . . . . . . . . . . . . . . . 5 2.3.1 RRQ/RRP packets . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2 IP-IP and IP-over-UDP . . . . . . . . . . . . . . . . . . . 5 3. Security considerations . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . 8 Vaarala & Kotivuori Expires July 11, 2004 [Page 2] Internet-Draft Fragmentation MTU Extension January 2004 1. Introduction 1.1 Overview Mobile IPv4 UDP encapsulation [3] requires that Mobile IPv4 UDP encapsulated IPv4 packets must be fragmented before UDP encapsulation. This helps Mobile IPv4 to deal with some NAT devices and firewalls with limited support for fragmented packets. IP-IP encapsulation also allows fragmentation before encapsulation, although for different reasons (see [1], Section 5.1). IP-IP specification suggests path MTU discovery to determine the largest MTU for fragmentation. However, path MTU discovery relies on a number of assumptions regarding ICMP processing in the intervening routers, and is often problematic in the real world -- due to both misconfiguration and deliberate filtering of ICMP packets. Mobile IPv4 UDP encapsulation specification does not describe how to choose the MTU; path MTU discovery or manual configuration seem to be the best options. In some real world networks, it may be extremely difficult to determine the MTU that works in both directions between the communicating Mobile IPv4 nodes. This may be caused by problems in configuration or implementation of intervening devices, for instance. Unfortunately, deployment experience suggests that such problems are not as rare as one might at first imagine. Such devices are certainly configured improperly or non-compliant, and should be fixed by the vendor and the administrator. Even so, it would be useful to be able to establish Mobile IPv4 connectivity even in such adverse network conditions. This document specifies an extension to the Mobile IPv4 UDP encapsulation specification [3] and the IP-IP encapsulation specification [1]. One new skippable extension, the Fragmentation MTU Extension, is defined, containing a 16-bit fragmentation MTU preference. The preference applies to reception of data packets by the sender of the extension, i.e. the extension is unidirectional, although typically the extension is sent in both directions. 2. Fragmentation MTU Extension 2.1 Extension format The Fragmentation MTU Extension is a Normal Vendor/Organization Specific Extension (NVSE) [2]. Because the extension is skippable, it SHOULD be sent by a supporting implementation in all RRQ and RRP packets. Vaarala & Kotivuori Expires July 11, 2004 [Page 3] Internet-Draft Fragmentation MTU Extension January 2004 The format of this extension is as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor/Org-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-NVSE-Type | Fragmentation-MTU-Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type NVSE-TYPE-NUMBER 134 Length 10 Reserved Reserved for future use, MUST be set to 0 when sending and ignored when receiving Vendor/Org-ID 9213 (allocated to Netseal by IANA) Vendor-NVSE-Type 8 Fragmentation-MTU-Preference The preferred fragmentation MTU value, i.e. maximum preferred packet size after fragmentation and encapsulation for packets received by the sender of the extension. If a node has no special preference, it SHOULD send this extension with this field set to its link MTU. This value applies only to IP-IP and IP-over-UDP encapsulation and MUST be ignored for other encapsulation methods. A node MUST NOT send a value larger than its current link MTU. The extension placement depends on sender and registration mode. If a co-located care-of address is being used, i.e. the D-bit is set in the RRQ, the extension MUST be placed before the Mobile-Home Authentication Extension in both the RRQ and the RRP. The FA MUST NOT send the extension in this case, and the HA MUST ignore the extension if one has been placed after the Mobile-Home Authentication Extension. (Note that it is possible to do a co-located registration through a FA; if D-bit is set, these requirements still apply.) Vaarala & Kotivuori Expires July 11, 2004 [Page 4] Internet-Draft Fragmentation MTU Extension January 2004 If a foreign agent care-of address is being used, i.e. the D-bit is zero in the RRQ, the extension MUST be placed after the Mobile-Home Authentication Extension, but before a Foreign-Home Authentication Extension (if present), in both the RRQ and the RRP. The MN MUST NOT send the extension in this case, and the HA MUST ignore the extension if one has been placed before the Mobile-Home Authentication Extension. 2.2 Determining effective-MTU for sending If a Fragmentation MTU Extension was received, a node (MN, FA, or HA) determines its effective-MTU for sending IP-IP or IP-over-UDP data packets by first taking a minimum of (a) received Fragmentation-MTU-Preference and (b) the node's own preference for maximum MTU when sending (if any). This value is then clamped to the range [576, current link MTU], resulting in the effective-MTU. The effective-MTU is conceptually stored in the mobility binding, and is re-negotiated on each registration. Effective-MTU only applies to data packets sent by the receiver of the Fragmentation MTU Extension. The effective-MTU refers to the maximum size of an encapsulated data packet after all Mobile IPv4 processing. For instance, if IP-over-UDP is used, encapsulation overhead is typically 32 octets (20 octets for a new IP header, 8 octets for UDP header, and 4 octets for Tunnel Data header). Thus, an effective-MTU of 1000 implies that maximum fragment size of a fragmented data packet, before encapsulation, is 1000-32 = 968 octets. Had IP-IP encapsulation been used instead, the maximum fragment size before encapsulation would have been 1000-20 = 980 octets. Fragmentation-MTU-Preference is a voluntary mechanism; a node MUST accept and process encapsulated packets of arbitrary size regardless of the effective-MTU value. 2.3 Implementation issues 2.3.1 RRQ/RRP packets Mobile IPv4 RRQ/RRP packets are fragmented and reassembled normally, i.e. any fragmentation of RRQ/RRP packets is not hidden as is the case with UDP encapsulation. Similarly, maximum packet size of RRQ/ RRP packets cannot be effectively restricted. 2.3.2 IP-IP and IP-over-UDP When UDP encapsulation is not forced, the mobility binding may end up using either IP-IP or IP-over-UDP encapsulation. In both cases, Vaarala & Kotivuori Expires July 11, 2004 [Page 5] Internet-Draft Fragmentation MTU Extension January 2004 Fragmentation-MTU-Preference refers to the size of the packet being sent after all processing, and the effective-MTU is chosen independently of the encapsulation method used. As a result, the effective "payload size", i.e. the size of the fragments before encapsulation, varies depending on the encapsulation method chosen. Maximum packet size after encapsulation is effective-MTU in either case. 3. Security considerations When used between the MN and the HA, the Fragmentation MTU Extension is authenticated and thus protected from tampering. When used between the FA and the HA, authentication for extensions sent between the FA and the HA is typically not available and the extension may thus be altered by an attacker. The direct results of tampering are changing the effective-MTU of encapsulated packets. The value is clamped to a minimum of 576 octets and a maximum of link MTU octets. Small MTUs induce more overhead and more packet traffic to be generated in response to legitimate MN or HA traffic. The minimum effective MTU requirement ensures that the impact of spoofing a small MTU is limited. The maximum effective MTU requirement ensures that a node is not fooled into trying to send a larger packet into its current link that the current link can accommodate. Of course, the node should detect such a condition itself in its lower layers; however, the specified negotiation mechanism ensures that a working mobility binding is established also in this case. References [1] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [2] Dommety, G. and K. Leung, "Mobile IP Vendor/ Organization-Specific Extensions", RFC 3115, April 2001. [3] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003. Vaarala & Kotivuori Expires July 11, 2004 [Page 6] Internet-Draft Fragmentation MTU Extension January 2004 Authors' Addresses Sami Vaarala Netseal Niittykatu 6 Espoo 02600 Finland EMail: sami.vaarala@iki.fi URI: http://www.netseal.com/ Nuutti Kotivuori Netseal Niittykatu 6 Espoo 02600 Finland EMail: nuutti.kotivuori@netseal.com URI: http://www.netseal.com/ Vaarala & Kotivuori Expires July 11, 2004 [Page 7] Internet-Draft Fragmentation MTU Extension January 2004 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 (2004). 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 Vaarala & Kotivuori Expires July 11, 2004 [Page 8] Internet-Draft Fragmentation MTU Extension January 2004 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. Vaarala & Kotivuori Expires July 11, 2004 [Page 9]