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

[Tim Chown <[e-mail]>]

On 9 Jan 2014, at 16:21, Ray Hunter <[e-mail]> wrote:

>> Lorenzo Colitti <mailto:[e-mail]>
>> 9 January 2014 03:27
>> 
>>    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".
>> 
>> ------------------------------------------------------------------------
> Most organisations I know have way less than 100K hosts globally, and typically 10's or 100s of hosts per LAN.
> 
> We seem to agree that people can't track at /64 because 2^64 is too big to track.
> 
> Why then would we suggest that people track at /64 level when you already admit there's equally too many /64's to track (also 2^64)?
> 
> The point is that people *could* trivially track and filter at /128 within an enterprise *if* we give network infra people the ability to control/register which /128(s) the end host uses.
> 
> Ideally, that ability to control/register active /128's should not rely on cooperation of L2 switches or other LAN functionality that requires purchasing new switches, or constant MIB scanning.
> 
> I think that's a valid problem statement, and assigning >>/64 (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static addressing) is one way to address that problem.

I;m not sure you're defining what your problem is fully enough here.

What's wrong with polling network devices to maintain a database of IP/MAC/port bindings?  Some reasonably sized campuses with IPv6 deployed do just that, on the assumption devices can effectively pick their own addresses and/or change them over time.

Tim