Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? 
IPv4 without PMTUD, of course.
We are (afaik) discussing IPv6 in this thread, I assume you typo'd here
Because IPv6 requires ICMP packet too big generated against
multicast, it is designed to cause ICMP implosions, which
means ISPs must filter ICMP packet too big at least against
multicast packets and, as distinguishing them from unicast
ones is not very easy, often against unicast ones.
I do not see the problem that you are seeing, to adress the two
issues in your slides:
- for multicast just set your max packetsize to 1280, no
need for pmtu and thus this "implosion"
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 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.
I really cannot see the problem with this as multicast networks tend to be rare and very much closed. Heck, for that matter the m6bone is currently pretty much in a dead state for quite a while already.... 
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 and presto the issue becomes a problem of the sender. As the sender's intention is likely to reach folks they will adhere to that advice too instead of just sending packets which get rejected at the first hop.
The only protection is not to generate packet too big and
to block packet too big at least against multicast packets.
No need, as above, reject and send PtB and all is fine.
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".
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.
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.
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.
I guess one should not be so scared of ICMP, there are easier ways to overload a network. Proper BCP38 goes a long way.
You think might happen. The sender controls the packetsize
anyway and one does not want
to frag packets for multicast thus 1280 solves all of it.
That's what I said in IETF IPv6 WG more than 10 years ago, but
all the other WG members insisted on having multicast PMTUD,
ignoring the so obvious problem of packet implosions.
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.
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?
In addition, there should be malicious guys.
- when doing IPv6 inside IPv6 the outer path has to be
1280+tunneloverhead, if it is not then
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.
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.
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 that you chose to layer it inside so many stacks that the underlying medium cannot transport packets bigger as 1280, that medium has to take care of it.
Considering that many inner packet will be just 1280B long,
many packets will be fragmented, as a result of stupid attempt
to make multicast PMTUD work, unless you violate RFC2460
to blindly send packets a little larger than 1280B.
Your statement only works when:
- you chose a medium unable to send packets with a minimum of 1280
Which thus makes the medium IPv6 incapable, the mediums issue to frag
- someone filters ICMP PtB even though one should not
- when in the rare case with the above someone actually uses interdomain multicast
I hope you see how much of a non-issue this thus is.
Please fix your network instead, kthx.
Greets,
Jeroen