idnits 2.17.1 draft-generic-v6ops-tunmtu-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2013) is 4040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-taylor-v6ops-fragdrop-00 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-52 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational March 28, 2013 5 Expires: September 29, 2013 7 Operational Considerations for Tunnel Fragmentation and Reassembly 8 draft-generic-v6ops-tunmtu-13.txt 10 Abstract 12 The Maximum Transmission Unit (MTU) for popular IP-in-IP tunnels is 13 currently recommended to be set to 1500 (or less) minus the length of 14 the encapsulation headers when static MTU determination is used. 15 This requires the tunnel ingress to either fragment any IP packet 16 larger than the MTU or drop the packet and return an ICMP Packet Too 17 Big (PTB) message. Concerns for operational issues with Path MTU 18 Discovery (PMTUD) point to the possibility of MTU-related black holes 19 when a packet is dropped due to an MTU restriction. The current 20 "Internet cell size" is effectively 1500 bytes (i.e., the minimum MTU 21 configured by the vast majority of links in the Internet) and should 22 therefore also be the minimum MTU assigned to tunnels, but this has 23 proven to be problematic in common operational practice. This 24 document therefore discusses operational considerations for tunnel 25 fragmentation and reassembly necessary to accommodate this Internet 26 cell size. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Tunnel Fragmentation and Reassembly . . . . . . . . . . . . . 3 64 3. Jumbo Packet Accommodation . . . . . . . . . . . . . . . . . 5 65 4. Common Tunneling Mechanisms . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Maximum Transmission Unit (MTU) for popular IP-in-IP tunnels is 77 currently recommended to be set to 1500 (or less) minus the length of 78 the encapsulation headers when static MTU determination is used. 79 This requires the tunnel ingress to either fragment any IP packet 80 larger than the MTU or drop the packet and return an ICMP Packet Too 81 Big (PTB) message [RFC0791][RFC2460]. Concerns for operational 82 issues with Path MTU Discovery (PMTUD) [RFC1191][RFC1981] point to 83 the possibility of MTU-related black holes when a packet is dropped 84 due to an MTU restriction. The current "Internet cell size" is 85 effectively 1500 bytes (i.e., the minimum MTU configured by the vast 86 majority of links in the Internet) and should therefore also be the 87 minimum MTU assigned to tunnels, but this has proven to be 88 problematic in common operational practice. 90 [RFC4459] discusses "MTU and Fragmentation Issues with In-the-Network 91 Tunneling" and provides a comprehensive study of the various 92 techniques that could be applied to alleviate the issues, including: 94 1. Fragmenting all too big encapsulated packets to fit in the paths, 95 and reassembling them at the tunnel endpoints. 97 2. Signal to all the sources whose traffic must be encapsulated, and 98 is larger than fits, to send smaller packets, e.g., using PMTUD. 100 3. Ensure that in the specific environment, the encapsulated packets 101 will fit in all the paths in the network, e.g., by using MTU 102 bigger than 1500 in the backbone used for encapsulation. 104 4. Fragmenting the original too big packets so that their fragments 105 will fit, even encapsulated, in the paths, and reassembling them 106 at the destination nodes. Note that this approach is only 107 available for IPv4 under certain assumptions. 109 After considerable effort by many individuals since the publication 110 of [RFC4459], these four alternatives continue to cover the domain of 111 potential solutions - all of which have drawbacks and/or 112 impracticalities. In this document, we discuss further 113 considerations within the framework of the only solution alternative 114 that can be applied generically - namely, fragmentation and 115 reassembly at the tunnel endpoints. 117 2. Tunnel Fragmentation and Reassembly 119 Pushing the tunnel MTU to 1500 bytes or beyond is met with the 120 challenge that the addition of encapsulation headers would cause an 121 inner IP packet that is 1500 bytes (or slightly smaller) to appear as 122 a slightly larger than 1500 byte outer IP packet on the wire, where 123 it may be too large to traverse the path in one piece. When an IP 124 tunnel configures an MTU smaller than 1500 bytes, packets that are 125 small enough to traverse earlier links in the path toward the final 126 destination may be dropped at the tunnel ingress which then returns a 127 PTB message to the original source. However, operational experience 128 has shown that the PTB messages can be lost in the network [RFC2923], 129 in which case the source does not receive notification of the loss. 131 It is therefore highly desirable that the tunnel configure an MTU of 132 at least 1500 bytes even though encapsulation would cause some 133 tunneled packets to be slightly larger than 1500 bytes. In that 134 case, the tunnel ingress would need to make special adaptations to 135 deliver packets that are no larger than 1500 bytes yet larger than 136 can be accommodated in a single piece. 138 One possibility is to use IP fragmentation of the inner IP layer 139 protocol before encapsulation so that inner packet fragments can be 140 delivered via the tunnel without loss due to a size restriction and 141 then reassembled at the final destination. This option removes the 142 burden from the tunnel endpoints, but is only available for IPv4 143 packets (since IPv6 deprecates router fragmentation [RFC2460]), and 144 is further only available when the IPv4 header sets the Don't 145 Fragment (DF) bit in the IPv4 header to 0. 147 A second possibility is to use IP fragmentation of the outer IP layer 148 protocol following encapsulation so that the outer packet fragments 149 can be delivered via the tunnel without loss due to a size 150 restriction and then reassembled at the tunnel egress. This option 151 is available for tunnels over both IPv4 and IPv6, and indeed the 152 tunnel ingress is permitted to use IPv6 fragmentation since it is 153 acting as a "host" (i.e., and not a router) for the encapsulated 154 packets it produces. While IPv6 fragmentation is assumed to be "safe 155 at all speeds", IPv4 fragmentation can be dangerous at high data 156 rates due to the possibility of Identification field wrapping while 157 reassemblies are still active [RFC4963][RFC6864]. Also, if outer IP 158 fragmentation were used the tunnel ingress has no assurance that the 159 egress can reassemble packets larger than 1500 bytes, since the 160 Minimum Reassembly Unit (MRU) is 1500 bytes for IPv6 [RFC2460] and 161 only 576 bytes for IPv4 [RFC1122]. Finally, recent studies have 162 shown that IPv6 fragments are sometimes dropped in the network due to 163 middlebox misconfigurations [I-D.taylor-v6ops-fragdrop]. 165 A third possibility for accommodating inner packets that are slightly 166 too large is the use of "tunnel fragmentation" based on a mid-layer 167 encapsulation that is inserted between the inner and outer IP 168 headers. Tunnel fragmentation requires separate packet 169 Identification and segmentation control bits in the mid-layer 170 encapsulation that are distinct from those that appear in the inner 171 and/or outer headers. As for outer fragmentation, the tunnel egress 172 is responsible for reassembly. Tunnel fragmentation can be 173 particularly useful for tunnels over IPv4, since the mid-layer 174 encapsulation can include an extended Identification field that 175 avoids the identification wrapping issue discussed above. However, 176 tunnel fragmentation is not used in common widely-deployed tunneling 177 mechanisms at the time of this writing. An example of tunnel 178 fragmentation appears in SEAL [I-D.templin-intarea-seal]. 180 Following any inner, tunnel or outer fragmentation, the ingress must 181 allow the encapsulated packets or fragments to be further fragmented 182 by a router on the path that configures a link with a too-small MTU. 183 These fragments would be reassembled by the tunnel egress the same as 184 if the fragmentation occurred within the tunnel ingress. This final 185 form of fragmentation is undesirable and should be avoided if at all 186 possible through the application of fragmentation at the tunnel 187 ingress. However, common widely-deployed tunneling mechanisms at the 188 time of this writing make no such provisions. 190 3. Jumbo Packet Accommodation 192 In addition to failure to accommodate packets up to 1500 bytes in 193 length, current tunneling solutions typically do not make provisions 194 for delivering packets that are larger than 1500 bytes. As long as 195 they are no larger than the underlying link used for tunneling, the 196 tunnel ingress should admit such "jumbo" packets into the tunnel and 197 allow them to either be delivered to the egress in one piece or be 198 dropped with the possibility of a PTB message being returned. The 199 original host will then be able to determine the correct packet sizes 200 whether or not PTB messages are delivered if it is using [RFC4821]. 201 However, this approach is not used in common widely-deployed 202 tunneling mechanisms at the time of this writing. 204 4. Common Tunneling Mechanisms 206 The operational issues discussed in this document apply to existing 207 IPv6-in-IPv4 transition mechanisms, including configured tunnels 208 [RFC4213], 6to4 [RFC3056], Teredo [RFC4380], ISATAP [RFC5214], DSMIP 209 [RFC5555], 6rd [RFC5969], etc. 211 The issues further apply to existing IP-in-IP tunneling mechanisms of 212 all varieties, including GRE [RFC1701], IPv4-in-IPv4 [RFC2003], IPv6 213 -in-IPv6 [RFC2473], IPv4-in-IPv6 [RFC6333], IPsec [RFC4301], etc. 215 5. IANA Considerations 217 There are no IANA considerations for this document. 219 6. Security Considerations 221 The security considerations for the various tunneling mechanisms 222 apply also to this document. 224 7. Acknowledgments 226 This method was inspired through discussion on the IETF v6ops and 227 NANOG mailing lists in the May/June 2012 timeframe. 229 8. References 231 8.1. Normative References 233 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 234 1981. 236 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 237 6 (IPv6) Specification", RFC 2460, December 1998. 239 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 240 Network Tunneling", RFC 4459, April 2006. 242 8.2. Informative References 244 [I-D.taylor-v6ops-fragdrop] 245 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 246 M., and T. Taylor, "Why Operators Filter Fragments and 247 What It Implies", draft-taylor-v6ops-fragdrop-00 (work in 248 progress), October 2012. 250 [I-D.templin-intarea-seal] 251 Templin, F., "The Subnetwork Encapsulation and Adaptation 252 Layer (SEAL)", draft-templin-intarea-seal-52 (work in 253 progress), March 2013. 255 [RFC1122] Braden, R., "Requirements for Internet Hosts - 256 Communication Layers", STD 3, RFC 1122, October 1989. 258 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 259 November 1990. 261 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 262 Routing Encapsulation (GRE)", RFC 1701, October 1994. 264 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 265 for IP version 6", RFC 1981, August 1996. 267 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 268 October 1996. 270 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 271 IPv6 Specification", RFC 2473, December 1998. 273 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 274 2923, September 2000. 276 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 277 via IPv4 Clouds", RFC 3056, February 2001. 279 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 280 for IPv6 Hosts and Routers", RFC 4213, October 2005. 282 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 283 Internet Protocol", RFC 4301, December 2005. 285 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 286 Network Address Translations (NATs)", RFC 4380, February 287 2006. 289 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 290 Discovery", RFC 4821, March 2007. 292 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 293 Errors at High Data Rates", RFC 4963, July 2007. 295 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 296 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 297 March 2008. 299 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 300 Routers", RFC 5555, June 2009. 302 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 303 Infrastructures (6rd) -- Protocol Specification", RFC 304 5969, August 2010. 306 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 307 Stack Lite Broadband Deployments Following IPv4 308 Exhaustion", RFC 6333, August 2011. 310 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 311 RFC 6864, February 2013. 313 Author's Address 315 Fred L. Templin (editor) 316 Boeing Research & Technology 317 P.O. Box 3707 318 Seattle, WA 98124 319 USA 321 Email: fltemplin@acm.org