mailing list archives
Re: IPv6 RA vs DHCPv6 - The chosen one?
From: Ray Soucy <rps () maine edu>
Date: Tue, 27 Dec 2011 16:53:39 -0500
Much like with IPv4, we capture the DUID at the time of registration
and store it in the database. We make use of a web-based registration
system that allows users to register computers for network access with
a valid ID (that piece is still in development, though).
There is still work to be done on DHCPd for IPv6. Along with the DUID
we need support for specifying and logging IAID (especially with
My initial reaction to DUID was one of complete hatred at first, but
like most things IPv6, having worked with it a while longer, it's
actually quite useful. We just need tools and knowledge to catch up.
So far the biggest "problem" was people creating system images poorly
and not deleting DUID, leading to duplicates. Our systems people know
better these days and it's a non-issue, though.
On a side note, you can build a DHCPd config these days that uses the
MAC address as an identifier, and if a DUID is based on that MAC using
one of the two methods that do, then it will make the association.
It's not ideal, but it is a quick fix to the "we only have a list of
MAC addresses" problem.
I've actually been working to start an open source (free software)
group dedicated to the development of IPv6 infrastructure systems
based on Linux. Hopefully this summer I'll be at a point where we
have some useful technology to provide. You can either talk about the
challenges of IPv6 deployment, or actively try to find solutions to
them for everyone is the general idea.
On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski <tpoder () cis vutbr cz> wrote:
On 12/23/11 7:48 AM, Ray Soucy wrote:
On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski <tpoder () 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
I've watched the webcast and I like it. It's very realistic approach and
I especially agree with opinion that deploying IPv6 means going into
many compromises. We have been faced with very similar (almost same)
troubles that you have been talking about.
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).
We are doing things just in the same way. Using PACL where is it
possible (almost nowhere) and rest of the network we are trying to
monitor. In case when an invalid RA appears we tries to repair it. For
that we use combination of scapy sripts and home made tools (we were not
satisfied with ndpmon, rafixd, ...). My colleague had a talk at that
topic that is available
Having over 120 subnets monitoring is not the perfect solution. Requires
installation of extra probes into each segment (so we do it only for
some segments) and can't solve malicious attacks. But is better than
nothing - for many subnets it is the only thing we can do. At least it
minimizes impact of Microsoft's ICS behavior.
We probably haven't see any malicious attack on that. It's quite
difficult say it for sure, because is quite difficult to distinguish
which RA's are originated on ICS or witch ones are "other" activity. But
remains that monitoring of rogue RA shows to us sometimes a really weird
I believe that is a matter of time when viruses/trojans will start using
IPv6 features to perform DNS hijack as we were able to observe it in
IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective
there is still quite easy solution how to guard against that attack in
the IPv6 environment. I think we all know that solution :-)
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.
In that area we also tried to use longer prefixes than /64, but we had
difficulties on some devices. There was two kind of problems. Some of
devices weren't able properly handle longer prefixes for example in
routing protocols. The second group of devices tries to solve processing
longer prefixes via software. So we had to gave up of using longer
prefixes and now we uses 64-bit prefixes including point to point links
(and hope that nothing will happen). But fact is that was 3 years ago,
so maybe today the situation is much better. I haven't check for long time.
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.
With that we had a little differed attitude. Our idea was preferring
native connectivity instead of running unattended tunneled traffic and
traffic forwarded by ICS. We also were not certain whether SLAAC or
DHCPv6 would be widely used. So we decided to preffer SLAAC because we
wanted support as much system as possible. We also tried to develop our
system solving data retention with connection to privacy extension
(tech report http://www.fit.vutbr.cz/research/view_pub.php?id=9840 and
. It runs quite well in our campus, it is maybye interesting research
project but frankly said I have doubt whether such system is reliable to
use in really large scale.
Now, when apple started supporting DHCPv6 it seems to me that DHCPv6
will be a common way for configuring addresses in a enterprise
environment so maybe we will start thinking about it. There is another
big issue with DUIDs.
Talking aboud DUIDs how do you solve that problem in your environment ?
For v4 we have automatized (home made) system where users register their
MAC addresses and based on it the the configuration for DHCP servers is
created. In your presentation I saw that something similar is used in
your environment as well. Do you use some automatized system for
gathering UIDs or do you have to manually maintain a new DUID after
every re-installation of OS ?
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.
I agree with you. Deploying IPv6 is really not easy and not cheep as
some IPv6 enthusiasts claims. Having practical experience it seems to me
that many things in IPv6 that are very differed comparing to IPv4 (and I
am not sure whether all this differences are really necessary) and that
is the reason why many people and organizations prefer putting off
deploying IPv6 instead investing effort and - of course - money.
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System