Subject: RE:

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 Aug 2005 15:29:20 -0700

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
[email-masked]   

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 3:18 PM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; [email-masked]
> 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.
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 Aug 2005 16:00:54 -0700

no, it doesn't, for two reasons.

First, in a best effort network, it is invalid to presume that order  
will be preserved in the network.

Second, changing the identifier field in IPv4 from 16 bits to 10 and  
using the remaining bits to indicate something else is a change to  
the identifier field in IPv4. RFC 791 and RFC 1122 merely specify  
that the identifiers should be locally unique within a field of time,  
not that they have certain characteristics from which other  
functionality may be deduced.

I really not trying to be a pain here, but you really need to take  
this to a working group that does protocols, and specifically in this  
case, does changes to IPv4. v6ops can develop requirements for such a  
protocol if you like, but the protocol work needs to be done  
somewhere appropriate to the protocol.