Subject: Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 9 Jul 2011 14:51:43 +0100

On 6 Jul 2011, at 22:52, Sabahattin Gucukoglu wrote:
On 6 Jul 2011, at 19:03, james woodyatt wrote:
>> You're invited to file a report with <http://bugreport.apple.com> about this.  Be sure to explain why fixing the broken path MTU discovery in the network is not an option and requiring the AirPort user to know enough about IPv6 router advertisement MTU options to set the value properly is an appropriate mitigation.
> 
> Thank you, and what should the severity of the bug be?

This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping.  Severity 2.

Hurricane Electric very generously lowered my tunnel's MTU to 1476 bytes IPv6 payload, so I'm now back on the IPv6 Internet again.  (Yay!)

There is still one important detail to clear up, though.  My ISP, BT Infinity Business in the UK, seems to be ensuring that its links do not overflow by "Clamping" the MSS option in TCPv4 SYN packets to 1400, and no sight of ICMPv4 "Datagram too large and DF set" messages.  Can I take it for granted that you didn't choose the same value, or do a similar terrible thing, in the Airport products?  I don't have any other PPPoE servers to try it on.

Cheers,
Sabahattin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 10 Jul 2011 14:52:49 +0200

> This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping.  Severity 2.

THIS IS A BAD IDEA.

MSS clamping is modifying packets exchanged between consenting hosts. As a rule the network doesn't get to do this. Unfortunately the situation with IPv4 is so bad that it's not realistically possible to avoid this when you have a path MTU smaller than 1500.

But with IPv6 we have a new chance to punish the people creating the problem rather than the ones implementing PMTUD properly, so The Right Thing To Do is NOT fix any PMTUD breakage in properly behaving systems, but rather push people that configure their systems incorrectly to fix this. And it seems to be working, PMTUD black holes happen with IPv6, but they're relatively rare.

Advertising MTUs smaller than 1500 when the uplink has an MTU smaller than 1500 is completely unnecessary because IPv6 has good path MTU discovery and doing this also limits the size of packets exchanged locally.

Advertising an MTU of 1500 is also not proper behavior, BTW.

However, I do think that it's a good idea for makers of home routers to allow users to set the MTU advertised in RAs to anything between 1280 and 1500 (inclusive, assuming ethernet), but this should not be done by default.

I still plan to get http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03 published at some point and having widespread reduced MTUs advertising in RAs means one more hurdle to an internet with larger packets. This is something that's sorely needed: 100 gigabit ethernet transmits more than two average sized IP packets in the time 10 megabit ethernet sends one bit with the current average packet size of ~ 500 bytes. Despite the fact that virtually all hardware supports larger packets these days. But unfortunately our friends over at the IEEE aren't in the position to increase the ethernet maximum packet size because that would break backward compatibility (of course with every new standard they create new stuff that's going to break if they eventually do it, those NE2000 cards aren't an issue anymore today). So if anyone is going to do it it's going to be us here at the IETF because unlike ethernet, IP allows for some parameter exchange between hosts during neighbor discovery (or ARP).

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Jul 2011 00:20:03 +0900

Iljitsch van Beijnum wrote:

> But with IPv6 we have a new chance to punish the people creating
> the problem rather than the ones implementing PMTUD properly,
> so The Right Thing To Do is NOT fix any PMTUD breakage in
> properly behaving systems, but rather push people that
> configure their systems incorrectly to fix this.

Let's see the reality.

IPv6 is broken to request packet too big ICMPs must be
generated even against multicast packets, which causes
serious periodic ICMP implosions when MTUs are, because of
tunneling, below 1500 near many receivers and is 1500 at a
sender and other part of the network.

It means that rational operators MUST filter some ICMP
and, not surprisingly, some operators will block all
ICMP or all packet too big ICMPs, which means PMTUD
won't work.

Who are the people to be punished for creating the problem?

					Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 10 Jul 2011 17:42:53 +0200

On 10 jul 2011, at 17:20, Masataka Ohta wrote:

I was wondering what kind of unique perspective you would have here, and I wasn't disappointed:

> ICMP or all packet too big ICMPs

That is more or less ok as long as they don't send any packets larger than 1280 bytes.

If you want to send 1281-byte packets you MUST use PMTUD and thus you MUST accept incoming packet too big messages.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Jul 2011 06:36:49 +0900

> have here, and I wasn't disappointed:

You always outperform me with your imagination.

> That is more or less ok as long as they don't send any packets

That's not an assumption on end users' behavior rational
operators can rely on.

> If you want to send 1281-byte packets you MUST use PMTUD and
> thus you MUST accept incoming packet too big messages.

End users might think they can, but operators won't, accept
them.

Note that it's operators who filter.

						Masataka Ohta