DHCPv6 and stateless autoconf, was: NANOG 40 agenda posted

Wed May 30 19:10:02 UTC 2007

On 30-mei-2007, at 20:16, David W. Hankins wrote:

>> DHCPv6 can't provide a
>> default gateway, you need stateless autoconfig for that even if you
>> use DHCPv6 for address assignment.

> I think you mean "router advertisement", not stateless autoconfig.

Sure.

> On this topic, DHCPv6 also can't deliver a subnet prefix to clients.

That's not a huge deal in IPv6 because the router will redirect if  
you communicate with someone on the same physical subnet.

> These are only delivered by router advertisements containing prefix
> options (not all router advertisements will contain prefix options,

It's common that routers automatically include the prefixes for their  
own addresses in RAs. Ciscos even automatically enable RAs as soon as  
they have a global address.

> Logically, they can't talk to one another without an advertising
> router present.

If you can spare a DHCPv6 server, then a router wouldn't be too much  
of a problem, I'd assume. There is also the on-link assumption,  
although that's not universally implemented, and the ability to run  
things on link-local addresses.

> So...I think how these two protocols comingle could use some work.

DHCPv6 itself needs work, it's basically two protocols: stateful and  
stateless, and the client needs to know which to use. You need the  
RAs anyway so do stateless autoconf and save yourself the trouble of  
running another rather complex binary UDP protocol, which don't have  
great security track records.

> In truth, I think we should just ditch rtadv/rtsol and add routers
> and subnet-mask options to DHCPv6.

You are aware that most IPv6 implementations out there don't even  
support DHCPv6, right? This would take the better part of a decade.

It's also the wrong thing to do. When there are several routers, and  
one dies, IPv6 can (fairly) seamlessly move to another by virtue of  
dead neighbor detection. If the router listed in the DHCP info dies,  
you're dead in the water.

> That's a shorter path with more
> finality than the pandora's box of adding options to rtadv.

Adding options to DHCPv6 is easier/better than adding options to RAs  
why exactly?

>> And there is the extra info, but DNS resolvers may be availalbe in
>> stateless autoconfig in the future as well.

> Again, you mean in rtadv.  Is it just me, or does it seem unusual
> for network infrastructure to advertise host configuration
> parameters?

It's not unusual at all. Pretty much all routers implement DHCP for  
IPv4 and are thus capable of doing this today. It's the notion that a  
separate server is needed to make a network usable that's strange.

> Maybe I'm getting old, but the idea of managing this configuration
> information in my routers sounds like a real chore compared to the
> old DHCP relayed central server model.

If you like DHCP, fine, run DHCP. But I don't like it, so please  
don't force _me_ to run it.

>> This is probably the way we want to do IPv6 address provisioning for
>> end-users in the future, but that requires that home gateways that
>> implement IPv6 routing functionality come with the DHCPv6 prefix
>> delegation client capability and have this configured by default so
>> it all works out of the box.

> There's also a bit of a hinky issue in routing the delegated prefix
> to the client.  Obviously, you don't trust route advertisements
> from the client - you're not going to run OSPF or BGP with all your
> broadband customers.

I think with the Cisco implementation this is taken care of if you  
run a DHCPv6 prefix delegation server in the access router that talks  
to your customer's routers.

> How to "do this" in a way we can all just plug and play hasn't quite
> been decided yet.

Right.