Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

[Lorenzo Colitti <[e-mail]>]

On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter <[e-mail]> wrote:

> It may not be a widely held belief, but I remain concerned about the
> potential for resource exhaustion for any number of processes due to the
> "massive over sizing" of prefixes to /64: any number of untested processes
> that track state based on /128 IPv6 address could be attacked. The flip
> side of expanding privacy through address obfuscation at IID level is that
> the source space available for attacks also increases. ND cache exhaustion
> is probably just the first issue we've discovered of many that exist. This
> may have knock on operational consequences, which in the IPv4 world have
> relied on the scarcity of IPv4 address space to be able to operate
> correctly under stress scenarios. We're going to discover who has been
> swimming naked when the tide goes out. Call that FUD, or operational
> expediency, whichever you like. BCP38 has saved me on a number of occasions
> when all else has failed.
>

It's true that some implementations may have made incorrect assumptions
about IPv6 attacks based on their IPv4 knowledge. But on the other hand, a
/64 provides plentiful space, freedom from renumbering, and operational
simplicity because "you will always have enough subnet space" and "you can
pick your own IID because a /64 provides enough space for everyone".

I don't think it's a good trade-off to give up those advantages just
because of some implementations may temporarily have made insecure choices.
By the same token, we didn't design IPv4 to be partitioned into security
zones, even though I'm sure that when IPv4 rolled around, people were
shocked - and I'm sure some got burnt - by the fact that enabling IPv4 on a
machine suddenly meant that the machine was suddenly accessible from
anywhere in the world. I think it's much better to start with a flexible,
full-featured, simple architecture and them secure it.

It's not that securing it is hard to do: in first instance, make the abuse
systems just track /64s instead of tracking /128s, and problem solved. Of
course, you still have the problem that there are too many /64s to keep
track of, but there's no way around that except to stick with IPv4, or make
a new protocol that has more address space than IPv4 but less address space
than IPv6... but why would you want that?

I know that smaller subnets are consistent with IPv4. But "different from
IPv4" doesn't mean "worse than IPv4". In many cases, it means "better than
IPv4".