Re: DNS discovery

[Ted Lemon <mellon@nominum.com>]

On Nov 12, 2003, at 3:07 PM, Tim Chown wrote:
> Could you clarify what I'm missing?

You obviously weren't aware that I hadn't read RFC2461 or RFC2462 since 
the last time I did some serious thinking about DHCPv6, which was quite 
a while ago, and that I had forgotten about the distinction between the 
'M' and 'O' bits.   Shame on you!   :')   You are right, and I 
apologize for stating my case based on my poor recollection, instead of 
going and reading up on the stateless bits first.

My first reaction to this was to say "well, then my point was wrong".  
My second reaction was "so why do so many people for whom I have great 
respect say we should pick one?"

After thinking some more, I think my objection is still correct - I 
just stated it badly because I didn't do my research first.   Let's say 
we use the 'O' bit to say what to do.   What if the 'O' bit is not set, 
but there's no DNS information in the RA?   Is there a protocol written 
down that says what to do in this case?   What if the 'O' bit is not 
set, and there is non-node-address in the RA, whatever that may be, but 
still no DNS information?  Do I do DHCP-lite in this case?   What if 
DHCP-lite gives me information that conflicts with what I got in the RA 
- which do I prefer?

 From the perspective of implementation, in order for a client to work 
correctly in all cases, it has to:
    - Know what to do in the cases I just mentioned
    - Implement DHCP-lite
    - Implement the DNS server RA option, which implies:
      Provide a way for the resolver and the RA listener to communicate.

This sounds doable, but is it in fact the minimal correct solution?   I 
don't think so.   I think the minimal correct solution is to pick one.  
  One reason I like DHCP-lite, as I stated in my previous message, is 
that it doesn't piggyback on a routing protocol, so you don't have to 
tie the RA listener and the resolver together.   So I think it's a good 
choice if we're going to pick one.  And I think picking one is a good 
idea, because it means that you only have to implement DHCP-lite.   You 
don't need to know what to do in the edge cases I talked about.

That doesn't mean we can't describe how to do the more complicated 
two-protocol case.   In the case of a cell phone network, where you 
don't mind hooking the resolver and the RA listener together, and you 
really want to stuff the DNS info in the RA message, you can still do 
it without any extra packet exchanges - you had to wait for the RA 
anyway, and if the 'O' bit is set and there's a DNS server option in 
the message, you're done - you don't have to do DHCP-lite.   But when 
you roam to a network that doesn't provide this functionality, you do 
have to be able to fall back to DHCP-lite.

What this means is that devices for which it's advantageous to use the 
RA DNS server information will have to implement both DHCP-lite and RA, 
and pay attention to the 'O' bit, and devices for which it's 
advantageous to implement only one protocol will just implement 
DHCP-lite.   And system administrators that want devices to take 
advantage of the 'O' bit if possible need to configure things so that 
that works.   Which can probably be done automatically, with no 
operator intervention, in applications like the cell sites.

The other thing this means is that we can move forward now.   
Describing how to make RA and DHCP-lite implementations coexist doesn't 
have to be on our critical path.

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