RE: Link Adaptation for IPv6-in-IPv4 Tunnels

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

Hello Fred,

A while back, we had an exchange on the v6ops list regarding
a proposal for doing link adaptation over IPv6-in-IPv4 tunnels.
Your comments pointed out a glaring error that is (hopefully)
fixed now. See:

 http://www.ietf.org/internet-drafts/draft-templin-linkadapt-01.txt

Although the gist of the ensuing discussion was that the
document could not be worked out of v6ops since it proposes
a new mechanism/protocol, one angle we did not explore was
whether it could be contributed as an extension to an
*existing* v6ops work item.

In particular, what the link adapation work proposes could
make for a natural extension to "Basic Transition Mechanisms"
(i.e., draft-ietf-v6ops-mech-v2-07) and would in fact complete
that work in such a way that other transition mechanisms that
cite [MECH] can also take advantage of the larger MTUs.

Can this work be contributed as an extension to [MECH]?

Fred
fred.l.templin@boeing.com  

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Wednesday, August 31, 2005 4:01 PM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org
> Subject: Re: RE: 
> 
> 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.
> 
> On Aug 31, 2005, at 3:29 PM, Templin, Fred L wrote:
> 
> > 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.
> >>
> >
>