Another Big day for IPv6 - 10% native penetration
Hi, according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883. I'm wondering when we reach another significant milestone - 50% :-) Tomas Original Message Subject:Big day for IPv6 - 1% native penetration Date: Tue, 20 Nov 2012 10:14:18 +0100 From: Tomas Podermanski <tpo...@cis.vutbr.cz> To: nanog@nanog.org Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.
Fw: new message
Hey! New message, please read <http://dinkinsautoservice.com/opinion.php?cm9w> Tomas Podermanski
Re: IPv6 adoption in the past few days
False alarm. Sorry for vain hope (if there was any). IPv6 is back in normal. Seatbelts can be unfasten. T. On 6/24/13 2:39 PM, Randy Bush wrote: there is massive increase in IPv6 adoption (from 1.5% to 1.7%) in the past few days. luckily i had my seatbelt fastened randy
IPv6 adoption in the past few days
Hi, according to Google IPv6 statistics (http://www.google.com/intl/en/ipv6/statistics.html) there is massive increase in IPv6 adoption (from 1.5% to 1.7%) in the past few days. I think it is the biggest increase ever. Does anyone have any idea what happened? T.
L2 redundant VPN
Hi networking guys, I need some help :-). We try to find for our department reliable solution for L2 VPN. The task is to connect two remote data centers, each of them connected two 1Gbps lines (with link aggregation). Only IP connectivity between data centers is available (so there is no possibility to create circuit based on MPLS or something like that). The basic problem is that high reliability is required, so the solution have to be fully redundant. The initial idea was about two OpenVPN servers in each data center + two switches (HP E5800) joined into one logical switch via VRF. The link failure is based on LACP packets between both data centers. The solution works, however performance of OpenVPN is really creepy. The maximum we were able to get from this configuration was about 100Mbps. We expect at least 500Mbps (or more in the future). In our thoughts then we were thinking about l2tp on some cisco/HP(H3C) device, however there is little information about performance of that solution and I am not sure how the failure detection would work in redundant configuration. Have anybody some experience with similar solution or at least any idea ? Thanks a lot for thoughts Tomas
Big day for IPv6 - 1% native penetration
Hi, It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.
Re: Big day for IPv6 - 1% native penetration
Hi, On 11/20/12 7:24 PM, Blair Trosper wrote: I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up. However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me. Turning IPv6 on at the basic/core of the infrastructure is the easiest part of the job. However turning IPv6 for customers requires a lot of effort and compromises. Some of the reasons are described in: http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-perspective/ and related presentation: http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/23/11 7:48 AM, Ray Soucy wrote: On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@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 RE 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 '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 '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
Re: IPv6 RA vs DHCPv6 - The chosen one?
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 tpo...@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 tpo...@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 RE 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 '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 '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
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/23/11 7:07 AM, Mohacsi Janos wrote: On Thu, 22 Dec 2011, Tomas Podermanski wrote: Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. This is implementation issue. Has to be fixed. Or your have to think about port-security Port security does not help in that case (same as 802.1x). Port security is a layer 2 feature so all layer 3 attacks can be still performed. That prevents only against source MAC address spoofing. All other attacks like DAD DOS, NDP Exhaustion, RA flooding etc. can be performed even though the port security is implemented. I am very interested how the sites with similar number of access ports (users/customers) solve that problems. If users are not seperated by interfaces you can see similar issues in IPv4 (spoofing attacks) That is true, but we know solution for IPv4 (DHCP snooping, ARP protection, source address validation) and there are access switches on the market having that security features. Switches supporting such features for IPv6 are usually much more expensive. And there is another problem. Although you have money for that hardware it does not protect you against malicious attacks. Tomas I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. - DHCPv6 is currently tied with SLAAC (M,O
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/23/11 4:33 AM, Owen DeLong wrote: Sent from my iPad On Dec 23, 2011, at 3:46 AM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, On 12/22/11 12:18 AM, Owen DeLong wrote: The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. I agree that the requirement to run both is broken. I don't agree that this means we should remove the option of using SLAAC in environments where it makes sense. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments So? It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system: 1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario: 1. DHCP options are processed by dhcp-client Except when they are processed by BIOS, Kernel, or something else. Sure, in all this parts (you probably meant PXE, network booting) we will have more difficult code. If developers are ok with that and I will have all that code in PXE, grub and a kerel code... Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way. - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) SLAAC and DHCPv6 can't really provide conflicting information unless the router is misconfigured. Even if a host gets different answers for the same prefixes from SLAAC and DHCP, it should be able to use both host addresses. There's the question of source address selection, but, the answer to that question at the IETF level should only be a matter of what the default answer is. There are configuration options for setting host source address selection priorities. I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ... If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. Solved for SLAAC -- SEND. Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any actual implementations yet. Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be: If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4. I can not agree with that. Many operators having customers into a shared segment and uses security features I mentioned before ( again DHCP snooping, ARP protection, source address validation). In IPv6 is quite difficult to implement
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/23/11 6:56 AM, Mohacsi Janos wrote: On Wed, 21 Dec 2011, Tomas Podermanski wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment Your opinion is very extreme. Another extremity would be to add some extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms have their merits. They have to interporate! Every environment should develop their policy according to their needs! The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments They already do. If not they have to be fixed. It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. So any manufacturer of operating systems or devices do not have to support DHCPv6. - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) Administrators are deliberately providing conflicting information? Not administrators, but attackers then could have more ways for harmful activity. - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. This can be an argument for remove DHCPv6 completely Why not :-), but SLAAC can provide only a subset functionality comparing to DHCPv6. It is actually the reason why DHCPv6 was added into IPv6. Sothe world without DHCPv6 had already been there. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. Some operating system do the SLAAC processing in user space. What is the problem. As I wrote. Troubleshooting is more difficult. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. I think it is matter of implementation. Because DHCPv6 is depended on a information provided by SLAAC (RA messages) and DHCPv6 client have to wait. I hope that this dependency will disappear when the route option is added into DHCPv6. Nice thread on this topic is on http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. But suitable in certain environments. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by connection sharing in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) Their is an RAguard RFC to prevent this. - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. - With SLAAC is difficult to implement security features like ARP/ND protection/inspection, IP source guard/Dynamic lock down, because all this techniques are based on a MAC-IP database created during a communication with a DHCP server. There are some attempts (ND protection, SAVI) but it does not provide the same level of security. What is missing? It works quite well in DHCPv6 only environments (with M
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/23/11 9:09 PM, Ray Soucy wrote: On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: That is true, but we know solution for IPv4 (DHCP snooping, ARP protection, source address validation) and there are access switches on the market having that security features. Switches supporting such features for IPv6 are usually much more expensive. And there is another problem. Although you have money for that hardware it does not protect you against malicious attacks. Yes, and over time similar Layer-2 security features will become available for IPv6 by default. The more people who work to deploy IPv6 and express these concerns to vendors, the more likely vendors are to give them priority. RA Guard is one such example where vendors have responded to community concerns and have begun to implement the functionality. All these problems exist for IPv4, and I would go as far as to say that the vast majority of networks don't even implement things like ARP inpsection, DHCP snooping, IP source verification, UUFB, etc. They're things that dramatically increase network stability, and things that are used by those of us who run larger networks, but they are certainly not typical by any measure. I agree with you, that is not typical for many networks. For example in our network we have enabled some of that features (not all) only in some subnets. Unfortunately those subnets connects over 70% of our users (6500). Is also great that many produces are going to take that issues seriously. Actually we have quite big concerns with decision if: 1. to buy cheaper access switches (like HP 42xx) that have security features for IPv4 but will never have support for IPv6. The hardware does not support IPv6 at all. In that case we will be able to replace access switches in quite short time - one year. And in next five years we will be buy a brand new generation of switches that will have all those problems solved (I hope). or 2. to buy much more expensive switches (like HP 54xx) that supports some basic security features for IPv6 and there is some a probability that other features will be implemented. So we will be able to use ra-guard and ACLs immediately. In that case there is still a chance that some features will not be implemented due to hardware limits. So we will have to buy new generation of switches again in five years. Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. I am very interested how the sites with similar number of access ports (users/customers) solve that problems. I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by connection sharing in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) - With SLAAC is difficult to implement security features like ARP/ND protection/inspection, IP source guard/Dynamic lock down, because all this techniques
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: On 12/21/11 12:40, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. And that's a very good reason not to deprecate SLAAC. Tomas may prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6. Many of us have been working with IPv6 for years and have found SLAAC to be quite useful. The biggest benefit it provides, which Tomas did not acknowledge, is the ability to autoconfigure hosts without running a central server. That said, I have also found DHCPv6 to be quite useful. We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). I also agree with Owen: Provide two complete solutions, and let operators choose based on their needs. That implies fixing DHCPv6 so I don't have to go in and disable the autonomous flag on my routers and run RAs just to get a default route. But it also implies not deprecating either SLAAC or DHCPv6. Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that fixing DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/22/11 12:18 AM, Owen DeLong wrote: The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. I agree that the requirement to run both is broken. I don't agree that this means we should remove the option of using SLAAC in environments where it makes sense. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments So? It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system: 1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario: 1. DHCP options are processed by dhcp-client - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) SLAAC and DHCPv6 can't really provide conflicting information unless the router is misconfigured. Even if a host gets different answers for the same prefixes from SLAAC and DHCP, it should be able to use both host addresses. There's the question of source address selection, but, the answer to that question at the IETF level should only be a matter of what the default answer is. There are configuration options for setting host source address selection priorities. I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ... - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. Solved for SLAAC -- SEND. Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any actual implementations yet. Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be: as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx However, Microsoft does not support SEND in any version of Windows. I have found only one implementation for Linux (http://amnesiak.org/NDprotector/) that is not ready for production. So we can not think seriously about SEND today. SEND also brings another set of problems like certificate management, etc., but is a little differed story. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. That seems like an argument for SLAAC, if anything. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. While I agree with you that the standard is broken in this regard, there is at least one OS vendor that already violates that rule anyway. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. Yes, but, it does it in a much simpler way with a lot less overhead which can be a benefit in some environments. I have to admit that less overhead is one of benefit of SLAAC. But having experience with DHCP(v4) all devices that we have today (phones, cameras, etc.) do not have a problem to process DHCPv4 packets, so there is no reason why same devices could not do it for DHCPv6. The sensor networks mentioned in one mail before is a very special case of use. I believe SLAAC might be useful there but is not typical case. - SLAAC is
Re: IPv6 RA vs DHCPv6 - The chosen one?
.pdf [2] IPv6 - security threads http://www.fit.vutbr.cz/research/view_pub.php?id=9835 [3] Deploying IPv6 in University Campus Network - Practical Problems http://www.fit.vutbr.cz/research/view_pub.php?id=9836 Regards, Tomas Podermanski On 12/20/11 8:31 AM, Owen DeLong wrote: Different operators will have different preferences in different environments. Ideally, the IETF should provide complete solutions based on DHCPv6 and on RA and let the operators decide what they want to use in their environments. Owen On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: Hi, IPv6 devices (routers and hosts) can obtain configuration information about default routers, on-link prefixes and addresses from Router Advertisements as defined in Neighbor Discovery. I have been told that in some deployments, there is a strong desire not to use Router Advertisements at all and to perform all configuration via DHCPv6. There are thus similar IETF standards to get everything that you can get from RAs, by using DHCPv6 instead. As a result of this we see new proposals in IETF that try to do similar things by either extending RA mechanisms or by introducing new options in DHCPv6. We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends DHCPv6 to do what RA does. And now, we have draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise the NTP information that is currently done via DHCPv6. My question is, that which then is the more preferred option for the operators? Do they prefer extending RA so that the new information loaded on top of the RA messages gets known in the single shot when routers do neighbor discovery. Or do they prefer all the extra information to be learnt via DHCPv6? What are the pros and cons in each approach and when would people favor one over the other? I can see some advantages with the loading information to RA since then one is not dependent on the DHCPv6 server. However, the latter provides its own benefits. Regards, Ravi D.
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
Hi Daniel, all IPv6 multihoming ideas are very theoretical today. None of them is ready to use. Shim6 looks very good, but it requires support on both a client and a server side. As you can guess, there is only experimental support for some operating systems. Microsoft and Apple doesn't support it. A one possible solution I have found is based on a network prefix translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using NPTv6 you can do multihoming that is very similar to multihoming based on IPv4 NAT. I haven't found any commercial product that supports it, but you can use an implementation for Linux (map66 http://sourceforge.net/projects/map66/). Assembling map66 with some other scripts (to detect link failure) you can have what are you looking for. On 4/7/11 11:58 AM, isabel dias wrote: have you thought about taking a Cisco training course? I wonder if that kind of knowledge can be learned in any Cisco course today. I don't think so. Tomas - Original Message From: Daniel STICKNEY dstick...@optilian.com To: nanog@nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2 (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches as well as Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]. After the comparison of all host-centric methods it adds [...], the IETF has decided by the end of 2004 to foster the SHIM approach. This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel
