[ipv6hackers] IPv6 security (slides and training)

[Owen DeLong]

>> The new connected enterprises which don(t own a large IPv4 block of
>> addresses will have no choice than deploying IPv6.
> 
> Why? Why not just do what most of them do now, IPv4 NAT on the internal
> network, and a small block of IPv4 PA space on the border?
> 

Because at some point, there are no small blocks of IPv4 available to create
that border space from.

Because at some point, someone will launch the next gotta-have-it social
network, web5.0 application, or whatever, and, there won't be enough IPv4
to host their servers on so they WILL be IPv6 only.

>> So you will have two Internet, the old IPv4 internet with people who want
>> to stick with IPv4 and the new connected with IPv6.
>> 
>> Do you think that even if we setup some translation between the IPv4 and
>> the IPv6 wold, this will scale to provide seamless connectivity between
>> the two Internet?
> 
> Yes. Will it be optimal? No. But it will cover most of the bell-shaped
> curve, and people will "route around" the rest.
> 

It will cover most of the CURRENT bell-shaped curve. You can't route
around a lack of addresses no matter how hard you try. Eventually, most
of that bell will be IPv6 because at the current rate of growth, the proportion
of the internet which doesn't fit in the existing IPv4 address space will be
larger than the existing IPv4 address space within a few years.

>> I think that the IPv4 folks will quickly have problems communicating with
>> their partners and customers running IPv6.
> 
> ... which is one of the big motivations to not be a first-mover to IPv6
> in the first place.
> 

Nonsense. I can see it as a motivation not to be the first to turn off IPv4,
but, deploying IPv6 along side IPv4 (dual-stack) does not in any way
degrade your IPv4 experience. It simply makes it possible for you to
talk to both the IPv4 and IPv6 internets seamlessly. (Well, as seamlessly
as you currently can with IPv4 to the IPv4 internet given the problems
created by pervasive header mutilation).

>> Most of the applications on the Internet are Real-Time applications. Video
>> is #1 but there is also VoIP, WebEX and more.
>> Do you think that this will be OK with CGN, Double NAT?
>> 
>> This is for me a good reason.
> 
> Me too, and I think is going to be one of the things that actually
> pushes people to move. But, unfortunately, I think that the failures
> here will have to be experienced before the lessons are learned.
> 

Unfortunate, indeed, since it takes time to deploy IPv6 in an environment,
and, if you wait until IPv4 starts failing, then, you have to live with that failure
for the duration of your IPv6 deployment.

>> Now you say that IPv6 is immature, untested! But IPv6 6BONE testing
>> started in 1996!
>> More than 15 years of tests.
>> 
>> What is enough for you? 20, 30 years of tests?
> 
> First, anything carrying less than 1% of Internet traffic is untested by
> definition. And yes, immature ... ND flooding, lack of DHCP parity,
> stupid ivory-tower debates about RA vs. DHCP, last minute fixes to
> flowlabel, just-before-last-minute fixes to the route 0 problem ... I
> could go on, but it would be much better to follow closely the work in
> v6ops and 6man (which I know you're involved with to some extent, which
> makes your assertion that IPv6 is "mature" that much harder to understand).
> 

Here you have created your own tautology. We shouldn't deploy it because
it's untested. It can be tested until it carries more than 1% of traffic.  Did you
consider IPv4 tested 15 years ago? If so, then, consider that IPv6 is already
carrying more bits every day than IPv4 was then. Let's face it, e-commerce
was getting into pretty good swing 15 years ago. Sure, we've learned even
more since then, but, reality is that most people considered IPv4 fairly well
tested by that time. IPv6 is already past that point on traffic levels, so, if
you think traffic levels are somehow a meaningful part of testing (I don't
agree with your premise, but, let's go with it for a moment), then, even that
argument doesn't really hold water.

> We don't do ourselves, or the Internet, any favors by continuing to
> stick our heads in the sand and denying that the problems exist. There
> are reasons why CGN is seen as a much more attractive alternative to
> IPv6 (whether they are good or bad isn't relevant). If we can't
> understand those reasons, we can't address them intelligently.
> 

I'm not denying that problems exist in IPv6. I'm asking you to enumerate
the ones you see because I believe that in most cases, they can be solved
by applying better v6-think and less v4-think to the situation. In regards to
the security issues that have been raised, I think they are not significantly
worse nor significantly better than the current state of IPv4 except on certain
theoretical levels when you consider the entire risk context and not just
one narrow aspect of it.

Owen