DHCPv6lite, RA and WKA

[Iljitsch van Beijnum <iljitsch@muada.com>]

I do understand the concerns the proponents of DHCPv6lite-only have 
with regards to having more than one mechanism. The general software 
engineering approach is "put all your eggs in one basket, but be sure 
you're making one hell of a basket". I disagree this applies here, 
though.

I believe the situations where DNS addresses need to change and when a 
large number of hosts connect to a subnet simultaneously uncover 
problem areas with DHCPv6lite. The former can be handled by a full 
stateful implementation of DHCP, but using such an implementation when 
all that's needed is distribution of DNS addresses isn't attractive. 
Avoiding a "DHCP storm" when a large number of hosts connect isn't 
readily solvable without creating additional mechanisms, also not 
attractive.

For this reason, and because running the DHCP(lite) service results in 
additional operational complexity and security risks on both the 
servers and clients, I feel very strongly that we need a non-DHCP 
mechanism for determining DNS resolver addresses that can be used 
together with RFC 2462 IPv6 address configuration. This mechanism can 
either be an RA option or well-known addresses.

What I don't understand is the fear of well-known addresses. This 
subject seems to have an extensive history, but I can't seem to find 
the actual arguments, as the discussion has long since deteriorated to 
kindergarten level: "Would you want 200 million devices to be shipped 
with the DNS of your organization burned into ROM?"

Obviously the well known addresses for DNS resolvers shouldn't come 
from regular unicast space that is assigned to an organization. At the 
very least these addresses should be sitting in portable blocks so they 
can be moved around without impact to the organization hosting one (or 
more) of them. Another option would be anycasting the addresses in 
question. The best way to handle this would probably be for a small 
number of organizations to host a well know address each, and allow 
sites and ISPs to anycast the addresses within their AS. So a host 
within a site anycasting the DNS WKA the host has selected for a query, 
the request will be handled by a local DNS resolver. If the site 
doesn't anycast the address but the ISP does, the query goes to the ISP 
DNS resolver. If the ISP doesn't anycast either, the request goes to 
the organization hosting the WKA.

I don't believe the permutations of when to use which mechanism in the 
presence of multiple mechanisms are too complex. It boils down to 
"listen to the "additional stateful config" flag". The only situation 
where this leads to sub-optimal results is in the case where router 
advertisements indicate the use of DHCPv6lite for additional 
configuration, but the DHCP negotiation fails. When this happens, the 
presence of another configuration mechanism allows the host to function 
anyway. The choices are relatively straightforward:

1. Configure WKA or RA, overwrite with DHCP after DHCP completes
2. Configure WKA or RA only after DHCP fails

(Alternatively, what should happen in the case where the "additional 
stateful config" flag isn't set but there are no non-DHCP mechanisms 
available to configure DNS resolver addresses?)

I understand it's annoying to keep having this discussion, but 
annoyance doesn't configure DNS resolvers, so let's come up with an 
approach (nearly) everyone can live with and put this all to bed. After 
all, we're talking about a two page RFC (excluding the boilerplate) for 
either WKA or RA, this all pretty basic stuff.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.