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
--------------------------------------------------------------------
