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