> another painful issue in today’s IPv6 Internet, namely that of network filters discarding ICMPv6 Packet Too Big messages.
How about we just let the people who configure these filters solve their own problems?
How about we just let the people who configure these filters solve their own problems?
I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not.
- It's not perceived to be a problem. Most services just work, so TCP/IP with mss clamping will avoid the fragmentation issue for many services. So the services that have an issue, might be something like 2%, and the question that always lingers is if everything else works, and this one thing doesn't, it's not the filters problem.
- ICMP doesn't necessarily work with multiple layers of encapsulation anyways I encountered this on mobile wireless networks, where doing multiple rounds of encapsulation caused multiple packet size reductions. Basically, if we encapsulate in tunnels used by the mobile network, then encapsulate again in say IPSec, the IPSec node will send it's icmp packet too big to the tunnel endpoint, not the originator of the traffic.
While I suppose it could be argued that the tunnel endpoint should maintain it's own PMTU, and pro-actively send it's own icmp packet too big based on this, it can be difficult to guarantee these components work.
I've seen lots of telco equipment struggle with handling this properly, and it's not just filtering, it's bugs.
So unfortunately, we're in a situation where many networks are likely miss-configured, but lots of other services for various reasons just work. So unless you can drive the networks with problems to actually change, realistically you just lose a portion of your own customer base if you don't handle the situation while your competitors just work.
I've fought this argument countless times and lost. Not being able to ping a server, check for "destination unreachable" messages, etc. leads to frustrating troubleshooting sessions.
It's actually quite easy to identify which should be allowed and which should not.
ICMP: 0,3,8,11 (echo reply, destination unreachable, echo, time exceeded)
ICMP6: 1,2,3,4,128,129,135,136 (unreachable, packet too big, time exceeded, parameter problem, echo request, echo reply, neighbor solicitation, neighbor advertisement)
See, that wasn't hard. These are the base requirements for you to have a reasonably functional IPv4 network, and the absolute minimum requirements for IPv6 to work properly.
It's just the argument that gets made for filtering, is we'd rather just filter it all instead of trying to understand what should and should not be filtered.