Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational October 2, 2007 Expires: April 4, 2008 Simple Packetization and Reassembly for IP/*/IP Tunnel Endpoint MTUs (sprite-mtu) draft-templin-inetmtu-02.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 April 4, 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/*/IP tunneling mechanisms impose an encapsulation overhead that can reduce the effective path MTU to smaller values. Additionally, existing tunneling mechanisms are limited in their ability to support larger MTUs. This document specifies simple packetization and reassembly for IP/*/IP tunnel endpoint MTUs (sprite-mtu). Templin Expires April 4, 2008 [Page 1]
Internet-Draft sprite-mtu October 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. End-to-End MTU Determination . . . . . . . . . . . . . . . . . 4 5. Tunnel Interface MTU . . . . . . . . . . . . . . . . . . . . . 4 6. Tunnel Soft State . . . . . . . . . . . . . . . . . . . . . . 4 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Conceptual Sending Algorithm . . . . . . . . . . . . . . . 5 7.2. Inner Packet Fragmentation . . . . . . . . . . . . . . . . 6 7.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 7.4. Outer Packet Fragmentation . . . . . . . . . . . . . . . . 8 7.5. Sending Packets . . . . . . . . . . . . . . . . . . . . . 9 7.6. Tunnel Recursion . . . . . . . . . . . . . . . . . . . . . 9 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 9 8.1. IPv4 Reassembly Cache Management . . . . . . . . . . . . . 9 8.2. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 9 8.3. Receiving Packet Too Big (PTB) Errors . . . . . . . . . . 10 9. 'minMTU' Determination . . . . . . . . . . . . . . . . . . . . 10 9.1. Sending Sprites . . . . . . . . . . . . . . . . . . . . . 10 9.2. Receiving (Sprite-)Replys . . . . . . . . . . . . . . . . 11 9.3. Receiving Sprites . . . . . . . . . . . . . . . . . . . . 11 9.4. Sending Sprite-Replys . . . . . . . . . . . . . . . . . . 11 10. 8-bit Fletcher Checksum Calculation . . . . . . . . . . . . . 11 11. Updated Specifications . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 15.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Templin Expires April 4, 2008 [Page 2]
Internet-Draft sprite-mtu October 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, packets can be dropped due to an MTU restriction on the path. Upper layers see IP/*/IP 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 simple packetization and reassembly for IP/*/IP tunnel endpoint MTUs (sprite-mtu). It updates the functional specifications for Tunnel Endpoints (TEs) found in existing tunneling mechanisms (see: Section 11). 2. Terminology The following abbreviations and terms are used in this document: IPv4 - Internet Protocol, Version 4 [RFC0791] IPv6 - Internet Protocol, Version 6 [RFC2460] IP - Internet Protocol, either Version 4 or Version 6 DF - the IPv4 header "Don't Fragment" flag ENCAPS - the size of the encapsulating */IP headers plus trailers minMTU - minimum MTU of the tunnel, in bytes MTU - Maximum Transmission Unit PTB - Packet Too Big error (either ICMPv4 [RFC1191] or ICMPv6 [RFC1981]) sprite/sprite-reply - a request/reply used for minMTU probing TE - Tunnel Endpoint TFE - Tunnel Far End Templin Expires April 4, 2008 [Page 3]
Internet-Draft sprite-mtu October 2007 TNE - Tunnel Near End IP/*/IP - an IP packet encapsulated in */IP headers (e.g. for "*" = NULL, UDP, TCP, AH, ESP, etc.) inner packet/header/payload - an IP packet/header/payload before IP/*/IP encapsulation. outer packet/header/payload - a */IP packet/header/payload after IP/*/IP encapsulation. 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. Concept of Operation TEs that implement this scheme engage in a continuous probing process by sending "sprites" and "sprite-replys" while data is flowing to determine and maintain a minimum MTU for the tunnel. When the flow of data through the tunnel is suspended, the probing process is discontinued. Under normal conditions, only the TNE need implement the scheme, therefore deployment can occur independently of deployment on the TFE. Under extreme conditions, performance is enhanced when both TEs implement the scheme. 4. End-to-End MTU Determination This specification assumes that original sources that send unfragmentable packets larger than 1500 bytes will use end-to-end MTU determination per [RFC4821]. 5. Tunnel Interface MTU TEs should configure an MTU on the tunnel interface that is at least as large as (linkMTU - ENCAPS) for the largest linkMTU for all interfaces over which the tunnel is configured. 6. Tunnel Soft State TEs maintain the following per-TFE conceptual variables as soft state: Templin Expires April 4, 2008 [Page 4]
Internet-Draft sprite-mtu October 2007 minMTU the current minimum MTU for the tunnel, discovered through probing to determine the largest size outer packet/fragment that can traverse the tunnel. (See: [RFC3819], Section 2 for subnetwork MTU recommendations that influence 'minMTU'.) Initial and minimum value: 128 bytes for */IPv4 tunnels; 1280 bytes for */IPv6 tunnels. isExtreme boolean indicating whether the tunnel traverses a path with an extremely small MTU. Initial value: TRUE. isQualified boolean indicating whether the TFE implements the scheme. Initial value: FALSE. 7. Sending Packets TEs that implement this scheme use the specifications for sending packets found in the following sections: 7.1. Conceptual Sending Algorithm Packets that are larger than the tunnel interface MTU are dropped with a packet too big (PTB) sent back to the original source as for any IP interface. For other packets, TEs use the conceptual sending algorithm found in Figure 1: Templin Expires April 4, 2008 [Page 5]
Internet-Draft sprite-mtu October 2007 if inner packet is larger than ('minMTU' - ENCAPS) and inner packet is not a sprite (see: Section 9.1) if inner packet is not fragmentable (see: Section 7.2) if inner packet is larger than 1500 bytes if inner packet is larger than the underlying linkMTU minus ENCAPS Send PTB appropriate to the inner protocol with MTU = (MAX('minMTU', linkMTU) - ENCAPS). Drop packet and return. else Encapsulate as an outer packet (see: Sect. 7.3). Send packet and return (see: Section 7.5). endif else Send PTB appropriate to the inner protocol with MTU = ('minMTU' - ENCAPS). Drop packet and return. endif else Fragment inner packet into fragments no larger than ('minMTU' - ENCAPS) (see: Section 7.2). endif endif foreach inner packet/fragment Encapsulate as an outer packet (see: Section 7.3). Fragment outer packet if necessary (see: Section 7.4). Send packet(s)/fragment(s) (see: Section 7.5). endforeach Figure 1: Conceptual Sending Algorithm 7.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 unfragmented IPv6 packet no larger than 1280 bytes with a fragment header, etc. Per the conceptual sending algorithm, the TE uses the IP fragmentation mechanism of the inner protocol to fragment inner packets into fragments no larger than ('minMTU' - ENCAPS). Note that for IPv6/*/IPv4 tunnels, ('minMTU' - ENCAPS) may not be large enough to accommodate the minimum IPv6 MTU such that the TE may be required to drop an unfragmentable inner IPv6 packet of 1280 bytes or smaller and return an ICMPv6 PTB with an MTU value less than 1280 bytes. The original IPv6 source will then set the path MTU to 1280 bytes and include a fragment header in subsequent IPv6 packets. The TE can then perform IPv6 fragmentation using the fragment header included by the source per [RFC2460], Section 5. Templin Expires April 4, 2008 [Page 6]
Internet-Draft sprite-mtu October 2007 7.3. Encapsulation TEs encapsulate inner IP packets according to the specific IP/*/IP document. During encapsulation the TE also appends a trailer (if necessary) that includes zero or more zero-padding bytes and a 4-byte trailing "footer" immediately following the inner IP packet. 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, the outer IPv6 length field for IPv6/IPv6 tunnels, etc. The encapsulation is shown in Figure 2: +---------------------------------+ | Outer IP Header | | | +---------------------------------+ | * 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 */IP protocol trailers ... +------------------------------ Outer Packet Figure 2: Encapsulation Format with Trailer For all packets that include a trailer, the footer is encoded as the final 4 bytes and is byte-aligned only, i.e., it need not be aligned on an even word/longword/etc. boundary. The footer format is shown in Figure 3: 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 Templin Expires April 4, 2008 [Page 7]
Internet-Draft sprite-mtu October 2007 Version (4 bits) The Version field indicates the format of the trailer. This document describes version 4. Type (4 bits) The type of encapsulated packet. The following types are defined: 0 - ordinary data packet. 1 - sprite 2 - sprite-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 sprite and sprite-reply packets, as well as in all IPv4 data packets that are sent as 2 fragments. For other data packets, 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 first 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 (not counting the 4 byte footer). The TE then calculates the 8-bit Fletcher checksum as specified in Section 10 and encodes the results in the Fletcher A and B fields of the footer. The TE finally sets Version=4 and Type=0, 1, or 2 according to the type of packet being encapsulated (i.e., for ordinary data, sprite or sprite-reply packets, respectively). 7.4. Outer Packet Fragmentation For IP/*/IPv4 tunnels, when 'isExtreme' is TRUE and the encapsulated packet is not a sprite, the TE fragments the packet into 2 outer IPv4 fragments of 68 bytes or smaller using IPv4 fragmentation. Templin Expires April 4, 2008 [Page 8]
Internet-Draft sprite-mtu October 2007 7.5. Sending Packets For IP/*/IPv4 tunnels, the TE sets DF=1 in the outer IPv4 header of all packets. When 'isExtreme' is TRUE and 'isQualified' is FALSE, the TE must maintain a window that limits the number of data packets admitted into the tunnel to avoid IPv4 reassembly misassociations according to the reassembly timeout recommendations in [RFC1122], Section 3.3.2. The TE is permitted to relax this windowing limitation after either 'isExtreme' is set to FALSE or 'isQualified' is set to TRUE. For IP/*/IPv6 tunnels, there is no requirement for the TE to institute windowing limitations since the IPv6 fragment header includes a 32bit Identification field. 7.6. Tunnel Recursion For IP/*/IPv4 tunnels, even when 'isExtreme' is TRUE, recursively- nested encapsulations within IPv4 can extend indefinitely due to the minimal outer fragmentation and reassembly used under extreme conditions. For IP/*/IPv4 tunnels, recursively-nested encapsulations within IPv6 impose a minimum of 40 bytes of header per encapsulation with no outer fragmentation possible such that the headers can overflow the available packet space with no room left for data. 8. Receiving Packets TEs that implement this scheme use the specifications for receiving packets found in the following sections: 8.1. IPv4 Reassembly Cache Management TEs SHOULD perform active management in their IPv4 reassembly cache, i.e., they should actively discard "stale" reassemblies that have no apparent opportunity for successful completion prior to the normal reassembly timeout expiration recommended in [RFC1122], Section 3.3.2. 8.2. Decapsulation When the TE receives (and, if necessary, reassembles) an encapsulated packet from a TFE for which 'isQualified' is TRUE, and the packet includes a trailing footer per Section 7.3 with an incorrect trailing checksum, the TE drops the packet. Otherwise, the TE decapsulates the packet exactly as specified in the appropriate IP/*/IP document. Templin Expires April 4, 2008 [Page 9]
Internet-Draft sprite-mtu October 2007 Note that the decapsulation automatically erases the trailer. 8.3. Receiving Packet Too Big (PTB) Errors TEs may receive PTB errors in response to any packets that were admitted into the tunnel. When the TE receives a PTB with an MTU value smaller than 'minMTU', it SHOULD reduce 'minMTU' and send sprites to determine a new 'minMTU'. It SHOULD also send a translated PTB back to the inner source if possible. Further strategies for handling PTB errors are specified in [RFC4821], Section 7. 9. 'minMTU' Determination TEs probe the path to determine a 'minMTU' for the tunnel by sending sprites and sprite-replys as specified in the following sections: 9.1. Sending Sprites TEs engage in a probing process while data is actively flowing through the tunnel to determine 'minMTU' by sending sprites to the TFE. TEs generate sprites by creating a minimum-sized echo request packet according to the inner IP protocol (e.g., an ICMPv6 [RFC4443] echo request) that includes identifying information such as sequence/ identification numbers, nonce values, sprite sizes, etc. that will be echoed in the reply. The TE then encapsulates the echo request with padding added to create a sprite of the desired size per Section 7.3 then sends the sprite into the tunnel. The TE SHOULD send a series of sprites of various sizes early in the tunnel lifetime to determine the largest possible 'minMTU' no smaller than (128 bytes for IPv4; 1280 bytes for IPv6) and up to (1500 + ENCAPS). The TE SHOULD NOT attempt to increase 'minMTU' to larger values, since this may interfere with end-to-end path MTU discovery. When the TE receives sufficient evidence through probing that the forward path supports a larger sprite size, it advances 'minMTU'. The SHOULD limit the rate at which it sends sprites, but SHOULD send them frequently enough to refresh 'minMTU'. The TE SHOULD set 'isExtreme' to TRUE and reduce 'minMTU' to the minimum value when minimum-sized sprites fail to produce replys. Additional probing considerations are specified in [RFC4821], Section 7. The TE SHOULD retain a cache of recently-sent sprites and use them to verify any resulting replys. The TE MAY discontinue the probing process and garbage-collect stale soft state for dormant tunnels. Templin Expires April 4, 2008 [Page 10]
Internet-Draft sprite-mtu October 2007 9.2. Receiving (Sprite-)Replys When a TE receives an encapsulated echo reply, it first determines whether the reply matches one of its sprites by examining any identifying information in the inner packet. If the echo reply matches one of the TE's sprites, the TE sets 'isExtreme' to FALSE and uses the sprite size for 'minMTU' determination. Otherwise, the TE decapsulates the echo reply and passes it to upper layers as for ordinary data. For echo replys that match one of the TE's sprites, the TE next verifies whether the reply is also a sprite-reply that was encapsulated per Section 7.3. For valid sprite-replys, the TE sets: 'isQualified' to TRUE for this TFE; otherwise it sets: 'isQualified' to FALSE. The TE then discards the packet. 9.3. Receiving Sprites When a TE receives an echo request that was encapsulated as a sprite per Section 7.3, it sends a sprite-reply. For ordinary echo requests, the TE decapsulates the packet and sends an ordinary echo reply. 9.4. Sending Sprite-Replys TEs send sprite-replys in response to sprites by creating an inner IP echo reply packet according to the inner IP protocol (e.g., an ICMPv6 echo reply [RFC4443]). The TE includes in the echo reply any identifying information that the TFE included in its echo request. The TE then encapsulates the echo reply as a sprite-reply per Section 7.3 and sends it into the tunnel. The TE SHOULD adopt a consistent behavior when responding to sprites, i.e., it should consistently send either well-formed sprite-replys or ordinary echo replys and should not, e.g., sometimes send sprite- replys and other times send echo replys. 10. 8-bit Fletcher Checksum Calculation The 8-bit Fletcher Checksum is discussed in [RFC1146][STONE1][STONE2] 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 Templin Expires April 4, 2008 [Page 11]
Internet-Draft sprite-mtu October 2007 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. 11. Updated Specifications This document updates the following specifications: o RFC2003 (IP-in-IP) o RFC2473 (Generic packet tunneling in IPv6) 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) o RFC4213 (Basic IPv6 Transition Mechanisms) o RFC4214 (ISATAP) o RFC4301 (IPSec) Templin Expires April 4, 2008 [Page 12]
Internet-Draft sprite-mtu October 2007 o RFC4302 (AH) o RFC4303 (ESP) o RFC4380 (TEREDO) o LISP o others.... 12. IANA Considerations The IANA is instructed to create a 'sprite-mtu' registry for the Version and Type values that occur in the footers of encapsulated packets per Section 7.3. 13. Security Considerations A possible attack vector involves an off-path attacker sending sprites with spoofed source addresses, however the legitimate sprites sent by a TE contain identifying information that is useful for defending against off-path attacks. Security considerations for specific IP/*/IP tunneling mechanisms are given in the respective documents. 14. Acknowledgments This work has benefited from discussions with Fred Baker, Iljitsch van Beijnum, Brian Carpenter, Steve Casner, Remi Denis-Courmont, Aurnaud Ebalard, Gorry Fairhurst, John Heffner, Christian Huitema, Joe Macker, Matt Mathis, Joe Touch and James Woodyatt. 15. References 15.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. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, Templin Expires April 4, 2008 [Page 13]
Internet-Draft sprite-mtu October 2007 November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 15.2. Informative References [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [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. [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. Templin Expires April 4, 2008 [Page 14]
Internet-Draft sprite-mtu October 2007 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 April 4, 2008 [Page 15]
Internet-Draft sprite-mtu October 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 April 4, 2008 [Page 16]