[no subject]

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Fred,

Agree that moving fragmentation bits to an ULP header would
constitute a new IP protocol, however I believe there are other
alternatives which would not. One way would be to perform host-
based vanilla IPv4 fragmentation at the tunnel encapsulator (and
set the DF flag in each fragment) but that has the limitation that
often only first-fragments of fragmented datagrams are able to pass
through firewalls and NATs.

Another method would be to define a new form of IPv4 fragmentation
("Type-2 IPv4 fragmentation") that works as follows:

  - at the tunnel encapslator:
    - fragment packets into segments no larger than the IPv4 path MTU
      minus protocol headers. Each segment is encapsulated in an IPv4
      header *plus* the protocol header indicated by the ip-protocol
      field.
    - set the DF flag in the encapsulating IPv4 header of each fragment
      and set the MF flag in each fragment except the final one. Also,
      set the Reserved fragmentation flag in each fragment to indicate
      Type-2 IPv4 fragmentation.
    - Redefine the 16-bit IPv4 Identification field as an 11-bit ID in
      the least-significant bits and a 5-bit Segment number in the most
      significant bits. For each segment in a multi-segment packet, the
      value in the ID field would be the same, and the value in the
      Segment field would encode 0, 1, 2, etc. up to 31.
    - Set the 13-bit Fragment Offset field to 0 in each fragment 
  - at the tunnel decapsulator, intercept Type-2 IPv4 fragments
    before they are handled by the vanilla IPv4 reassembly engine
    and reassemble them accordingly 

This Type-2 IPv4 fragmentation would only be supported by tunnel
decapsulators that provide instrumentation to intercept fragments
with the Reserved flag set, but encapsulators could probe to detect
whether individual decapsulators are "Type-2 enabled" and drop back
to the default behavior for those that do not. Type-2 fragmentation
also has the feature that each fragment in a multi-fragment tunneled
packet would appear to the network as though it were a first-fragment
since the ULP header is included and the Fragment Offset field is
zero in each fragment, so all fragments would pass through firewalls
and NATs.

In terms of v6ops charter requirements, Type-2 IPv4 fragmentation
would not introduce any new header fields outside of the IPv4 header
and would be used with pre-existing protocols that already have
ip-protocol numbers assigned in the registry.

So, can we call this a new (extension, mechanism, method, etc.)
instead of a new protocol and run it past the v6ops charter again?

Fred
fred.l.templin@boeing.com   



> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Friday, August 26, 2005 3:14 PM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org
> Subject: Re: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item?
> 
> yup, it's a protocol.
> 
> We're not chartered to do protocols; in fact, our charter  
> specifically says we are NOT to do protocols. I'm going to have to  
> ask you to take it elsewhere. I'd suggest a discussion with 
> the AD as  
> to where he would recommend it go.
> 
> On Aug 26, 2005, at 2:57 PM, Templin, Fred L wrote:
> 
> >  instead of (re)using the IPv4 header
> > bits as currently specified, a small (8 bytes or less) L2.5
> > header that sits above the IPv4 header could be defined with:
> >
> >   - a segment ID field (i.e., instead of using the
> >     fragment offset bits as in the current draft)
> >   - a "more fragments" bit
> >   - flow identifier fields
> >   - a next header field
> >   - etc.
> >
>