Re: IPv6 Deployment for the LAN
Thought this off-list reply would be of interest to many here: On Sun, Oct 18, 2009 at 1:43 PM, Daniel G. Kluge wrote: Hello Ray, on the Subject on DHCPv6 for MacOS, there were some discussions on the IPv6-dev lists on Apple, with the usual comment from Apple engineers, that they are not authorized to discuss plans on product features. If you have a substantial MacOS population, I'd recommend to join the discussion, and chime in for support of DHCPv6 on MacOS. The two recent threads on DHCPv6 are: http://lists.apple.com/archives/Ipv6-dev/2009/Sep/msg00018.html http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg3.html The first one is from the perspective of service providers, the latter one from the perspective of enterprises and educational networks Cheers, -daniel I'd like to urge everyone to send in bug reports to Apple as described in the mailing list posts above requesting DHCPv6 in OS X. Thank you, Dan. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
TJ wrote: It is still the router, a piece of managed infrastructure sending out the information - not like we are encouraging hosts to make up their own prefix info here ... and hosts choosing the low-order bits shouldn't matter that much. But that's the fatal flaw of autoconfiguration. Hosts chosing the low-order bits works great until either A) one of those hosts wants a semi-permanent name lodged in a DNS server and the IT guy wants to semi-permanently assign an IP address to it without having to touch the host configuration or B) the RIAA/MPAA/FBI/etc. comes and asks to see the logs which show which user on the subnet had a particular address and then goes to the local court and claims that you're using this newfangled protocol so as to avoid making information available that has always been available before. If *both* of these problems were fixed as well as DHCP fixes them for IPv4, there'd be a whole lot more support for letting the hosts choose their low-order bits. Matthew Kaufman
Re: IPv6 Deployment for the LAN
On Oct 17, 2009, at 8:55 PM, Ray Soucy wrote: Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. ... My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking. I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Deployment for the LAN
Thanks for the response, if only to force me put my thoughts down into words. On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin s...@cs.columbia.edu wrote: ... My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking. Not my place to implement policy; I'm not a lawyer. We already have monitoring in place for accountability that maps each address used on a network (regardless of IP or IPv6) to a device and interface for incident response. The greater concern is that SLAAC makes IPv6 available to hosts that may not be prepared for it. If administrators are asked if they would like IPv6 enabled, having been explained the implications of such if SLAAC is used for configuration, the majority of the time they come back and say thanks, but no thanks. In this situation, SLAAC is holding back deployment of IPv6. I suspect other have seen this as well. Part of the problem here is that IPv6 isn't new; it's old. Implementations have been in place for years on certain systems without proper testing as they have gone largely unused. We've seen cases where older versions of Linux can be crashed by enabling SLAAC on a network being one example. By using DHCPv6 we gain some advantages: We can automatically update DNS for hosts so that IPv4 records and IPv6 records match; We have the ability to roll out DHCPv6 on a per-host basis without causing problems on the production IP network; and we can roll it in to our existing [home grown] tools for network management in a way that is easy for users of the system to understand (keep in mind, we provide tools to delegate network control to hundreds of sub-administrators throughout the State). The original question here wasn't SLAAC vs. DHCPv6. I think many network operators here who are tasked with managing anything of scale will agree that SLAAC doesn't quite cut it and is often a step backwards. The overhead of implementing and administering such a system at this scale generally wins out over not doing so. The question I was mainly concerned with was if anyone has encountered issues with the use of an 80-bit prefix to prevent SLAAC from being active. While the prefix advertisement does have the autonomous flag which can be set to false, the underlying problem of IPv6 implementations not being consistent across hosts operating systems yet doesn't change. I'm not convinced that there aren't implementations out there that will enable SLAAC regardless of what the prefix flag is set to, so using a prefix other than a 64 provides an easy way to [attempt to] avoid this, all the while allowing for us to eventually migrate to a 64-bit prefix when host support improves. Another concern is that we certainly don't want to use SLAAC for servers, and I'm hesitant to promote the use of manual IP configuration as it can quickly become a nightmare if you need to move networks (admittedly there should be less need for network moves, but all the same). DHCP has long solved many of these issues in the IP world, and it is perfectly reasonable, and desirable, to apply them to IPv6 though the use of DHCPv6. Perhaps in the future, as we see less legacy hosts online we'll be in a position to make use of both SLAAC and DHCPv6 for host configuration, but in all honesty, once DHCPv6 is in place, why would you want to use SLAAC? My other question was DHCPv6 support from Apple (who seems to be one of the few in resistance of DHCPv6). This list managed to point me in the right direction to nag them about it. I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run. --Steve Bellovin, http://www.cs.columbia.edu/~smb -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On Sun, Oct 18, 2009 at 01:29:54PM -0400, TJ wrote: You say hacks, others see it as relatively-speaking simple additions of more functionality. You can define any options you want for DHCPv6, write a draft and get community support. I don't see how that (continuously evolving DHCPv6 hacks) is any better than what is happening with RAs? The difference is that I don't have to wait for my switch/router vendor to implement RA extensions, I can just implement it myself in an open source DHCPv6 server. Software that is embedded in hardware is very hard to get changed.
IPv6 Deployment for the LAN
Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy r...@maine.edu wrote: As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Ray, Common wisdom says that? Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Deployment for the LAN
I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? The ipv6 nd suppress-ra config will only suppress unsolicited RA, it will still respond to RA solicitations. Load it up in Wireshark and you'll see. A lot of host implementations of IPv6 seem to enable SLAAC as soon as they see any 64-bit prefix regardless of what flags are set. Making assumptions about IPv6 has proven to be unwise in my experience. So far, the only thing that I've seen that is close to working is to configure the router to not advertise the 64-bit prefix using ipv6 nd prefix prefix no-advertise, but at that point it seems easier to just go with a 80-bit prefix and remove any doubt. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 2:28 PM, William Herrin wrote: On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy r...@maine.edu wrote: As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Ray, Common wisdom says that? Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? RA is generally required whether you use stateless or stateful autoconfiguration. You have to tell the hosts to send a DHCPv6 DISCOVER message by turning on the managed flag in the RA. RA does not mean that SLAAC happens. Ray, do you have examples of hosts or stacks that ignore AdvAutonomousFlag? -- Nathan Ward
Re: IPv6 Deployment for the LAN
On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote: making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Some hosts - very dumb ones or very old ones, probably embedded stacks - may do SLAAC even with a prefix other than 64 bits! Once a stack is broken,, anything is possible, so I'm not sure you win much here. Zig to avoid one dud, you'll have to zag to avoid thenext, and before you know it your life is nothing but dodging. Take the high ground instead. Better to find and cure/replace/isolate broken hosts than break your entire network just to accommodate them. If you start doing the wrong thing to accommodate broken hosts, you will never find peace. Zig to avoid one dud; you'll have to zag to avoid the next and before you know it your life is nothing but dodging. Take the high ground instead. Do the advertisements right, advise sysadmins that hosts should not do SLAAC, and (if you are really concerned about broken hosts) collect MAC address information from your switches and do an automated test of reachability on all SLAAC addresses. You can generate the addresses yourself easily enough from the prefix and the MAC. None should be reachable, and any that are - well, you now know where they are and can take appropriate action. And then block all SLAAC addresses at your routers or firewalls, that'll larn 'em :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On Sat, 17 Oct 2009, Ray Soucy wrote: Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. IETF has historically dropped the ball on delivering IPv4/v6 services securely, and all the development for IPv4 done outside the IETF hasn't been integrated into IPv6, which now shows when people are trying to deploy it. There is now some working going on though, you should look into the SAVI working group, they have some nice work going on both for v4 and v6 in this space. The v6ops WG is also producing deployment models for securely deploying v6 in ISP environment. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Deployment for the LAN
Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. To me, from a small ISP perspective, this is where the largest delima is what 'vendor' is already depolying end user equipment that is ipv6 ready?? Then there's the 'delivering the customer' their ipv6 block (hopefully alongside their ipv4 block). Dual stack seems the way to go... To me, there's still a lot of wiggle room on how this should be deployed to the absolute edge. What's folks experience in rolling this out the the customer ... be it DHCP or SLAAC?? Also from a BBA perspective?? On Sat, Oct 17, 2009 at 7:55 PM, Ray Soucy r...@maine.edu wrote: Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Interview: Patrik Fältström on the role of go vernment in IPv6 deployment
We uploaded another interview: http://www.youtube.com/watch?v=zrE1TEan4Jo To make sure we cover as many areas of the industry as possible, we asked Patrik Fältström on the role of government in IPv6 deployment. Patrik is Senior Consulting Engineer with Cisco, but has served as an advisor to the Swedish government on IT policy since 2003. In the interview, he makes a note about the American government as well. I hope you enjoy it. If you have feedback on specific topics you would like to see covered in future interviews, please let us know. We appreciate your comments. Alex Band RIPE NCC
RIPE NCC interview about IPv6 deployment with Randy Bush
As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the second in a series of interviews. Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Arno Meulenkamp RIPE NCC PGP.sig Description: This is a digitally signed message part
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
Am 12.06.2009 um 19:05 schrieb Arno Meulenkamp: As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the second in a series of interviews. Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU thanks but thats not Randy Bush its Andy Davidson Randy Bushs Video is here http://www.youtube.com/watch?v=Qh3i6lDqWBM greetings Marc So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Arno Meulenkamp RIPE NCC -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 Köln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
On Fri, 12 Jun 2009, Arno Meulenkamp wrote: As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the second in a series of interviews. Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU He got larger! And developed an accent... oh wait. Randy here, but I enjoyed Andy as well. http://www.youtube.com/watch?v=Qh3i6lDqWBM So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Arno Meulenkamp RIPE NCC
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
On 12 Jun 2009, at 19:29 , Marc Manthey wrote: thanks but thats not Randy Bush its Andy Davidson Randy Bushs Video is here http://www.youtube.com/watch?v=Qh3i6lDqWBM you are right! guess that tells me that cutting and pasting is dangerous.. thanks! :) Arno PGP.sig Description: This is a digitally signed message part
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
http://downforeveryoneorjustme.com/http://youtube.com/ It's not just you! http://youtube.com looks down from here. Ken Arno Meulenkamp wrote: As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the second in a series of interviews. Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Arno Meulenkamp RIPE NCC -- Ken Anderson Pacific Internet - http://www.pacific.net
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite different. Marvelous technologies of these days ... Cheers
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite different. it was the duct tape
Re: RIPE NCC interview about IPv6 deployment with Randy Bush
On Fri, Jun 12, 2009 at 9:52 PM, Randy Bushra...@psg.com wrote: Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite different. it was the duct tape He, he, BTW your interview was really good. Hope some folks get the point that besides many of the challenges to transition to v6 the real deal is what you put very clearly in just one word: experience. Cheers
RIPE NCC does a series of interviews about IPv6 deployment
As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, I am proud to announce the first in a series of interviews. Andy Davidson of NetSumo ISP Consultancy discusses the IPv6 deployment they have done for their customers and themselves: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Alex Band RIPE NCC
Re: Study of IPv6 Deployment
Elliott Karpilovsky wrote: Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (ATT Research), Dan Pei (ATT Research), Jennifer Rexford (Princeton University), and Aman Shaikh (ATT Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. Nasty comment time... To analyze native IPv6 traffic, we use Netflow records collected from an IPv6 Internet gateway router in a US tier-1 ISP with 11 IPv6 BGP neighbors. These records were collected from 2008-4-1 to 2008-9-26, and are taken from the business customers. Sorry to have to make this comment, but the IPv6 side of the Internet is quite a bit larger than 11 peers. I don't really think that ATT can call themselves a tier-1 ISP on the IPv6 field (they can on IPv4), especially as there are these wonderful give-aways as using OCCAID as a transit: [..] 7 fr-par02a-re1-t-2.ipv6.aorta.net (2001:730::1:2d) 51.944 ms 51.596 ms 51.915 ms 8 uk-lon01a-re1-t-1.ipv6.aorta.net (2001:730::1:2a) 60.802 ms 61.405 ms 61.498 ms 9 ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1) 37.941 ms 37.797 ms 37.88 ms 10 bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2) 106.622 ms 106.538 ms 106.701 ms 11 r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2) 145.847 ms 145.762 ms 146.049 ms 12 2001:1890:61:9017::2 (2001:1890:61:9017::2) 222.045 ms 222.694 ms 223.185 ms 13 mail.ietf.org (2001:1890:1112:1::20) 221.683 ms 221.66 ms 222.839 ms Heck, I can't find a single ISP in GRH with which I can reach ATT (where eg www.ietf.org is currently in) from Europe directly. Unfortunately, I will have to state that that thus completely makes that whole paper useless as the data is used is just that: useless. I really really really hope that ATT finally realizes that they have to start deploying IPv6. When they have done that, re-run your study and then release those numbers as then they will maybe be interesting when there are actual customers on the links. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Study of IPv6 Deployment
On Tue, Apr 28, 2009 at 4:06 AM, Jeroen Massar jer...@unfix.org wrote: Elliott Karpilovsky wrote: Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (ATT Research), Dan Pei (ATT Research), Jennifer Rexford (Princeton University), and Aman Shaikh (ATT Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.htmlhttp://www.cs.princeton.edu/%7Eelliottk/ipv6study.html. If you have comments or feedback with respect to these results, please feel free to express them. Nasty comment time... To analyze native IPv6 traffic, we use Netflow records collected from an IPv6 Internet gateway router in a US tier-1 ISP with 11 IPv6 BGP neighbors. These records were collected from 2008-4-1 to 2008-9-26, and are taken from the business customers. Sorry to have to make this comment, but the IPv6 side of the Internet is quite a bit larger than 11 peers. I don't really think that ATT can call themselves a tier-1 ISP on the IPv6 field (they can on IPv4), especially as there are these wonderful give-aways as using OCCAID as a transit: [..] 7 fr-par02a-re1-t-2.ipv6.aorta.net (2001:730::1:2d) 51.944 ms 51.596 ms 51.915 ms 8 uk-lon01a-re1-t-1.ipv6.aorta.net (2001:730::1:2a) 60.802 ms 61.405 ms 61.498 ms 9 ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1) 37.941 ms 37.797 ms 37.88 ms 10 bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2) 106.622 ms 106.538 ms 106.701 ms 11 r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2) 145.847 ms 145.762 ms 146.049 ms 12 2001:1890:61:9017::2 (2001:1890:61:9017::2) 222.045 ms 222.694 ms 223.185 ms 13 mail.ietf.org (2001:1890:1112:1::20) 221.683 ms 221.66 ms 222.839 ms Heck, I can't find a single ISP in GRH with which I can reach ATT (where eg www.ietf.org is currently in) from Europe directly. Unfortunately, I will have to state that that thus completely makes that whole paper useless as the data is used is just that: useless. I really really really hope that ATT finally realizes that they have to start deploying IPv6. When they have done that, re-run your study and then release those numbers as then they will maybe be interesting when there are actual customers on the links. Greets, Jeroen
Re: Study of IPv6 Deployment
On Mon, Apr 27, 2009 at 10:56 PM, Elliott Karpilovsky ellio...@cs.princeton.edu wrote: Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (ATT Research), Dan Pei (ATT Research), Jennifer Rexford (Princeton University), and Aman Shaikh (ATT Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. Agreed. SPs are driven by customers. Customers, generally, still want the IPv4 net. However, at least where I am at, we have started to gain more and more demand for IPv6 services (in this case, its specific to Private IP services). The relief is hampered by the ability to provide the service quality demanded by our customers. As an SP, if you can't provide the quality and technology together, you will push back to stave it off until you are able to provide both (either way is less than optimal, but one way results in losing whole accounts and the other is just a minor setback) 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. There is not a widespread adoption yet. Until SPs are deploying gear that is adept to handling this traffic and able to guarantee the service quality, there will not be a significant load on the IPv6 infrastructure. On a separate rant, since we have to NAT/PAT on IPv4 already, who really cares if we NAT/PAT between IPv4 and IPv6? Interop as a transition tool would certainly hasten the deployment of IPv6. With major SW vendors now providing full support for the IPv6 suite, SPs that provide interop with IPv4 can start the migration sooner rather than later. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Kudos to the p2p developers/users who have gone this route. What an intuitive way to handle matters. On Tue, Apr 28, 2009 at 4:06 AM, Jeroen Massar jer...@unfix.org wrote: Unfortunately, I will have to state that that thus completely makes that whole paper useless as the data is used is just that: useless. I really really really hope that ATT finally realizes that they have to start deploying IPv6. When they have done that, re-run your study and then release those numbers as then they will maybe be interesting when there are actual customers on the links. Greets, Jeroen From our perspective as net engineers, this is how we are going to view this. The information in the document gives *some* good information, but Jeroen is right... the data coming off of ATT nodes doesn't give any credence to the report. The report *does* tell us that there is still an active effort to avoid IPv6. The rationale used to derrive the conclusions in the report is lacking at best, harmful to adoption at worst. I feel that the grossly incomplete data will be percieved as a lot of FUD coming off this report, but I'm unsure who it would benefit to maintain such stances (except a current Tier-1 IPv4 provider who doesn't have the same status in the IPv6 Internet).
Re: Study of IPv6 Deployment
Elliott Karpilovsky wrote: Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (ATT Research), Dan Pei (ATT Research), Jennifer Rexford (Princeton University), and Aman Shaikh (ATT Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. Thank you. Hi! Please check out the following link with some information/statistics from a LAN-party taking place in Norway (yeah, Norway is in Europe, not North America, but it stills give an overview): http://technet.gathering.org/?p=121 There were over 5000 computers in the arena and of those 47% had a valid and working IPv6 address. They was also provided with IPv4 and no NAT at all. The only ports being closed outbound was 25, 135-139 and 445. Google over IPv6 was enabled for the event as well, so a lot of the traffic was towards google. -- Harald Firing Karlsen
Re: Study of IPv6 Deployment
On 29/04/2009, at 5:30 AM, Harald Firing Karlsen wrote: Please check out the following link with some information/statistics from a LAN-party taking place in Norway (yeah, Norway is in Europe, not North America, but it stills give an overview): http://technet.gathering.org/?p=121 There were over 5000 computers in the arena and of those 47% had a valid and working IPv6 address. They was also provided with IPv4 and no NAT at all. The only ports being closed outbound was 25, 135-139 and 445. Google over IPv6 was enabled for the event as well, so a lot of the traffic was towards google. Did you have any problems that you encountered? Poorly behaving IPv6 stacks, rogue RA+SLAAC/DHCPv6, etc.? Do you have any netflow logs from the event? -- Nathan Ward
Study of IPv6 Deployment
Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (ATT Research), Dan Pei (ATT Research), Jennifer Rexford (Princeton University), and Aman Shaikh (ATT Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. Thank you.
Re: IPv6 Deployment (Was: Re: NANOG 40 agenda posted)
Donald Stahl wrote: If ARIN is going to assign /48's, and people are blocking anything longer than /32- well then that's a problem :) To be specific, ARIN is currently assigning up to /48 out of 2620::/23. I noticed that http://www.space.net/~gert/RIPE/ipv6-filters.html has the following entry in the strict list: ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 24 le 32 which is not particularly useful. It should be 'le 48' if the intent is to track RIR assignment policies. - Kevin
Re: IPv6 Deployment
what problem is it that IPv6 is actually supposed to solve? that's an easy one. in 1993-5, the press was screaming that we were about to run out of ip space. a half-assed design was released. the press stopped screaming. victory was declared, everyone went home. and, as usual, ops and engineering get to clean up the disaster. randy
Re: IPv6 Deployment
Most of those features were completely gone by 1995 TLAs et alia lasted until 2000+. and i think anycast is still broken, though we can at least ignore it and use v4-style anycast, which turns out to be what we need. leaving larger address space as the sole practical benefit and no actual transition plan. This wisdom of this approach is questionable at best, and I'll admit to being part of the team that went along... well, you get two points for copping to it. i lay on the train tracks and was squashed. i take the arin proclamation as a problem is looming. the solution space is not as appealing as we might wish. the time to figure out the transition plan is now. don't expect arin to figure it out for you. i like 40 more bits as well as the next geek. but how the hell do we get from here to there? either we sort out how a v6-only site gets to the internet, there is still ipv4 space at every site and all that implies, or the users are screwed. randy
Re: IPv6 Deployment
i think anycast is still broken, though we can at least ignore it and use v4-style anycast, which turns out to be what we need. recant i am told by a good friend who lurks that this was actually fixed a year or two ago. a team of ops-oriented folk were sufficiently persistent and strident to get it fixed. randy
Re: IPv6 Deployment
At 6:28 PM -0700 5/30/07, Randy Bush wrote: well, you get two points for copping to it. i lay on the train tracks and was squashed. Well, I became a contentious objector... (RFC1669). One can confirm a real sense of humor to the cosmos, because I now get to be lead advocate for the very scenario I noted back then really might not be viable... :-) i like 40 more bits as well as the next geek. but how the hell do we get from here to there? either we sort out how a v6-only site gets to the internet, there is still ipv4 space at every site and all that implies, or the users are screwed. We aggressively work on getting little Internet content sites (aka the 'servers' of new Internet endsites) reachable via IPv6, whether by native IPv6 to endsite, tunnel to endsite, or tunnel transition mechanism within the ISP. ISPs need to take the lead on this for now new sites, by actively promoting IPv6 with IPv4 connections. Doing that, plus the significant effort of IPv6 backbone work is serious work. Big content providers have to figure out how to do native IPv6 (or fake it really well) before the first IPv6-only user arrives... Their readiness has to be 100% on that day (or the day they can't themselves obtain additional IPv4 space), but it's fairly academic until that point. /John
Re: IPv6 Deployment
On Wed, 30 May 2007 18:52:12 PDT, Randy Bush said: i think anycast is still broken, though we can at least ignore it and use v4-style anycast, which turns out to be what we need. recant i am told by a good friend who lurks that this was actually fixed a year or two ago. a team of ops-oriented folk were sufficiently persistent and strident to get it fixed. Fixed as in new RFC released, or New IOS shipped that DTRT, or Most sites have actually *deployed* the new code? pgp5R0JWFIFm4.pgp Description: PGP signature
IPv6 Deployment (Was: Re: NANOG 40 agenda posted)
We do have dual stack in all our customer sites, and at the time being didn't got complains or support calls that may be considered due to the . So far everyone who has contacted me has generally reported a positive experience with their transitions. The biggest complaints so far have come from end users who want to multihome and will be unable to do so under IPv6 due to allocation restrictions. End user sites seem to be of the opinion that they have enough addresses and that IP shortages are the ISP's problem. They don't want to spend money on upgrades only to wind up with a lesser service than they already have- and that's a fair criticism. Does it make sense to allow early adopters to multi-home and punish those who delay by making it significantly harder? Would that help? Hurt? Accomplish nothing? Regarding the prefix filters- Do /32 filters make sense given the ISP allocation of /32 or would a /34 filter (for example) make sense to allow for very limited deaggregation (to make moves and transitions easier- or to allow better traffic balances)- or is this just asking for problems? I'm just curious about opinions and by no means trying to start a flame war. -Don
