Re: [v6ops] PMTUD forever, was: MTUs on the general Internet

["Templin, Fred L" <[e-mail]>]

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Jeroen Massar
> Sent: Friday, December 05, 2014 5:40 AM
> To: Philip Homburg
> Cc: [e-mail] WG
> Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> 
> 
> Please doc this 'frag on the layer below' idea with the pros and cons it
> has, would be a good informational document; but likely that will see
> little global/large deployment due to the cons.

You are misunderstaing; we are talking about a little bit of fragmentation
that should be turned off as soon as possible. That will happen as more
and more links set MTUs larger than 1500.

> On 2014-12-05 14:32, Philip Homburg wrote:
> > In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote:
> >> On 2014-12-05 12:00, Philip Homburg wrote:
> >>> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet,
> >>> not the inner (IPv6) packet.
> >>
> >> Not only tunnels have a lower MTU. Just adding an extension header
> >> somewhere and you already lower the payload size.
> >
> > In the current internet, PMTU is quite broken. Not completely broken, but enough
> > to be noticeable. Extension headers are also routinely filtered.
> >
> > So if you don't want to much pain, you avoid PMTU and extension headers.
> 
> I've been using PMTU successfuly for over 15 years.

I'm surprised no one has mentioned this yet, but any node on the Internet
can send a forged PTB message; it doesn't even need to spoof the source
address. Fernando Gont raises this concern in his "atomic fragments" doc.

> Only recently there where two events where a middle box was broken as
> they do not comply to the IPv6 specification (they ignore ICMPv6).
> 
> All other instances of PMTU issues are easily classified as either:
>  - misconfigurations
>  - rate limitting
> 
> Yes. These are problematic. Not much one can do about as these involve
> people and physical limits.
> 
> >> Doing fragmentation means sending at least two packets, maybe one gets
> >> lost, what to do, resend, wait? Note that most tunneling protocols do
> >> not resend data (unless they run over TCP and then TCP handles it).
> >
> > Locally, i.e. between my CPE and my tunnel endpoints the loss rate of IPv4 packets
> > in general is way lower than losses caused by PMTU discovery.
> >
> > So this is good trade off. By the time PMTU discovery is essentially perfect
> > it may be time to reconsider.
> 
> PMTU will never be 'perfect' as well, humans...
> 
> >> It also pushes the burden of refragmentation towards the receiver of the
> >> packet, which suddenly becomes open to a fragmentation attack, which is
> >> likely not what they will want to see happening (enough crap gets send
> >> to those boxes already because someone is misbehaving on IRC).
> >
> > If somebody wants to DoS my CPE, they can just do that. No need to try a
> > fragmentation attack.
> 
> The CPE is not the typical target, but the endpoint where your tunnel
> terminates likely is.
> 
> And of course we are not talking about a single user setup here, or even
> 10 people using the same setup. Scale up to a few thousand.
> 
> >> Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe
> >> to use for tunneling and other constructs where one does not have a full
> >> Ethernet MTU.
> >
> > And then somebody starts a VPN that goes over a tunnel somewhere and we are back at
> > square one.
> 
> Then they should not do that or let that VPN support the fragmentation.
> 
> > Furthermore, unless you can somehow get all hosts on the internet to use a 1280 MTU,
> > your tunnel will cause PMTU problems.
> 
> Forcing a singular MTU is not a proper solution. Your proposal forces
> everybody to 1500.

No, the idea is to make sure *all* 1500s get through while at the same time
allowing larger packets through as long as they can make it without any
fragmentation. No more tunnel MTU clamping.

> And re-read your sentence above "then somebody starts a VPN that goes
> over a tunnel"... ;)

Tunnels within tunnels, yes. That is why the solution needs to work recursively.

> > Way more than a decade after ethernet devices first started supporting jumbograms,
> > most ethernets are still at 1500. So the most sane way to avoid PMTU problems is
> > to run all links at a 1500 octet MTU.
> 
> Exactly a major reason for not having a fixed MTU: you will fix the
> whole network to that MTU and it will never be able to change.

Correct - no fixed upper bound. But, a 1500 lower bound.

> Thus while your proposal is a reasonable solution it does not solve
> anything, it just avoids it (and with big penalties at that).
> 
> >> Just sticking everywhere to 1500 is not a solution. Unless one wants to
> >> define the minimum MTU for IPv6 as 1500. It is still a minimum and there
> >> are speakers out there that do 9000 with ease, just not intra-AS, and
> >> intra-AS is where these kind of PTB and ICMP ratelimiting problems
> >> exist: in somebody elses network.
> >
> > The only practical MTU on the internet is currently 1500. Locally you can go
> > higher or lower.
> 
> By fixing the MTU like you propose we will be stuck with an 1500 MTU
> forever. Lets not go there.

No more tunnel MTU clamping, as above. 1500 is only the *minimum*.

Thanks - Fred
[e-mail]

> Greets,
>  Jeroen
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops