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
