IPv6 RA vs DHCPv6 - The chosen one?

Tomas Podermanski tpoder at cis.vutbr.cz
Tue Dec 27 16:16:32 CST 2011

On 12/27/11 10:53 PM, Ray Soucy wrote:
> 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
> fixed-address statements).
> 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.

It was my initial idea to workaround DUID issue. But MAC address in DUID
is not necessary the address of a communicating interface. It can be
derived from wireless interface when a node is connected via an Ethernet
adapter. So I had to leave that idea very soon. In addition, RFC refuses
DUID to be treated in that way :-). There is an  RFC 6221 that solves
that problem, however I haven't seen any implementation yet.


> 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 at cis.vutbr.cz> wrote:
>> Hi,
>> On 12/23/11 7:48 AM, Ray Soucy wrote:
>>> 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
>>> network).
>>> 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
>>> http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html
>>>   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
>> http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml,
>> slides
>> http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf .
>> 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
>> traffic.
>> 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
>>> them.
>>> 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
>>> SLAAC).
>>> 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
>> related presentation
>> http://www.cesnet.cz/akce/2011/monitorovani-kampusovych-siti/p/podemanski-monitoring-ipv6-toku.pdf)
>> . 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.
>> Tomas

More information about the NANOG mailing list