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

Rethinking autoconfig



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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------