Whither Cometh BCP38?

Justin M. Streiner streiner at cluebyfour.org
Wed Jun 13 15:43:28 UTC 2012


On Mon, 11 Jun 2012, Mikael Abrahamsson wrote:

> This is for IPv4, for IPv6 we're back 10 years again with very lacking 
> support.

Amen to that.  At first glance, building IPv6 ACLs/firewall rules/filters 
isn't much different from building IPv4 equivalents in many environments, 
but there are lots of vendor-specific 'gotcha's out there that make for 
more work to get to a point of sanity with IPv6.  To be fair, at the 
application level, things are still pretty similar - the sun still rises 
in the east, HTTP still normally works on well-known destination port 
tcp/80, etc.

Examples:
1. Junos firewall filters can be bypassed in some cases with appropriately 
crafted extension headers, depending on how the filter is built.  In the 
case of border ingress/egress filters, which are often written in a "deny 
specific types of traffic, but permit everything else" fashion, re-working 
the order of the filter elements is often not practical.

2. Cisco's handling of ICMPv6 on the ASA platform still seems a bit 
'green' to me.  Hopefully the kinks will get worked out as everyone 
(vendors included) get more operational experience with IPv6.  I'm basing 
this on my efforts to develop a set of basic firewall rules for our IPv6 
deployment templates, with the goal being to allow necessary ICMPv6 
traffic through, while limiting the exposure of the hosts behind the 
firewall.  A lot of this has been based on RFC 4890 as a starting point.

3. Some devices leak link-local traffic beyond the link, in violation of 
RFC 4192, sec 2.5.6.  This can have implications for filter/acl/ruleset 
design, since the assumption that devices will always 'do the right thing' 
with link-local traffic is not valid.

jms




More information about the NANOG mailing list