DHCPv6 and stateless autoconf, was: NANOG 40 agenda posted
Iljitsch van Beijnum
iljitsch at muada.com
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.
> 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
>> 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
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.
More information about the NANOG