IPv6 RA vs DHCPv6 - The chosen one?

Ray Soucy rps at maine.edu
Fri Dec 23 06:48:37 UTC 2011

On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski <tpoder at cis.vutbr.cz> wrote:

> Well, then how many devices do you have in the network that uses IPv6?

Good question, and I applaud you for wanting to verify that people
talking about IPv6 have legitimate experience deploying it.

I dug into the database I log all IPv6 traffic into.  We have 8,509
active hosts using IPv6, that's in comparison to 35,229 on the IPv4
side, so about 24% (mind you, this is only the LAN networks we manage,
we provide IPv6 transit to other entities as the regional R&E

At this point over 95% of IPv4 LAN networks have IPv6 available,
wireless is still a challenge (which is a big part of the difference
between the host numbers you see above).

We participate in Google's trusted IPv6 program, so Google announces
AAAA's to us for nearly all their services, so a significant amount of
bandwidth is actually over IPv6.  I would say that Google does make up
the majority of IPv6 traffic though; there isn't much else out there
announcing AAAA's yet.

We have always taken the approach that IPv6 isn't ready to be deployed
if you can't do so while maintaining the same standards you have for
IPv4 in the areas of manageability, security, availability, and
stability.  And we literally spent a few years modifying internal
systems (and implementing new ones) to support IPv6 before we started
making it available. See
  for the case I've been making the last few years, or listen to me
(and others) talking a little about it on Cisco's Higher Education
webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html

> Do you have implemented first hop  security? What will you do when some
> user runs RA flood attack

You can hear me talk a little about that in the Cisco webcast.  Right
now we maintain a PACL on our switches that filter RA or DHCPv6 server
traffic originating from access ports.  As you mentioned it doesn't
protect against malicious attempts to disrupt services on the network
(fragmented packets) but it does add a reasonable level of stability
(e.g. prevent Windows ICS) to levels that are similar to IPv4.  In
addition, we have a process that monitors our routers for new RAs on
the network, and alerts us to that (which would let us respond to a
malicious RA that got past the PACL).

For neighbor table exhaustion, I've written a set of scripts that I
can use in a lab environment to perform the attacks against the
platforms we use, and test how they fair.  There is a pretty wide
range of results.  Most of the larger platforms that are the ones we
would be concerned about actually hit CPU limitations before neighbor
table exhaustion is accomplished, mainly because the neighbor
discovery process doesn't appear to be implemented in hardware.  It
doesn't take much to pull off the attack either; a handful of
residential connections would do the trick.  This isn't an IPv6
problem so much as a vendor implementation problem, though.  Like most
DoS and DDoS attack vectors, vendors will need to take extra steps to
harden equipment against these attack vectors as they become aware of

Until vendors catch up (and that includes us having the funds to
upgrade to new platforms that do a better job with it), we have opt'd
to make use of longer prefixes than 64-bit (in fact we mirror the
capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in
IPv6).  A good description of this is available in some slides by Jeff
Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf

While your mileage may vary with longer prefixes, with the same
attacks we saw the impact on CPU usage to be less than half when
longer prefixes were used, and that's pretty good.  You can also keep
external attacks from reaching internal routers if you don't do route
summarization internally, which sees considerable gains, as more of
that logic appears to be in hardware.

On the deployment side, we make use of DHCPv6 and RA with M and O set,
and A unset.  Our DHCPv6 servers only hand out IPv6 addresses to
registered systems that are in the database and have been flagged as
OK for IPv6.  This has allowed us to roll out IPv6 on a host-by-host
basis, rather than a network-wide basis (as you would need to do with

This does have the consequence of excluding hosts from IPv6,
piticurally Windows XP systems, and pre-Lion OS X systems.  But since
IPv6 isn't "required" yet (there is really no IPv6-only content yet),
we take the position that we only provide IPv6 to systems that support
DHCPv6 and have an adequate IPv6 host-level firewall as part of their
IPv6 implementation.  This makes it easy to exclude hosts that might
be problematic to deliver IPv6 to, due to lack of security, or even
bugs (RHEL 3 can kernel panic when connected to over IPv6, for
example).  It also keeps the pressure on to upgrade legacy systems.

Wireless is an area we would really like to move forward with IPv6,
but we still have concerns that need to be addressed before that can
happen.  In a Cisco environment, like ours, for example.  IPv6
requires Ethernet Mode Multicast to be enabled on the WLAN.
Unfortunately it doesn't provide tools to filter which multicast
traffic is permitted, and at the scale we deploy wireless it just
isn't practical.  We might be able to re-architect wireless to better
handle this, but that's a future project.

I think the big picture here is that IPv6 isn't as "easy" as it should
be for large deployments just yet, but that's the case with any new
technology.  The more people who begin to work through it, the more we
will identify problems, and work to resolve them.

The almost religious debate of RA vs DHCPv6 gets a lot of attention,
but there are much more important issues in my view; like making sure
our routers and switches provide the functionality we want them to,
and this is an argument that takes away from that.  Over 10 years of
implementation for IPv6, both RA and DHCPv6 work nicely, well enough
that they are reasonably functional and flexible.  We can look to
enhance them, but that will take another 10 years to wait for
implementations to be updated (and then users to upgrade).  I would
much rather focus the energy of this list to things like neighbor
table exhaustion, RA guard, etc. and getting vendors to understand the
importance of addressing these concerns.  It's a lot easier to upgrade
one router than a thousand hosts.

Furthermore, DHCPv6 "Other Only" implementations are trivial if you
want to use SLAAC for DNS, and most routers already support it.
DHCPv6 may not be the only option for DNS in a few years.  Things from
the ZEROCONF WG like multicast DNS for example (or even an anycast DNS
standard) will more than likely come into play, allowing SLAAC without
DNS information or DHCPv6 to function just fine on its own.  IPv6 is
also designed to last quite a while.  We might not always be using
DNS, something better might come a long, and keeping that out of RA
would be my personal preference.  But options are always good, and I
have no problem adding DNS to RA and route information to DHCPv6; just
understand that even if we do get these implemented, you won't be able
to use them as a standard for another 5 years at minimum; it would be
nice to see IPv6 adoption not be held up over re-designing something
that already gets the job done.

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

More information about the NANOG mailing list