DHCP, RA or both? was: Re: DHCP failures

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 3-aug-2007, at 13:16, Ralph Droms wrote:

> The dhc WG has received a request to develop, on behalf of network  
> operators who have expressed the specific requirement that they do  
> not want the operation of their network to depend on RAs, new  
> options for DHCPv6 to pass prefix

Hm, didn't we already have that part?

> and default router information to a host.

That would be new...

> That information would allow a host to get all of its configuration  
> information from DHCPv6, obviating the use of RAs.

> Will the IETF elite allow the standardization of these new options  
> to support this different mode of configuration or will those  
> network operators who would prefer to use only DHCPv6 be forced to  
> continue to use RAs?

That's not a question we can answer in isolation, it depends on our  
collective view of the IPv6 provisioning architecture.

The reason that any way to configure DNS resolver addresses other  
than through DHCPv6 was frustrated for so long was the argument that  
we shouldn't have multiple mechanisms that do the same thing. Since  
using RAs for configuring a host with one or more default routers has  
been the standard for a decade, it seems that sticking to this  
argument would make adding this capability to DHCPv6 impossible.

However, if we agree that DHCPv6 and RA based mechanisms suit  
different users, it makes sense that we give both protocols the  
capability to provide hosts with all essential configuration  
information.

(Cue discussion about what's essential and what isn't. In my opinion,  
all non-essential information and/or information that's too large  
should be handled by a layer of indirection in the form of a small  
set of URLs where it can be downloaded.)

And when we've done all that, we need to figure out how to handle the  
situation where different mechanisms supply conflicting information.

If DHCP and RAs are going to supply the same information, wouldn't it  
make sense to make the option formats the same for easy parsing by an  
implementation that handles both protocols, and for easier  
synchronization between the capabilities of the two mechanisms?

Along the way somewhere someone will have to figure out how the DHCP  
server learns the router's address, as this tends to be neither very  
predictable nor memorable in current implementations and mistakes  
have been known to happen with IPv4 DHCP.