Mike Tancsa IPV6 blog

One of the promises of IPv6 is that its supposed to do away with the evils of NAT! My Favorite book so far on IPv6 is “IPv6 in Practice” and he writes on one of the benefits of IPv6

Abolition of NAT With IPv6 there is no need to connect multiple machines to the Internet using a single address and network address translation (NAT). Without NAT, end-to-end connectivity becomes available again, allowing machines to connect to each other without intermediate “broker” services, like mail exchangers/relays, web proxies, DNS forwarders or SIP gatekeepers, that are run by a service provider. At first glance this doesn’t seem like much of an advantage, but at this time its consequences are barely fathomable, making services possible that are difficult even to imagine to our NAT-conditioned minds.

Allowing… end to … end connectivity ??? Good lord. I dont want unrestricted end to end connectivity. I want it restricted on the big bad internet.  And the strawman argument that NAT is not security that you will often see in other IPv6 discussions is just that, a strawman. .  Of course, NAT by itself is NOT security.  But given the choice between

a) Stateful firewall between hosts and the internet

b) Stateful firewall between hosts that are RFC 1918 and the internet

I will take b)
Case in point. While setting up our office firewall to allow out IPv6 from our workstations, I had allowed all icmp6 traffic in and out by accident. BAD! Is it the end of the world, no of course not. It would take eons for someone to scan for internal hosts with a traditional ping scan. But outbound connectivity from various internal severs will leave enough information for someone to find such hosts by other means. e.g. our internal WINS file server has a static IPv6 IP. It also punts out mail on occasion… which will be in some headers. With that in mind, someone could now send icmp6 traffic to the host. Is that a bad thing… Well, not in of itself, but hacks rarely are. They are usually a combination of partial vulnerabilities combined together in novel ways.
Looking at my favorite OS, FreeBSD, I see the following default rules for IPv6 ipfw

00400           0              0 deny ip from any to ::1
00500           0              0 deny ip from ::1 to any
00600           8            580 allow ipv6-icmp from :: to ff02::/16
00700      118703        8071672 allow ipv6-icmp from fe80::/10 to fe80::/10
00800        4890         507228 allow ipv6-icmp from fe80::/10 to ff02::/16
00900       21025        3182910 allow ipv6-icmp from any to any ip6 icmp6types 1
01000      179147       12264112 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136

OK, so some link local prefixes, fair enough… icmp types 1,2,135 and 136. Looking at the sys/netinet/icmp6.h, it looks like they are

#define ICMP6_DST_UNREACH               1       /* dest unreachable, codes: */
#define ICMP6_PACKET_TOO_BIG            2       /* packet too big */
#define ND_NEIGHBOR_SOLICIT             135     /* neighbor solicitation */
#define ND_NEIGHBOR_ADVERT              136     /* neighbor advertisement */

Ummm, ok. I guess that makes sense. But why not

#define ICMP6_TIME_EXCEEDED             3       /* time exceeded, code: */
#define ICMP6_PARAM_PROB                4       /* ip6 header bad */

They seem reasonable messages you would want to allow too no ? Not a rhetorical question….