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. Tomas > > > > > 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 <[email protected]> > wrote: >> Hi, >> >> On 12/23/11 7:48 AM, Ray Soucy wrote: >>> On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski <[email protected]> >>> 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 >> >> > >
