Re: DNS discovery

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Wed, Nov 12, 2003 at 04:49:14PM -0600, Ted Lemon wrote:
> 
> 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?"

Good question.  I am trying to be open minded :)    My head says DHCPv6
is there and can be done now (is being done now).  My heart says lets
not preclude RA method.
 
> 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.

I think the "what to do when a device gets an RA answer and a DHCPv6
answer" question may be avoidable.  The client should only select one
method based on the RA O/M bits.

The hint for configuration comes from the RA O/M bits.   The network provider 
has to configure the RA O/M bits to match the DHCPv6 or RA method that 
they support.

The device does not care if it is getting the O-bit DHCPv6 options via
"stateful" DHCPv6 or "stateless" DHCPv6 light.   

Cases are, if we assume O=0 means RA method is used:

1) M=1 O=1: Stateful address autoconfiguration, DNS options by DHCPv6

2) M=1 O=0: Stateful address autoconfiguration, DNS options by RA 

3) M=0 O=0: Stateless address autoconfiguration, DNS options by RA

4) M=0 O=1: Stateless address autoconfiguration, DNS options by DHCPv6

I think of the above (2) is the only improbable scenario.  The other
cases are valid for different types of networks.  I would hope (2) could
simply be discarded.

So I think the RA "hint" and service provided should always be in sync;
the problem is what support the client has, and in particular then
how/if you fall back when client support is not present for the method 
"hinted" by the RA.

The DHCPv6 camp is really suggesting cases (1) and (4) are the only
valid RA option settings that should be used.   This creates simplicity,
but at a cost of flexibility.

Consider client support.   We assume all devices have stateless address
autoconfiguration ability, so we don't have to fall back from that to DHCPv6
(full) for address autoconfiguration.

So that leaves these cases:

Case 1:
 - no DHCPv6 (full) => fall back to case (4)
 - neither DHCPv6 (full) or DHCPv6 (light) => fall back to case (3)
 - if the client has DHCPv6 (full) it has DHCPv6 (light)

Case 3:
 - no RA method for DNS options => fall back to case (4)

Case 4:
 - no DHCPv6 (light) => fall back to case (3).

So the real concern are these four fallback cases, and the delays or
other implications they have (like whether you will actually find a method
that works at all!).   A minimum agreed single method gives a guarantee 
that one fallback will work ....

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