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

[Lorenzo Colitti <[e-mail]>]

On Tue, Jan 7, 2014 at 12:10 PM, Matthew Petach <[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