Subject: Rethinking autoconfig, was Re: prefix length determination for DHCPv6

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Sep 2007 11:02:43 +0200

[Tried to send this message to v6ops because of the DHCPv6 discussion  
there, went to the ipv6 list instead, trying again...]

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2007 21:33:56 +0930

On Mon, 17 Sep 2007 11:02:43 +0200

> > whether RA is present or not, and whether M=0 or M=1, despite the  
<snip>

> autoconfiguration process.

What is the motive for reducing the number of packets, and multicast in
particular? I seem to remember a comment in this or a related thread,
regarding concerns that multicast traffic will decrease battery life on
portable wireless devices. If that is a concern, wouldn't it be better
for the the "ultra" power conscious layer 2 to operate in an NBMA
model, rather than a BMA model, avoiding broadcasts or multicasts
completely?

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Sep 2007 14:21:05 +0200

On 17-sep-2007, at 14:03, Mark Smith wrote:

> particular?

Packets use up bandwidth and other resources. The main issue with  
multicast is with wifi and similar networks. Unicast packets are  
acknowledged on those networks and retransmitted at lower speed if  
necessary. With multicast this isn't possible, so those are always  
sent at a low speed and never retransmitted. So they use up more link  
capacity but are less reliable.

In a network such as an IETF meeting network, one or two extra  
multicast packets in the autoconfiguration process can lead to enough  
extra traffic to noticeably impact performance. (Although multicast  
DNS traffic is probably much worse than autoconfig traffic with  
current implementations.)

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Sep 2007 22:06:22 +0930

On Mon, 17 Sep 2007 14:21:05 +0200

> current implementations.)

So what's wrong with using conventional or existing methods to address
or avoid this problem, such as reducing the layer 2 network size,
therefore reducing the number of nodes that can generate multicasts, or
completely abandoning multicast/broadcast operation, by using NBMA
models?

Redoing DHCP seems to me to be a lot of effort when I'd think adequate
and well known solutions to these sorts of problems already exist.
Having a look at the IPv6 NBMA RFC (RFC2491), connectionless
NMBA technologies, such as SMDS, are accommodated. Based on that, I'd
be guessing that wireless ethernet wouldn't be too hard to operate in
an NBMA model if necessary.

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Sep 2007 14:57:17 +0200

> completely abandoning multicast/broadcast operation, by using NBMA

Obviously making good layer 2 networks is always a good idea.

However, IPv6 really needs a multicast-capable network. In the  
absense of additional protocols, I wouldn't even know how to run the  
protocol without VERY extensive manual configuration over a non-broad 
(multi)cast lower layer network.

> and well known solutions to these sorts of problems already exist.

I certainly don't want to "redo" DHCP. The only thing that I suggest  
is an alternative method of _starting_ a DHCPv6 exchange.

> an NBMA model if necessary.

Maybe some of the WIMAX folks could chime in? I understand that's NBMA.

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Sep 2007 07:17:19 +0930

On Mon, 17 Sep 2007 14:57:17 +0200

> (multi)cast lower layer network.

Well, that's what the IPv6 NBMA RFC describes how to automate, using
protocols / methods such as MARS and NHRP. Initially NHRP over Ethernet
seems a bit inconceivable however I was recently looking into NHRP
to better understand it, and found that Cisco implemented NHRP support
for Ethernet back as early as IOS v11.2. I think an implementation
existing, albeit for IPv4, indicates NHRP for IPv6 over Ethernet and
other BMA layer 2s could be a possibility.

From what I was reading last night, it seems that all that is needed to
bootstrap IPv6 over NBMA is the end-node can communicate with the MARS
host. Reserving a well-known unicast/anycast IPv6 and having it
pre-configured within the end node could probably be a way to avoid
having users enter the MARS address manually.

> is an alternative method of _starting_ a DHCPv6 exchange.

Oh, ok.

Regards,
Mark.