[ipv6hackers] Implications of IPv6 on network firewalls

Owen DeLong owend at he.net
Thu Nov 24 21:31:46 CET 2011

On Nov 24, 2011, at 9:24 AM, Fernando Gont wrote:

> On 11/24/2011 06:02 AM, Frederic Bovy wrote:
>> CISCO default is to deny by default the Routing Headers.
> That's for patched IOS... which might or might not be the IOS version
> your device is running...
>> I am not sure that we should deny all the headers by defaults as some
>> of them are required for basic  IPv6 features (hop by hop with Router
>> Alert for MLD)... 
> I don't think extension headers other than "Fragment Header" are needed
> for basic functionality. Regarding use of HBH extension headers for MLD,
> they are only needed if:
I guess that depends on your definition of basic functionality.

In IPv6, IPSEC is implemented in extension headers. I would consider that
basic functionality.

> a) Your local network is supported by an MLD-snooping switch, or,
> b) You're using "global" multicast (as opposed to link-local multicast)

Both of which I would consider basic functionality in IPv6.

> When it comes to "a", *if* you wanted, you could disable the
> MLD-snooping functionality (your switch might not even support it, anyway).

You could, but, then you lose the advantages that come from MLD snooping
and I don't think that would be desirable, especially when combined with b).

> "b" is not the case for most networks.

It may not be the case for many networks today, but, I certainly hope that will
change going forward in IPv6. Especially when you consider that case b isn't
limited to global multicast. It's actually applicable to any multicast scope
larger than link. (Multicast address ≥ff02::/16).

> In any case, *MLDv1* is fine (simple enough). OTOH, MLDv2 is
> unnecessarily complex if you just want to support link-local multicast.

Site, Admin, or Organization scoped multicast for mDNS service discovery
is not out of the question as a way forward for IPv6 service discovery. In such
a case, limiting multicast to link-local makes little or no sense.

> So my advice would be that, rather than disabling MLD completely, you
> use MLDv1 (instead of MLDv2), and use MLDv2 only if you're expecting to
> use non-local multicast.

My advice is that most people should be expecting to use non-local multicast
in their futures.


More information about the Ipv6hackers mailing list