[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
From: Ralph Droms <rdroms@cisco.com>
Date: Thu, 02 Oct 2003 20:39:12 -0400
In-Reply-To: <4.3.2.7.2.20031002161548.036620f8@mailhost.iprg.nokia.com>
Sender: owner-dnsop@cafax.se
Subject: Re: How IPv6 host gets DNS address

I think the slippery slope is not so much the options, but rather the
requirement that a stack implement both mechanisms.  That is, the
stack - not knowing which of RA or DHCP might be in use where the device
might be attached - must have both the RA and DHCP implementation.  The
problem gets worse if more options get added, perhaps in parallel, to both
RA and DHCP.  With Bob's suggestion, the specification of the two
protocols in parallel seems easy enough.  But the stack implementer will
have to add code for any new options to both RA and DHCP.

- Ralph

At 05:04 PM 10/2/2003 -0700, Bob Hinden wrote:
>Doug,
>
>>The problem with this argument is that it's a slippery slope. It sounds
>>totally reasonable to say, "As long as we have X, we might as well
>>include Y." However, the address(es) of the recursive name servers
>>aren't that useful without a search list. Then, once you get into a
>>windows environment you really need the netbios name server address....
>>etc. Once you get done with that, you've invented something that looks
>>an awful lot like dhcp.
>
>To clarify by slippery slope, I think you mean creating two sets of 
>options (e.g., one for DHCPv6 and one for RA's) as both DHCPv6 and IPv6 
>neighbor discovery are existing protocols.  It seems to be this can easily 
>be avoided by creating an ND option that can carry a DHCPv6 option.  The 
>ND options are <type><length> form so it should be easy to define a new 
>one that said the contents was a DHCPv6 option.   This seems very simple to me.

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

Home | Date list | Subject list