idnits 2.17.1 draft-foo-v6ops-6rdmtu-03.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 (February 14, 2014) is 3722 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational February 14, 2014 5 Expires: August 18, 2014 7 6rd Tunnel MTU 8 draft-foo-v6ops-6rdmtu-03.txt 10 Abstract 12 The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE) 13 routers is currently recommended to be set to 1480. This is to avoid 14 IPv4 fragmentation within the tunnel, but requires the tunnel ingress 15 to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 16 Packet Too Big (PTB) message. Concerns for operational issues with 17 both IPv4 and IPv6 Path MTU Discovery point to the possibility of 18 MTU-related black holes when a packet is dropped due to an MTU 19 restriction somewhere in the Internet. Fortunately, the "Internet 20 cell size" is 1500 bytes (i.e., the minimum MTU configured by the 21 vast majority of links in the Internet) so if the 6rd PE router can 22 set a tunnel MTU of at least 1500 bytes the MTU issues are 23 alleviated. This document specifies methods that can be employed to 24 support these larger sizes. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 18, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. 6rd Provider Edge (PE) Router MTU Mitigations . . . . . . . . . 3 62 3. 6rd Provider Edge (CE) Router MTU Mitigations . . . . . . . . . 4 63 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE) 75 routers is currently recommended to be set to 1500 bytes minus the 76 IPv4 header encapsulation overhead minus the encapsulation overhead 77 for any additional encapsulations that may occur on the path 78 [RFC5969]. This is to avoid IPv4 fragmentation within the tunnel 79 [RFC0791], but requires the tunnel ingress to drop any IPv6 packet 80 larger than the tunnel MTU and return an ICMPv6 Packet Too Big (PTB) 81 message [RFC2460]. Concerns for operational issues with both IPv4 82 and IPv6 Path MTU Discovery [RFC1191][RFC1981] point to the 83 possibility of MTU-related black holes when a packet is dropped due 84 to an MTU restriction somewhere in the Internet. Fortunately, the 85 "Internet cell size" is 1500 bytes (i.e., the minimum MTU configured 86 by the vast majority of links in the Internet) so if the 6rd PE 87 router can set a tunnel MTU of at least 1500 bytes the MTU issues are 88 alleviated. This document specifies methods that can be employed to 89 support these larger sizes. 91 Pushing the 6rd tunnel MTU to 1500 bytes or larger is met with the 92 challenge that the addition of the IPv4 encapsulation header would 93 cause a 1500 byte IPv6 packet to appear as a 1520 byte IPv4 packet on 94 the wire. This can result in the packet being either fragmented or 95 dropped by an IPv4 router that configures a smaller link MTU, 96 depending on the setting of the "Don't Fragment" (DF) bit in the IPv4 97 header. Therefore, this document recommends complementary mechanisms 98 to ensure that packets of various sizes can be delivered as long as 99 the underlying IPv4 network can support the larger sizes. The 100 following two sections present the methods used by 6rd PE and CE 101 routers. 103 2. 6rd Provider Edge (PE) Router MTU Mitigations 105 The 6rd PE Router employs the following MTU-handling mitigations: 107 1. Set the 6rd tunnel interface MTU to the maximum of 1500 and 108 the MTU of the underlying IPv4 interface minus the expected 109 encapsulation overhead for the IPv4 header as well as any 110 other encapsulations that may occur on the path. 111 2. For each 6rd CE, maintain a RATE-LIMIT boolean variable set 112 to TRUE. 113 3. When the PE sends an IPv6 packet no larger than 1500 bytes 114 minus encapsulation overhead to a CE, encapsulate and set the 115 DF bit to 1. 116 4. When the PE sends an IPv6 packet larger than 1500 bytes to a 117 CE, encapsulate and set the DF bit to 1. Optionally cache any 118 IPv4 MTU values returned in ICMPv4 packet too big messages 119 that may result. 120 5. When the PE sends an IPv6 packet larger than 1500 bytes minus 121 the encapsulation overhead but no larger than 1500 bytes, 122 encapsulate and set the DF bit to 0. Send the packet to the CE 123 subject to rate limiting if RATE-LIMIT is TRUE. The packet may 124 be fragmented in the IPv4 network on the path to the CE. 125 6. Send a 1500 byte IPv6 probe packet to each active CE subject 126 to rate limiting using the neighbor reachability test procedure 127 specified in Section 8 of RFC5969. If the probe succeeds, set 128 RATE-LIMIT for the CE to FALSE. 130 3. 6rd Provider Edge (CE) Router MTU Mitigations 132 The 6rd CE Router employs the following MTU-handling techhniques: 134 1. Set the 6rd tunnel interface MTU to the maximum of 1280 and the 135 the MTU of the underlying IPv4 interface minus the expected 136 encapsulation overhead for the IPv4 header as well as any other 137 encapsulations that may occur on the path. 138 2. If the underlying interface has a sufficiently-large MTU, send 139 a 1500 byte IPv6 probe packet to the PE using the neighbor 140 reachability test procedure specified in Section 8 of RFC5969. 141 If the probe succeeds, set the IPv4 MTU for the PE to the MTU 142 of the underlying IPv4 interface; else, set the IPv4 MTU to 143 1520 minus the expected encapsulation overhead. 144 3. For each TCP session initiated by an IPv6 host within the CE's 145 LAN, rewrite the Maximum Segment Size (MSS) to 1500 minus the 146 TCP header length minus the IPv6 header length minus the 147 encapsulation overhead for (see: [RFC0879][RFC6691]). As a 148 result, the local IPv6 host and its remote IPv6 correspondent 149 will begin their TCP messages exchanges using IPv6 packets no 150 larger than the minimum tunnel path MTU. 151 4. When the CE sends an IPv6 packet to the PE, if the encapsulated 152 packet is larger than the IPv4 MTU for the PE drop and return 153 an ICMPv6 Packet Too Big. Else, set the DF bit to 1 and send 154 the packet. 155 5. For each neighboring CE, maintain a RATE-LIMIT boolean variable 156 set to TRUE. 157 6. When the CE sends an IPv6 packet no larger than 1500 bytes minus 158 the encapsulation overhead to a neighboring CE, encapsulate and 159 set the DF bit to 1. 160 7. When the CE sends an IPv6 packet larger than 1500 bytes to a 161 neighboring CE, encapsulate and set the DF bit to 1. Optionally 162 cache any IPv4 MTU values returned in ICMPv4 packet too big 163 messages that may result. 164 8. When the CE sends an IPv6 packet larger than 1500 bytes minus 165 the encapsulation overhead but no larger than 1500 bytes to a 166 neighboring CE, encapsulate and set the DF bit to 0. Send the 167 packet to the neighboring CE subject to rate limiting if 168 RATE-LIMIT is TRUE. 169 9. Send a 1500 byte IPv6 probe packet to each active neighboring 170 CE subject to rate limiting using the neighbor reachability 171 test procedure specified in Section 8 of RFC5969. If the probe 172 succeeds, set RATE-LIMIT for the CE to FALSE. 174 4. Discussion 176 There are several interrelated aspects to the recommended MTU 177 mitigations. First, the unconditional rewriting of the MSS by CE 178 routers ensures that the initial packets sent by IPv6 correspondents 179 will be no larger than the minimum tunnel path MTU following 180 encapsulation. The IPv6 correspondents can thereafter use 181 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] to attempt 182 to increase the MSS during the course of the TCP session and thereby 183 take advantage of larger packet sizes when available. 185 However, not all transport protocols observe the TCP MSS and so the 186 packets of other protocols generated by IPv6 hosts may be larger than 187 would fit in the minimum tunnel path MTU. Since most IPv6 hosts 188 expect to see a minimum MTU of 1500 bytes without any ancillary MTU 189 assurance mitigations, the approach specified here takes special care 190 of packets larger than the minimum tunnel path MTU but no larger than 191 1500 bytes. Namely, these packets are allowed to undergo IPv4 192 fragmentation on the path from the PE to a CE or on the path from a 193 CE to another CE. Since sustained fragmentation at high data rates 194 is dangerous however [RFC4963][RFC6864] packets in this size range 195 must only be admitted into the tunnel subject to rate limiting so 196 that reassembly misassociations do not occur. Meanwhile, packets 197 larger than 1500 bytes are admitted into the tunnel unconditionally 198 on a "best effort" basis with the understanding that these packets 199 may be dropped silently. 201 Using these methods, CE routers may need to perform a small amount of 202 IPv4 reassembly. PE routers on the other hand will never be asked to 203 perform reassembly. 205 5. IANA Considerations 207 There are no IANA considerations for this document. 209 6. Security Considerations 211 The security considerations for 6rd apply also to this document. 213 7. Acknowledgments 215 This method was inspired through many years of discussion on IETF 216 lists and other forums on the topic of tunnel MTU. 218 8. References 220 8.1. Normative References 222 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 223 September 1981. 225 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 226 (IPv6) Specification", RFC 2460, December 1998. 228 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 229 Infrastructures (6rd) -- Protocol Specification", 230 RFC 5969, August 2010. 232 8.2. Informative References 234 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 235 RFC 879, November 1983. 237 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 238 November 1990. 240 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 241 for IP version 6", RFC 1981, August 1996. 243 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 244 Discovery", RFC 4821, March 2007. 246 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 247 Errors at High Data Rates", RFC 4963, July 2007. 249 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 250 RFC 6691, July 2012. 252 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 253 RFC 6864, February 2013. 255 Author's Address 257 Fred L. Templin (editor) 258 Boeing Research & Technology 259 P.O. Box 3707 260 Seattle, WA 98124 261 USA 263 Email: fltemplin@acm.org