Re: NANOG 40 agenda posted
Not speaking directly for my employer (in any official capacity that is), but it's is *not* as easy as as just IPv6 enabling our network, enabling ipv6 on the servers, and putting up ipv6.yahoo.com. Currently, the biggest roadblock we have is loadbalancer support (or, more specificly, lack of thereof) for IPv6 (hell, we still can't even get a I don't know what load balancer you use but all the testing I've done with my F5's has worked out. Granted I'm sure I've forgotten to test some stuff along they way but it simply hasn't been an issue during the initial testing. Considering they support IPv6 gateway and IPv6 proxy modules you can generally make things work in your environment. I would like to know when Foundry's LB's are going to support IPv6 (unless I missed an announcement they still don't). That said- your v6 support does not have to match your v4 support to at least allow you to begin testing. You could set up a single server with v6 support, test, and not worry about it affecting production. Obviously the drive and motivation is different for different companies. Personally- I just want to get it implemented sooner rather than later so I have as much time as possible to track down bugs before normal people start using it. -Don
IPv6 transition work was RE: NANOG 40 agenda posted
Without naming any vendors, quite a few features that work with hardware assist/fast path in v4, don't have the same hardware assist in v6 (or that sheer enabling of ipv6 doesn't impact v4 performance drasticly). Also, quite a few features simply are not supported in v6 (not to mention that some LB vendors don't support v6 at all). Just because it works, doesn't mean it works corrctly, or at the right scale. Again, not naming any vendors... This just emphasizes the importance of turning on IPv6 today either in some part of your production networks in order to identify the specifics of these issues and get them out in the open where they can be fixed. Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement. This doesn't sound like transition as we know it. If you can set up everything that you need to test in a lab environment and then certify IPv6 as ready for use, this could work. But I don't believe that the IPv6 transition can be handled this way. It involves many networks with services and end-users of all types which interact in interesting ways. We need everybody to get some IPv6 into live Internet production. The only way this can work is to take lots of baby steps. Turn on a bit of v6, test, repeat. My stance is that simply enabling v6 on a server in not interesting, v6 has to be enabled on the *service*, I disagree. If a company can offer their service using lots of IPv4 in-house with an IPv6 proxy gateway to the Internet, then this is still valuable and useful in order to support OTHER people's testing. Let's face it, IPv4 is not going away and even when the v4 addresses run out, anybody who has them can keep their services running as long as they don't need to grow the v4 infrastructure. This is not an issue of turning on some IPv6 to test it and then evaluate the results. The fact of IPv4 exhaustion is an imperative that means you and everyone else must transition to an IPv6 Internet. You turn on some v6, test, adjust, turn on some more, test, adjust and repeat until your infrastructure no longer has a dependency on new IPv4 addresses. Your end game may still have lots of IPv4 in use which is OK as long as no new IPv4 addresses are needed. Like you said, different companies have different approaches, but if I'm going to invest my (and a lot of other engineers/developers/qa) time in enabling v6, it's not going to be putting a single server behind the mail.ipv6.yahoo.com rotation, it's going to be figuring out how to take everything that we use for mail.yahoo.com, and making it work in v6 (as that is the only way it would be concidered a valid test), so that at some point in the not-too-distant future it could become dual-stack... I don't disagree with the general thrust of your approach, in particular related to the investment that you have to make. But as part of your overall IPv6 transition program, it should not cause you a lot of pain to make the mail.yahoo.com service available to IPv6 users. By doing that you help everybody else move along in their transition process and you cut your costs because you will be able to leverage the lessons that other people learn. The network effect will help those who actually deploy stuff in production. --Michael Dillon
Re: NANOG 40 agenda posted
On Sun, 03 Jun 2007 15:35:29 EDT, Donald Stahl said: That said- your v6 support does not have to match your v4 support to at least allow you to begin testing. You could set up a single server with v6 support, test, and not worry about it affecting production. If I read the thread so far correctly, Igor can't enable a single server with v6, because the instant he updates the DNS so an MX for his domain references a , that will become the preferred target for his domain from the entire IPv6 world, and he's gonna need a load balancer from Day 0. pgpevjj6uva77.pgp Description: PGP signature
Re: NANOG 40 agenda posted
[EMAIL PROTECTED] wrote: On Sun, 03 Jun 2007 15:35:29 EDT, Donald Stahl said: That said- your v6 support does not have to match your v4 support to at least allow you to begin testing. You could set up a single server with v6 support, test, and not worry about it affecting production. If I read the thread so far correctly, Igor can't enable a single server with v6, because the instant he updates the DNS so an MX for his domain references a , that will become the preferred target for his domain from the entire IPv6 world, and he's gonna need a load balancer from Day 0. ipv6 load balancers exist, one's current load balancer is/may probably not be up to the task. The tools required to do a particular task may not exist or may not be directly applicable to your environment. If this stuff were easy, everyone would do it. The number of free email providers with more than 4 millions users for example is pretty small and thus the exercise of building a scalable service that works for your application given the financial and technical constraints is left as an exercise for the reader.
Re: NANOG 40 agenda posted
Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement. That's obviously your choice. I don't know the first thing about your application/services/systems but in my case my load balancer has nothing to do with my application/services- and I would be frightened if there was some sort of significant dependence. I'm not saying that it's an all or nothing deal, but I have absolutely no intention of having 100% different set-up for the current v4 and the test v6, and then have to troubleshoot v6 issues, not being sure if something was simply not carried over from v4 that it should have been. I don't see leaving the load balancers out as 100% different but that's just me. Whether you deal with these issues all in one shot- or slowly over time is your choice. I would rather understand the various ways things can go wrong- even if I don't think they apply to my environment- as it makes troubleshooting unforseen problems a LOT easier. It also means I can get most of the potential problems sorted out ahead of time. Like you said, different companies have different approaches, but if I'm going to invest my (and a lot of other engineers/developers/qa) time in enabling v6, it's not going to be putting a single server behind the mail.ipv6.yahoo.com rotation, Seeing as it takes the application people I work with a long time to implement new features and QA the builds- I'd rather they start sooner than later. If there are problems it gives me a lot longer to get them straightened out. I already know my load balancers work with v6 for my application- they may not be up to full speed yet- but performance and QA testing new load balancers is a LOT faster and easier than implementing new features in our app. You may not have that problem. it's going to be figuring out how to take everything that we use for mail.yahoo.com, and making it work in v6 (as that is the only way it would be concidered a valid test), so that at some point in the not-too-distant future it could become dual-stack... I'd rather do this in a stepwise fashion. In my case that means step 1 is implementing v6 in the backbone. v6 on the servers is step 2. v6 in the app is step three. v6 on the load balancers is the final step. This is simply how I prefer to work on my migration. If you feel it would be better to wait until all the pieces are in place and troubleshoot everything at the same time then go for it. -Don
Re: NANOG 40 agenda posted
If I read the thread so far correctly, Igor can't enable a single server with v6, because the instant he updates the DNS so an MX for his domain references a , that will become the preferred target for his domain from the entire IPv6 world, and he's gonna need a load balancer from Day 0. This was the whole point in using a separate domain name so that this wouldn't happen. Having said that- I suspect every user in the current v6 Internet could hit his site and still not overwhelm a single server :) There simply aren't that many of us :) -Don
Re: NANOG 40 agenda posted
On 4/06/2007, at 12:43 PM, [EMAIL PROTECTED] wrote: On Sun, 03 Jun 2007 15:35:29 EDT, Donald Stahl said: That said- your v6 support does not have to match your v4 support to at least allow you to begin testing. You could set up a single server with v6 support, test, and not worry about it affecting production. If I read the thread so far correctly, Igor can't enable a single server with v6, because the instant he updates the DNS so an MX for his domain references a , that will become the preferred target for his domain from the entire IPv6 world, and he's gonna need a load balancer from Day 0. Sounds fair enough to me. The other mode would be to set up mail.ipv6.yahoo.com and have customers use that for whatever protocol they send/receive mail with, and not point an MX at an for the time being. However, that means that you can't simply turn it off if it becomes a problem (although, you could switch the out for an A), and when you end up being able to do a proper IPv6 deployment you end up with customers still caring about this legacy DNS entry. That, in short, sounds painful. -- Nathan Ward
Re: NANOG 40 agenda posted
On Thu, 31 May 2007, Larry J. Blunk wrote: Chris L. Morrow wrote: On Tue, 29 May 2007, Iljitsch van Beijnum wrote: # traceroute6 www.nanog.org traceroute6: hostname nor servname provided, or not known That would be a start... It took years to get the IETF to eat its own dog food, though. i suspect the merit/nanog folks involved with the server(s) could probably hook up a way for that to actually work... I'd even volunteer an apache reverse proxy in v6-land if it'd help. A v6 server is now up at www.ipv6.nanog.org. As a bonus incentive, you get to see the Merit mascot (no, it's not a dancing turtle).Unfortunately, there's some unresolved issues with the secure registration server, so we can't add an record for www.nanog.org yet. wow, with dns-sec sig stuff too I see? :) Thanks!
RE: NANOG 40 agenda posted
Isn't his point that y! could offer IPv6 e-mail in parallel to the existing IPv4 service, putting the IPv6 machines in a subdomain ipv6.yahoo.com, so that end users and networks who want to do it can do so without bothering the others? This doesn't sound at all like a transitional plan whatsoever. If my home and office have v6 connections, but a hotel I am staying at does not, I shouldn't need to start reconfiguring layer 7 properties in my applications. Yes you should! You are an early adopter and that is exactly what early adopters do during a technology transition. They also complain loudly, and in technical detail, about what they had to do to make things work and that feedback is invaluable to the people tweaking systems to make them ready for the masses. So stop complaining about it unless you have a specific instance that you experienced, in which case please provide full technical details. Some of my colleagues wont even know how to. Then they are clearly not early adopters and have a minimal role to play during the transition. Don't bother them until we have sorted all the bugs out. The point is that we do not have to solve ALL IPV6 ISSUES FIRST, and then start using it. That's not the way any technology transition works. We are now at the point where anyone who wishes to, has access to the software that they need to trial IPv6 in some form or other. We need to encourage technically inclined people to actually deploy and use IPv6 on a regular basis and start feeding back their experiences so that issues can be dealt with. Content providers like Google and Yahoo will soon take note of the activity and find some way to join in. The fact is that IPv4 is running down to the exhaustion point in 3 to 4 years. The impacts of that will start being felt much sooner, probably within the next 12 months. That means we all have to roll up our sleeves and start trialing IPv6, climbing the learning curve, and providing trial services. Fortunately, there are some people (in RE mostly) who have up to 10 years of operational experience with IPv6 so we are not starting from scratch. Over the past few days it is clear that a lot of North American companies are further along the IPv6 deployment curve than was previously believed. --Michael Dillon
Re: NANOG 40 agenda posted
Larry J. Blunk wrote: [..] A v6 server is now up at www.ipv6.nanog.org. As a bonus incentive, you get to see the Merit mascot (no, it's not a dancing turtle).Unfortunately, there's some unresolved issues with the secure registration server, so we can't add an record for www.nanog.org yet. Great job for getting that up and running! But can that Flamingo fly any faster? :) Greets, Jeroen PS: Can I request that some reverses get added to 2001:468::/32? :) signature.asc Description: OpenPGP digital signature
RE: NANOG 40 agenda posted
In the past we've used www6 for v6 only, www4 for v4 only, and www has both v6 and v4. Which works fine for you and me, but not for my mother. Which means it is an excellent suggestion for the transition phase into an IPv6 Internet. Since that happens to be where we are right now, IPv6 transition, this is an excellent all-round idea for all services and servers. We should adopt this as a best-practice. In a few years, when IPv6 is everywhere and your mother comes online with IPv6, then we will be out of the transition period and a new set of best practices comes into play. --Michael Dillon
Re: why same names, was Re: NANOG 40 agenda posted
On 30/05/2007, at 8:00 PM, Iljitsch van Beijnum wrote: I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. What browser are you using that falls back? Does it require hints (ie. unreachables, or similar) or does a timeout in TCP session establishment trigger it? Of course you can argue that the only way we'll be able to get to the ideal world is by forcing people to deal with the breakage so that it'll be fixed, but I'd point to Vijay's presentations. The problem is, if you're a large scale ISP, how many calls to your help desk will it take until your helpdesk staff says turn off IPv6? Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year. The ball is in the ISP/NSP court at the moment. Here's why, which is really a really really brief summary of how I've read this thread, and my thoughts as it's progressed. a) Vista and other systems try IPv6. If they think they can get IPv6 they'll (often) prefer records to A records. That's good, on the surface. b) If (a) happens, and the endpoint referred to by the record isn't reachable, then the eyeball can't reach the content. Service is degraded. c) Because of (b), content providers aren't going to turn on records. So, it seems to me that the unreachable mentioned in (b) needs to be fixed. That's us, as network operators. Teredo relays/servers and 6to4 relays would be a good first step. Who here who runs an access network has either of these available for production use? If you do, what info can you share? Before someone starts it, the debate between transition protocols to use is well and truely over. Teredo and 6to4 have been chosen for use by the software vendors of the end systems. (fine by me) If I were attending NANOG, I'd be more than happy to run workshops on how to deploy Teredo and 6to4, however I'm in New Zealand and flights are expensive. I'm sure there are people who have more operational experience with these than I do currently. Microsoft run both, perhaps someone from there can say a few words? Vista points to their Teredo server by default, so they'll definitely have some learnings from that, I'm sure. -- Nathan Ward
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: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
On Wed, 30 May 2007, Jeroen Massar wrote: [let me whine again about this one more time... *sigh*] [guilty parties in cc + public ml's so that every body sees again that this is being sent to you so that you can't deny it... *sigh again*] Actually appreciated, as the only sessions with 3ffe link addresses (less than you can count on one hand) are with networks that haven't responded to previous emails from us to renumber, and hopefully now something will be done. It will all get sorted out anyway as we've recently completed a network wide core router upgrade and moved IPv6 into our core, and IPv6 BGP sessions over tunnels are deprecated and being replaced with native sessions. (BTW for observers, he isn't talking about 3ffe prefix announcements, he is talking about a left over 3ffe::/127 address used on a link.) BTW, here is our IPv6 peering information for anybody with a IPv6 BGP tunnel with us, we would be happy to migrate you to native sessions (send email to [EMAIL PROTECTED] to get sessions setup): NAP Status Speed IPv4 IPv6 --- --- --- -- EQUINIX-ASH UP 10GigE 206.223.115.37 2001:504:0:2::6939:1 EQUINIX-CHI UP GigE206.223.119.37 2001:504:0:4::6939:1 EQUINIX-DAL UP GigE206.223.118.37 2001:504:0:5::6939:1 EQUINIX-LAX UP GigE206.223.123.37 2001:504:0:3::6939:1 EQUINIX-SJC UP 10GigE 206.223.116.37 2001:504:0:1::6939:1 LINXUP 10GigE 195.66.224.21 2001:7f8:4:0::1b1b:1 LINXUP GigE195.66.226.21 2001:7f8:4:1::1b1b:2 LoNAP UP GigE193.203.5.128 2001:7f8:17::1b1b:1 AMS-IX UP 10GigE 195.69.145.150 2001:7f8:1::a500:6939:1 NL-IX UP GigE194.153.154.14 2001:7f8:13::a500:6939:1 PAIX Palo Alto UP 10GigE 198.32.176.20 2001:504:d::10 NYIIX UP 10GigE 198.32.160.61 2001:504:1::a500:6939:1 LAIIX UP GigE198.32.146.50 2001:504:a::a500:6939:1 PAIX New York PENDING DE-CIX PENDING NOTAPENDING SIX PENDING Iljitsch van Beijnum wrote: On 30-mei-2007, at 13:23, Nathan Ward wrote: I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. [..] I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. I also just started noticing this, that is, that it does not work. And there is a very simple explanation for this: 6bone space. As a lot of people might recall, the 6bone was shutdown on 6/6/6. Still there are folks who are definitely not running anything operational or who care at all about the state of their network, if they did they would not be using it now would they? As this is what I found on the way from $US - $IE 7 2001:470:0:1f::2 112.131 ms 108.949 ms 108.316 ms 8 2001:470:0:9::2 109.864 ms 112.767 ms 111.586 ms 9 3ffe:80a::c 111.118 ms 86.010 ms 86.648 ms 10 2001:450:2001:1000:0:670:1708:1225 193.914 ms 194.640 ms 194.976 ms And what do we see: 6bone space and still in use. As a lot of places correctly filter it out, the PMTU's get dropped, as they are supposed to be dropped. Just the same as you would expect to see if somebody was using 10.0.0.0/8 address space for a link. Similarly discouraged, though done on occasion. The whois.6bone.net registry is fun of course: inet6num: 3FFE:800::/24 netname: ISI-LAP descr:Harry Try IPv6 country: CA Fortunately it still also has: ipv6-site:ISI-LAP origin: AS4554 descr:LAP-EXCHANGE Los Angeles country: US Which matches what GRH has on list for it: Bill. Now I have a very very very simple question: Can you folks finally, a year after the 6bone was supposed to be completely gone, renumber from out that 6bone address space that you are not supposed to use anymore? That most likely will resolve the issues that a lot of people are seeing. Or should there be another 6/6/7 date which states that de-peering networks which are still announcing/forwarding 6bone space should become into effect? Would you similarly disconnect a nonresponsive customer because they used a /30 from RFC1918 space on a point to point link with you? BTW, I do agree that the links involved should be renumbered immediately. Considering we are in the business of providing connectivity, the thought of tearing down the session as opposed to gracefully getting rid of them didn't cross our mind. Of course, Neustar, who are hosting www.ietf.org, might also want to look for a couple of extra transit providers who can provide them with real connectivity to the rest of the world. That won't renumber Bill Manning's links
RE: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. I also just started noticing this, that is, that it does not work. And there is a very simple explanation for this: 6bone space. We (OCCAID) had recently turned up peering with a few networks (including HE and others) and as a result our outbound path to HEAnet and other networks had changed. Some of the abrupt route changes are being corrected today evening and hopefully should resolve pMTU problems in reaching www.ietf.org. If you continue to experience trouble in reaching thru OCCAID via IPv6, please don't hesitate to drop me a line in private. Regards, James
Re: NANOG 40 agenda posted
On Wed, May 30, 2007 at 12:40:00PM -0700, Randy Bush wrote: This is a grand game of chicken. The ISPs are refusing to move first due to lack of content pure bs. most significant backbones are dual stack. you are the chicken, claiming the sky is falling. I'd have to say I agree. Even those networks that are saddled with lots of legacy gear are coming up with creative ways to deploy it (eg: 6PE). GX, FT, NTT(was verio), and lots of other carriers have IPv6 capabilities and the ability to deliver them in a global fashion. I'm leaving out a lot of folks i know, but the case in my mind is a lack of sufficent push or pull to create the required intertia to move things. Push -- ie: US Federal purchasing mandate impacts a small number of folks who can decipher the FAR. Pull -- user demand for their ipv6 pr0n. The same has been true of other failed or niche technologies such as multicast and IPv6. There are a lot of enterprises and NSPs that have solved these issues within their domain and they've scaled [so far]. I'd say that if your provider can't give you a reasonable answer on a date for some form of IPv6 support (even experimental, free, tunneled or otherwise) you will run into issues with them up to some point. I am a bit sympathetic to those that have to wait for stuff like upgraded DOCSIS and otherwise from their provider if they have the usual one or two providers at your home, but at the same time applying some pressure to them will help get a good deployment and may get you in on their beta or something else. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Jun wrote: I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. I also just started noticing this, that is, that it does not work. And there is a very simple explanation for this: 6bone space. We (OCCAID) had recently turned up peering with a few networks (including HE and others) and as a result our outbound path to HEAnet and other networks had changed. Some of the abrupt route changes are being corrected today evening and hopefully should resolve pMTU problems in reaching www.ietf.org. If you continue to experience trouble in reaching thru OCCAID via IPv6, please don't hesitate to drop me a line in private. Regards, James - --- that was quick, although I tunneling via freenet6. [EMAIL PROTECTED]:/etc/ppp/peers$ traceroute6 www.ietf.org traceroute to www.ietf.org (2610:a0:c779:b::d1ad:35b4) from 2001:5c0:8fff:::a5, 30 hops max, 16 byte packets 1 2001:5c0:8fff:::a4 (2001:5c0:8fff:::a4) 91.114 ms 90.643 ms 92.29 ms 2 freenet6.hexago.com (2001:5c0:0:5::114) 95.166 ms 102.207 ms 95.866 ms 3 if-5-0-1.6bb1.mtt-montreal.ipv6.teleglobe.net (2001:5a0:300::5) 89.454 ms 120.386 ms 92.113 ms 4 if-1-0.mcore3.mtt-montreal.ipv6.teleglobe.net (2001:5a0:300:100::1) 90.882 ms 92.495 ms 91.239 ms 5 if-13-0.mcore4.nqt-newyork.ipv6.teleglobe.net (2001:5a0:300:100::2) 96.672 ms 97.731 ms 97.782 ms 6 2001:5a0:400:200::1 (2001:5a0:400:200::1) 107.734 ms 96.951 ms 97.486 ms 7 2001:5a0:600:200::1 (2001:5a0:600:200::1) 107.223 ms 105.586 ms 103.39 ms 8 2001:5a0:600:200::5 (2001:5a0:600:200::5) 104.942 ms 106.728 ms 102.465 ms 9 2001:5a0:600::5 (2001:5a0:600::5) 107.945 ms 104.898 ms 103.782 ms 10 equinix6-was.ip.tiscali.net (2001:504:0:2::3257:1) 107.448 ms 109.082 ms 107.891 ms 11 equi6ix-ash.ipv6.us.occaid.net (2001:504:0:2:0:3:71:1) 223.532 ms 217.531 ms 218.709 ms 12 unassigned.in6.twdx.net (2001:4830:e6:d::2) 219.648 ms 221.496 ms 223.614 ms 13 stsc350a-eth3c0.va.neustar.com (2610:a0:c779::fe) 228.079 ms 227.053 ms 226.536 ms 14 www.ietf.ORG (2610:a0:c779:b::d1ad:35b4) 226.191 ms 227.959 ms 219.163 ms regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXdovpbZvCIJx1bcRAu0lAJ4ldNWYXCvBf4Vtvkdih8WknZc5XwCfdKKy UsquQuxR+AytwKrfuOF0MlM= =oJoI -END PGP SIGNATURE-
Re: NANOG 40 agenda posted
This is useless. Users need to use the same name for both IPv4 and IPv6, they should not notice it. And if there are issues (my experience is not that one), we need to know them ASAP. Any transition means some pain, but as sooner as we start, sooner we can sort it out, if required. Regards, Jordi De: Donald Stahl [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 29 May 2007 09:21:49 -0400 (EDT) Para: John Curran [EMAIL PROTECTED] CC: nanog@nanog.org Asunto: Re: NANOG 40 agenda posted At this point, ISP's should make solid plans for supplying customers with both IPv4 and IPv6 connectivity, even if the IPv6 connectivity is solely for their web servers and mail gateway. The priority is not getting customers to use IPv6, it's getting their public-facing servers IPv6 reachable in addition to IPv4. Exactly. So many people seem to be obsessed with getting the end users connected via IPv6 but there is no point in doing so until the content is reachable. The built in tunneling in Windows could be a problem so let's start by using different dns names for IPv6 enabled servers- mail.ipv6.yahoo.com or whatever. Can anyone think of a reason that a separate hostname for IPv6 services might cause problems or otherwise impact normal IPv4 users? -Don ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: NANOG 40 agenda posted
On Tuesday 29 May 2007 15:21, Donald Stahl wrote: Can anyone think of a reason that a separate hostname for IPv6 services might cause problems or otherwise impact normal IPv4 users? None that I can think of. In the field, for servers/services we have enabled v6 on, we have created parallel hostnames for v6 addresses, e.g., someservice + someservice6, e.t.c. This is mostly for the period we continue to get an all-around feel for v6 on a user/service/administration level; hopefully, we shall come up with a more intuitive naming structure in the future, the ultimate being the same names currently in use with v4. We haven't seen any issues so far with either v4 or v6 connections/users (except for inexplicably marginally quicker response times over v6, but that's another story). In all cases, the v4 and v6 services live on the same box. Mark. pgpEjBuFSXIp1.pgp Description: PGP signature
Re: NANOG 40 agenda posted
Jared Mauch wrote: Some providers (eg: www.us.ntt.net) have their sales/marketing path ipv6 enabled. Perhaps this will help self-select customers that are clued? ;) Most European/Asian based providers/peers don't even blink when I mention turning up IPv6. Not so with most US based networks. The upcoming nanog meeting I think will have native IPv6 connectivity (not a tunnel). It's a good time for folks to play around with it. Visit the ipv6 enabled websites from the lan. Submit a nice 10 min talk saying what you loved and what you hated about the ipv6 network. Better yet, nanog would be a good place for folks to arrange IPv6 peering. - Kevin
Re: NANOG 40 agenda posted
On Tue, 29 May 2007, John Curran wrote: ISP's are going to have to actually *lead* the transition to IPv6 both in terms of infrastructure and setting customer expectations. and this means getting a good story in front of bean-counters about expending opex/capex to do this transition work. Today the simplest answer is: if we expend Z dollars on new equipment, and A dollars on IT work we will be able to capture X number of users for Y new service or some version of that story. Solving that has turned out to be difficult (as is shown by the global lack of meaningful deployment) p.s. It's not the classic chicken/egg situation; it's much simpler: Look up and see the IPv4 Internet - that's the egg, it's first, and it's falling. We have to recognize that fact and gentle catch it, or there just won't be any chicken. ok...
Re: NANOG 40 agenda posted
but ipv6 is more secure, yes? :) (no it is not) Does the relative security of IVp4 and IPv6 *really* matter on the same Internet that has Vint Cerf's 140 million pwned machines on it? was the :) not enough: I'm joking ?? Just askin', ya know? some people do think that it does... they would be wrong, but they don't know that. There is something to be said for not being able to blindly spew worm traffic and still expect to get a sensible hit ratio as with IPv4. -Don
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
Re: NANOG 40 agenda posted
On 29/05/2007, at 1:35 PM, Donald Stahl wrote: For core links it should IMHO be mostly possible to keep them IPv4/ IPv6 dual-stack. When that is not the case one can always do minimal tunnels inside the AS. Same for getting transit, it doesn't have to be directly native, but when getting it try to keep the AS's crossed with a tunnel for getting connectivity to a minimum (See also MIPP*). Actually setting up a dual-stack infrastructure isn't very difficult- anyone who has done so would probably agree. The problems (as has already been pointed out) come from management, billing and the like. Don't forget customers. Turning this thing on for customers appears to be non-trivial in many cases. Am I off my rocker? Slightly, but not entirely. Testing is already happening, and has been for a long time. More and more end users are having a play with the various transition technologies, etc. Having said that, the first work that I have seen in the Make it easy for real-world end users space is the Great IPv6 Experiment stuff. With Vista and OS X turning on IPv6 natively, as well as Vista's love for 6to4 and Teredo, are your helpdesk staff skilled enough to deal with problems if say, Google or Yahoo! were to turn on records tomorrow? This is here now, and if we want this to happen without pain, I think we need to be acting. ...or is your helpdesk process to turn IPv6 off? (When I say your, I mean the reader, not you specifically Donald) -- Nathan Ward
Re: NANOG 40 agenda posted
On Sun, 27 May 2007, Martin Hannigan wrote: On 5/26/07, Chris L. Morrow [EMAIL PROTECTED] wrote: On Sat, 26 May 2007, Jared Mauch wrote: on things, could cost some money. I'd love to see google or Y! with an record. Or even Microsoft ;) i agree 100%, which is why I posted something similar almost 2 years ago now :( It'd be very good to get some actual content on v6 that the masses want to view/use. Isn't the driver going to be scarcity and/or expense of v4 addresses? honestly I have no idea... at this point (15 yrs into the process) there has to be SOME reason, its just not clear which one it will be. Scarcity of v4 addresses might just mean more and more NAT gets deployed... or it could mean that v6 starts to show up on content provider networks. I doubt there will be a network that is only ipv6 and successful anytime soon, there simply is no content of consequence available only via v6 today (heck, there's no consequential content available on v6 AND v4 currently). I think that it is in most folks interest to get some familarity with and experience with the coming change, before it's on the critical path. Using Google as an example, if they don't have v6 deployed/testing today and tomorrow a portion (sizable enough for them to notice) of their userbase moves to mostly v6 access methods (say v6 only transport with some v6-v4 gateway) they may feel pressured into deploying v6 access to their services without proper testing/scaling/management. That could be messy... One of the things that came back as interesting (to me) from the thread 2 years ago was that adding a v6 vif to the content wasn't the scary part. What was scary was the OSS/backend/metrics/management parts that all needed to understand what ipv6 addresses were. I wonder if google-analytics understands ipv6 yet? In short Marty, I'm not sure what the driving factor will be, I'm not holding out hope that it's v4 depletion though.
Re: NANOG 40 agenda posted
On Sun, 27 May 2007, william(at)elan.net wrote: On Sun, 27 May 2007, Chris L. Morrow wrote: So, I think I can sum up your reply by saying that your suggestion is to provide a lesser service than we do now (v4 NAT, proxies, etc. sound to me like lesser service), during the transition period. I think you also missed the suggestion that sending out CPE with DD-wrt was a 'good idea'. Honestly DD-wrt/open-wrt are nice solutions for testing or for people willing to fiddle, they are not a good solution for 'grandma'. My parents and brother both have linksys with dd-wrt that I put up. I don't maintain it at all and it just works. No, they are not using v6, but if it was available I don't anticipate any problems as their system os at home all support it now. The point BTW is not that its not good or bad solution for grandma but that if solutions were needed quickly getting up in would no longer be as big of a deal. And besides all those vendors would love to have a reason to market to folks that they need to upgrade their router ASAP. However the reason why ipv6 is not happening is that nobody has strong enough reason to do it and unless some reall cool (p2p or alike) application comes along, all the upgrades will happen at the very last moment when we actually run out of v4. On this point I personally do not see it happening in 2010 (and I have done my own calculations) but within 2010-2015 closer to end of that range - however I'm not sure exact date/year is really important because of the reasons stated above. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: NANOG 40 agenda posted
william(at)elan.net wrote: On Sun, 27 May 2007, Chris L. Morrow wrote: So, I think I can sum up your reply by saying that your suggestion is to provide a lesser service than we do now (v4 NAT, proxies, etc. sound to me like lesser service), during the transition period. I think you also missed the suggestion that sending out CPE with DD-wrt was a 'good idea'. Honestly DD-wrt/open-wrt are nice solutions for testing or for people willing to fiddle, they are not a good solution for 'grandma'. My parents and brother both have linksys with dd-wrt that I put up. I don't maintain it at all and it just works. No, they are not using v6, but if it was available I don't anticipate any problems as their system os at home all support it now. I am usually just lurk around here but I had to say something. Working for a service provider that has tried to make an entire product around IPV6 it does not work. Since none of the big players (google, yahoo, etc...) have started to atleast provide some IPV6 content the little guys are not going to jump on the bandwagon. Yes it's the chicken or the egg thing but its economics not logic that will get people to move to IPV6. Manolo
Re: NANOG 40 agenda posted
I need to insist on this: I agree that having the content providers dual-stack is nice to have, of course, and I will applaud it if happens in Google, Yahoo, Microsoft, etc.. BUT it is NOT an immediate need. We should not deploy IPv6-only networks at the LANs. We may have IPv6 only at core infrastructures when the traffic on that network becomes IPv6 predominant (I've been in several of those cases with customer networks), but make sure to keep using dual-stack in the LANs (even with NAT and private IPv4) if you want to make sure that no translation is needed and we have a trouble-free transition. There are many things in Vista, and hopefully more to come, which prefer IPv6 for peer-to-peer. And even if the ISPs don't offer IPv6 at all, hosts use 6to4 or Teredo to automatically provide the required IPv6 connectivity. This IPv6 peer to peer traffic is growing and that will impact networks sooner or later. I've already worked a bit on this topic and still working on a paper, in order to show how important is to deploy 6to4 and Teredo relays to improve IPv6 customers experience. I've presented at the last EOF/RIPE meeting about this The cost of NOT deploying IPv6. Regards, Jordi De: Manolo Hernandez [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 27 May 2007 12:48:23 -0400 Para: nanog@nanog.org Asunto: Re: NANOG 40 agenda posted william(at)elan.net wrote: On Sun, 27 May 2007, Chris L. Morrow wrote: So, I think I can sum up your reply by saying that your suggestion is to provide a lesser service than we do now (v4 NAT, proxies, etc. sound to me like lesser service), during the transition period. I think you also missed the suggestion that sending out CPE with DD-wrt was a 'good idea'. Honestly DD-wrt/open-wrt are nice solutions for testing or for people willing to fiddle, they are not a good solution for 'grandma'. My parents and brother both have linksys with dd-wrt that I put up. I don't maintain it at all and it just works. No, they are not using v6, but if it was available I don't anticipate any problems as their system os at home all support it now. I am usually just lurk around here but I had to say something. Working for a service provider that has tried to make an entire product around IPV6 it does not work. Since none of the big players (google, yahoo, etc...) have started to atleast provide some IPV6 content the little guys are not going to jump on the bandwagon. Yes it's the chicken or the egg thing but its economics not logic that will get people to move to IPV6. Manolo ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: NANOG 40 agenda posted
On 5/26/07, Randy Bush [EMAIL PROTECTED] wrote: [ snip ] wow! you missed the one day workshop in the lacnic meeting you just attended? bummer. I'm lucky enough to be able to attend RIPE, ARIN, and LACNIC meetings so that I can get basic information since I can't get that at a NANOG meeting. I can advertise a v6 prefix, number a host, and I know what a tunnel is. I believe you already understand that I'm talking about operational experiences as well as basic training as a service to our community. Your comment seems to accidentally infer that you support my point in that we should have more v6 activity at NANOG meetings and on this list so that people don't have to go to Latin America or Europe to get it. Best, Marty
Re: NANOG 40 agenda posted
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush [EMAIL PROTECTED] wrote: you have something new and interesting about ipv6? if so, did you submit? Given the ARIN statement, I think it's time for more discussion of v6 migration, transition, and operations issues. No, I'm not volunteering; I'm not running a v6 network. I suspect that Martin is right -- the program committee should be proactive on this topic and seek out presenters. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: NANOG 40 agenda posted
On 5/26/07, Steven M. Bellovin [EMAIL PROTECTED] wrote: On Sat, 26 May 2007 00:39:19 -0400 Randy Bush [EMAIL PROTECTED] wrote: you have something new and interesting about ipv6? if so, did you submit? Given the ARIN statement, I think it's time for more discussion of v6 migration, transition, and operations issues. No, I'm not volunteering; I'm not running a v6 network. I suspect that Martin is right -- the program committee should be proactive on this topic and seek out presenters. I would urge potential sponsors to insist that V6 is on the agenda as a condition of funding, both meeting sponsors and Beer 'N Gear. -M
Re: NANOG 40 agenda posted
you have something new and interesting about ipv6? if so, did you submit? If you are going to stand at microphones at other groups meetings and take credit for turning on the first v6 network, perhaps you should be asking yourself this very question? first, i did not say i turned it on. i said the company for which i worked did. second, nothing new and interesting about ipv6 of which i am aware. My colleagues and I need some training. We don't have the experience. I'm asking because we want to see this at NANOG and I'm wondering why there isn't. wow! you missed the one day workshop in the lacnic meeting you just attended? bummer. what would a nanog v6 workshop contain? especially given the excellent tee shirt 96 more bits, no magic? randy
