[ipv6hackers] Implications of IPv6 on network firewalls

[Owen DeLong]

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.

Owen