Subject: Rethinking autoconfig

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 19 Aug 2007 14:50:17 +0200

In light of the DHCP discussion, let me repost this message that I  
posted to the ipv6 list a month ago:

On 17-aug-2007, at 22:09, james woodyatt wrote:

>> To stop unnecessary DHCP traffic. [...]

> I think what we're seeing here is a vocal faction of the community  
> who believe that DHCP discovery multicasts are always necessary,  
> whether RA is present or not, and whether M=0 or M=1, despite the  
> text in RFC 2462.

Right.

Over the course of this dicussion and remembering the previous ones  
about the M and O bits and what to do about DNS resolver  
configuration, I've reached the conclusion that DHCPv6 the way it is  
now is too incompatible with other aspects of IPv6 the way they are  
now. Also, even if we ignore the resulting difficulties, there are  
several needs that aren't met today. So I think it would be a good  
idea to take a leap forward and come up with something that actually  
does what we want rather than keep reinterpreting existing  
specifications and implementation behavior.

The goal is to make server-assisted autoconfiguration much more  
useful, and reduce the number of packets in general and multicast  
packets in particular, as well as any delays or timeouts in the  
autoconfiguration process.

The first step is to add an option to the router solicitation message  
that makes it possible to use this message as the start of a DHCP  
exchange. This way, a host doesn't have to know whether it will  
receive configuration through RAs or DHCP or both, and there is no  
delay if there are no RAs. I'm not sure whether the option should  
have a DUID identifier in it or that a small cookie that the DHCP  
server can recognize to see if the host needs new configuration is  
more efficient. Preferably, the option should be no larger than the  
minimum 8 bytes option size.

When the option is seen in a router solicitation, the info is  
forwarded through regular DHCP forwarders, or possibly be turned into  
an existing DHCP message for backward compatibility. Obviously DHCP  
servers on the link will listen for the messages directly. It is the  
job of the DHCP server to determine what type of configuration the  
host requires and respond with a unicast message if a response is  
needed. I'm thinking there are three types of configuration information:

- "shared" other configuration (= configuration items that are the  
same for all hosts on a link)
- host-specific but stateless configuration (i.e., if the DHCP server  
loses state it will still return the same configuration information  
later)
- stateful configuration

In most cases, the shared other configuration shouldn't be sent out  
by a DHCP server, but rather, be included in router advertisements.  
To make this simpler, router advertisements gain the capability to  
include DHCP options.

A new DHCP capability is address registration. This means that the  
host selects one or more addresses autonomously, and then tells the  
DHCP server about those addresses, for the following purposes:

- to avoid DAD
- to allow administrators to know which host uses which address at  
any given time
- to open up firewall holes
- to register addresses in the DNS

I'm not current on the work to reduce duplicate address detection,  
but unless I'm mistaken it should be possible to skip DAD on any  
address derived from an EUI-64 with the global/local bit set to  
"global". If all nodes that use these addresses do in fact derive  
them from an EUI-64 or 48-bit MAC address, then the only way a  
duplicate can happen is when there is a duplicate MAC address and  
then DAD is moot because communication can't happen anyway.

For all other addresses used on multiple access networks, i.e., ones  
where the g/l bit is set to "local" or where no 64-bit interface  
identifier was used because the subnet size is different than /64,  
it's necessary to make sure there are no duplicates. The idea here is  
that DAD and therefore several multicast packets and a timeout can be  
avoided by having a DHCP server keep track of the addresses that are  
in use on a subnet.

I'm assuming the other three uses speak for themselves.

I realize all of this requires significant extra work, but the upside  
is that it will give us a streamlined way to do autoconfiguration,  
both in the case where there is no coordination beyond a router  
advertising its presence and one or more prefixes, in the case where  
everything is managed and in the continuum inbetween, as opposed to  
the current toolbox of loosely related mechanisms that we have a hard  
time getting to work together well.

Obviously the above is only a fairly rough idea, there are lots of  
things to be worked out. If anyone is interested in working on this,  
please let me know in a private message.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------