[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: New Version Notification	for draft-bonica-6man-frag-deprecate-00.txt
From:       "Templin, Fred L" <Fred.L.Templin () boeing ! com>
Date:       2013-06-28 22:44:32
Message-ID: 2134F8430051B64F815C691A62D983180B02A3 () XCH-BLV-504 ! nw ! nos ! boeing ! com
[Download RAW message or body]

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Friday, June 28, 2013 3:26 PM
> To: Templin, Fred L
> Cc: james woodyatt; 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
> 
> On 29/06/2013 09:03, Templin, Fred L wrote:
> > Hi Brian,
> >
> >> Let's face it, this train left the station a while back. (This
> doesn't
> >> mean I'm happy, but it is what it is.)
> >
> > Do you mean that you want to give up and declare that the fixed
> > MTU for IPv6 is 1280 now and for always (and remember, that still
> > would not excuse tunnels from using frag/reass)?
> 
> No. I believe that (a) strongly recommending packetizatiion layer
> PMTUD and deprecating fragmentation at source is a sound long
> term policy

No disagreement here.

> and (b) accepting that strapping the MTU at 1280 is
> a reasonable short term policy. If (a) progressively pervades
> the installed base then (b) can be dropped as the years go by.

Once a link sets a 1280 MTU, how will it know that it is now
safe to increase the MTU? And, once set, how can we expect
operators to go back and re-set in the future. IMHO, strapping
the MTU to 1280 everywhere now would become ossified long into
the future.

> (Though frankly I have never seen MTU problems in v6 since I stopped
> trying to use 6to4; I've used three different configured tunnel
> solutions, and various native services, without problems. So while
> there are clearly paths with this problem, I suspect they're a minority
> even today.)
> 
> > I still think the situation can be salvaged with something like SEAL,
> > but if we want to just give up then I think I agree with others that
> > we may need to increment the IP protocol version (I for one would not
> > like to see that).
> 
> In effect using SEAL is part of (a), for the cases where tunels
> are used, isn't it?

I was originally thinking about SEAL for just tunnels, but the
realization I am coming to is that it can also be used anywhere
the IPv6 fragmentation header can be used - i.e., both tunnel
and transport modes are possible. That includes use with "atomic
fragments" and assurance that the ULP headers are contained in
the first fragment. Think of deprecation of the IPv6 fragment
header as giving way to a new method that fixes fragmentation,
i.e., the same as deprecation of site local gave way to ULA.

> Talk of changing the version number doesn't have much to do with
> the world that I live in. We have plenty of experience now of
> how easy it isn't to change the version number.

It was a poor pun on my part, and not something I would advocate.
I do not mean to offend all of the contributors who have worked
long and hard to move IPv6 forward.

Thanks - Fred
fred.l.templin@boeing.com

>    Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]