I'm getting sick and tired of the "ooh we'll make things more secure and block all ICMP" because it's stupid.  Folks who insist on this thought process may be able to slide by in the IPv4 world, but this non-logic causes tons of problems in the IPv6 world.  This is because ICMPv6 is used for path MTU discovery, among other things.  It's done between hosts with the aid of routers signalling the hosts when the MTU on the path is too small.  Here's a perfect example, Juniper Networks: http://ipv6.juniper.net/.  Juniper, I'm a big fan, but why'd you have to screw this up?  Didn't you learn anything from Brocade last year when they did the same thing?

Ok, here's the problem.  I've got a box (dax), which happens to be this webserver, on native IPv6 provided by Voxel dot Net with a few tunnels, one of which connects back home.  This tunnel connection has an IPv6 MTU of 1280.  So, most sites on the IPv6 Internet need to lower their MTU when serving pages and other content to my workstation.  What tells them to do this?  dax.  It's em0 interface facing Voxel's network sends out ICMPv6 packet too big messages telling sending hosts that they need to decrease their MTU to fit the packets down the tunnel.  Sometimes, it doesn't work, like with ipv6.juniper.net, apparently.  Here's what happens when I run wget fron my workstation:

(destiny:20:41)% wget --tries=1 http://ipv6.juniper.net/
--2011-03-09 20:44:32--  http://ipv6.juniper.net/
Resolving ipv6.juniper.net... 2620:12::5
Connecting to ipv6.juniper.net|2620:12::5|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1295 (1.3K) [text/html]
Saving to: “index.html”

 0% [                                       ] 0           --.-K/s   in 1m 41s  

2011-03-09 20:46:14 (0.00 B/s) - Read error at byte 0/1295 (Connection reset by peer). Giving up.

wget connects, but doesn't get any content back, and gives up.  Here's some tcpdump output showing the relevant traffic in and out of dax's em0 interface during the above test:

Yep, 2001:48c8:1:2::2 (dax's em0) is trying to tell 2620:12::5 (ipv6.juniper.net) that the length of the TCP packets (1268 + 32 + 40 = 1340) is quite a bit larger than the maximum MTU of the tunnel it's trying to forward the packet out, which is 1280.  ipv6.juniper.net should really be reacting to this ICMPv6 message and lowering its MTU to 1280, which would result in a TCP segment size of 1208.  Um, nope, we're not seeing this.  What it looks like is that Juniper is blocking these ICMPv6 messages or not statefully associating them with the TCP session.

So, what kind of firewall do we think Juniper is running one of their new fancy SRX firewalls or one of the older NetScreen, SSG, or ISG product lines?  Let's just say I know for a fact that the NetScreen product lines work great with IPv6 and don't exhibit these problems if you only allow TCP port 80.  They associate the ICMPv6 packet too big messages with the TCP session and pass it back to the host statefully.  If this is an SRX bug, I'm really going to be annoyed, for a number of different reasons!

Hopefully this'll be fixed soon.  ICMPv6 silliness is no laughing matter!

New comments are currently disabled for this entry.