idnits 2.17.1 draft-savola-mtufrag-network-tunneling-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 626. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2005) is 6775 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1981 (ref. '8') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-04 == Outdated reference: A later version (-05) exists of draft-gont-tcpm-icmp-attacks-04 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: April 8, 2006 October 5, 2005 6 MTU and Fragmentation Issues with In-the-Network Tunneling 7 draft-savola-mtufrag-network-tunneling-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 8, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Tunneling techniques such as IP-in-IP when deployed in the middle of 41 the network, typically between routers, have certain issues regarding 42 how large packets can be handled: whether such packets would be 43 fragmented and reassembled (and how), whether Path MTU Discovery 44 would be used, or how this scenario could be operationally avoided. 45 This memo justifies why this is a common, non-trivial problem, and 46 goes on to describe the different solutions and their characteristics 47 at some length. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Description of Solutions . . . . . . . . . . . . . . . . . . . 5 54 3.1. Fragmentation and Reassembly by the Tunnel Endpoints . . . 5 55 3.2. Signalling the Lower MTU to the Sources . . . . . . . . . 6 56 3.3. Encapsulate Only When There is Free MTU . . . . . . . . . 7 57 3.4. Fragmentation of the Inner Packet . . . . . . . . . . . . 8 58 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 65 Appendix A. MTU of the Tunnel . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 A large number of ways to encapsulate datagrams in other packets, 72 i.e., tunneling mechanisms, have been specified over the years: for 73 example, IP-in-IP (e.g., [1] [2], [3]), GRE [4], L2TP [5], or IPsec 74 [6] in tunnel mode -- any of which might run on top of IPv4, IPv6, or 75 some other protocol and carrying the same or a different protocol. 77 All of these can be run so that the endpoints of the inner protocol 78 are co-located with the endpoints of the outer protocol; in a typical 79 scenario, this would correspond to "host-to-host" tunneling. It is 80 also possible to have one set of endpoints co-located, i.e., host-to- 81 router or router-to-host tunneling. Finally, many of these 82 mechanisms are also employed between the routers for all or a part of 83 the traffic that passes between them, resulting in router-to-router 84 tunneling. 86 All these protocols and scenarios have one issue in common: how does 87 the source select the maximum packet size so that the packets will 88 fit, even encapsulated, in the smallest Maximum Transfer Unit (MTU) 89 of the traversed path in the network; and if you cannot affect the 90 packet sizes, what do you do to be able to encapsulate them in any 91 case? The four main solutions are (these will be elaborated in 92 Section 3): 94 1. Fragmenting all too big encapsulated packets to fit in the paths, 95 and reassembling them at the tunnel end-points. 97 2. Signal to all the sources whose traffic must be encapsulated, and 98 is larger than that fits, to send smaller packets, e.g., using 99 Path MTU Discovery [7][8]. 101 3. Ensure that in the specific environment, the encapsulated packets 102 will fit in all the paths in the network, e.g., by using MTU 103 bigger than 1500 in the backbone used for encapsulation. 105 4. Fragmenting the original too big packets so that their fragments 106 will fit, even encapsulated, in the paths, and reassembling them 107 at the destination nodes. Note that this approach is only 108 available for IPv4 under certain assumptions (see Section 3.4). 110 It is also common to run multiple layers of encapsulation, for 111 example GRE or L2TP over IPsec; with nested tunnels in the network, 112 the tunnel endpoints can be the same or different, and both the inner 113 and outer tunnels may have different MTU handling strategies. In 114 particular, signalling may be a scalable option for the outer tunnel 115 or tunnels if the number of innermost tunnel endpoints is limited. 117 The tunneling packet size issues are relatively straightforward in 118 host-to-host tunneling or host-to-router tunneling where Path MTU 119 Discovery only needs to signal to one source node. The issues are 120 significantly more difficult in router-to-router and certain router- 121 to-host scenarios, which are the focus of this memo. 123 It is worth noting that most of this discussion applies to a more 124 generic case, where there exists a link with lower MTU in the path. 125 A concrete and widely deployed example of this is the usage of PPP 126 over Ethernet (PPPoE) [11] at the customers' access link. These 127 lower-MTU links, and particularly PPPoE links, are typically not 128 deployed in topologies where fragmentation and reassembly might be 129 unfeasible (e.g., a backbone), so this may be a slightly easier 130 problem. However, this more generic case is considered out of scope 131 of this memo. 133 There are also known challenges in specifying and implementing a 134 mechanism which would be used at the tunnel end-point to obtain the 135 best suitable packet size to use for encapsulation: if a static value 136 is chosen, a lot of fragmentation might end up being performed. On 137 the other hand, if PMTUD is used, the implementation would need to 138 update the discovered interface MTU based on the ICMP Packet Too Big 139 messages and originate ICMP Packet Too Big message(s) back to the 140 source(s) of the encapsulated packets; this also assumes that 141 sufficient data has been piggybacked on the ICMP messages (beyond the 142 required 64 bits after the IPv4 header). We'll discuss using PMTUD 143 to signal the sources briefly in Section 3.2, but in-depth 144 specification and analysis is described elsewhere (e.g., in [4] and 145 [2]) and is out of scope of this memo. 147 Section 2 includes a problem statement, section 3 describes the 148 different solutions with their drawbacks and advantages, and section 149 4 presents conclusions. 151 2. Problem Statement 153 It is worth considering why exactly this is considered a problem. 155 It is possible to fix all the packet size issues using the solution 156 1, fragmenting the resulting encapsulated packet, and reassembling it 157 by the tunnel endpoint. However, this is considered problematic for 158 at least three reasons, as described in Section 3.1. 160 Therefore it is desirable to avoid fragmentation and reassembly if 161 possible. On the other hand, the other solutions may not be 162 practical either: especially in router-to-router or router-to-host 163 tunneling, Path MTU Discovery might be very disadvantageous -- 164 consider the case where a backbone router would send ICMP Packet Too 165 Big messages to every source who would try to send packets through 166 it. Fragmenting before encapsulation is also not available in IPv6, 167 and not available when the Don't Fragment (DF) bit has been set (see 168 Section 3.4 for more). Ensuring high enough MTU so encapsulation is 169 always possible is of course a valid approach, but requires careful 170 operational planning, and may not be a feasible assumption for 171 implementors. 173 This yields that there is no trivial solution to this problem, and it 174 needs to be further explored to consider the tradeoffs, as is done in 175 this memo. 177 3. Description of Solutions 179 This section describes the potential solutions in a bit more detail. 181 3.1. Fragmentation and Reassembly by the Tunnel Endpoints 183 The seemingly simplest solution to tunneling packet size issues is 184 fragmentation of the outer packet by the encapsulator, and reassembly 185 by the decapsulator. However, this is highly problematic for at 186 least three reasons: 188 o Fragmentation causes overhead: every fragment requires the IP 189 header (20 or 40 bytes), and with IPv6, additional 8 bytes for the 190 Fragment Header. 192 o Fragmentation and reassembly require computation: splitting 193 datagrams to fragments is a non-trivial procedure, and so is their 194 reassembly. For example, software router forwarding 195 implementations may not be able to be perform these operations at 196 line rate. 198 o At the time of reassembly, all the information (i.e., all the 199 fragments) is normally not available; when the first fragment 200 arrives to be reassembled, a buffer of the maximum possible size 201 may have to be allocated because the total length of the 202 reassembled datagram is not known at that time. Further, as 203 fragments might get lost, be reordered or delayed, the reassembly 204 engine has to wait with the partial packet for some time (for 205 example, 60 seconds [9]). When this would have to be done at the 206 line rate, with e.g., 10 Gbit/s speed, the length of the buffers 207 that reassembly might require would be prohibitive. 209 When examining router-to-router tunneling, the third problem is 210 likely the worst; certainly, a hardware computation and 211 implementation requirement would also be significant, but not all 212 that difficult in the end -- and the link capacity wasted in the 213 backbones by additional overhead might not be a huge problem either. 215 However, IPv4 identification header length is only 16 bits (compared 216 to 32 bits in IPv6), and if a larger number of packets are being 217 tunneled between two IP addresses, the ID is very likely to wrap and 218 cause data misassociation. This reassembly wrongly combining data 219 from two unrelated packets causes data integrity and potentially a 220 confidentiality violation. This problem is further described in 221 [12]. 223 IPv6, and IPv4 with the DF bit set in the encapsulating header, 224 allows the tunnel endpoints to optimize the tunnel MTU and minimize 225 network-based reassembly. This also prevents fragmentation of the 226 encapsulated packets on the tunnel path. If the IPv4 encapsulating 227 header does not have DF bit set, the tunnel endpoints will have to 228 perform significant amount of fragmentation and reassembly, while the 229 use of PMTUD is minimized. 231 As Appendix A describes, the MTU of the tunnel is also a factor on 232 which packets require fragmentation and reassembly; the worst case 233 occurs if the tunnel MTU is "infinite" or equal to the physical 234 interface MTUs. 236 So, if reassembly could be made to work sufficiently reliably, this 237 would be one acceptable fallback solution but only for IPv6. 239 3.2. Signalling the Lower MTU to the Sources 241 Another approach is to use techniques like Path MTU Discovery (or 242 potentially a future derivative [13]) to signal to the sources whose 243 packets will be encapsulated in the network to send smaller packets 244 so that they can be encapsulated; in particular, when done on 245 routers, this includes two separable functions: 247 a. Forwarding behaviour: when forwarding packets, if the IPv4-only 248 DF bit is set, the router sends an ICMP Packet Too Big message to 249 the source if the MTU of the egress link is too small. 251 b. Router's "host" behaviour: when the router receives an ICMP 252 Packet too Big message related to a tunnel, it (1) adjusts the 253 tunnel MTU, and (2) originates an ICMP Packet Too Big message to 254 the source address of the encapsulated packet. (2) can be done 255 either immediately or by waiting for the next packet to trigger 256 an ICMP; the former minimizes the packet loss due to MTU changes. 258 Note that this only works if the MTU of the tunnel is of reasonable 259 size, and not e.g., 64 kilobytes: see Appendix A for more. 261 This approach would presuppose that PMTUD works. While it is 262 currently working for IPv6, and critical for its operation, there is 263 ample evidence that in IPv4, PMTUD is far from reliable due to e.g., 264 firewalls and other boxes being configured to inappropriately drop 265 all the ICMP packets [14], or software bugs rendering PMTUD 266 inoperational. 268 Further, there are two scenarios where signalling from the network 269 would be highly undesirable: when the encapsulation would be done in 270 such a prominent place in the network that a very large number of 271 sources would need to be signalled with this information (possibly 272 even multiple times, depending on how long they keep their PMTUD 273 state), or when the encapsulation is done for passive monitoring 274 purposes (network management, lawful interception, etc.) -- when it's 275 critical that the sources whose traffic is being encapsulated are not 276 aware of this happening. 278 When desiring to avoid fragmentation, IPv4 requires one of two 279 alternatives [1]: copy the DF bit from the inner packets to the 280 encapsulating header, or always set the DF bit of the outer header. 281 The latter is better especially in controlled environments, because 282 it forces PMTUD to converge immediately. 284 A related technique, which works with TCP under specific scenarios 285 only is so-called "MSS clamping". With that technique or rather a 286 "hack", the TCP packets' Maximum Segment Size (MSS) is reduced by 287 tunnel endpoints so that the TCP connection automatically restricts 288 itself to the maximum available packet size. Obviously this does not 289 work for UDP or other protocols which have no MSS. This approach is 290 most applicable and used with PPPoE, but could be applied otherwise 291 as well; the approach also assumes that all the traffic goes through 292 tunnel endpoints which do MSS clamping -- this is trivial for the 293 single-homed access links, but could be a challenge otherwise. 295 A new approach to PMTUD is in the works [13], but it is uncertain 296 whether that would fix the problems -- at least not the passive 297 monitoring requirements. 299 3.3. Encapsulate Only When There is Free MTU 301 The third approach is an operational one, depending on the 302 environment where encapsulation and decapsulation is being performed. 303 That is, if an ISP would deploy tunneling in its backbone, which 304 would consist only of links supporting high MTUs (e.g., Gigabit 305 Ethernet or SDH/SONET), but all its customers and peers would have a 306 lower MTU (e.g., 1500, or the backbone MTU minus the encapsulation 307 overhead), this would imply that no packets (with the encapsulation 308 overhead added) would have larger MTU than the "backbone MTU", and 309 all the encapsulated packets would always fit MTU-wise in the 310 backbone links. 312 This approach is highly assumptive of the deployment scenario. It 313 may be desirable to build a tunnel to/from another ISP (for example), 314 where this might no longer hold; or there might be links in the 315 network which cannot support the higher MTUs to satisfy the tunneling 316 requirements; or or the tunnel might be set up directly between the 317 customer and the ISP, in which case fragmentation would occur, with 318 tunneled fragments terminating on the ISP and thus requiring 319 reassembly capability from the ISP's equipment. 321 To restate, this approach can only be considered when tunneling is 322 done inside a part of specific kind of ISP's own network, not e.g., 323 transiting an ISP. 325 Another, related approach might be having the sources use only a low 326 enough MTU which would fit in all the physical MTUs; for example, 327 IPv6 specifies the minimum MTU of 1280 bytes. For example, if all 328 the sources whose traffic would be encapsulated would use this as the 329 maximum packet size, there would probably always be enough free MTU 330 for encapsulation in the network. However, this is not the case 331 today, and it would be completely unrealistic to assume that this 332 kind of approach could be made to work in general. 334 It is worth remembering that while the IPv6 minimum MTU is 1280 bytes 335 [10], there are scenarios where the tunnel implementation must 336 implement fragmentation and reassembly [3]: for example, when having 337 an IPv6-in-IPv6 tunnel on top of a physical interface with MTU of 338 1280 bytes, or when having two layers of IPv6 tunneling. This can 339 only be avoided by ensuring that links on top of which IPv6 is being 340 tunneled have a somewhat larger MTU (e.g., 40 bytes) than 1280 bytes. 341 This conclusion can be generalized: because IP can be tunneled on top 342 of IP, no single minimum or maximum MTU can be found such that 343 fragmentation or signalling to the sources would never be needed. 345 All in all, while in certain operational environments it might be 346 possible to avoid any problems by deployment choices, or limiting the 347 MTU that the sources use, this is probably not a sufficiently good 348 general solution for the equipment vendors, and other solutions must 349 also be provided. 351 3.4. Fragmentation of the Inner Packet 353 A final possibility is fragmenting the inner packet, before 354 encapsulation, in such a manner that the encapsulated packet fits in 355 the the tunnel's path MTU (discovered using PMTUD). However, one 356 should note that only IPv4 supports this "in-flight" fragmentation; 357 further, it isn't allowed for packets where Don't Fragment -bit has 358 been set. Even if one could ignore IPv6 completely, so many IPv4 359 host stacks send packets with DF bit set that this would seem 360 unfeasible. 362 However, there are existing implementations that violate the standard 363 that: 365 o Discard too big packets with DF bit not set instead of fragmenting 366 them (this is rare), 368 o Ignore the DF bit completely, for all or specified interfaces, or 370 o Clear the DF bit before encapsulation, in the egress of configured 371 interfaces. This is typically done for all the traffic, not just 372 too big packets (allowing configuring this is common). 374 This is non-compliant behaviour, but there are certainly uses for it 375 especially in certain tightly controlled passive monitoring 376 scenarios, and has potential for more generic applicability as well, 377 to work around PMTUD issues. 379 Clearing the DF bit effectively disables the sender's PMTUD for the 380 path beyond the tunnel. This may result in fragmentation later in 381 the network, but as the packets have already been fragmented prior to 382 encapsulation, this does fragmentation later on does not make matters 383 significantly worse. 385 As this is an implemented and desired (by some) behaviour, the full 386 impacts e.g., for the functioning of PMTUD (for example) should be 387 analyzed, and the use of fragmentation-related IPv4 bits should be 388 re-evaluated. 390 In summary, this approach provides a relatively easy fix for IPv4 391 problems, with potential for causing problems for PMTUD; as this 392 would not work with IPv6, it could not be considered a generic 393 solution. 395 4. Conclusions 397 Fragmentation and reassembly by the tunnel endpoints is a clear and 398 simple solution to the problem, but the hardware reassembly when the 399 packets get lost may face significant implementation challenges which 400 may be insurmountable. This approach does not seem feasible 401 especially for IPv4 with high data rates due to problems with 402 wrapping fragment identification field [12]. Constant wrapping may 403 occur when the data rate is in the order of MB/s for IPv4 and in the 404 order of dozens of GB/s for IPv6. However, this reassembly approach 405 is probably not a problem for passive monitoring applications. 407 PMTUD techniques, at least at the moment and especially for IPv4, 408 appear to be too unreliable or unscalable to be used in the 409 backbones. It is an open question whether a future solution might 410 work better in this aspect. 412 It is clear that in some environments the operational approach to the 413 problem, ensuring that fragmentation is never necessary by keeping 414 higher MTUs in the networks where encapsulated packets traverse, is 415 sufficient. But this is unlikely to be enough in general, and for 416 vendors which may not be able to make assumptions about the 417 operators' deployments. 419 Fragmentation of the inner packet is only possible with IPv4, and is 420 sufficient only if standards-incompliant behaviour, with potential 421 for bad side-effects e.g., for PMTUD, is adopted. It should not be 422 used if there are alternatives; fragmentation of the outer packet 423 seems a better option for passive monitoring. 425 However, if reassembly in the network must be avoided, there are 426 basically two possibilities: 428 1. For IPv6, use ICMP signalling or operational methods, and 430 2. For IPv4, packets for which DF bit is not set can be fragmented 431 before encapsulation (and the encapsulating header would have DF 432 bit set); packets whose DF bit is set would need to get the DF 433 bit cleared (though this is non-compliant). This also minimizes 434 the need for (unreliable) Internet-wide PMTUD. 436 An interesting thing to explicitly note is that when tunneling is 437 done in a high-speed backbone, typically one may be able to make 438 assumptions on the environment; however, when reassembly is not 439 performed in such a network, it might be done in software or with 440 lower requirements, and there either exists a reassembly 441 implementation, using PMTUD, or using a separate approach for passive 442 monitoring -- so this might not be a real problem. 444 In consequence, the critical questions at this point appear to be 1) 445 whether a higher MTU can be assumed in the high-speed networks that 446 deploy tunneling, and 2) whether "slower-speed" networks could cope 447 with a software-based reassembly, a less capable hardware-based 448 reassembly, or the other workarounds. An important future task would 449 be analyzing the observed incompliant behaviour about DF-bit to note 450 whether it has any unanticipated drawbacks. 452 5. IANA Considerations 454 This document makes no request of IANA. 456 Note to RFC Editor: this section may be removed on publication as an 457 RFC. 459 6. Security Considerations 461 This document describes different issues with packet sizes and in- 462 the-network tunneling; this does not have security considerations on 463 its own. 465 However, different solutions might have characteristics which may 466 make them more susceptible to attacks -- for example, a router-based 467 fragment reassembly could easily lead to (reassembly) buffer memory 468 exhaustion if the attacker would send a sufficient number of 469 fragments without sending all of them, so that the reassembly would 470 be stalled until a timeout; these and other fragment attacks (e.g., 471 [15]) have already been used against e.g., firewalls and host stacks, 472 and need to be taken into consideration in the implementations. 474 It is worth considering the cryptographic expense (which is typically 475 more significant than the reassembly, if done in software) with 476 fragmentation of the inner or outer packet. If an outer fragment 477 goes missing, no cryptographic operations have been yet performed; if 478 an inner fragment goes missing, cryptographic operations have already 479 been performed. Therefore, which of these approaches is preferable 480 also depends on whether cryptography or reassembly are already 481 provided in hardware; for high-speed routers, at least, one should be 482 able to assume that if it is performing relatively heavy 483 cryptography, hardware support is already required. 485 The solutions using PMTUD (and consequently ICMP) will also need to 486 take into account the attacks using ICMP. In particular, an attacker 487 could send ICMP Packet Too Big messages indicating a very low MTU to 488 reduce the throughput and/or as a fragmentation/reassembly denial-of- 489 service attack. This attack has been described in the context of TCP 490 in [16]. 492 7. Acknowledgements 494 While the topic is far from new, recent discussions with W. Mark 495 Townsley on L2TP fragmentation issues caused the author to sit down 496 and write up the issues in more general. Michael Richardson and Mika 497 Joutsenvirta provided useful feedback on the first draft. When 498 soliciting comments from NANOG list, Carsten Bormann, Kevin Miller, 499 Warren Kumari, Iljitsch van Beijnum, Alok Dube, and Stephen J. Wilcox 500 provided useful feedback. Later, Carlos Pignataro provided excellent 501 input, helping in improving the document. Joe Touch also provided 502 input on the memo. 504 8. References 506 8.1. Normative References 508 [1] Perkins, C., "IP Encapsulation within IP", RFC 2003, 509 October 1996. 511 [2] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 512 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in 513 progress), March 2005. 515 [3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 516 Specification", RFC 2473, December 1998. 518 [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 519 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 521 [5] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 522 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 524 [6] Kent, S. and K. Seo, "Security Architecture for the Internet 525 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 526 April 2005. 528 [7] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 529 November 1990. 531 [8] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 532 IP version 6", RFC 1981, August 1996. 534 [9] Braden, R., "Requirements for Internet Hosts - Communication 535 Layers", STD 3, RFC 1122, October 1989. 537 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 538 Specification", RFC 2460, December 1998. 540 8.2. Informative References 542 [11] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and 543 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 544 (PPPoE)", RFC 2516, February 1999. 546 [12] Mathis, M., "Fragmentation Considered Very Harmful", 547 draft-mathis-frag-harmful-00 (work in progress), July 2004. 549 [13] Mathis, M., "Path MTU Discovery", draft-ietf-pmtud-method-04 550 (work in progress), February 2005. 552 [14] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution 553 of Transport Protocols in the Internet", Computer 554 Communications Review, Apr 2005, . 556 [15] Miller, I., "Protection Against a Variant of the Tiny Fragment 557 Attack (RFC 1858)", RFC 3128, June 2001. 559 [16] Gont, F., "ICMP attacks against TCP", 560 draft-gont-tcpm-icmp-attacks-04 (work in progress), 561 September 2005. 563 Appendix A. MTU of the Tunnel 565 Different tunneling mechanisms may treat the tunnel links as having 566 different kind of MTU values. Some might use the same default MTU as 567 for other interfaces; some others might use the default MTU minus the 568 expected IP overhead (e.g., 20, 28, or 40 bytes); some others might 569 even treat the tunnel as having "infinite MTU", e.g., 64 kilobytes. 571 As [2] describes, having an infinite MTU, i.e., always fragmenting 572 the outer packet (and never the inner packet) and never performing 573 PMTUD for the tunnel path is a very bad idea, especially in host-to- 574 router scenarios. (It could be argued that if the nodes are sure 575 that this is a host-to-host tunnel, a larger MTU might make sense if 576 fragmentation and reassembly is more efficient than just sending 577 properly sized packets -- but this seems like a stretch.) 579 Author's Address 581 Pekka Savola 582 CSC/FUNET 583 Espoo 584 Finland 586 Email: psavola@funet.fi 588 Full Copyright Statement 590 Copyright (C) The Internet Society (2005). 592 This document is subject to the rights, licenses and restrictions 593 contained in BCP 78, and except as set forth therein, the authors 594 retain all their rights. 596 This document and the information contained herein are provided on an 597 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 598 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 599 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 600 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 601 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 602 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 604 Intellectual Property 606 The IETF takes no position regarding the validity or scope of any 607 Intellectual Property Rights or other rights that might be claimed to 608 pertain to the implementation or use of the technology described in 609 this document or the extent to which any license under such rights 610 might or might not be available; nor does it represent that it has 611 made any independent effort to identify any such rights. Information 612 on the procedures with respect to rights in RFC documents can be 613 found in BCP 78 and BCP 79. 615 Copies of IPR disclosures made to the IETF Secretariat and any 616 assurances of licenses to be made available, or the result of an 617 attempt made to obtain a general license or permission for the use of 618 such proprietary rights by implementers or users of this 619 specification can be obtained from the IETF on-line IPR repository at 620 http://www.ietf.org/ipr. 622 The IETF invites any interested party to bring to its attention any 623 copyrights, patents or patent applications, or other proprietary 624 rights that may cover technology that may be required to implement 625 this standard. Please address the information to the IETF at 626 ietf-ipr@ietf.org. 628 Acknowledgment 630 Funding for the RFC Editor function is currently provided by the 631 Internet Society.