The stupidity of trying to "fix" DHCPv6

Leo Bicknell bicknell at
Tue Jun 14 20:25:13 UTC 2011

In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:
> This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.

The problem for most folks is that it becomes an "in addition to"
thing to support, troubleshoot, and debug.  To make that ok, you
have to look at the cost/benefits.

I urge everyone in this thread to try a simple experiment.  Configure
an IPv6 segment in your lab.  Make sure there is no IPv4 on it, not
on the router, and that the IPv4 stack (to the extent possible) is
disabled on the hosts.  Now try to use one of the hosts to access IPv6

You'll find the box does SLAAC just fine and gets an address.  You'll
find RA's provide a default gateway and can get your packets out to the
world.  You'll also find absolutely nothing works, at a bare minimum
because you have no DNS servers.

People aren't noticing this today because they are dual stack, and end
up reaching their DNS servers from IPv4 DHCP information over IPv4
transport.  They may then get AAAA's, and use IPv6 after that.

Your box is dead in the water.  How do you get DNS servers?  Today
the answer is to run DHCPv6.  Of course if you need other options
(netboot information, NTP servers, domain controllers, and so on) you
also need DHCPv6 to get a functioning box.

So just like in IPv4, IPv6 requires DHCP to have a functioning end user
box.  DHCP remains a hard requirement.  The odd part now is that in IPv4
DHCP carries the default gateway, while in IPv6 land you must also run
Router Advertisements on your router and have the host listen to them.

The industry has taken a robust single protocol solution and turned it
into a dual, co-dependent protocol situation.

The IETF is working on one solution, which is to add DNS information to
the RA's!  So now you'll configure your routers to hand out DNS servers
to clients, and then everything else (NTP servers, Domain Controllers,
etc) in DHCP!

What I and others are suggesting is the other way around, how about we
just put a default route in DHCPv6 like we did in v4, and forget all
about RA's so we're back to a single protocol solution?

Beyond that it is important to notice that the failure modes and attack
vectors for RA's and DHCP are different.  I argue DHCP is "better", but
I also realize that's a very subjective judgment.  That said, there
are cases where people may prefer DHCP's robustness and/or failure
modes, and cases where people might prefer RA's.

Lastly, there's a hidden bit here many people haven't dealt with
yet in lab networks.  In IPv4 critical environments it's typical
to use HSRP or VRRP to provide a single gateway across two routers.
The IPv6 way to do this is to have both advertise RA's, possibly
with different priorities.  Depending on your environment this may
or may not be as "feature rich" for you.  For instance RA's timers
aren't as adjustable (as they depend on end hosts), and I don't
know of any vendor who implements interface tracking for RA's the
way it is done with HSRP/VRRP.

We need more folks using IPv6 in production to find this stuff.  If you
spin up a dual stacked box in the lab with a single router RA's work
great, DHCPv4 gives you DNS, and you'll never notice any issues.  Run a
dual-router IPv6 only production network for some end users, and you'll
notice some differences, and I think find that some of those differences
are deficiencies.

       Leo Bicknell - bicknell at - CCIE 3440
        PGP keys at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <>

More information about the NANOG mailing list