Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational September 25, 2007 Expires: March 28, 2008 Minimal Packetization Layer Path MTU Discovery for IP/*/IPv4 Tunnels draft-templin-inetmtu-lite-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The nominal Maximum Transmission Unit (MTU) of the Internet has become 1500 bytes, but existing IP/*/IPv4 tunneling mechanisms impose an encapsulation overhead that can reduce the effective path MTU to smaller values. Additionally, existing IP/*/IPv4 tunneling mechanisms are limited in their ability to discover and utilize larger MTUs. This document specifies minimal mechanisms for conveying packets over IP/*/IPv4 tunnels that address these issues. Templin Expires March 28, 2008 [Page 1]
Internet-Draft M/PLPMTUD for Tunnels September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. MTU and EMTU_R . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Tunnel Soft State . . . . . . . . . . . . . . . . . . . . . . 4 6. Sending Packets . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Conceptual Sending Algorithm . . . . . . . . . . . . . . . 5 6.2. Inner packet Fragmentation . . . . . . . . . . . . . . . . 6 6.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Outer Packet Fragmentation . . . . . . . . . . . . . . . . 9 6.5. Setting DF in the Outer Header . . . . . . . . . . . . . . 9 7. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IPv4 Reassembly Cache Management . . . . . . . . . . . . . 9 7.2. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Receiving Packet Too Big (PTB) Errors . . . . . . . . . . 9 8. Tunnel Qualification and Soft State Management . . . . . . . . 10 8.1. Basic Probing Strategy . . . . . . . . . . . . . . . . . . 10 8.2. MaxFragSize Probing . . . . . . . . . . . . . . . . . . . 10 8.3. Sending Probe Requests . . . . . . . . . . . . . . . . . . 10 8.4. Receiving Probe Requests . . . . . . . . . . . . . . . . . 11 8.5. Sending Probe Replies . . . . . . . . . . . . . . . . . . 11 8.6. Receiving Probe Replies . . . . . . . . . . . . . . . . . 11 9. 8-bit Fletcher Checksum Calculation . . . . . . . . . . . . . 11 10. Updated Specifications . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Discussion . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Templin Expires March 28, 2008 [Page 2]
Internet-Draft M/PLPMTUD for Tunnels September 2007 1. Introduction The nominal Maximum Transmission Unit (MTU) of today's Internet has become 1500 bytes due to the preponderance of networking gear that configures an MTU of that size. Since not all links in the Internet configure a 1500 byte MTU, however [RFC3819], packets can be dropped due to an MTU restriction on the path. Internet Protocol, Version 4 (IPv4) [RFC0791] is the predominant network layer protocol in the Internet today, and it is likely that IP/*/IPv4 tunnel use will continue to grow into the future. Upper layers see IP/*/IPv4 tunnels as ordinary links, but even for packets no larger than 1500 bytes these links are susceptible to silent loss (e.g., due to path MTU restrictions, lost error messages, layered encapsulations, reassembly buffer limitations, etc.) resulting in poor performance and/or communications failures [RFC2923][RFC4459][RFC4821][RFC4963]. This document specifies minimal mechanisms for IP/*/IPv4 tunnels that provide robust handling for packets of 1500 bytes or smaller and best-effort handling for packets larger than 1500 bytes. It updates the functional specifications for Tunnel Endpoints (TEs) found in existing IP/*/IPv4 tunneling mechanisms (see: Section 10). 2. Terminology The following abbreviations and terms are used in this document: DF - the IPv4 header "Don't Fragment" flag ([RFC0791], Section 3.1). EMTU_R - Effective MTU to Receive ([RFC1122], Section 3.3.2). ENCAPS - the size of the encapsulating */IPv4 headers plus trailers. IPv4 - Internet Protocol, Version 4 IPv6 - Internet Protocol, Version 6 MaxFragSize - Maximum Outer Packet size, in bytes MTU - Maximum Transmission Unit PTB - Packet Too Big error Templin Expires March 28, 2008 [Page 3]
Internet-Draft M/PLPMTUD for Tunnels September 2007 TE - Tunnel Endpoint TFE - Tunnel Far End TNE - Tunnel Near End IP/*/IPv4 - an IP packet encapsulated in */IPv4 headers (e.g. for "*" = NULL, UDP, TCP, AH, ESP, etc.). inner packet/header/payload - an IP packet/header/payload before IP/*/IPv4 encapsulation. outer packet/header/payload - a */IPv4 packet/header/payload after IP/*/IPv4 encapsulation. 3. Concept of Operation TEs that implement this scheme engage in a continuous probing process while data is flowing through the tunnel to confirm that the TFE is participating and to maintain soft state used for determining maximum packet sizes. When the flow of data through the tunnel is suspended, the probing process is discontinued. When one or both of the TEs do not implement the scheme, the behavior automatically reverts to that of the legacy IP/*/IPv4 tunneling mechanism. 4. MTU and EMTU_R TEs configure an indefinite MTU on the tunnel interface, i.e., there is no logical limit on the size of inner packets that upper layers can present to the tunnel interface. TEs MUST configure an EMTU_R that is no smaller than 2048 bytes (2KB) on all IPv4 interfaces over which a tunnel interface is configured. Additionally, they MUST configure an EMTU_R that is no smaller than 2KB on the tunnel interface, and SHOULD configure an EMTU_R that is no smaller than the largest EMTU_R of any IPv4 interfaces over which the tunnel is configured. See: [RFC1122], Section 3.3.2 for EMTU_R recommendations. 5. Tunnel Soft State TEs maintain the following per-TFE conceptual variables as soft state (e.g., in a conceptual neighbor cache): Templin Expires March 28, 2008 [Page 4]
Internet-Draft M/PLPMTUD for Tunnels September 2007 MaxFragSize the current maximum length outer packet/fragment that can be accommodated by the IPv4 path MTU without further fragmentation. See: [RFC3819], Section 2 for subnetwork MTU recommendations that influence 'MaxFragSize'. Recommended default value: 128 bytes. Range: 68 bytes to 64KB. IPv4Id the current IPv4 ID value that the TE will assign in the outer IPv4 header of packets it sends into the tunnel. Initial value: randomly chosen. Range: 0 to 2^16-1. isQualified boolean indicating whether the TFE implements the scheme. Recommended default value: FALSE. 6. Sending Packets TEs send packets across tunnels to TFEs for which 'isQualified' is TRUE according to the following specifications. (TEs also use portions of the following specifications to qualify new TFEs through initial 'isQualified' probing). 6.1. Conceptual Sending Algorithm With reference to Sections 6.2 - 6.5, TEs use the following conceptual sending algorithm: Templin Expires March 28, 2008 [Page 5]
Internet-Draft M/PLPMTUD for Tunnels September 2007 if inner packet is larger than 1500 bytes and inner packet is not fragmentable (see: Section 6.2) Encapsulate as an outer IPv4 packet (see: Section 6.3). Set DF in the outer header per Section 6.5. Send packet. else if inner packet is larger than 2*('MaxFragSize' - ENCAPS) and inner packet is not a probe if inner packet is not fragmentable (see: Section 6.2) Send PTB appropriate to the inner protocol with MTU = 2*('MaxFragSize' - ENCAPS). Drop packet. else Fragment inner packet into fragments no larger than 2*('MaxFragSize' - ENCAPS) (see: Section 6.2). endif endif foreach inner packet/fragment Encapsulate as an outer IPv4 packet (see: Section 6.3). if outer packet is not a probe fragment outer packet into fragments no larger than 'MaxFragSize' (see: Section 6.4). endif foreach outer packet/fragment Set DF in the outer header per Section 6.5. Send packet/fragment. endforeach endforeach endif Figure 1: Conceptual Sending Algorithm 6.2. Inner packet Fragmentation An inner packet is fragmentable IFF the TE is permitted to break it into inner fragments before encapsulation, e.g., an IPv4 packet with DF=0, an IPv6 packet of 1280 bytes or smaller with a fragment header (see below), etc. TEs break fragmentable inner packets into inner fragments of no more than 2*('MaxFragSize' - ENCAPS) bytes. The TE then encapsulates each inner fragment per Section 6.3. These inner fragments will be reassembled by the final destination. Note that 2*('MaxFragSize' - ENCAPS) may not be large enough to accommodate the minimum IPv6 MTU such that the TE may be required to drop an IPv6 packet of 1280 bytes or smaller and send an ICMPv6 PTB with an MTU value less than 1280 bytes. The original IPv6 source Templin Expires March 28, 2008 [Page 6]
Internet-Draft M/PLPMTUD for Tunnels September 2007 will then include a fragment header in subsequent IPv6 packets and the TE can then perform IPv6 fragmentation on these inner packets using the fragment header included by the source according to the final paragraph of [RFC2460], Section 5. 6.3. Encapsulation TEs encapsulate inner IP packets according to the specific IP/*/IPv4 document, except that the TE maintains a randomly-initialized and monotonically-increasing (modulo 64K) per-TFE 'IPv4Id' value that it encodes in the outer IPv4 headers of successive encapsulated packets. During encapsulation the TE also appends a trailer (if necessary) that includes zero or more zero-padding bytes and a 4-byte trailing "footer". The TE increments the innermost '*' header length field by the number of trailer bytes added, for example it increments the UDP length field for IPv6/UDP/IPv4 tunnels, the IPv4 length field for IPv6/IPv4 tunnels, etc. The encapsulation is shown in Figure 2: +---------------------------------+ | Outer IPv4 | | Header w/'IPv4Id' | +---------------------------------+ | * Headers | | | +-------------+ +---------------------------------+ | Inner IP | | Inner IP | ~ packet ~ ===> ~ packet ~ | | | | +-------------+ +---------------------------------+ -\ T Inner Packet | | | r ~ Zero-Padding (0 or more bytes) ~ | a | | > i +---------------------------------+ | l | Footer (4 bytes) | | e +---------------------------------+ -/ r | Any */IPv4 protocol trailers ... +------------------------------ Outer Packet Figure 2: Encapsulation Format with Trailer The footer is encoded as the final 4 bytes of the trailer and is byte-aligned only, i.e., it need not be aligned on an even word/ longword/etc. boundary. The footer is formatted as shown in Figure 3: Templin Expires March 28, 2008 [Page 7]
Internet-Draft M/PLPMTUD for Tunnels September 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Reserved | Fletcher A | Fletcher B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Footer Format Version (4 bits) The Version field indicates the format of the trailer. This document describes version 2. Type (4 bits) The type of encapsulated packet. The following types are defined: 0 - Ordinary data packet. 1 - Probe Request 2 - Probe Reply 3 - 15 - Reserved for future use. Reserved (8 bits) Reserved for future use. Fletcher A (8 bits) The 8-bit Fletcher A checksum component. Fletcher B (8 bits) The 8-bit Fletcher B checksum component. During encapsulation, the TE MUST include a trailer with a non-zero checksum in all probe request/reply packets and in all data packets that are sent as multiple outer fragments. For data packets that are sent as a single outer fragment, the TE MAY: 1) include a trailer with a non-zero checksum, 2) include a trailer with a zero checksum, or 3) omit the trailer. For all packets that will include a trailer with a non-zero checksum, the TE appends zero-filled padding bytes as necessary to extend the packet to a minimum length of 64 bytes beyond the beginning of the inner IP header. The TE then calculates the 8-bit Fletcher checksum as specified in Section 9 and encodes the results in the Fletcher A and B fields of the footer. Templin Expires March 28, 2008 [Page 8]
Internet-Draft M/PLPMTUD for Tunnels September 2007 6.4. Outer Packet Fragmentation For outer packets other than probe requests used for 'MaxFragSize' determination, TEs use IPv4 fragmentation to fragment the packets into fragments no larger than 'MaxFragSize' bytes. These outer fragments will be reassembled by the TFE. 6.5. Setting DF in the Outer Header TEs MUST set DF=1 in the outer IPv4 header of probe requests used for 'MaxFragSize' determination. TEs MAY set DF=0 in the outer header of other probe requests and SHOULD set DF=0 in the outer header of probe replies. TEs MUST set DF=1 in the outer header of ordinary data packets/ fragments. 7. Receiving Packets 7.1. IPv4 Reassembly Cache Management TEs that implement this scheme should perform active management in their IPv4 reassembly cache. That is, they should actively discard "stale" reassemblies that have no apparent opportunity for successful completion prior to the normal reassembly timeout expiration. 7.2. Decapsulation TEs decapsulate each outer packet they receive exactly as specified in the appropriate IP/*/IPv4 document except that when 'isQualified' is TRUE and the packet includes a non-zero trailing checksum the TE first verifies the checksum in the outer packet as specified in Section 9. If the A and B results of the checksum calculation match the values stored in the trailing checksum, the TE decapsulates the packet; otherwise it drops the packet. Note that the initial probe request/reply packets from a new TFE will be received before 'isQualified' is set to TRUE. The TE decapsulates these packets also, as specified in Section 8. 7.3. Receiving Packet Too Big (PTB) Errors TEs may receive ICMPv4 PTB errors with Type=3 ("Destination Unreachable") and Code=4 ("fragmentation needed, and DF set") that include a Next-Hop MTU value [RFC1191] in response to any packets that were admitted into the tunnel with DF=1 [RFC0792]. Templin Expires March 28, 2008 [Page 9]
Internet-Draft M/PLPMTUD for Tunnels September 2007 When the TE receives an ICMPv4 PTB with a Next-Hop MTU value smaller than 'MaxFragSize', it SHOULD reduce 'MaxFragSize' and/or actively probe to discover and confirm a new 'MaxFragSize'. When the TE receives an ICMPv4 PTB for an inner packet larger than 1500 bytes, it SHOULD send a translated PTB back to the inner source if possible. 8. Tunnel Qualification and Soft State Management TEs engage in a probing process to qualify new TFEs and refresh per- TFE soft state for qualified TFEs thereafter. TEs discontinue the probing process and garbage-collect stale soft state for dormant tunnels and unqualified TFEs. TEs exchange probe requests and replies as specified in the following sections: 8.1. Basic Probing Strategy TEs send probe requests while data is actively flowing through the tunnel. The TE sends initial probe requests to qualify each new TFE, then sends periodic probe requests thereafter. The TE SHOULD limit the rate at which it sends probe requests to each TFE, but MUST probe frequently enough to refresh per-TFE conceptual variables. The TE retains a cache of recently-sent probe requests and uses them to verify subsequent probe replies. 8.2. MaxFragSize Probing The TE SHOULD probe to detect larger 'MaxFragSize' values by sending progressively larger probe requests padded to the desired probe size (up to 1500 bytes + ENCAPS). When the TE receives sufficient evidence through probing that the forward path to the TFE supports the probed size, it advances 'MaxFragSize' to the probe size. The TE MAY send a series of probes in parallel to mitigate 'MaxFragSize' fluctuations in the case of multipath routes with diverse path MTUs. 8.3. Sending Probe Requests TEs generate probe requests by creating a minimum-sized and unfragmentable IP echo request packet according to the inner IP protocol (e.g., an ICMPv6 echo request [RFC4443] when the inner IP protocol is IPv6). The echo request MUST include source and destination addresses that correspond to the TNE and TFE respectively, and SHOULD include additional identifying information (e.g., sequence/identification numbers, nonce values, etc.) that the TFE will echo in its reply. The TE then encapsulates the echo Templin Expires March 28, 2008 [Page 10]
Internet-Draft M/PLPMTUD for Tunnels September 2007 request with padding added to create an outer probe request of the desired probe size and sends the probe request into the tunnel as specified in Section 6. 8.4. Receiving Probe Requests When a TE receives a potential probe request from a TFE (i.e., as- told by examining the potential trailer), it first determines whether the packet includes a valid trailer (i.e., a valid footer and checksum). If the packet does not include a valid trailer, the TE discontinues probe request processing, decapsulates the packet as for ordinary data and returns from processing. Otherwise, the TE generates and sends a probe reply. 8.5. Sending Probe Replies TEs send probe replies in response to valid probe requests, but MUST limit the rate at which it sends replies to each TFE to avoid DOS amplification based on probe requests with spoofed source addresses. When it sends a probe reply, the TE creates an inner IP echo reply packet according to the inner IP protocol (e.g., an ICMPv6 echo reply [RFC4443] when the inner protocol is IPv6). The TE includes in the echo reply the destination address of the echo request as the source address and the source address of the echo request as the destination addresses. The TE also includes in the echo reply any additional identifying information that the TFE included in its echo request. The TE then encapsulates the echo reply as specified in Section 6.3. 8.6. Receiving Probe Replies When a TE receives a potential probe reply from a TFE, it first determines whether the packet includes a valid trailer. If the packet did not include a valid trailer, the TE discontinues probe reply processing, decapsulates the packet as for ordinary data and returns from processing. Otherwise, the TE verifies that the inner IP echo reply matches one of its cached probe requests by examining the inner IP source and destination addresses as well as any other identifying information in the inner packet. The TE sets: 'isQualified' to TRUE for this TFE if the probe reply is valid; otherwise, it discards the probe reply and returns from processing. 9. 8-bit Fletcher Checksum Calculation The 8-bit Fletcher Checksum is discussed in [RFC1146][STONE1][STONE2] Templin Expires March 28, 2008 [Page 11]
Internet-Draft M/PLPMTUD for Tunnels September 2007 and is used by this specification to provide an integrity check with different properties than those used by common link layers and upper layer protocols. The TE calculates the 8-bit Fletcher checksum of the first 64 bytes of the inner packet beginning with the inner IP header according to the algorithm of [RFC1146], which is reproduced below with an additional rule for representing zero results: The 8-bit Fletcher Checksum Algorithm is calculated over a sequence of data octets (call them D[1] through D[N]) by maintaining 2 unsigned 1's-complement 8-bit accumulators A and B whose contents are initially zero, and performing the following loop where i ranges from 1 to N: A := A + D[i] B := B + A If, at the end of the loop, either or both of the A, B accumulators encode the value 0x0000, invert the value in the accumulator(s) to 0xffff. Note that faster algorithms are possible and may be used instead of the algorithm above; see: [RFC1146] for citations of alternate algorithms. 10. Updated Specifications This document updates the following specifications: o RFC2003 (IP-in-IP) o RFC2529 (6over4) o RFC2661 (L2TP) o RFC2784 (GRE) o RFC3056 (6to4) o RFC3378 (ETHERIP) o RFC3884 (IPSec Transport Mode for Dynamic Routing) o RFC4023 (MPLS-in-IP) Templin Expires March 28, 2008 [Page 12]
Internet-Draft M/PLPMTUD for Tunnels September 2007 o RFC4213 (Basic IPv6 Transition Mechanisms) o RFC4214 (ISATAP) o RFC4301 (IPSec) o RFC4302 (AH) o RFC4303 (ESP) o RFC4380 (TEREDO) o LISP o others.... 11. IANA Considerations The IANA is instructed to create a registry for the Version and Type values that occur in the footers of encapsulated packets per Section 6.3.1. 12. Security Considerations A possible attack vector involves an off-path attacker sending probe requests with spoofed source addresses. Legitimate probe requests and replies contain identifying information that is useful for defending against off-path attacks. Security considerations for specific IP/*/IPv4 tunneling mechanisms are given in the respective documents. 13. Acknowledgments This work has benefited from discussions with Fred Baker, Iljitsch van Beijnum, Steve Casner, Gorry Fairhurst, John Heffner, Joe Macker, Matt Mathis, and Joe Touch. Dan Romascanu mentioned the IEEE 802.3as extension of the Ethernet frame size to 2048 bytes. Remi Denis- Courmont noted that trailers could be added using the innermost '*' protocol length field. 14. References Templin Expires March 28, 2008 [Page 13]
Internet-Draft M/PLPMTUD for Tunnels September 2007 14.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 14.2. Informative References [RFC0905] International Organization for Standardization (ISO), "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984. [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, September 2002. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. Templin Expires March 28, 2008 [Page 14]
Internet-Draft M/PLPMTUD for Tunnels September 2007 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. [STONE1] Stone, J., "Checksums in the Internet (Stanford Doctoral Dissertation)", August 2001. [STONE2] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of Checksums and CRC's over Real Data, IEEE/ ACM Transactions on Networking, Vol 6, No. 5", October 1998. Appendix A. Discussion Probing strategies for packetization layer protocols are specified in ([RFC4821], Section 7) and apply also to the TE's 'MaxFragSize' probing process. Further strategies for handling ICMPv4 PTB errors are specified in ([RFC4821], Section 7) and apply also to the TE's 'MaxFragSize' probing process. Note that decapsulation automatically erases any padding that may have been inserted by the TE along with the trailing checksum. Author's Address Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Templin Expires March 28, 2008 [Page 15]
Internet-Draft M/PLPMTUD for Tunnels September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin Expires March 28, 2008 [Page 16]