RE:

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

Fred,

What I suggested in my previous message was more dramatic
(and complicated) than what is really needed. If the tunnel
encapsulator simply defines for itself a coding for the
16-bit IPv4 Identification field such as the following:

    0                   1   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Identification   |A|Segment #|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

then the requirements of RFC 791 (and the others) are observed
and there is no change to IPv4.

The bits encoded in the field would include a 10-bit ID, a
1-bit Auxilliary fragmentation flag and a 5-bit Segment number
for use by the tunnel decapsulator to reassemble a packet that
was segmented according to the link adaptation spec. There is
no need for a "Type-2 IPv4 fragmentation", there is no need to
set the Reserved fragmentation bit and there is no interaction
with ordinary IPv4 fragmentation/reassembly regardless of the
setting of the DF bit.

All that is needed is for the decapsulator to have a means for
receiving the 16-bit Identification field intact following IPv4
reassembly and a means for the encapsulator to discover whether
the decapsulator implements the link adaptation scheme.

One concern is that the actual Identifier is shrunk down to
10 bits instead of 16, meaning that the degree of packet
reordering in the network should be such that packets are
rarely mis-ordered by more than 1024 places. This is part of
the motivation for using a checksum to detect packet splicing
errors such as suggested by the link adapatation document.

Does this help address your concerns regarding changes to IPv4
and defining new protocols?

Fred
fred.l.templin@boeing.com   

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Tuesday, August 30, 2005 3:18 PM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org
> Subject: Re: 
> 
> On Aug 29, 2005, at 7:30 PM, Templin, Fred L wrote:
> > So, can we call this a new (extension, mechanism, method, etc.)  
> > instead of a new protocol and run it past the v6ops charter again?
> 
> If it uses IPv4 fields but re-interprets them in a way that 
> RFCs 791,  
> 1122/3, 1812, 1349, and 2474 don't discuss, it is a change to 
> IPv4. I  
> would suggest discussing it in a working group that suggests  
> modifications to IPv4. If it's implemented in a header outside of  
> IPv4, it's a new protocol, and needs to be discussed in a WG that  
> deals with that.
>