Why used DHCPv6 when RA has RDNSS and DNSSL?

[Nick Hilliard]

James R Cutler wrote on 31/03/2020 19:21:
> Wouldn’t it be more cost effect in the long term to simply make SLAAC 
> and DHCPv6 cooperative and complementary attributes of end-to-end 
> networking?

DHCPv6 lacks a tiny handful of features to make it fully independent of 
SLAAC: a default route option and the network prefix would be the most 
important of these, but it also lacks a prefix length option and an 
option for specifying MTU.  Other than the lack of these features, there 
is no technical reason that DHCPv6 couldn't be fully standalone.

The prevailing sentiment expressed at the various IETF groups where this 
has formally been discussed (mif, dhc, v6ops, 6man) is that there is no 
requirement for DHCPv6 to have these features because they already exist 
in ND, and as ND is necessary for DHCPv6 to work already, it would be 
pointless and confusing to duplicate the functionality in DHCPv6.

As an aside, the concerns about duplicating functionality often do not 
apply to SLAAC, RDNSS being a good example, and pref64.  The ambivalence 
here is surprising, particularly considering that some peoples' 
arguments about whether duplicated functionality is acceptable seems to 
change depending on which protocol they're advocating at the time.

There are several reasons that people shout about DHCPv6:

- protocol purity: minimalist protocols are better, so the fewer options 
each protocol has, the simpler things are.  That's fine as far as it 
goes, but we need to overlook that that horse bolted over 20 years ago, 
settled down, and had foals, a mortgage and car loan, but yet people are 
still insistent that the barn door ought to be kept closed on principal.

- technical distaste: lots of reasons here; some understandable (e.g. 
cannot force state changes on dhcp client devices unless the client 
requests an update), and some not (it allows the operator to force their 
networking policies on you, like omg, as if you're not already subject 
to a network operator's policies to start with).  The consequence of 
this is that there is an extraordinarily long history at the IETF of 
people dissing DHCP which goes right back to the earliest days of 
dhcpv4.  No-one claims that DHCP is perfect, but it's a reasonably good 
solution for many use cases.

- politics: probably the most contentious area. One well-known example 
is how ipv6 on cellular impacts carrier vs handset control politics. 
3GPP specifies that the ppp context for tethering must support SLAAC and 
therefore it provides a /64 for LAN connectivity. This means that the 
handset applications have as much address space as they need.  The 
argument goes that if DHCPv6 were a viable option for this, then the 
mobile operators would effectively wrestle control of the applications 
running on the handset (and ultimately control of the handset 
capabilities itself away from the handset software vendors) by handing 
control of the number of available IPv6 addresses to the cellular 
operator.  This is, at least, the reason cited by the Android authors 
for the point-blank refusal to implement DHCPv6 in android (bug ID 
32621).  This argument has been carried into the IETF on the basis that 
any attempt to make dhcpv6 a standalone protocol should be resisted in 
all cases because this will hand too much control over to the operator - 
never mind the fact that it is arguably only relevant on cellular 
connections, which are defined by 3GPP rather than the IETF.

Obviously if the Android people refuse to implement DHCPv6 for reasons 
which make sense to their specific use-cases, then it's in their 
interests to ensure that standalone DHCPv6 does not ever become a viable 
option, because that would undermine their ability to continue to refuse 
to implement DHCPv6.

- "I don't need it, therefore you can't have it".  Related closely to 
the previous point, this is one of the most thoroughly disappointing 
positions to take because it screws over other dhcpv6 deployment 
scenarios with scathing regard to their technical or operational 
validity.  This is routinely accompanied by straw-man technical 
alternatives and/or disingenuous lines of questioning, leading to claims 
of lack of consensus, often by the people doing the shouting-down.

Another recurrent line of argument there is where people successfully 
run SLAAC on their home / lab / local networks, and then incorrectly 
extrapolate that because their requirements are fulfilled by SLAAC's 
feature sets, everyone else should be fine too.

Ultimately, operators would prefer the ability to make their own choices 
about how to manage their own network.

If DHCPv6 had the features above, then this whole sorry debate could 
finally be put to bed and everyone could move on with their lives. 
SLAAC people could use SLAAC to their heart's content, and operators who 
preferred DHCP could use DHCP.  However, the current state of play at 
the IETF is blocking this from happening.

It's also not helped that several ietf WG chairs have made it clear that 
they don't want the issue reappearing on their WGs because it causes too 
much shouting.

Engineering / cost concerns play little to no part in the debate.

Nick