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

AVLs and other data structures cope fine with IPv6. Its true you have to
have a heap and pointers, rather than a statically sized array, but I think
if you want to change address architecture because you think arrays are the
only construct to process integers, you really have bigger problems.

They're bitstrings. They sort well in patricia trie

On Thu, Jan 9, 2014 at 12:27 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

> On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter <v6ops@globis.net> 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".
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>