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

[Ray Hunter <[e-mail]>]

> Tim Chown <mailto:[e-mail]>
> 9 January 2014 18:31
> On 9 Jan 2014, at 17:18, Ray Hunter<[e-mail]>  wrote:
>
>>> Tim Chown<mailto:[e-mail]>
>>> 9 January 2014 17:32
>>>
>>> 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
>> I'd also probably consider that on a campus, which is geographically limited, there's no latency, network devices are uniform, there's a single management vendor, SNMP access is allowed, and bandwidth is free.
>>
>> DHCP (which is effectively a form of event-triggered central registration) works pretty well today. Two people can support all global IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the lowest common denominator of a DHCP proxy on any LAN equipment pointing at your regional servers, and a DHCP client on end user devices, which is basically universally supported. And you can lever that information up in all sorts of ways. DHCPv6 would not be cost impacting (part of licensing on existing kit). Anything else would be. You're not going to be able to get any less than 2 support people for this sort of enterprise critical infra. Off topic for this ID, but just saying.
>
> Fair comment, but for a campus style network, I'd argue for the polling approach, and it works well (enough).
>
> There's a distinction though between controlling addresses and being able to observe all addresses that are in use.
Agreed. Many scenarios I have in mind are about knowing all addresses in 
use, and who is using them. Not necessarily limiting them.
>> The bottom line is that sparse addressing in IPv6, as implemented today, also has a down side for enterprise operations; but perhaps that discussion should be held in v6ops.
>
> Well, I think it's relevant to this draft.
>
> I'm not sure it's really down to the sparse addressing per se, rather that there is enough address space in a subnet for there to be a mechanism for hosts to pick multiple addresses to use over time.
>
> Tim
>
>
My point of view is that there's a trade off to be made between "too few 
and too many" when talking about sparse address allocation, and that the 
current fixed /64 boundary allows "too many" IIDs/IPv6 addresses for 
many operational scenarios. So many in fact that it's a potential 
liability. Either that or we need a mechanism that more reliably tracks 
and registers addresses actually in use on a semi-trusted environment, 
so that the actual /128's in use are known (centrally) e.g. for 
improving/extending source address validation and anti-spoofing, 
helpdesk calls, log correlation, QoS tracking etc.

As an example, how many implementations of QoS mechanisms like WFQ do 
you know today that protect their resources used for counting active 
flows on a /48 and /64 boundary? And how many just track session use per 
/128? Or have no limit at all on allowable active sessions per 
address/prefix?

So how many implementations are vulnerable today to flow table size 
exhaustion that could have a global service impact by an attack from a 
single compromised host that can spoof source addresses from an entire 
/64 or /48?

-- 
Regards,
RayH