nanog mailing list archives

Re: DHCPv6 and stateless autoconf, was: NANOG 40 agenda posted


From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Wed, 30 May 2007 21:10:02 +0200


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.


Current thread: