Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpen...@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.temp...@boeing.com > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------