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

[Ray Hunter <[e-mail]>]

Lorenzo Colitti wrote:
> On Tue, Jan 7, 2014 at 12:10 PM, Matthew Petach <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     There are multi-billion dollar companies that have a need
>     to operate their networks in very specific ways.  If those
>     ways are not supported by the RFCs, they will pay money
>     to vendors to have options added to the software to allow
>     them to operate their networks in that way.  See for example
>     the filter-aaaa-on-v4 option in BIND; while there was resistance
>     to the idea that DNS servers be configurable to not
>     return quad-A records to v4 queries, in the end, the
>     needs of the business won out. 
>
>
> I think that's a terrible example. AFAIK (and I think I was in the 
> room) the filter-aaaa-on-v4 hack was originally proposed for use in 
> CPEs, and it met with opposition even there. Opposition for getting it 
> into bind was pretty strong, and AIUI - as you say - it was included 
> only because someone said, "We have a contract. Here's a check. Now 
> honour the contract."
>
> In hindsight, it turned out to be a really bad idea. The hack was 
> never used for its intended purpose in the CPE, but it did end up 
> being used basically by an entire country to cling to a fundamentally 
> broken IPv6 deployment model (the NTT walled-garden "here's a global 
> IPv6 address and a default route, but you can't reach the IPv6 
> Internet, have a nice day" fiasco). I think that if filter-aaaa-on-v4 
> is an example of anything, it's an example of the law of unintended 
> consequences.
>
>     There are very large networks
>     that require DCHPv6-only implementations to work, and they
>     will get software to support that model, one way or another,
>     because without it, they cannot move to a dual-stack
>     environment.  Not from a technical perspective, of course,
>     but from an accounting and control perspective; the DHCP
>     server must be the source of both v4 and v6 address assignments,
>     and the only such source, in order for the staff to know for certain
>     who has been assigned a given address on the network.
>
>
> <sidenote>
> DHCPv6 is not *necessary* accounting and control. It is one way to do 
> it, but you can do it just as well with address tracking in the 
> switches. Address tracking is also much more flexible (allowing 
> multiple addresses, dynamic addresses) and more secure: while using 
> DHCP for address verification requires strong first-hop security in 
> the switches (DHCP snooping, address-to-MAC binding, forced 
> forwarding, etc) address tracking requires none of that. In fact, 
> there's a fallacy here: I have personally see security people think 
> that DHCP-provided addresses are secure, when by themselves they are 
> not secure at all. They can only be made secure if first-hop security 
> is in place.
>
> In fact, I'd argue that DHCPv4 is not particularly well-suited for 
> address tracking at all, and the only reason we use DHCP for address 
> tracking in IPv4 is that in IPv4 there is basically no other mechanism 
> to assign addresses.
> </sidenote>
>
> With that out of the way: why are you talking about address 
> assignment. DHCPv6-only address assignment is already a standard. Send 
> an RA with M=1 (and optionally a prefix with A=0) and - assuming your 
> hosts implement DHCPv6 - you're done.
>
>     You can argue back and forth until you're blue in the face;
>     but it's rather like trying to persuade a glacier to stop
>     advancing by pointing a hair dryer at it.  There *will* be
>     networks that will be run with address assignments from DHCP only,
>     both for v4 and v6, and it can either happen with support from the
>     RFC-discussing community, or it can come via paid-for-knobs in
>     software to allow for non-RFC DHCPv4+DHCPv6-only environments.
>
>
> Of course. In the privacy of your own network, or between consenting 
> networks and implementations, you can do whatever you like. But 
> standardizing it is a much higher bar. In hindsight, I think it's 
> pretty clear to that filter-aaaa-on-v4 is a terrible idea (just think 
> of what will happen to it when DNSSEC rolls around), and I think it's 
> clear that it will never be standardized. But that doesn't stop people 
> from using it.
>
>     Or, you're a company with tens of thousands
>
>     of desktops, where static configuration is not
>     a viable option, but control over address
>     assignment from central servers is a must;
>     in that environment, DHCPv6-assignment-only is
>     a reality, and will exist; it is already being explored
>     today, and to to deny that it is coming is equally as
>     useful as cursing the coming of nightfall; it
>     will happen, with or without your agreement
>     or support.
>
>
> It's not entirely clear to me what you're talking about here, since 
> DHCPv6-only address assignment is already possible today. But take a 
> random $FEATURE. If you're right and your multi-billion dollar 
> enterprises get all host operating systems to support $FEATURE, then 
> it will be a de facto standard. But until then, it would be a mistake 
> for the IETF to to standardize $FEATURE if there are existing and 
> technically superior ways of implmenting $FEATURE's functionality just 
> because a subset of users want to stick to the same practices they 
> used in IPv4.
>
> 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.

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.

-- 
Regards,
RayH