[153263] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Mon Jun 4 10:09:03 2012
In-Reply-To: <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
From: Jeroen Massar <jeroen@unfix.org>
Date: Mon, 4 Jun 2012 07:07:52 -0700
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 4 Jun 2012, at 06:36, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wr=
ote:
> Jeroen Massar wrote:
>=20
>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>>>=20
>>> Completely wrongly.
>>=20
>> Got a better solution? ;)
>=20
> 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.
>>=20
>> 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"
>=20
> 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 multic=
ast packets in the rare case that a network is multicast enabled then they w=
ill 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 r=
are and very much closed. Heck, for that matter the m6bone is currently pret=
ty 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 inten=
tion 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 w=
hich is echod inside the data of the ICMPv6 packet would indeed require one t=
o look quite deep, but if one is so determined to firewall them well, then y=
ou would have to indeed.
I do not see a reason to do so though. Please note that the src/dst of the p=
acket 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 overlo=
ad 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.
>=20
> 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 requi=
rements. With the current spec you can go your way and break pMTU requiring m=
anual 1280 settings, while other networks can use pMTU in their networks. Ev=
erbody 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 pr=
oblem with this?
> In addition, there should be malicious guys.
>=20
>> - when doing IPv6 inside IPv6 the outer path has to be
>> 1280+tunneloverhead, if it is not then
>=20
> Because PMTUD is not expected to work,
You assume it does not work, but as long as per the spec people do not filte=
r 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 mig=
ht 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
>=20
> 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 la=
yer it inside so many stacks that the underlying medium cannot transport pac=
kets 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 mu=
lticast
I hope you see how much of a non-issue this thus is.
Please fix your network instead, kthx.
Greets,
Jeroen
