Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Mark ZZZ Smith <[e-mail]>]

<snip>

>>  BTW, I am aware of at least one company that meets your "multi-billion 
> 
>>  dollar, tens of thousands of desktops" definition that claims to have 
>>  brought IPv6 to 99% of its engineers without using DHCPv6 for address 
>>  assignment. In fact, they saw this as an opportunity to not run a 
>>  DHCPv6 server at all.
>> 
>>  Cheers,
>>  Lorenzo
> Correct me if I'm wrong, but there seems to be an underlying assumption 
> in this discussion that the infra and infra people knowing the address 
> that a particular host uses for communication is universally for "bad 
> things"
> 
> e.g. to break privacy so people can be tracked.
> e.g. to prevent unauthorised access.
> 

I don't think so. I think there are are quite valid reasons to track addresses in use. The point is that DHCPv6 cannot possibly accurately provide that information, because it only has records of the addresses it hands out, which doesn't include other types of addresses that hosts may or will have, such as static, SLAAC or link-local addresses.

If the enterprise admin has absolute control over the hosts then it would seem to me that they don't need to be concerned with unauthorised address use, because there is no possibility of unauthorised address use. In the least, as first steps, they should be enforcing this control by using 802.1X to prevent unauthorised access to the network, as well as shutting down network ports that aren't in use.

If they are concerned about unauthorised address use, that means they don't have absolute control over the hosts and their attachment to the network, and therefore there is a possibility that untrusted and less controlled hosts can choose to not use the DHCPv6 assigned addresses, use link-locals instead for which DHCPv6 has no records, or completely ignore the DHCPv6 assigned addresses and statically configure their own ULA prefix to use instead.

So DHCPv6 isn't an effective tool to accurately track address usage because untrusted hosts can choose not to use it or can avoid using the addresses it gives out.

> There are also "good things", especially in a "dumb host/ smart 
> network" 
> model found in many enterprises
> 
> e.g. your friendly help desk and network engineering staff can trace 
> your communication problem, and can correlate problem investigation 
> across various logs.
> e.g. you can be given VIP DSCP settings to improve your voice quality 
> and for call admission purposes.
> e.g. WAN acceleration can be used for certain servers/apps without 
> overloading the acceleration engine.
> e.g. PBR can be used to send your traffic over a better path.
> 
> Not all LANs are centrally managed. And being able to tell an outsourcer 
> to add "this config per interface and it'll all work" is 
> definitely 
> preferable in some environments.
> RA flags are not that tough to set, but I'm certain many will mess it up 
> and the A flag will not be set to 0. Then the ability to turn off/filter 
> RA altogether has some attraction.
> 
> Telling people "From now on, you have to organise your security ACLs, 
> firewall rules, WAN acceleration rules, PBR, QoS ACLs per /64 LAN 
> prefix" hasn't gone down too well so far.
> On the long term this may be a good thing, but lack of functional 
> equivalence with IPv4 is certainly a hurdle to deployment.
> 

I really struggle to understand how the additional effort to have to constantly "right size" IPv4 prefixes has somehow made creating firewall rules, ACLs, PBR etc. preferable. Every time the IPv4 prefix length is changed, all of those things need to be updated. It's monotonous work, may involve after hours changes to avoid network service disruption, and requires effort and concentration to ensure it is done correctly and accurately. Some people might find that enjoyable, but I think they're well and truly in the minority (people with no experience doing it might enjoy it the first few times, but after that ...).

Actually, most enterprises now use RFC1918 addresses, and if you look at their addressing, they'll commonly pick /24s for their LAN segments and use them everywhere (and call them "Class C"s). So it seems to be human nature to try to pick a simple and single large enough prefix size from the outset when the opportunity is there to do so.

"Right sizing" IPv4 prefixes has only really been necessary to deal with IPv4's lack of public address space, and has created much additional administrative work and network service disruption. It is a cost that can easily be eliminated when the address space is large. Making the network cheaper to operate and increasing its availability by minimising configuration changes can only be a good thing.

Regards,
Mark.