Re: DHCPv6lite, RA and WKA

[Ralph Droms <rdroms@cisco.com>]

At 08:35 PM 11/17/2003 +0100, Iljitsch van Beijnum wrote:
>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

This issue has never been found to be a problem DHCPv4.  The appropriate
timers will be added DHCPv6 to provide the same function in
stateless DHCPv6 (as you point out, those timers exist when DHCPv6 is used
for address assignment).

>  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.

"DHCP storm" has never been an issue for DHCPv4, where the problem is
potentially more serious because DHCPv4 is usually used for address
assignment.  What evidence do we have the "DHCP storm" will suddenly become
a problem in DHCPv6?

>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.

I think we should reserve judgment on the additional operational complexity
associated with stateless DHCPv6 until we actually have some operational
experience.   Based on the existing implementations of stateless DHCPv6, I
don't see where the additional operational complexity will come from.

>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?"

If well-known addresses are such a good idea, why haven't we adopted them
for IPv4?

Summarizing from below, I agree that we can specify the use of the 'O' bit
to control the use of stateless DHCPv6 just as the 'M' bit controls the use
of DHCPv6 for address assignment.  I still disagree that the supposed
shortcomings to stateless DHCPv6 given in the first paragraph are sufficient
to warrant the use of well known addresses or the development of an
extension to RAs.

>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>.

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