IPv6 day and tunnels

Mon Jun 4 14:07:52 UTC 2012

On 4 Jun 2012, at 06:36, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> wrote:

> 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