idnits 2.17.1 draft-templin-inetmtu-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 684. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 3, 2007) is 6051 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 501 == Missing Reference: 'N' is mentioned on line 501, but not defined ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1146 (Obsoleted by RFC 6247) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 Phantom Works 4 Intended status: Informational October 3, 2007 5 Expires: April 5, 2008 7 Simple Packetization and Reassembly for IP/*/IP Tunnel Endpoint MTUs 8 (sprite-mtu) 9 draft-templin-inetmtu-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 5, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The nominal Maximum Transmission Unit (MTU) of the Internet has 43 become 1500 bytes, but existing IP/*/IP tunneling mechanisms impose 44 an encapsulation overhead that can reduce the effective path MTU to 45 smaller values. Additionally, existing tunneling mechanisms are 46 limited in their ability to support larger MTUs. This document 47 specifies simple packetization and reassembly for IP/*/IP tunnel 48 endpoint MTUs (sprite-mtu). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and Requirements . . . . . . . . . . . . . . . . . 3 54 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 4 55 4. End-to-End MTU Determination . . . . . . . . . . . . . . . . . 4 56 5. Tunnel Interface MTU . . . . . . . . . . . . . . . . . . . . . 4 57 6. Tunnel Soft State . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Conceptual Sending Algorithm . . . . . . . . . . . . . . . 5 60 7.2. Inner Packet Fragmentation . . . . . . . . . . . . . . . . 6 61 7.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 62 7.4. Outer Packet Fragmentation . . . . . . . . . . . . . . . . 8 63 7.5. Sending Packets . . . . . . . . . . . . . . . . . . . . . 9 64 7.6. Tunnel Recursion . . . . . . . . . . . . . . . . . . . . . 9 65 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. IPv4 Reassembly Cache Management . . . . . . . . . . . . . 9 67 8.2. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 9 68 8.3. Receiving Packet Too Big (PTB) Errors . . . . . . . . . . 10 69 9. 'minMTU' Determination . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Sending Sprites . . . . . . . . . . . . . . . . . . . . . 10 71 9.2. Receiving (Sprite-)Replys . . . . . . . . . . . . . . . . 11 72 9.3. Receiving Sprites . . . . . . . . . . . . . . . . . . . . 11 73 9.4. Sending Sprite-Replys . . . . . . . . . . . . . . . . . . 11 74 10. 8-bit Fletcher Checksum Calculation . . . . . . . . . . . . . 11 75 11. Updated Specifications . . . . . . . . . . . . . . . . . . . . 12 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 15.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . . . 16 85 1. Introduction 87 The nominal Maximum Transmission Unit (MTU) of today's Internet has 88 become 1500 bytes due to the preponderance of networking gear that 89 configures an MTU of that size. Since not all links in the Internet 90 configure a 1500 byte MTU, however, packets can be dropped due to an 91 MTU restriction on the path. 93 Upper layers see IP/*/IP tunnels as ordinary links, but even for 94 packets no larger than 1500 bytes these links are susceptible to 95 silent loss (e.g., due to path MTU restrictions, lost error messages, 96 layered encapsulations, reassembly buffer limitations, etc.) 97 resulting in poor performance and/or communications failures 98 [RFC2923][RFC4459][RFC4821][RFC4963]. 100 This document specifies simple packetization and reassembly for 101 IP/*/IP tunnel endpoint MTUs (sprite-mtu). It updates the functional 102 specifications for Tunnel Endpoints (TEs) found in existing tunneling 103 mechanisms (see: Section 11). 105 The mechanisms in this document seek to achieve an appropriate 106 balance between function in the network and function in the end 107 systems, per [RFC1958], Section 2.3. 109 2. Terminology and Requirements 111 The following abbreviations and terms are used in this document: 113 IPv4 - Internet Protocol, Version 4 [RFC0791] 115 IPv6 - Internet Protocol, Version 6 [RFC2460] 117 IP - Internet Protocol, either Version 4 or Version 6 119 DF - the IPv4 header "Don't Fragment" flag 121 ENCAPS - the size of the encapsulating */IP headers plus trailers 123 minMTU - minimum MTU of the tunnel, in bytes 125 MTU - Maximum Transmission Unit 127 PTB - Packet Too Big error (either ICMPv4 [RFC1191] or ICMPv6 128 [RFC1981]) 130 sprite/sprite-reply - a request/reply used for minMTU probing 131 TE - Tunnel Endpoint 133 TFE - Tunnel Far End 135 TNE - Tunnel Near End 137 IP/*/IP - an inner IP packet encapsulated in outer */IP headers 138 (e.g. for "*" = NULL, UDP, TCP, AH, ESP, etc.) 140 inner packet/header/payload - an IP packet/header/payload before 141 */IP encapsulation. 143 outer packet/header/payload - a */IP packet/header/payload after 144 encapsulation. 146 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 147 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 148 document, are to be interpreted as described in [RFC2119]. 150 3. Concept of Operation 152 TEs that implement this scheme engage in a continuous probing process 153 by exchanging "sprites" and "sprite-replys" with the TFE while data 154 is flowing to determine and maintain a minimum MTU for the tunnel. 155 When the flow of data through the tunnel is suspended, the probing 156 process is discontinued. Under normal conditions, only the TNE need 157 implement this scheme, therefore deployment can occur independently 158 of deployment on the TFE. Under extreme conditions, performance is 159 enhanced when both TEs implement the scheme. 161 4. End-to-End MTU Determination 163 This specification assumes that original sources that send 164 unfragmentable packets larger than 1500 bytes will use end-to-end MTU 165 determination per [RFC4821]. 167 5. Tunnel Interface MTU 169 TEs should configure an MTU on the tunnel interface that is at least 170 as large as (linkMTU - ENCAPS) for the largest linkMTU for all 171 interfaces over which the tunnel is configured. 173 6. Tunnel Soft State 175 TEs maintain the following per-TFE conceptual variables as soft 176 state: 178 minMTU 179 the current minimum MTU for the tunnel, discovered through probing 180 to determine the largest size outer packet/fragment that can 181 traverse the tunnel. (See: [RFC3819], Section 2 for subnetwork 182 MTU recommendations that influence 'minMTU'.) 184 Initial and minimum value: 128 bytes for */IPv4 tunnels; 1280 185 bytes for */IPv6 tunnels. 187 isExtreme 188 boolean indicating whether the tunnel traverses a path with an 189 extremely small MTU. 191 Initial value: TRUE. 193 isQualified 194 boolean indicating whether the TFE implements the scheme. 196 Initial value: FALSE. 198 7. Sending Packets 200 TEs that implement this scheme use the specifications for sending 201 packets found in the following sections: 203 7.1. Conceptual Sending Algorithm 205 Packets that are larger than the tunnel interface MTU are dropped 206 with a packet too big (PTB) sent back to the original source as for 207 any IP interface. For other packets, TEs use the conceptual sending 208 algorithm found in Figure 1: 210 if inner packet is larger than ('minMTU' - ENCAPS) and 211 inner packet is not a sprite (see: Section 9.1) 212 if inner packet is not fragmentable (see: Section 7.2) 213 if inner packet is larger than 1500 bytes 214 if inner packet is larger than the underlying 215 linkMTU minus ENCAPS 216 Send PTB appropriate to the inner protocol 217 with MTU = (MAX('minMTU', linkMTU) - ENCAPS). 218 Drop packet and return. 219 else 220 Encapsulate as an outer packet (see: Sect. 7.3). 221 Send packet and return (see: Section 7.5). 222 endif 223 else 224 Send PTB appropriate to the inner protocol with 225 MTU = ('minMTU' - ENCAPS). 226 Drop packet and return. 227 endif 228 else 229 Fragment inner packet into fragments no larger than 230 ('minMTU' - ENCAPS) (see: Section 7.2). 231 endif 232 endif 233 foreach inner packet/fragment 234 Encapsulate as an outer packet (see: Section 7.3). 235 Fragment outer packet if necessary (see: Section 7.4). 236 Send packet(s)/fragment(s) (see: Section 7.5). 237 endforeach 239 Figure 1: Conceptual Sending Algorithm 241 7.2. Inner Packet Fragmentation 243 An inner packet is "fragmentable" IFF the TE is permitted to break it 244 into inner fragments before encapsulation, e.g., an IPv4 packet with 245 DF=0, an unfragmented IPv6 packet no larger than 1280 bytes with a 246 fragment header, etc. Per the conceptual sending algorithm, the TE 247 uses the IP fragmentation mechanism of the inner protocol to fragment 248 inner packets into fragments no larger than ('minMTU' - ENCAPS). 250 Note that for IPv6/*/IPv4 tunnels, ('minMTU' - ENCAPS) may not be 251 large enough to accommodate the minimum IPv6 MTU such that the TE may 252 be required to drop an unfragmentable inner IPv6 packet of 1280 bytes 253 or smaller and return an ICMPv6 PTB with an MTU value less than 1280 254 bytes. The original IPv6 source will then set the path MTU to 1280 255 bytes and include a fragment header in subsequent IPv6 packets. The 256 TE can then perform IPv6 fragmentation using the fragment header 257 included by the source per [RFC2460], Section 5. 259 7.3. Encapsulation 261 TEs encapsulate inner IP packets according to the specific IP/*/IP 262 document. During encapsulation the TE also appends a trailer (if 263 necessary) that includes zero or more zero-padding bytes and a 4-byte 264 trailing "footer" immediately following the inner IP packet. The TE 265 increments the innermost '*' header length field by the number of 266 trailer bytes added, for example it increments the UDP length field 267 for IPv6/UDP/IPv4 tunnels, the IPv4 length field for IPv6/IPv4 268 tunnels, the outer IPv6 length field for IPv6/IPv6 tunnels, etc. The 269 encapsulation is shown in Figure 2: 271 +---------------------------------+ 272 | Outer IP Header | 273 | | 274 +---------------------------------+ 275 | * Headers | 276 | | 277 +-------------+ +---------------------------------+ 278 | Inner IP | | Inner IP | 279 ~ packet ~ ===> ~ packet ~ 280 | | | | 281 +-------------+ +---------------------------------+ -\ T 282 Inner Packet | | | r 283 ~ Zero-Padding (0 or more bytes) ~ | a 284 | | > i 285 +---------------------------------+ | l 286 | Footer (4 bytes) | | e 287 +---------------------------------+ -/ r 288 | Any */IP protocol trailers ... 289 +------------------------------ 290 Outer Packet 292 Figure 2: Encapsulation Format with Trailer 294 For all packets that include a trailer, the footer is encoded as the 295 final 4 bytes and is byte-aligned only, i.e., it need not be aligned 296 on an even word/longword/etc. boundary. The footer format is shown 297 in Figure 3: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |Version| Type | Reserved | Fletcher A | Fletcher B | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Footer Format 307 Version (4 bits) 308 The Version field indicates the format of the trailer. This 309 document describes version 4. 311 Type (4 bits) 312 The type of encapsulated packet. The following types are defined: 314 0 - ordinary data packet. 316 1 - sprite 318 2 - sprite-reply 320 3 - 15 - Reserved for future use. 322 Reserved (8 bits) 323 Reserved for future use. 325 Fletcher A (8 bits) 326 The 8-bit Fletcher A checksum component. 328 Fletcher B (8 bits) 329 The 8-bit Fletcher B checksum component. 331 During encapsulation, the TE MUST include a trailer with a non-zero 332 checksum in all sprite and sprite-reply packets, as well as in all 333 IPv4 data packets that are sent as 2 fragments. For other data 334 packets, the TE MAY: 1) include a trailer with a non-zero checksum, 335 2) include a trailer with a zero checksum, or 3) omit the trailer. 337 For all packets that will include a trailer with a non-zero checksum, 338 the TE first appends zero-filled padding bytes as necessary to extend 339 the packet to a minimum length of 64 bytes beyond the beginning of 340 the inner IP header (not counting the 4 byte footer). The TE then 341 calculates the 8-bit Fletcher checksum as specified in Section 10 and 342 encodes the results in the Fletcher A and B fields of the footer. 343 The TE finally sets Version=4 and Type=0, 1, or 2 according to the 344 type of packet being encapsulated (i.e., for ordinary data, sprite or 345 sprite-reply packets, respectively). 347 7.4. Outer Packet Fragmentation 349 For IP/*/IPv4 tunnels, when 'isExtreme' is TRUE and the encapsulated 350 packet is not a sprite, the TE fragments the packet into 2 outer IPv4 351 fragments of 64 bytes or smaller using IPv4 fragmentation. In this 352 case alone, the TE fragments an inner IP packet for which 353 fragmentation is not explicitly permitted. 355 7.5. Sending Packets 357 For IP/*/IPv4 tunnels, the TE sets DF=1 in the outer IPv4 header of 358 all packets. When 'isExtreme' is TRUE and 'isQualified' is FALSE, 359 the TE must maintain a window that limits the number of data packets 360 admitted into the tunnel to avoid IPv4 reassembly misassociations 361 according to the reassembly timeout recommendations in [RFC1122], 362 Section 3.3.2. The TE is permitted to relax this windowing 363 limitation after either 'isExtreme' is set to FALSE or 'isQualified' 364 is set to TRUE. 366 For IP/*/IPv6 tunnels, there is no requirement for the TE to 367 institute windowing limitations since the IPv6 fragment header 368 includes a 32bit Identification field. 370 7.6. Tunnel Recursion 372 For IP/*/IPv4 tunnels, even when 'isExtreme' is TRUE, recursively- 373 nested encapsulations within IPv4 can extend indefinitely due to the 374 minimal outer fragmentation and reassembly used under extreme 375 conditions. 377 For IP/*/IPv4 tunnels, recursively-nested encapsulations within IPv6 378 impose a minimum of 40 bytes of header per encapsulation with no 379 outer fragmentation possible such that the headers can overflow the 380 available packet space with no room left for data after even a small 381 number of nested encapsulations. 383 8. Receiving Packets 385 TEs that implement this scheme use the specifications for receiving 386 packets found in the following sections: 388 8.1. IPv4 Reassembly Cache Management 390 TEs SHOULD perform active management in their IPv4 reassembly cache, 391 i.e., they should actively discard "stale" reassemblies that have no 392 apparent opportunity for successful completion prior to the normal 393 reassembly timeout expiration recommended in [RFC1122], Section 394 3.3.2. 396 8.2. Decapsulation 398 When the TE receives (and, if necessary, reassembles) an encapsulated 399 packet from a TFE for which 'isQualified' is TRUE, and the packet 400 includes a trailing footer per Section 7.3 with an incorrect trailing 401 checksum, the TE drops the packet. Otherwise, the TE decapsulates 402 the packet exactly as specified in the appropriate IP/*/IP document. 403 Note that the decapsulation automatically erases the trailer. 405 8.3. Receiving Packet Too Big (PTB) Errors 407 TEs may receive PTB errors in response to any packets that were 408 admitted into the tunnel. When the TE receives a PTB with an MTU 409 value smaller than 'minMTU', it SHOULD reduce 'minMTU' and send 410 sprites to determine a new 'minMTU'. It SHOULD also send a 411 translated PTB back to the inner source if possible. Further 412 strategies for handling PTB errors are specified in [RFC4821], 413 Section 7. 415 9. 'minMTU' Determination 417 TEs probe the path to determine a 'minMTU' for the tunnel by sending 418 sprites and sprite-replys as specified in the following sections: 420 9.1. Sending Sprites 422 TEs engage in a probing process while data is actively flowing 423 through the tunnel to determine 'minMTU' by sending sprites to the 424 TFE. TEs generate sprites by creating a minimum-sized echo request 425 packet according to the inner IP protocol (e.g., an ICMPv6 [RFC4443] 426 echo request) that includes identifying information such as sequence/ 427 identification numbers, nonce values, sprite sizes, etc. that will be 428 echoed in the reply. The TE then encapsulates the echo request with 429 padding added to create a sprite of the desired size per Section 7.3 430 then sends the sprite into the tunnel. 432 The TE SHOULD send a series of sprites of various sizes early in the 433 tunnel lifetime to determine the largest possible 'minMTU' that is no 434 smaller than (128 bytes for IPv4; 1280 bytes for IPv6) and up to 435 (1500 + ENCAPS). The TE SHOULD NOT increase 'minMTU' to larger 436 values, since this may interfere with end-to-end path MTU discovery. 437 When the TE receives sufficient evidence through probing that the 438 forward path supports a larger sprite size, it advances 'minMTU'. 440 The SHOULD limit the rate at which it sends sprites, but SHOULD send 441 them frequently enough to refresh 'minMTU'. The TE SHOULD set 442 'isExtreme' to TRUE and reduce 'minMTU' to the minimum value when 443 minimum-sized sprites fail to produce replys. Additional probing 444 considerations are specified in [RFC4821], Section 7. 446 The TE SHOULD retain a cache of recently-sent sprites and use them to 447 verify any resulting replys. The TE MAY discontinue the probing 448 process and garbage-collect stale soft state for dormant tunnels. 450 9.2. Receiving (Sprite-)Replys 452 When a TE receives an encapsulated echo reply, it first determines 453 whether the reply matches one of its sprites by examining any 454 identifying information in the inner packet. If the echo reply 455 matches one of the TE's sprites, the TE sets 'isExtreme' to FALSE and 456 uses the sprite size for 'minMTU' determination. Otherwise, the TE 457 decapsulates the echo reply and passes it to upper layers as for 458 ordinary data. 460 For echo replys that match one of the TE's sprites, the TE next 461 verifies whether the reply was also encapsulated as a sprite-reply 462 with a correct checksum per Section 7.3. For sprite-replys with a 463 correct checksum, the TE sets: 'isQualified' to TRUE for this TFE; 464 for other replys, it sets: 'isQualified' to FALSE. The TE then 465 discards the packet. 467 9.3. Receiving Sprites 469 When a TE receives an echo request that was encapsulated as a sprite 470 with a correct checksum per Section 7.3, it sends a sprite-reply. 471 For ordinary echo requests, the TE decapsulates the packet and sends 472 an ordinary echo reply. 474 9.4. Sending Sprite-Replys 476 TEs send sprite-replys in response to sprites by creating an inner IP 477 echo reply packet according to the inner IP protocol (e.g., an ICMPv6 478 echo reply [RFC4443]). The TE includes in the echo reply any 479 identifying information that the TFE included in its echo request. 480 The TE then encapsulates the echo reply as a sprite-reply with a 481 correct checksum per Section 7.3 and sends it into the tunnel. 483 The TE SHOULD adopt a consistent behavior when responding to sprites, 484 i.e., it should consistently send either sprite-replys per Section 485 7.3 or ordinary echo replys. It should not, e.g., sometimes send 486 sprite-replys and other times send ordinary echo replys. 488 10. 8-bit Fletcher Checksum Calculation 490 The 8-bit Fletcher Checksum is discussed in [RFC1146][STONE1][STONE2] 491 and is used by this specification to provide an integrity check with 492 different properties than those used by common link layers and upper 493 layer protocols. 495 The TE calculates the 8-bit Fletcher checksum of the first 64 bytes 496 of the inner packet beginning with the inner IP header according to 497 the algorithm of [RFC1146], which is reproduced below with an 498 additional rule for representing zero results: 500 The 8-bit Fletcher Checksum Algorithm is calculated over a 501 sequence of data octets (call them D[1] through D[N]) by 502 maintaining 2 unsigned 1's-complement 8-bit accumulators A and B 503 whose contents are initially zero, and performing the following 504 loop where i ranges from 1 to N: 506 A := A + D[i] 507 B := B + A 509 If, at the end of the loop, either or both of the A, B 510 accumulators encode the value 0x0000, invert the value 511 in the accumulator(s) to 0xffff. 513 Note that faster algorithms are possible and may be used instead of 514 the algorithm above; see: [RFC1146] for citations of alternate 515 algorithms. 517 11. Updated Specifications 519 This document updates the following specifications: 521 o RFC2003 (IP-in-IP) 523 o RFC2473 (Generic packet tunneling in IPv6) 525 o RFC2529 (6over4) 527 o RFC2661 (L2TP) 529 o RFC2784 (GRE) 531 o RFC3056 (6to4) 533 o RFC3378 (ETHERIP) 535 o RFC3884 (IPSec Transport Mode for Dynamic Routing) 537 o RFC4023 (MPLS-in-IP) 539 o RFC4213 (Basic IPv6 Transition Mechanisms) 541 o RFC4214 (ISATAP) 542 o RFC4301 (IPSec) 544 o RFC4302 (AH) 546 o RFC4303 (ESP) 548 o RFC4380 (TEREDO) 550 o LISP 552 o others.... 554 12. IANA Considerations 556 The IANA is instructed to create a 'sprite-mtu' registry for the 557 Version and Type values that occur in the footers of encapsulated 558 packets per Section 7.3. 560 13. Security Considerations 562 A possible attack vector involves an off-path attacker sending 563 sprites with spoofed source addresses. However, TEs send sprites 564 that contain identifying information that will be echoed in the TFE's 565 replys to defend against off-path attacks. 567 Security considerations for specific IP/*/IP tunneling mechanisms are 568 given in the respective documents. 570 14. Acknowledgments 572 This work has benefited from discussions with Fred Baker, Iljitsch 573 van Beijnum, Brian Carpenter, Steve Casner, Remi Denis-Courmont, 574 Aurnaud Ebalard, Gorry Fairhurst, John Heffner, Christian Huitema, 575 Joe Macker, Matt Mathis, Joe Touch and James Woodyatt. 577 15. References 579 15.1. Normative References 581 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 582 September 1981. 584 [RFC1122] Braden, R., "Requirements for Internet Hosts - 585 Communication Layers", STD 3, RFC 1122, October 1989. 587 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 588 November 1990. 590 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 591 for IP version 6", RFC 1981, August 1996. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 597 (IPv6) Specification", RFC 2460, December 1998. 599 15.2. Informative References 601 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 602 options", RFC 1146, March 1990. 604 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 605 RFC 1958, June 1996. 607 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 608 RFC 2923, September 2000. 610 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 611 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 612 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 613 RFC 3819, July 2004. 615 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 616 Message Protocol (ICMPv6) for the Internet Protocol 617 Version 6 (IPv6) Specification", RFC 4443, March 2006. 619 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 620 Network Tunneling", RFC 4459, April 2006. 622 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 623 Discovery", RFC 4821, March 2007. 625 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 626 Errors at High Data Rates", RFC 4963, July 2007. 628 [STONE1] Stone, J., "Checksums in the Internet (Stanford Doctoral 629 Dissertation)", August 2001. 631 [STONE2] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 632 "Performance of Checksums and CRC's over Real Data, IEEE/ 633 ACM Transactions on Networking, Vol 6, No. 5", 634 October 1998. 636 Author's Address 638 Fred L. Templin (editor) 639 Boeing Phantom Works 640 P.O. Box 3707 641 Seattle, WA 98124 642 USA 644 Email: fred.l.templin@boeing.com 646 Full Copyright Statement 648 Copyright (C) The IETF Trust (2007). 650 This document is subject to the rights, licenses and restrictions 651 contained in BCP 78, and except as set forth therein, the authors 652 retain all their rights. 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 657 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 658 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 659 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 660 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Intellectual Property 664 The IETF takes no position regarding the validity or scope of any 665 Intellectual Property Rights or other rights that might be claimed to 666 pertain to the implementation or use of the technology described in 667 this document or the extent to which any license under such rights 668 might or might not be available; nor does it represent that it has 669 made any independent effort to identify any such rights. Information 670 on the procedures with respect to rights in RFC documents can be 671 found in BCP 78 and BCP 79. 673 Copies of IPR disclosures made to the IETF Secretariat and any 674 assurances of licenses to be made available, or the result of an 675 attempt made to obtain a general license or permission for the use of 676 such proprietary rights by implementers or users of this 677 specification can be obtained from the IETF on-line IPR repository at 678 http://www.ietf.org/ipr. 680 The IETF invites any interested party to bring to its attention any 681 copyrights, patents or patent applications, or other proprietary 682 rights that may cover technology that may be required to implement 683 this standard. Please address the information to the IETF at 684 ietf-ipr@ietf.org. 686 Acknowledgment 688 Funding for the RFC Editor function is provided by the IETF 689 Administrative Support Activity (IASA).