Hi, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Erik Nygren > Sent: Friday, June 28, 2013 8:36 AM > To: Brian E Carpenter > Cc: 6man > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt > > If we accept that 1280 is the only non-broken MTU for IPv6, I share > James' fear that this would spell doom for IPv6 on the broad Internet > and land us in a world where broad IPv6 adoption stalls out and IPv4 > ith CGN dominates.
It doesn't have to be that way. With SEAL, packets up to 1500 get through no matter what, and larger packets also get through if the path MTU is sufficiently large. > The current reality is that many hosts do have > 1500 byte MTUs (as Tore observed with many of the top Alexa sites, and > presumably also with the default configuration for many hosts out > there). We need to make sure that this current reality keeps working. > > If content providers need to drop their IPv6 MTU/MSS down below that > of IPv4 (eg, to 1280), this has the potential to be enough of a > performance difference (even a few percent matters!) to cause many > content providers to hold off indefinitely on dual-stacking. If large > ISPs or enterprises need to find some way to get their end users down > to lower MTUs or need to wait for some OS updates to do some other > form of PMTU discovery, then IPv6 is DOA for them as well and they'll > have a good excuse to not roll out out. > > As such, I agree with other comments that it's important > to re-emphasize that any environment that both blocks ICMPv6 PTB > and at the same time doesn't allow 1500 byte packets through is broken > and needs to get fixed. This also means that anyone deploying > or implementing a tunnel (or VPN) needs to carefully consider > how they'll deal with this. Right. Tunnels over IPv6 absolutely require some form of frag/reass to meet the IPv6 minMTU of 1280. SEAL goes it one better and ensures that everything up to 1500 makes it through. > For fragments themselves, would it make more sense to constrain > their usage rather than deprecate them entirely? For example, > express that certain headers may not appear in fragments, > and also perhaps express that overlapping fragments or overly > spase fragments are likely to be dropped? I think the question has been raised as to whether standard IPv6 frag/reass can be re-worked now that it is already in widespread deployment. SEAL fixes these and other issues and also has the advantage that it doesn't yet have a widespread deployed base. Thanks - Fred fred.l.temp...@boeing.com > In looking at a global end-user facing HTTP (TCP) environment, > I'm seeing around 0.0005% of the packets arrive as fragments > which sounds similar to some of the other numbers on this thread. > > Erik > > > > On Tue, Jun 25, 2013 at 7:48 PM, Brian E Carpenter > <brian.e.carpen...@gmail.com> wrote: > > On 26/06/2013 11:08, james woodyatt wrote: > >> On Jun 25, 2013, at 13:13 , Randy Bush <ra...@psg.com> wrote: > >>> ron has made one suggestion. though brutal, its simplicity and its > >>> recognition of reality appeal to me. > >> > >> Why not go large and deprecate all of RFC 2460? > >> > >> I'm not entirely joking. If the practical global MTU for IPv6 is > 1280, ... > > > > We went through a protracted phase where the practical global MTU > > for IPv4 was around 512, unless you wanted to reconfigure your laptop > > stack experimentally each time you checked into a hotel and figured > > out how to connect to the phone line. I even recall having to set the > > MTU to 256 in one hotel. We may well have to accept a protracted > phase > > of 1280 for IPv6. Eventually it will resolve itself, as it did for > IPv4. > > I think that's orthogonal to the question of deprecating L3 > fragmentation. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
