Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Experimental May 1, 2007 Expires: November 2, 2007 Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels draft-templin-linkadapt-04.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 November 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IPv6-in-(foo)-in-IPv4 tunnels support a minimum Maximum Transmission Unit (MTU) of 1280 bytes for IPv6 via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document specifies link adaptation mechanisms for IPv6-in-(foo)-in-IPv4 tunnels that present an assured MTU to the IPv6 layer using tunnel endpoint-based segmentation/reassembly and dynamic segment size probing. Templin Expires November 2, 2007 [Page 1] Internet-Draft Link Adaptation for Tunnels May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels . . . . . . 4 3.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Tunnel MTU and MRU . . . . . . . . . . . . . . . . . . . . 4 3.3. Encapsulation/Segmentation . . . . . . . . . . . . . . . . 5 3.4. IPv4 Fragmentation and setting the DF Bit . . . . . . . . 8 3.5. Decapsulation/Reassembly . . . . . . . . . . . . . . . . . 9 3.6. ICMPv4 "Fragmentation Needed" Messages . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Appendix A: Additional Considerations . . . . . . . . . . . . 11 8. Appendix B: Changes . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Templin Expires November 2, 2007 [Page 2] Internet-Draft Link Adaptation for Tunnels May 2007 1. Introduction IPv6-in-(foo)-in-IPv4 tunnels may span multiple IPv4 network hops yet are seen by IPv6 as ordinary links that must support the minimum IPv6 Maximum Transmission Unit (MTU) of 1280 bytes ([RFC2460], Section 5). Common IPv6-in-(foo)-in-IPv4 tunneling mechanisms meet this requirement through conservative static prearrangements at the expense of degraded performance over some paths due to excessive IPv4 network-based fragmentation and/or missed opportunities to discover larger MTUs. Optional dynamic MTU determination methods [RFC1191] are also available, but may not provide adequate robustness (see: Section 3.6). This document specifies link adaptation mechanisms for IPv6-in-(foo)- in-IPv4 tunnels that present an assured MTU to the IPv6 layer. It uses tunnel endpoint-based segmentation/reassembly and dynamic segment size probing with authenticated probe feedback. Thus, it provides greater robustness and efficiency by avoiding IPv4 network- based fragmentation and dependence on ICMPv4 feedback from IPv4 network middleboxes. 2. Terminology The following terms are defined within the scope of this document: Upper Layer Payload (ULP) a whole IPv6 packet, or a fragment packet created by IPv6 fragmentation. Ingress Tunnel Endpoint (ITE) the tunnel interface endpoint that accepts ULPs from the IP layer and segments/packetizes them for transmission into a tunnel. Egress Tunnel Endpoint (ETE) the tunnel interface endpoint that receives packets from a tunnel and de-packetizes/reassembles them into ULPs for delivery to the IP layer. IP Layer the layer above the tunnel interface, i.e., the IPv6 layer. Templin Expires November 2, 2007 [Page 3] Internet-Draft Link Adaptation for Tunnels May 2007 Sub-IP Layer any sublayers that occur within the tunnel interface, i.e., any (foo) layers and including the upper portion of the IPv4 layer. Note that IPv4 is also viewed as the Layer 2 protocol from the perspective of the tunnel, so the Sub-IP layer begins below the IP layer and extends into Layer 2. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels The following subsections specify link adaptation mechanisms for IPv6-in-(foo)-in-IPv4 tunnels with properties similar to the link adaptation mechanisms defined for AAL5 [RFC2684] and IEEE 802.11 [WLAN]: 3.1. Layering IPv6-in-(foo)-in-IPv4 tunnel endpoints that implement the link adaptation mechanisms specified in this document operate at a logical midpoint between the IPv6 and IPv4 protocol modules. From the viewpoint of IPv6, the tunnel appears as an ordinary network interface module that delivers whole IPv6 packets and IPv6 fragment packets as ULPs to and from an underlying link. From the viewpoint of IPv4, the tunnel appears as a packetization layer protocol that segments and reassembles ULPs. This document refers to the IPv6 layer as the "IP Layer" (i.e., layer 3) and any sublayers that occur within the tunnel interface (i.e., any (foo) layers and including the upper portion of the IPv4 layer) as the "Sub-IP layer". Note that IPv4 is also viewed as the Layer 2 protocol from the perspective of the tunnel, so the Sub-IP layer begins below the IP layer and extends into Layer 2. Note also that (foo) may entail multiple nested sublayers or may even be NULL, i.e., in the case of IPv6-in-IPv4 tunnels. 3.2. Tunnel MTU and MRU ITEs MUST configure a minimum IPv6 link MTU of 1280 bytes and SHOULD provide a configuration knob to set larger values. A nominal MTU of 9180 bytes (i.e., the same as defined in [RFC1626]) is RECOMMENDED, since it is large enough to accommodate frame sizes as large as Gigabit Ethernet Jumbo Frames [GIGE]. ITEs MAY set still larger MTU values, but are advised that this may lead to excessive packet loss Templin Expires November 2, 2007 [Page 4] Internet-Draft Link Adaptation for Tunnels May 2007 and ICMPv6 "packet too big" messages. ETEs MUST configure a minimum per-flow Sub-IP layer reassembly buffer size (i.e., a minimum Sub-IP layer Maximum Receive Unit (MRU)) of 1280 bytes, and SHOULD configure an MRU of 9180 bytes or larger to accommodate the recommended nominal MTU for ITEs. A maximum MRU of 11454 bytes is RECOMMENDED, since 11454 bytes is the maximum packet size for which a 32-bit CRC can provide Ethernet-quality bit error detection [JAIN][AARNET]. ETEs MAY set still larger MRU values, but are advised that larger values may lead to unacceptable levels of undetected errors unless all physical segments in the path provide assured error-free delivery for larger packets. 3.3. Encapsulation/Segmentation ITEs maintain a per-flow segment size ("SEGSIZE") for the purpose of segmenting ULPs that are too large to traverse the tunnel. It is RECOMMENDED that ITEs configure an initial value such that SEGSIZE (plus the length of any (foo) headers and the IPv4 header) is between 512 and 576 bytes to accommodate the recommended nominal MTU and since IPv4 nodes are only required to accept datagrams of up to 576 bytes [RFC0791]. Since most IPv4 links in the Internet configure still larger MTUs [RFC3150][RFC3819], and since IPv4 nodes should accept packets as large as the underlying link MTU [RFC1122], a larger initial SEGSIZE value (e.g., 1KB) may be used if there is assurance that it would not cause gratuitous IPv4 fragmentation. ITEs split each ULP they send into a tunnel into chains of segments for packetization and presentation to the IPv4 layer. For ULPs that will span multiple segments, the ITE first uses the 2's compliment Fletcher-32 checksum [STONE][RFC3385] to calculate a checksum across the entire ULP, then appends the A and B results as a trailing 32-bit checksum at the end of the ULP. For ULPs that fit within a single segment, the ITE omits the trailing checksum. After it appends the trailing checksum (if needed), the ITE splits the ULP into a chain of consecutive segments that MUST be created as contiguous and non-overlapping, i.e., the final byte of the (i)th segment MUST be the byte that immediately precedes the first byte of the (i+1)th segment. Non-final segments in the chain MUST be SEGSIZE bytes in length; the final segment MAY be of different length. The ITE next encapsulates each segment in Sub-IP layer headers (including any (foo) headers and an IPv4 header) to form a chain of IPv4 packets. Each packet in the chain MUST include identical Sub-IP layer encapsulation headers with the exception of any length fields or per-packet identification fields. Templin Expires November 2, 2007 [Page 5] Internet-Draft Link Adaptation for Tunnels May 2007 The ITE sets the reserved bit in the IPv4 "Flags" field to '1' to inform the ETE that the segmentation/reassembly scheme specified in this document is used and also sets or clears the DF bit according to the specification in Section 3.4. In addition, the ITE encodes the following information in the 16-bit IPv4 "Identification" field of each segment: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ULPID | SEGID |P|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Identification Field ULPID: 8 bits An identifying value assigned by the ITE to aid the ETE in reassembling the segments of a ULP. SEGID: 6 bits A value that identifies a specific segment within a ULP. P: 1 bit Probe flag; 0 = Ordinary Segment, 1 = Probe Segment. A: 1 bit Additional Segments flag; 0 = Last Segment, 1 = Additional Segments. The ITE encodes an identical value in the "ULPID" field (bits 0 - 7 of the IPv4 Identification field) of each IPv4 packet in a chain to identify the segments of a specific ULP; it encodes different ULPID values in IPv4 packets that encapsulate segments of different ULPs. The ITE also encodes an increasing Segment ID value between 0 - 62 in the "SEGID" field (bits 8 - 13 of the IPv4 Identification field) of consecutive packets in a chain, i.e., it encodes the value '0' in the first packet, encodes the value '1' in the second packet, etc. The ITE then sets the "Additional Segments - A" bit (bit 15 of the IPv4 Identification field) in each packet in the chain except the final one to indicate that additional segments follow. Finally, it delivers each packet in the chain to the link layer (i.e., the IPv4 layer) in increasing SEGID order, i.e., SEGID 0 first, followed by SEGID 1, etc., up to the final packet. The IPv4 layer SHOULD NOT reorder the packets in a chain, but rather SHOULD deliver them to the Templin Expires November 2, 2007 [Page 6] Internet-Draft Link Adaptation for Tunnels May 2007 underlying link in the order in which the tunnel interface produced them. Upon sending a packet chain, the ITE may receive an encapsulated ICMPv6 "packet too big" message [RFC1981] from an ETE at the far end of the tunnel (see: Section 3.5). The ITE SHOULD cache the MTU value encoded in the "packet too big" message as the new MTU for the tunnel, and relay the ICMPv6 message back to the original source. Upon sending a packet chain, the ITE may receive an encapsulated ICMPv6 "parameter problem" message with code "reassembly/checksum error" [RFC4443] from an ETE at the far end of the tunnel (see: Section 3.5). This may indicate an isolated packet splicing error at the ETE, or packet loss due to temporal network conditions such as congestion, MTU restrictions, link errors, signal intermittence, etc. If it receives persistent reassembly/checksum errors from the same ETE, the ITE SHOULD take adaptive measures, e.g., rate-limit the packets it sends into the tunnel, etc. Since each reassembly/ checksum error corresponds to a dropped packet, the ITE SHOULD relay the messages back to the original source (subject to rate limiting). To increase efficiency and avoid excessive packet chain lengths, ITEs SHOULD seek to increase a flow's SEGSIZE to larger values through careful path probing (e.g., see: [RFC4821]). ITEs probe a candidate SEGSIZE value 'N' by setting the "Probe Segment - P" bit (bit 14 of the IPv4 Identification field) in packets that encapsulate a probe segment of size N. For probe segments that contain valid data for reassembly as part of a packet chain, the ITE sets the appropriate SEGID value in the IPv4 packet header as for ordinary segmentation. For probe segments that are to be discarded by the ETE, the ITE sets the value 63 in the SEGID field. When the ITE sends a probe packet, it marks the probe as "pending" for a period of 'MaxProbeDelay' msec (i.e., a per-flow round-trip time estimate for the tunnel) and caches the probe packet's IPv4 destination, length and identification field values, as well as the IPv6 flow label value [RFC3697]. If the ITE receives a valid Node Information Query reply (NI Reply) [RFC4620] from the ETE (see: Section 3.5) before the probe period expires, it marks the probe as successful; otherwise, it marks the probe as failed. A valid NI Reply MUST have: o the Type, Code, Qtype and Flags fields set as specified for a NOOP reply in ([RFC4620], Section 6.1), and o the IPv4 length of the probe packet matches bits 0-15 of the Nonce field, and Templin Expires November 2, 2007 [Page 7] Internet-Draft Link Adaptation for Tunnels May 2007 o the IPv4 identification of the probe packet matches bits 16-31 of the Nonce field, and o the IPv6 flow label value matches bits 32-51 of the Nonce field Following a successful probe, but before advancing SEGSIZE to N, the ITE SHOULD enter a verification phase during which it sends additional probe segments to detect asymmetric multipath MTU restrictions and/or route fluctuations. Thereafter, the ITE SHOULD re-probe periodically to confirm that packets with up to SEGSIZE byte segments are still reaching the ETE. Additional strategies for SEGSIZE management are found in [RFC4821]. 3.4. IPv4 Fragmentation and setting the DF Bit When an ITE segments a ULP (see: Section 3.3), it can optionally set or not set the "Don't Fragment - DF" bit in the IPv4 headers of packets in the chain. If the DF bit is not set, network-based IPv4 fragmentation may occur resulting in well-known operational issues [FRAG] [I-D.heffner-frag-harmful]. Additionally, some middleboxes (such as IPv4 NATs and firewalls) may only be capable of passing the first fragment of a multi-fragment IPv4 datagram, which could result in silent communication failures. Finally, sending large IPv4 packets with the DF bit not set could result in IPv4 reassembly buffer overruns and thereby also result in silent communication failures. Although all IPv4 nodes are required to accept datagrams of up to 576 bytes, the minimum IPv4 MTU is only 68 bytes, i.e., the size required to encapsulate a maximum-length (60 byte) IPv4 header and a minimum- length (8 byte) fragment [RFC0791]. Therefore, a limited amount of IPv4 fragmentation may occur in the network even for packets as small as the recommended minimum of 512 bytes. Also, while IPv4 fragmentation can result in silent communication failures, in some instances it might result in successful communications when setting the DF bit would have resulted in packet loss due to a link MTU restriction within the path. In view of the above considerations, and in order to provide robustness, efficiency and consistent behavior: o ITEs SHOULD NOT set the DF bit in packets smaller than 512 bytes. o ITEs SHOULD set the DF bit in packets used for probing. o ITEs SHOULD adopt a consistent strategy in setting or not setting the DF bit in other packets. Templin Expires November 2, 2007 [Page 8] Internet-Draft Link Adaptation for Tunnels May 2007 Note that IPv4 fragmentation in the network could theoretically result in silent communication failures along certain paths even with the recommended minimum IPv4 packet size of 512 bytes. As such, robust implementations could reduce their IPv4 packet sizes to as small as 68 bytes if silent communication failures are suspected, but such small packet sizes might not satisfy the nominal tunnel MTU of 9180 bytes. ITEs SHOULD therefore return locally-generated IPv6 "packet too big" messages for IPv6 packets that cannot be accommodated within current IPv4 packet size and chain length limitations for the tunnel. 3.5. Decapsulation/Reassembly For tunneled packets with the reserved bit in the IPv4 "Flags" field set to '1' (see: Section 3.3), the IPv4 length, ULPID, SEGID and A fields along with the IPv6 flow label [RFC3697] provide sufficient information for the ETE to reassemble an original ULP with protection for packet reordering in the IPv4 network. ETEs MUST configure per- flow reassembly buffers of at least 1280 bytes and SHOULD configure reassembly buffers of 9180 bytes or larger to accommodate the nominal tunnel MTU (see: Section 3.2). Note that these reassembly buffers occur at the Sub-IP layer and are thus distinct from the IPv4 and IPv6 reassembly caches. ETEs use per-flow reassembly buffers to concatenate the segments received in packet chains for a particular ULPID in increasing SEGID order (i.e., SEGID 0, followed by SEGID 1, etc.) even if the packets were re-ordered by the network. When all segments for a particular ULPID have been concatenated into the reassembly buffer, the ETE uses 2's complement Fletcher-32 to detect errors if a trailing checksum was included (see: Section 3.3). If the ETE receives a packet chain that would overflow the reassembly buffer, it discards the chain and sends an ICMPv6 "packet too big" message [RFC1981] back to the IPv6 source via the reverse tunnel back to the ITE. The ETE includes in the message body up to 1280 bytes beginning with the upper layer packet headers (IPv6 and above) and the contents of the reassembly buffer beyond the upper layer packet headers; it encodes the size of the reassembly buffer in the MTU value. If the ETE receives at least one segment, but one or more segments are lost and/or checksum verification fails, it SHOULD send an ICMPv6 "parameter problem" message with code "reassembly/checksum error" [RFC4443] back to the IPv6 source via the reverse tunnel back to the ITE. The ETE includes in the message body up to 1280 bytes beginning with the upper layer packet headers (IPv6 and above) and contents of the reassembly buffer beyond the upper layer packet headers, and sets Templin Expires November 2, 2007 [Page 9] Internet-Draft Link Adaptation for Tunnels May 2007 the pointer to either the beginning of the first missing segment or the beginning of the 4 byte checksum field (if no segments were missing). If the ETE receives a segment used for probing (i.e., an IPv4 packet in the chain with the 'P' flag set), it sends a Node Information Query reply (NI Reply) [RFC4620] message back to the ITE. The ETE MUST construct the NI Reply as follows: o the Type, Code, Qtype and Flags fields set as specified for a NOOP reply in ([RFC4620], Section 6.1), and o the IPv4 length of the probe packet encoded in bits 0-15 of the Nonce field, and o the IPv4 identification of the probe packet encoded in bits 16-31 of the Nonce field, and o the IPv6 flow label value encoded in bits 32-51 of the Nonce field If the IPv4 packet containing the probe segment encodes the value 63 in the SEGID field, the ETE discards the segment; otherwise, it includes the segment as part of the normal reassembly procedure described above. Following successful reassembly, the ETE discards the trailing checksum (if present) and delivers the ULP to the IP layer. 3.6. ICMPv4 "Fragmentation Needed" Messages ITEs may receive ICMPv4 "fragmentation needed" error messages from middleboxes inside a tunnel, but are advised to consider such messages as "soft errors". Implementers are advised to consult [RFC1191][RFC2923][RFC4821] for operational recommendations on processing ICMPv4 "fragmentation needed" messages. 4. IANA Considerations The IANA is instructed to assign a code type for "reassembly/checksum error" under the ICMPv6 Parameter Problem message type in the "ICMPv6 Type Numbers" registry. 5. Security Considerations The nonce values in NI Reply messages from ETEs provide spoofing protection against off-path attackers. Templin Expires November 2, 2007 [Page 10] Internet-Draft Link Adaptation for Tunnels May 2007 6. Acknowledgments Earlier versions of this work attempted to cite all who made significant contributions over the years, but the list was far too extensive to capture. This work therefore acknowledges the mindshare of many contributors. There are still others to acknowledge whose vital contributions could never be expressed in tangible terms. 7. Appendix A: Additional Considerations ITEs can use the probing mechanism described in Section 3.3 as a general-purpose method for eliciting acknowledgements from an ETE if improved reliability at the expense of additional overhead is desired. The equal size restriction for non-final segments and non-overlapping restriction for all segments in packet chains provides a significant simplification for reassembly algorithms [RFC0815]. Use of the link adaptation mechanisms specified in this document may lead to an overall increase in short chains of small packets in the Internet. Network administrators are advised to follow the recommendations in [RFC3150] to minimize packet loss and packet reordering. Also, overly-long packet chains should be avoided if possible due to interactions with Active Queue Management (AQM) in the network. Since link-layer CRC-32 checks normally occur on each segment in the path, most errors detected during ULP reassembly are due to packet splices and/or errors in the data path between the NIC hardware and the reassembly buffer. The Fletcher-32 checksum algorithm has been shown to provide an effective edge-to-edge error detection capability for such errors [STONE]. The Fletcher-32 checksum is also dissimilar from both CRC-32 and the Internet checksum used by many upper layer protocols, thereby decreasing the likelihood of undetected errors. Some upper layer packetization protocols (e.g., NFS) may generate fixed payload sizes and rely on the network layer to deliver the payloads either as whole IP packets or as chains of IP fragments. Since NFS performance (and the performance of other upper layer packetization protocols) is sensitive to packet handling overhead, implementations should periodically attempt to increase the SEGSIZE through probing even if initial probe attempts fail. Templin Expires November 2, 2007 [Page 11] Internet-Draft Link Adaptation for Tunnels May 2007 8. Appendix B: Changes (Note to RFC Editor - please remove this section before publishing as an RFC.) Changes since -03: o Clarified that mechanisms cover IPv6-in-(foo)-in-IPv4; not just IPv6-in-IPv4. o New terminology for ITE/ETE o Clarifications to layering model o Replaced RA with NI Reply as probe response o Reduced SEGID to 6 bits and increased ULPID to 8 bits o IPv6 flow label RFC cited Changes since -01, -02: o Updated references Changes since -00: o Defined new coding of segmentation/reassembly info in the IPv4 Identification field o Changed "tunneling mechanism" to "tunnel endpoint" o Clarified text on trailing checksums o general document cleanup; removed "additional considerations" that no longer apply 9. References 9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Templin Expires November 2, 2007 [Page 12] Internet-Draft Link Adaptation for Tunnels May 2007 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [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. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. 9.2. Informative References [AARNET] "AARNet: Network: Large MTU: Size, http:// www.aarnet.edu.au/engineering/networkdesign/mtu/ size.html", April 2007. [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful, In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology.", August 1987. [GIGE] Dykstra, P., "Gigabit Ethernet Jumboframes (And Why You Should Care), http://sd.wareonearth.com/~phil/jumbo.html", December 1999. [I-D.heffner-frag-harmful] Heffner, J., "IPv4 Reassembly Errors at High Data Rates", draft-heffner-frag-harmful-04 (work in progress), January 2007. [JAIN] Jain, R., "Error Characteristics of Fiber Distributed Data Interface (FDDI), http://www.cse.wustl.edu/~jain/papers.html", August 1990. [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1626] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, May 1994. [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation Templin Expires November 2, 2007 [Page 13] Internet-Draft Link Adaptation for Tunnels May 2007 over ATM Adaptation Layer 5", RFC 2684, September 1999. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001. [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. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [STONE] Stone, J., "Checksums in the Internet (Stanford Doctoral Dissertation)", August 2001. [WLAN] Society, I., "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Computer Society, ANSI/IEEE 802.11, 1999 Edition.". 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 November 2, 2007 [Page 14] Internet-Draft Link Adaptation for Tunnels May 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 November 2, 2007 [Page 15]