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

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 4 Apr 2016 23:37:17 +0200 (CEST)

Hi,

I'll be presenting 
https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on 
Wednesday. There are operational considerations here, so I encourage 
people to drop in and/or comment on this draft.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Apr 2016 13:13:45 +0100

> people to drop in and/or comment on this draft.

I'm pretty sure the added complication of what's suggested in this draft
is not going to make ipv6 networking either better or easier.

Sometimes worse is better.

Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Apr 2016 17:31:42 +0200

Hi,

> Sometimes worse is better.

I totally see this as being great fun for IXP routers.

The draft really only seems to be talking about end-system talking to
each other, but for routers, it's quite a bit more complex.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 06 Apr 2016 17:09:48 +0100

> each other, but for routers, it's quite a bit more complex.

it's not just IXPs routers: the protocol adds failure modes at the
bottom of the protocol stack, some of which will end up with packets
being blackholed.  Operationally, it's a good idea to avoid situations
like this:  apart from trashing connectivity, problems relating to
network layer blackholes are troublesome to debug and fix.

Maybe it would have been different if this idea had been suggested in
1996, but it's 20 years since ipv6 was first deployed and I'm not
convinced that the use case is sufficient to justify digging out the
foundations of the protocol, particularly when RA already supports a
per-broadcast-domain dynamic MTU option anyway.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2016 19:38:28 +0200 (CEST)

> per-broadcast-domain dynamic MTU option anyway.

That option is mostly just useful for lowering the MTU from 1500 to 
something lower, not raising it...

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Apr 2016 14:00:00 +0200

>network layer blackholes are troublesome to debug and fix.

Assuming two nodes (hosts or routers) have announced such a larger MTU. And
they have verified (using ICMP, or whatever) that is is actually possible
to exchange packets at a bigger MTU.

Then what problems do you expect in todays networks?

Do you expect bridges to corrupt packets even though the test packet work out.
(And is a there a class of devices known to do this)

Do you expect a spanning tree protocol to pick a route through different bridges.
(Does anyone expect to deploy ethernet jumbograms in such an environment)

Or maybe other source of failure.

I assume that to be safe, this option should be disabled by default and would
require explicit action by an admin to be turned on.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 07 Apr 2016 23:38:57 +0100

> Then what problems do you expect in todays networks?

for starters, multicast and broken implementations.  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.  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.  Or
several of the situations mentioned in rfc2923.

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.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 Apr 2016 14:45:29 +0200

>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
>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
>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.

>that problems relating to MTU path mismatches are a huge headache which

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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2016 02:24:29 +0000

Hi,

> with TCP MSS options, just like they do for IPv4.

If every link runs at 1280, then tunnels will be forced to fragment.

Thanks - Fred
[email-masked]

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops