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.
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. You can do nothing against a sender who consciously (not necessarily maliciously) set it to 1500B. The only protection is not to generate packet too big and to block packet too big at least against multicast packets. If you don't want to inspect packets so deeply (beyond first 64B, for example), packet too big against unicast packets are also blocked. 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 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. Thus, RFC2463 requires: Sending a Packet Too Big Message makes an exception to one of the rules of when to send an ICMPv6 error message, in that unlike other messages, it is sent in response to a packet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ received with an IPv6 multicast destination address, or a linklayer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ multicast or link-layer broadcast address. They have not yet obsoleted the feature. So, you should assume some, if not all, of them still insist on using multicast PMTUD to make multicast packet size larger than 1280B. 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 must assume MTU of outer path is 1280B, as is specified "simply restrict itself to sending packets no larger than 1280 octets" in RFC2460.
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. 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. Masataka Ohta