Re: [v6ops] dhcpv6-slaac-problem

[Iljitsch van Beijnum <[e-mail]>]

On 30 mrt 2013, at 9:54, Brian E Carpenter <[e-mail]> wrote:

> I think people should look at draft-liu-bonica-dhcpv6-slaac-problem,
> because it really is time to resolve this issue. And it's
> orthogonal to the default/source route issue.

That draft mainly looks at what happens when the different bits go from 1 to 0. While it's useful to clean up the differences in behavior for that case, all of that seems largely orthogonal to the issues we were discussing previously.

Other than the above, my vote is for leaving well enough alone.

But if we collectively decide that the status quo is insufficient, we need to make changes in the right way, not haphazardly throw new DHCP options against the wall and see which ones stick.

Going back to first principle, if we want to support both some form of stateless autoconfiguration as well as some form of centrally managed configuration, it makes sense that hosts send one message that can initiate either or both rather than have two protocols that operate independently. This saves on messages exchanged, timeouts incurred and client-side guessing required.

Fortunately, it looks like the IPv6 designers knew what they were doing (for the most part) back in the day, and allowed pretty much every message to have options. So what we could do is put a DHCPv6 request inside a router solicitation message, and thus have a single message that can initiate both stateless autoconfig and DHCPv6. We now also have a clean upgrade path: old hosts don't include the DHCPv6 request and get back a normal RA (with A=1 and/or M=1 as desired). The same is true for new hosts that talk to old routers. But when a new host talks to a new router, we get to throw out all the old behavior. Then, for instance, the router can send back a regular RA, or relay the DHCPv6 message to a DHCPv6 server, which can take it from there.

Iljitsch