Re: DHCPv6lite, RA and WKA

["Jaehoon Paul Jeong" <paul@etri.re.kr>]

I completely agree with both Iljitsch and Bob Hinden
at the point of making basic RFCs of RA and WKA  for DNS discovery.
Until now, many people have described these two schemes well enough 
in addition to DHCPv6-lite.
Through the experience in the actual world, we can verify the coexistence of these three schemes
or know which is the most preferable in each application domain in the aspect of practical use.
If many people in DNSOP wg agree with my opinion, I will start to implement my proposal of
RA-based DNS discovery in order to progress the coexistence with the other schemes.
Thanks.

/Jaehoon

----- Original Message ----- 
From: "Bob Hinden" <bob.hinden@nokia.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>
Cc: <dnsop@cafax.se>
Sent: Wednesday, November 19, 2003 9:48 AM
Subject: Re: DHCPv6lite, RA and WKA


> 
> Iljitsch,
> 
> I think you make a very good case for going in this direction.  A few 
> comments in line.
> 
> At 11:35 AM 11/17/2003, 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 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.
> 
> As you point out below, all three mechanics could coexist in a hierarchy.
> 
> >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?)
> 
> A slightly different approach is to start with well known addresses.  If an 
> RA option is heard (probably in the same RA with the prefix) with new DNS 
> addresses give these priority over the well known addresses.  If the RA 
> messages tell the host to use DHCP for "additional stateful config", then 
> request this information via DHCP.  If new DNS addresses are received via 
> DHCP, then give these priority over any other DNS addresses known by the hosts.
> 
> >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.
> 
> Perhaps four pages each, but I am in complete agreement with your point!
> 
> Bob
> 
> #----------------------------------------------------------------------
> # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> 

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