[ipv6hackers] Implications of IPv6 on network firewalls

[Owen DeLong]

On Nov 24, 2011, at 2:38 PM, Fernando Gont wrote:

> On 11/24/2011 02:31 PM, Owen DeLong wrote:
>>> 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.
> 
> I consider "basic functionality" that which parallels what we currently
> do with IPv4.
> 

That's absurd. I would never think that NAT is basic functionality in IPv6.

Nor would I think that blocking PMTU-D is basic functionality in IPv6.

Nor would I consider it reasonable in IPv6 to do half a dozen other things
that are common behavior in IPv6.

The definition of basic functionality in IPv6 is different from IPv4. Pretending
that it is not gets in the way of deploying IPv6 rationally.

> 
> 
>>> 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.
> 
> Is your assessment that most networks have deployed e.g. multicast
> routing protocols?
> 

My assertion is that within 10 years, multicast routing in IPv6 will be much
more widespread than it is today. My assertion is that there are things coming
in IPv6 that will be considered basic functionality that will likely require the
use of multicast routing.

> 
>>> 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).
> 
> *My* recommendation is to run MLDv1 (as opposed to MLDv2), and *not* to
> disable MLD completely. (FWIW, the node requirements RFC does not even
> mandate MLDv2, but a lightwight version of it).
> 

MLDv2 carries significant advantages if you are routing multicast across multiple
segments.

> 
> 
>>> "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).
> 
> My take is that if you have an application that needs it, deploy it. If
> not, don't.
> 

My point is that the number of networks that have need for it is likely to radically
increase in the moderately near term future.

> 
>>> 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.
> 
> Yep, but usually you don't want to get hacked today for what you might
> be using in the future. That said, I argued in favor of MLDv1 (as
> opposed to MLDv2), and did *not* argue in favor of disabling MLD completely.
> 

I don't see MLDv2 making you more likely to get hacked than MLDv1.

I think that's more of your fear-mongering about IPv6.

Owen