Subject: RE: Link Adaptation for IPv6-in-IPv4 Tunnels

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Sep 2005 09:04:43 -0700

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

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, August 31, 2005 4:01 PM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; [email-masked]
> 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
> > [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: Fri, 23 Sep 2005 09:24:09 -0700

Does it still propose a protocol or protocol change?

I don't know offhand whether the charter of v6ops then precluded  
protocol work, and won't go into whether it was proper for [MECH] to  
be done in v6ops. Given the present charter, I can treat it as a  
requirements document that may be asking for something like the work  
you are proposing. But my read of the document you pointed to is that  
it is still proposing an incompatible change (as in "unchanged  
equipment will not perform the function and once the message is  
segmented in this fashion it must be reassembled in this fashion.

I think that has to be done in a WG chartered to do non-backward- 
compatible changes to IPv4.

---

From: Sebastien Roy <[email-masked]>
Date: Tue, 27 Sep 2005 18:50:34 -0400

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

Could this method also be used for IPv4-in-IPv4 tunneling?  I don't see
why the document restricts the algorithm to IPv6-in-IPv4, but I may be
missing something.
-Seb