RE: Meta-issues: On the deprecation of the fragmentation function

["Templin, Fred L" <[e-mail]>]

Hi,

> A quick read of Section
> 4 of my new draft should be all you need to understand
> what I'm talking about:
> 
>   http://tools.ietf.org/html/draft-generic-6man-tunfrag-08

Here is the text I'm talking about so I won't have to keep
repeating myself:

Thanks - Fred
[e-mail]

---

4.  IPv6 Tunnels

   IPv6 tunnels are used for many purposes, including transition,
   security, mobility, routing control, etc.  While it is assumed that
   transition mechanisms will eventually give way to native IPv6, it is
   clear that the use of tunnels for other purposes will continue and
   even expand.  A long term strategy for dealing with tunnel MTUs is
   therefore required.

   Tunnels may cross links (perhaps even other tunnels) that configue
   only the IPv6 minMTU of 1280 bytes while the tunnel ingress must be
   able to send packets that are at least 1280 bytes in length so that
   the IPv6 minMTU is extended to the source.  However, these tunneled
   packets become (1280 + HLEN) bytes on the wire (where HLEN is the
   length of the encapsulating headers), meaning that they would be
   vulerable to loss at a link within the tunnel that configures a
   smaller MTU.  Therefore, the only way to satisfy the IPv6 minMTU is
   through network layer fragmentation and reassembly between the tunnel
   ingress and egress, where the ingress fragments its tunneled packets
   that are larger than (1280 - HLEN) bytes.

   Unfortunately, fragmentation and reassembly are a pain point for in-
   the-network routers - especially for those that are nearer the core
   of the network.  It is therefore highly desirable for the tunnel
   ingress to discover whether this fragmentation and reassembly can be
   avoided.  This can only be done by allowing the ingress to probe the
   path to the egress by sending whole 1500 byte probe packets to
   discover whether the probes can be delivered to the egress without
   fragmentation.  These 1500 byte probes appear as (1500 + HLEN) bytes
   on the wire, therefore the path must support an MTU of at least this
   size in order for the probe to succeed.

   The tunnel fragmentation and reassembly strategy is therefore as
   follows:

   1.  When the tunnel ingress receives a packet that is no larger than
       (1280-HLEN) bytes, it encapsulates the packet and sends it to the
       egress without fragmentation.  The egress will receive the packet
       since it is small enough to fit within the IPv6 minMTU of 1280
       bytes.

   2.  When the tunnel egress receives a packet that is larger than 1500
       bytes, it encapsulates the packet and sends it to the egress
       without fragmentation.  If the packet is lost in the network due
       to a size restriction, the ingress may or may not reeceive a PTB
       message which it can then forward to the original soruce.
       Whether or not a PTB message is received, however, it is the
       responsibility of the original source to ensure that its packets
       larger than 1500 bytes are making it to the final destination by
       using a path probing technique such as specified by [RFC4821].

   3.  When the tunnel ingress receives a packet larger than (1280 -
       HLEN) but no larger than 1500 bytes, and it is not yet known
       whether packets of this size can reach the egress without
       fragmentation, the ingress encapsulates the packet and uses
       network layer fragmentation to fragment it into two pieces that
       are each signifiicantly smaller than (1280 - HLEN) bytes.  At the
       same time, the tunnel ingress sends an unfragmented 1500 byte
       probe packet toward the egress (subject to rate limiting) which
       will appear as (1500 + HLEN) bytes on the wire.  If the egress
       receives the probe, it informs the ingress that the probe
       succeeded.  If the probe succeeds, the ingress can suspend the
       fragmentation process and send packets between (1280-HLEN) and
       1500 bytes without using fragmentation.  This probing process
       exactly parallels [RFC4821].

   In this method, the tunnel egress must configure a slightly larger
   MRU than the minMRU specified for IPv6 in order to accommodate the
   HLEN bytes of tunnel encapsulation during reassembly. 2KB is
   recommended as the minMRU for this reason.

   These procedures give way to the ability for the tunnel ingress to
   configure an unlimited MTU (theoretical limit is 2^16 bytes for IPv4
   and 2^32 bytes for IPv6).  They will therefore naturally lead to the
   Internet migrating to larger packet sizes with no dependence on
   traditional path MTU discovery.  Operators will also soon discover
   that configuring larger MTUs on links between routers (e.g., 2KB or
   larger) will dampen the fragmentation and reassembly requirements
   until fragmentation and reassembly usage is gradually tuned out of
   the network.

   These procedures are not supported by the existing IPv6 fragmentation
   procedures, however they are exactly those specified in the
   Subnetwork Encapsulation and Adaptation Layer (SEAL)
   [I-D.templin-intarea-seal].  Widespread adoption of SEAL will
   therefore naturally lead to an Internet which no longer places MTU
   restrictions on tunnels and therefore supports natural migration to
   unbounded packet sizes.

---