IPv6 day and tunnels

Mon Jun 4 13:36:10 UTC 2012

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