Re: [v6ops] draft-van-beijnum-multi-mtu-05

[Philip Homburg <[e-mail]>]

>> Then what problems do you expect in todays networks?
>
>for starters, multicast and broken implementations.  

Broken implementations can do anything, including breaking things. I don't
think we can say much more about broken implementations. Except for statistics
about current brokenness on the internet.

I naively assumed that multicast would be out of scope because of the
use of neighbor discovery.

>If there are
>routers doing this negotiation, then this may change the path mtu
>mid-flight, which could cause problems if the path mtu drops
>unexpectedly, which it might easily if lots of things are dynamically
>negotiated.  

How is that different from today's internet? If traffic gets rerouted, the
PMTU may get lower.

Do you think it is more likely that the MTU will drop in an ethernet jumbogram
context than on the internet as a whole (taking into account the huge number
of tunnels that is still present on the IPv6 internet)

>Or if the MTU negotiation takes place at the first hop and
>the endpoints are left thinking that they can handle an mtu of 9200
>bytes while the intermediate path might only support 1500 and the
>fragmenting router is already rate limiting icmp6 toobig responses.  

So you are saying that PMTU doesn't work? I sort of agree with that.

But if that's the case, then we should pass an RFC that states that the IPv6
link MTU always has to be exactly 1280.

Otherwise, any network that runs at an MTU of 1500 can hit a tunnel that has
a lower MTU.

The same way I expect any router that routes between links with different MTU
to be carefully monitored with respect to packet to big ICMPs.

Let me also say that I find this a really sad statement. It essentially blocks
all forward progress because some people may misconfigure their routers.

>The issue is that the use case is not sufficiently compelling to warrant
>introducing low level changes in a protocol which has been around for 20
>years and has a wide deployment, where operational experience tells us
>that problems relating to MTU path mismatches are a huge headache which
>are difficult to debug.

In my perception, ever since Gbit/s ethernet interfaces generally started
supporting ethernet packets bigger than 1500, people have been looking at either
the IEEE or the IETF to find a way to make this autoconfigurable.

So the way I see it, this is a huge step forward. Something that should have
been done decades ago.

Yes, we have a PMTU problem. But the logical conclusion of giving in to that,
is that every link will run at 1280. Or, the middle boxes start messing
with TCP MSS options, just like they do for IPv4.