RE: Link Adaptation for IPv6-in-IPv4 Tunnels

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

Fred,

One additional point is that there is built-in support for backwards
compatibility. There is a means for the tunnel encapsulator to learn
whether the decapsulator implements the new method (and revert to the
old method otherwise) and a means for the decapsulator to learn whether
the encapsulator implements the new method (again, reverting to the
old method otherwise).

But my intention in bringing this up is simply to explore the [MECH]
angle; not to dogmatically push for v6ops adoption.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Friday, September 23, 2005 9:24 AM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org
> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels 
> 
> 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.
> 
> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> 
> > Can this work be contributed as an extension to [MECH]?
> >
>