[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
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]