Re: IPv6 day and tunnels

[Masataka Ohta <mohta () necom830 hpcl titech ac jp>]

Jeroen Massar wrote:

> > IPv4 without PMTUD, of course.
>
> We are (afaik) discussing IPv6 in this thread,

That's your problem of insisting on very narrow solution
space, which is why you can find no solution and are
trying to ignore the problem.

> > It is a sender of a multicast packet, not you as some ISP,
> > who set max packet size to 1280B or 1500B.
>
> If a customer already miraculously has the rare capability
> of sending multicast packets in the rare case that a
> network is multicast enabled

That is the case IPv6 WG insisted on.

> then they will also have been told to use a max packet size
> of 1280 to avoid any issues when it is expected that some
> endpoint might have that max MTU.

Those who insisted on the case won't tell so nor do so.

> I really cannot see the problem with this

because you insist on IPv6.

> > You can do nothing against a sender who consciously (not
> > necessarily maliciously) set it to 1500B.
>
> Of course you can, the first hop into your network can
> generate a single PtB

I can, but I can't expect others will do so.

I, instead, know those who insisted on the case won't.

> No need, as above, reject and send PtB and all is fine.

As I wrote:

> > That you don't enable multicast in your network does not
> > mean you have nothing to do with packet too big against
> > multicast, because you may be on a path of returning ICMPs.
> > That is, you should still block them.

you are wrong.

> > If you don't want to inspect packets so deeply (beyond first
> > 64B, for example), packet too big against unicast packets
> > are also blocked.
>
> Routing (forwarding packets) is in no way "expection".

What?

> Blocking returning ICMPv6 PtB where you are looking at the
> original packet which is echod inside the data of the
> ICMPv6 packet would indeed require one to look quite deep,
> but if one is so determined to firewall them well, then
> you would have to indeed.

As I already filter packets required by RFC2463, why, do you
think, do I have to bother only to reduce performance?

> I do not see a reason to do so though. Please note that the
> src/dst of the packet itself is unicast even if the PtB
> will be for a multicast packet.

How can you ignore the implosion of unicast ICMP?

> They did not ignore you, they realized that not everybody
> has the same requirements. With the current spec you can
> go your way and break pMTU requiring manual 1280 settings,
> while other networks can use pMTU in their networks.Everbody wins.

What? Their networks? The Internet is interconnected.

> > So, you should assume some, if not all, of them still insist
> > on using multicast PMTUD to make multicast packet size larger
> > than 1280B.
>
> As networks become more and more jumbo frame enabled,
> what exactly is the problem with this?

That makes things worse.

It will promote people try to multicast with jumbo frames.

> > Because PMTUD is not expected to work,
>
> You assume it does not work, but as long as per the spec
> people do not filter it, it works.

Such operation leaves network vulnerable and should be corrected.

> > you must assume MTU
> > of outer path is 1280B, as is specified "simply restrict
> > itself to sending packets no larger than 1280 octets" in
> > RFC2460.
>
> While for multicast enabled networks that might hit the 
> minimum MTU this might be true-ish, it does not make
> it universally true.

The Internet is interconnected.

> > >      you need to use a tunneling protocol that knows how to
> > >      frag and reassemble as is acting as a
> > >      medium with an mtu less than the minimum of 1280
> >
> > That's my point in my second last slide.
>
> Then you word it wrongly. It is not the problem of IPv6

You should read RFC2473, an example in my slide.

> Please fix your network instead, kthx.

It is a problem of RFC2463 and networks of people who insist
on the current RFC2463 for multicast PMTUD.

If you want the problem disappear, change RFC2463.

                                        Masataka Ohta