[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

Owen DeLong owend at he.net
Tue Aug 28 16:33:58 CEST 2012


On Aug 28, 2012, at 05:13 , Fernando Gont <fgont at si6networks.com> wrote:

> On 08/23/2012 10:04 AM, Jim Small wrote:
>> Marc - I agree that security could be better and there are still
>> some things that need to be addressed.  That said, in the space I
>> work in Cisco and Microsoft have done IMHO a pretty good job
>> addressing the issues.  
> 
> FWIW, in mine, they haven't.
> 

Here, I mostly agree with Fernando.

> 
> 
>> I also believe there is tremendous benefit for innovation with IPv6.
> 
> This has been claimed for ages -- yet we have not had a single killer
> application.

You can't have a killer app for an internet that doesn't exist yet. There's
room for tremendous innovation once IPv6 is deployed. Until it's deployed,
developers can't even begin to notice it, let alone take advantage of it.
(The potential for innovation, not IPv6).

> 
> 
>> NAT has become a strangle hold choking off innovation.  
> 
> At least half of the problems "introduced" by NATs are also introduced
> by firewalls that "only allow return traffic"  -- So I don't necessarily
> buy the "IPv6 fosters innovation" thing...
> 

Except that the firewalls _CAN_ be told to pass what you want. There is
no such possibility with NAT.

> 
>> no way.  Deploying IPv6 provides virtually limitless address space
>> and makes it far easier for developers to come up with fantastic new
>> applications.  
> 
> Some might argue "gimme the IPv6 killer app, and I'll do the ipv6
> roll-out if the app is good enough".
> 

That's like saying "Give me the web and I'll consider rolling out IPv4."

The web came into existence because IPv4 was already deployed,
not the other way around. The moon existed before we developed
spacecraft, not the other way around.


>> I know you're a great guy and I agree the security issues need to be
>> fixed, but how is this helping us move forward?
> 
> Without necessarily agreeing with eveything that Marc said (or
> "allegedly said"), I'd note that opinions should not be judged on the
> basis of how happy the make us feel.
> 

True, but...

> Quoting Bertrand Russell:
> 
> "When you are studying any matter, or considering any philosophy, ask
> yourself only what are the facts and what is the truth that the facts
> bear out. Never let yourself be diverted either by what you wish to
> believe, or by what you think would have beneficent social effects if it
> were believed. But look only, and solely, at what are the facts."
> 

Yes... This applies very much to things you and Marc tend to say...

Do not ignore the fact that we are running out of IPv4 addresses.
Do not ignore the fact that no matter how problematic the security issues
	you have raised with IPv6 (which I think in a real-world evaluation
	are relatively low risk) may be, the bigger risk to the functionality
	of the internet in general is widespread NAT444/CGN.
Do not ignore the fact that just the geolocation implications of NAT444
	are nearly enough to give one pause.
Do not ignore the security implications from an audit and event correlation
	perspective that are inherent in CGN.

Consider when evaluating IPv6 deployment, not only the facts of the
security issues raised, but also the facts and implications and
consequences of failing to deploy IPv6 in a timely manner.

> Clearly, if we find any problems, we shouldn't stop there, but that
> should be our starting point for engineering solutions. But that
> starting point is *needed*.
> 

Agreed. I don't think anyone is saying that you shouldn't call attention
to the security problems or that vendors should not work diligently
to solve them.

However, claiming that they should delay or derail an IPv6 rollout at
this point can only be accepted if one utterly and completely ignores
the truly heinous consequences of keeping IPv4 on life support for
another 5-10 years, if that is even possible.

> Most of the time I get the impression that IPv6 proponents essentially
> try to squelch any discussions about IPv6
> drawbacks/vulnerabilities/problems, yet they fail to support any efforts
> in improving the current state of affairs.

I don't think you've ever seen me attempt to squelch such a discussion.
I simply draw the line when you start saying that the drawbacks you
have mentioned to date should be given enough weight to delay or
avoid deploying IPv6 in general.

Any such advice is, IMHO, a disservice to the community due to the
extreme consequences inherent in following it.

> As a data-point, look at the lengthy discussions we have had about
> RA-Guard, how trivial it is to evade current implementations, and
> whether that makes the IPv6 world any worse (or not) than the IPv4 world.
> 

Consider this... What fraction of IPv4 networks with DHCP run DHCP
snooping? If you can show me that it is even 10%, then, you might
have a real world case. My observation in the real world is that it is
less than 5%. As such, I don't think that RA without RA Guard is
necessarily much worse than the current deployed state of IPv4.
RA Guard improves this situation (if people use it). Fixed RA-Guard
as you have proposed will improve it even more (if people use it).

> Yet when there was time to support a proposal to fix RA-Guard (now
> draft-ietf-v6ops-ra-guard-implementation), there were only a few folks
> there...

It seems to be making its way forward.

> 
> If half of the energy spent on convincing people (or pretending) that
> there are no problems with v6 was spent in producing tools (such as
> THC-IPv6), discussing the problems (to eventually engineer workarounds),
> producing proposals for improvements, supporting existing proposals for
> improvements, or slapping vendors that essentially refrain from fixing
> their own vulnerable stacks, the IPv6 world would certainly be a much
> better place.
> 

I've never claimed there are no problems with IPv6. I have, however, claimed
that the problems created by failing to deploy IPv6 in a timely manner
massively outweigh the problems mentioned in IPv6 to date.

Owen




More information about the Ipv6hackers mailing list