The NANOG Program Committee is pleased to announce that the agenda for the upcoming meeting in Bellevue, WA has been posted:
http://www.nanog.org/mtg-0706/topics.html
If you haven't already registered to attend, now is a great time!
Sorry to post 4 times this year, and really, it just kind of stuck out when I went to look at the agenda, but: Nothing about V6? Not a workshop, tutorial, or even a panel? Any reason why? Is V6 not happening? Best, Martin
you have something new and interesting about ipv6? if so, did you submit? randy
On 5/26/07, Randy Bush <randy@psg.com> wrote:
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? 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. Exhaustion from ICANN to RIR's and then to users is real, and it's happening. Help. -M<
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
On 5/26/07, Randy Bush <randy@psg.com> 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
On Sun, May 27, 2007 at 05:22:23PM -0400, Martin Hannigan wrote:
On 5/26/07, Randy Bush <randy@psg.com> 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.
In the past two years there have been two events that have happened jointly with nanog that performed some of this IPv6 training, but it wasn't as much under the 'NANOG' umbrella as the 'ARIN' one. Take the following two: http://www.arin.net/ARIN-XVIII/ipv6_workshop.html ARIN XVIII Networking with IPv6 Workshop - Sunday, 8 October 2006 http://www.nanog.org/mtg-0510/index.html ARIN and NANOG are offering a special, hands-on tutorial, titled Getting Started With IPv6, from 9:00 a.m. to 4:30 p.m. on Sunday. Our other tutorials will begin on Sunday afternoon at 1:30 p.m. The General Session begins at 9:00 a.m. on Oct. 24, and ends at approximately 4:00 p.m. on Tuesday, Oct. 25. [2005] Based on these, and making the ASSumption that I will, perhaps there is something upcoming for the october joint meeting? Did you or other members of the community also miss these two sessions? What was missing? The critique i've generally heard recently is the "So what, it just works, but what about all the backend upgrades, monitoring, etc.. you had to do". I've not heard a general session talk on this aspect. We've usually talked about making the bits move along the pipes..^Wtubes. So, would hearing that yes, we had to adjust our monitoring system to handle snmp traps to account for that v6 session going down and it displayed an improper interpretation of the IP address in the monitoring UI? I personally can't speak for what patchlevel or workarounds had to be done by the teams that captured some of that data on our side when we went live with the v6 network, but I know it was an issue that we were able to move past. When qualifying new software and hardware, these are things that one checks on. If you are starting with IPv6 you can easily set up a tunnel on an older 26xx and make it work, as well as setting up a bgp session and clearing it and sending a few traps at your monitoring host. These are fairly low-effort things that can be done, but I am sympathetic to those that are smaller and are time and resource constrained in this space. They're the ones who are going to be further stressed as this IPv6 stuff slowly creeps towards the edge. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On 26-mei-2007, at 12:10, Martin Hannigan wrote:
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. Exhaustion from ICANN to RIR's and then to users is real, and it's happening. Help.
Let me know if you find my IPv6 routing tutorial @ RIPE-53 useful and maybe I can take it on the road... http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html Iljitsch
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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
Agreed. The statement from ARIN is recent and impacts us all. We've got our core v6 routing in place, but operationally, that's really the easy part. Modifying the tools such as billing, monitoring, management, tracking, and auditting are the slow link in the chain. The space is dwindling but that doesn't seem to be putting the transition pressure on if the services aren't there to use v6. Until more transit providers support it, the reasoning for smaller provider to transition is limited. Eric Krichbaum, PhD Director Network Engineering, Citynet -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Steven M. Bellovin Sent: Saturday, May 26, 2007 11:31 AM To: Randy Bush Cc: Martin Hannigan; nanog@nanog.org Subject: Re: NANOG 40 agenda posted On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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
Krichbaum, Eric wrote:
Agreed. The statement from ARIN is recent and impacts us all. We've got our core v6 routing in place, but operationally, that's really the easy part. Modifying the tools such as billing, monitoring, management, tracking, and auditting are the slow link in the chain. The space is dwindling but that doesn't seem to be putting the transition pressure on if the services aren't there to use v6. Until more transit providers support it, the reasoning for smaller provider to transition is limited.
And give that most end user allocations are /64s, could bind really handle a 18,446,744,073,700,000,000 line zone file? :)
Steven M. Bellovin wrote:
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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.
If you want somebody to 'present' something about IPv6 transition, then probably the first step is to start indexing what the current problems are for ISP's and then kick the people who can explain that... From the top of my head, it starts by upgrading: - Routers - Management Tools - Monitoring Tools - CPEs - Getting proper transit - Loadbalancers and other net infra - and other things I forget here 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*). Towards endusers it can become nasty, eg it would require upgrades of the CPE and also the infrastructure might need to be upgraded. For Cable systems only recently the Docsis 3.0 standard was released and that would still require a lot of upgrades. Tunneling those users might be a way to provide IPv6 connectivity to these users without much ado. There are of course a lot of transition mechanisms, each with their pro's and con's and all depending on what one wants to achieve. When there is connectivity, the next step is to start upgrading services. First upgrading the actual servers that these services run on, then enabling the services to support IPv6 and starting to stick them in DNS. The latter point of course can become nasty. When a customer's client (eg Internet Explorer/Firefox) has IPv6 support and it thinks it can connect to the service as it sees a AAAA record, but the link in between doesn't work. Resulting in a unhappy customer as "it is broken" and they really can't care what is broken and they should not. Care is thus to be taken when upgrading these services, as it might cause a lot of helpdesk calls. Probably doing a trial on the customer base, especially having a group of people who will give good bugreports and enabling them to use it, is a good idea. A trick that might work there is to provide those people with alternate caching DNS servers which do return AAAAs. This can thus automatically be done using DHCP, when you have a user who is IPv6 enabled, steer them to the DNS servers that return AAAAs and presto, they start using it. And when you are lucky it also actually works. And of course that is not all, reading a good book and other materials on this subject and doing trials and testing is of course a good thing to do, but one should have done that in the last 5 years already... <spam>Lastly, don't forget to signup to GRH so that you can see how the status of your BGP is holding out :)</spam> Greets, Jeroen * MIPP = http://ip6.de.easynet.net/ipv6-minimum-peering.txt Yes that document is already 5 years old by now, there where people already then who where thinking about those things ;)
Jeroen Massar wrote:
Steven M. Bellovin wrote:
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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.
If you want somebody to 'present' something about IPv6 transition, then probably the first step is to start indexing what the current problems are for ISP's and then kick the people who can explain that...
I would vastly prefer to here people talk about what they are doing rather that hear the same set of usual suspects talk about "what we should be doing". The later is tiresome and we have a decade worth of examples of it to pick through.
From the top of my head, it starts by upgrading: - Routers - Management Tools - Monitoring Tools - CPEs - Getting proper transit - Loadbalancers and other net infra - and other things I forget here
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*).
Towards endusers it can become nasty, eg it would require upgrades of the CPE and also the infrastructure might need to be upgraded. For Cable systems only recently the Docsis 3.0 standard was released and that would still require a lot of upgrades. Tunneling those users might be a way to provide IPv6 connectivity to these users without much ado. There are of course a lot of transition mechanisms, each with their pro's and con's and all depending on what one wants to achieve.
When there is connectivity, the next step is to start upgrading services. First upgrading the actual servers that these services run on, then enabling the services to support IPv6 and starting to stick them in DNS. The latter point of course can become nasty. When a customer's client (eg Internet Explorer/Firefox) has IPv6 support and it thinks it can connect to the service as it sees a AAAA record, but the link in between doesn't work. Resulting in a unhappy customer as "it is broken" and they really can't care what is broken and they should not. Care is thus to be taken when upgrading these services, as it might cause a lot of helpdesk calls.
Probably doing a trial on the customer base, especially having a group of people who will give good bugreports and enabling them to use it, is a good idea. A trick that might work there is to provide those people with alternate caching DNS servers which do return AAAAs. This can thus automatically be done using DHCP, when you have a user who is IPv6 enabled, steer them to the DNS servers that return AAAAs and presto, they start using it. And when you are lucky it also actually works.
And of course that is not all, reading a good book and other materials on this subject and doing trials and testing is of course a good thing to do, but one should have done that in the last 5 years already...
<spam>Lastly, don't forget to signup to GRH so that you can see how the status of your BGP is holding out :)</spam>
Greets, Jeroen
* MIPP = http://ip6.de.easynet.net/ipv6-minimum-peering.txt Yes that document is already 5 years old by now, there where people already then who where thinking about those things ;)
Joel Jaeggli wrote: [..]
I would vastly prefer to here people talk about what they are doing rather that hear the same set of usual suspects talk about "what we should be doing". The later is tiresome and we have a decade worth of examples of it to pick through.
Well, what I described is what I already did quite some time ago, just very briefly summarizing what it takes to get there. The folks who already started or are already done deploying IPv6 are not the ones who need the attention. The ones who haven't yet though, now they are the ones who need to quickly still step over all the hurdles so they get back on track. =46rom a network operators point of view, IPv6 is just like IPv4, it work= s and it has it problems and you need the expertise and experience to know how to resolve those. Nothing more nothing less, except that the addresses are a bit longer... See that all, like the rest of NANOG, as helping out fellow colleagues; one could of course also simply say: they didn't bother for the last couple of years, so why should the rest of us care about them? From a economic/competition point of view that is actually not even such a bad idea. Defies a bit what NANOG is about though ;) Greets, Jeroen
On Sat, May 26, 2007 at 07:51:52PM +0100, Jeroen Massar wrote:
Steven M. Bellovin wrote:
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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.
If you want somebody to 'present' something about IPv6 transition, then probably the first step is to start indexing what the current problems are for ISP's and then kick the people who can explain that...
From the top of my head, it starts by upgrading: - Routers - Management Tools - Monitoring Tools - CPEs - Getting proper transit - Loadbalancers and other net infra - and other things I forget here
I think you're missing a few things here. (subset of CPE --) - "Firewalls" and NAT (wasn't v6 supposed to stop the latter) - end-hosts (Grandma still using unpatched win98/winME isn't going to be looking at the ipv6 pr0n project anyways.. or is she ;) - DDoS Mitigation devices (where's my ipv6 capable "guard"?) the good news is there's a mostly reasonable story for most folks under the CPE, Transit, "Core" Routers (subject to a caveat matrix), Monitoring and Management. It does require some upgrades to these systems, which depending on things, could cost some money. I'd love to see google or Y! with an AAAA record. Or even Microsoft ;) It'd be cool to see the number of folks still using busted resolver software who says 'google is busted' and the rest of the world will see it continue to work without trouble. It's going to take someone like them to help shift things. (or even akamai ;)) - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On May 26, 2007, at 8:57 PM, Jared Mauch wrote:
I think you're missing a few things here. (subset of CPE --) - "Firewalls" and NAT (wasn't v6 supposed to stop the latter) - end-hosts (Grandma still using unpatched win98/winME isn't going to be looking at the ipv6 pr0n project anyways.. or is she ;)
Speaking as your representative of the ipv6 pr0n project (http:// www.ipv6experiment.com) I thought I'd chime in here, as well. :) I hoped to be at a point with our experiment to be able to give a presentation at this NANOG(if it would be accepted, anyway), but some financial and technical setbacks have slowed us down a bit. A few of our offers of free transit for the experiment seem to have fallen through, as well as a few unrelated issues taking up most of our free time slowing down the progress of the custom software for it. That said, one of our definite goals is to measure things like: * What problems the average end user has after turning IPv6 on, no matter what method they're using for it. (Native connectivity, tunnels, 6to4, etc) * What issues we have trying to leverage a ton of off-the-shelf software (log analyzers, monitoring tools, discussion forums, etc) just getting this experiment accessible over v6. * We're going to try to touch on every piece of the IPv6 landscape in one way or another, and document what problems we run into. End user software/CPE support, transit issues, peering issues, server software, router configuration, etc. * What breaks on the user side just by turning v6 on? What breaks on the server side? * How much worse download speeds are on average over v6 than v4, for users motivated to download large files? So, while I can't do anything for this NANOG, I do plan on presenting our results at whatever *NOG will have us when the experiment is complete. If there are any avenues of interest that you specifically want more information on "what would happen if we had to deploy v6 now" kinds of things, we're in a position to tell you. Just let me know and I'll find some way of measuring/surveying/documenting it. -- Kevin
On Sat, 26 May 2007, Jared Mauch wrote:
on things, could cost some money. I'd love to see google or Y! with an AAAA 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.
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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? -M< -M<
On 27/05/2007, at 9:05 PM, Martin Hannigan wrote:
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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?
Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it. If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, Google (etc.) won't work until they upgrade." would you: a) Stick it out with that provider, even though there is no content for you to access. b) Hang up. If you answered (a) to the above, run through that again, from say, your Mother's perspective. Now that NAT-PT is deprecated (ie. can't be used as an excuse to not move), we need to move the large (and small) content providers to dual-stack, before we move any customers to v6-only. Content providers have all the IPv4 addresses they need already, they're not going to be asking for more any time soon. If someone has some bright ideas on how to transition without loss of service to *someone*, I'm all ears. (IPv4 NAT is not a bright idea.) In addition, when 2010 [1] rolls around, are the free CPE that your customers were given in the last 7 days upgradable to support IPv6? This is, of course, assuming we don't hold off until we've got a different IPv6 architecture as a result of the RAWS stuff. [2] While we're here, can someone point me in the direction of any ongoing discussion/work in this area? I attended the APRICOT workshop, but where to go to keep up with things/get involved isn't obvious. -- Nathan Ward [1] http://www.potaroo.net/tools/ipv4 [2] http://tools.ietf.org/id/draft-iab-raws-report-02.txt
Nathan Ward wrote: [..]
Isn't the driver going to be scarcity and/or expense of v4 addresses?
Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it.
Why not? If folks are still using Windows 98 by then I surely hope they can't have any connectivity to the Internet. The word "SpamDrone" comes to mind for those old versions. As Windows XP is already out for the last couple of years and has fully working IPv6 support, Vista is there also with fully working IPv6 support, the OS should definitely not be a problem anymore. For folks without money, all the Open Sourcish OS's also do IPv6 perfectly fine, some even already from the installer.
If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, [..]
Your grandma really doesn't know what "IP" is, nor will she ever care. Ever heared of this thing called "HTTP Proxy"? That solves 90% of those issues. Takes care of mail also as most intarweb-users are using webbased mailers anyways. They work perfectly fine and can do IPv4 and IPv6, using IPv6 as the transport. Otherwise, you can always abuse http://ipv6gate.sixxs.net or http://ipv4gate.sixxs.net for the other way around.
Now that NAT-PT is deprecated (ie. can't be used as an excuse to not move), we need to move the large (and small) content providers to dual-stack, before we move any customers to v6-only. Content providers have all the IPv4 addresses they need already, they're not going to be asking for more any time soon. If someone has some bright ideas on how to transition without loss of service to *someone*, I'm all ears. (IPv4 NAT is not a bright idea.)
What about looking up the word "transition" in the dictionary and comparing it to "flag day". There is no flag day, it will all be gradual. Some people have been providing commercial IPv6 connectivity already since as early as 2001 (and some even earlier!) Also, if you want to provide those users IPv4 access, you can always hurdle them behind an IPv4 NAT. They are used to that today already anyway.
In addition, when 2010 [1] rolls around, are the free CPE that your customers were given in the last 7 days upgradable to support IPv6?
You should have thought about that already, like, 5 years ago!? Also, you can always just TUNNEL over them. RFC1918 or something similar to the enduser and then provide them with a NAT to have a public IPv4 address so that they can reach legitimate resources. Then provide them with a tunnel so they can use IPv6 in full strength. But that is a doomsday scenario. Running out of addresses doesn't mean that IPv4 stops to work.
This is, of course, assuming we don't hold off until we've got a different IPv6 architecture as a result of the RAWS stuff.
Routing and addressing should be separate. Providing blocks of addresses to organizations that can justify the need for them is great. Reforming the routing system is a thing that can be done later when there is somebody who find the magic bullet that folks will accept. Can take some time of course, but up to then it appears that vendors of routing equipment can scale...
[2] While we're here, can someone point me in the direction of any ongoing discussion/work in this area? I attended the APRICOT workshop, but where to go to keep up with things/get involved isn't obvious.
As mentioned in various places: ram@iab.org, see https://www1.ietf.org/mailman/listinfo/ram Greets, Jeroen
On 27/05/2007, at 11:06 PM, Jeroen Massar wrote:
Nathan Ward wrote: [..]
Isn't the driver going to be scarcity and/or expense of v4 addresses?
Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it.
Why not? If folks are still using Windows 98 by then I surely hope they can't have any connectivity to the Internet. The word "SpamDrone" comes to mind for those old versions. As Windows XP is already out for the last couple of years and has fully working IPv6 support, Vista is there also with fully working IPv6 support, the OS should definitely not be a problem anymore. For folks without money, all the Open Sourcish OS's also do IPv6 perfectly fine, some even already from the installer.
Because for IPv6 to be useful to the masses, content is required. As I alluded to, getting content to move to IPv6 isn't terribly easy, and I don't think that proxying/NATing is a great solution, either.
If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, [..]
Your grandma really doesn't know what "IP" is, nor will she ever care. <stuff>
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. While I think that some degradation of service is inevitable, I believe that it would be better to minimise the lessening of service, and shorten the transition period, wouldn't you? It occurs to me, and correct me if I'm wrong, but in your model of this transition there becomes little benefit to moving customers to IPv6 at all if being stuffed behind a v4 NAT or HTTP proxies counts as "Internet connectivity". Of course, I'm probably taking your suggestions to an extreme there.
[2] While we're here, can someone point me in the direction of any ongoing discussion/work in this area? I attended the APRICOT workshop, but where to go to keep up with things/get involved isn't obvious.
As mentioned in various places: ram@iab.org, see https://www1.ietf.org/mailman/listinfo/ram
Cheers. -- Nathan Ward
Nathan Ward wrote:
On 27/05/2007, at 11:06 PM, Jeroen Massar wrote:
Nathan Ward wrote:
[..]
Because for IPv6 to be useful to the masses, content is required.
That is something for the content providers to resolve. That is the other side of the table and they have the 'easy' portion. The problem for them is having the equipment/software capable of doing it, which is easy to deploy and test for them. The really big problem is that there is a case that when you do enable AAAA's on your service that suddenly there is a possibility that some user can't reach your site properly anymore as they don't have proper connectivity to your site over IPv6.
As I alluded to, getting content to move to IPv6 isn't terribly easy, and I don't think that proxying/NATing is a great solution, either.
A lot of endusers are using IPv4 NAT already, and indeed that is not a great solution. Giving them the extra of IPv6 and thus no NAT there is a good thing. For NAT's here the biggest problem is simply the point that you can't directly SSH into that OS you are running on that cool Xen box with 20 different operating systems. Unless you love port forwarding and other such tricks of course.
If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, [..]
Your grandma really doesn't know what "IP" is, nor will she ever care. <stuff>
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.
No it is an extra service: They get full connectivity over IPv6. There are not that many ISP's where you, per default, get the amount of IPv4 addresses you already get, unless you pay them a wad of cash. In IPv6 ISP's are supposed to provide every end-site a /48. If they don't then they are not following up on the justification that they actually requested IPv6 address space under and then they should not have the space in the first place.
While I think that some degradation of service is inevitable, I believe that it would be better to minimise the lessening of service, and shorten the transition period, wouldn't you?
IPv4 will exist for a long long long long time, long after IPv6 is considered to be the 'standard' way of doing IP. To shorten the transition period all the 'important' things on the Internet have to be doing IPv6. But as it is business and it resolves around cash, they will be doing IPv4 for a long time too. And that is good, as it gives providers time to move over. Of course when you don't have any IPv4 addresses any more, you are quite bitten. So better start moving.
It occurs to me, and correct me if I'm wrong, but in your model of this transition there becomes little benefit to moving customers to IPv6 at all if being stuffed behind a v4 NAT or HTTP proxies counts as "Internet connectivity". Of course, I'm probably taking your suggestions to an extreme there.
They get the benefit of using IPv6 and thus full end to end connectivity for all their hosts, instead of receiving only 1 single IPv4 address. I see that as a real improvement, and it is a model that a lot of people are very happy with in using. It is what all the tunnel brokers provide and one of the main reasons I see as signup reason for people signing up to SixXS. Note that there are for some time already ISP's who put their users behind a NAT per default and as such those folks can't run any services at all. When they get an IPv6 tunnel, they can do almost* anything they want with their connectivity. Greets, Jeroen * = abuse is of course never tolerated...
On Mon, 28 May 2007, Nathan Ward 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'. Yes, vendors should have been asked for v6 capabilities equal to v4 capabilties for atleast 10 years now, in some cases they were in some cases not. Either way, they aren't pushing out v6 capable product today are they? Even with: 1) gao mandate 2) 'ipv4 exhaustion' 3) hue anc cry from v6 folks what's going to change this inthe near future?
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. -- William Leibzon Elan Networks william@elan.net
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.
excellent, so 3 out of 6 billion can work fine.. mass-supportability/deplyability that is not.
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 william@elan.net
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
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 <mhernand1@comcast.net> Responder a: <owner-nanog@merit.edu> 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.
On Sun, 27 May 2007, JORDI PALET MARTINEZ wrote:
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.
is there a global-ipv6 -> terado gateway in existence yet? If not... it's not ipv6 connectivity. It's nat-traversal to a 'private' network which happens to use ipv6 addressing. Things like 6to4 won't really scale as a solution either :( if comcast's 20m clients wake up and 6to4 tunnel tomorrow someone's 6to4 tunnel server is going to be in big trouble :( (same for the 7.5m verizon dsl customers, which reminds me I need to get back to playing some more with a 6to4 gateway again) Anyway, Terado had always seemed like a nice solution to not the ipv6 transition problem.
Hi Chris, Yes, there are several. We host one of them at least. But they are not needed for peer-to-peer only for those cases when some users use Teredo and others have 6to4 or other IPv6 (native, other transition techniques). Of course, this situation will become more and more frequent (more people using IPv6, even w/o knowing, means more people using different transition mechanisms and having more chances to need to use 6to4 and Teredo Relays). That's why I'm trying to convince folks about deploying 6to4 and Teredo relays, which is something quite simple to do. Also this will allow to scale. For example, I guess that if a big ISP setup 6to4 relays in the same router that they have at every POP, then there is not an scalability issue, even if those relays are only available for the ISP customers. For Teredo, today you need to use either Windows 2003 or the Longhorn (which is a beta), or Miredo which can be setup in any Open Source OS, but I don't think is a big issue either. I expect the router vendors to have Teredo support in a short time, hopefully. In our case, we host a Teredo Server+Teredo Relay+6to4 Relay+Tunnel Broker in the same Linux box, which is also IPv6 natively connected to our dual-stack infrastructure. This is what I would recommend. In fact, because this becomes much more relevant were the upstream transit is more expensive, in LACNIC and AfriNIC (in Spanish an English, respectively), next week I will start a thread to explain how to install both in different platforms and solve problems that the people may have when doing so. Folks interested in the English version should subscribe at https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss. For Spanish subscribe at https://mail.lacnic.net/mailman/listinfo/lactf. Regards, Jordi
De: "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> Responder a: <owner-nanog@merit.edu> Fecha: Sun, 27 May 2007 17:27:40 +0000 (GMT) Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: Nanog <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On Sun, 27 May 2007, JORDI PALET MARTINEZ wrote:
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.
is there a global-ipv6 -> terado gateway in existence yet? If not... it's not ipv6 connectivity. It's nat-traversal to a 'private' network which happens to use ipv6 addressing. Things like 6to4 won't really scale as a solution either :( if comcast's 20m clients wake up and 6to4 tunnel tomorrow someone's 6to4 tunnel server is going to be in big trouble :( (same for the 7.5m verizon dsl customers, which reminds me I need to get back to playing some more with a 6to4 gateway again)
Anyway, Terado had always seemed like a nice solution to not the ipv6 transition problem.
********************************************** 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.
I believe that using a gateway or a translation device for ipv6-ipv4 just gives people an excuse to ignore ipv6. I really do believe that if ipv6 is to go full scale we have to jump in with everything ipv6 only or ipv4 the intermediate will just postpone the inevitable. Take that from experience, give the suits an out and they will take it rather than taking the advised path which may cost more now but less down the road when you have to pry it out of people to abandon the translation servers. Manolo Chris L. Morrow wrote:
On Sun, 27 May 2007, JORDI PALET MARTINEZ wrote:
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.
is there a global-ipv6 -> terado gateway in existence yet? If not... it's not ipv6 connectivity. It's nat-traversal to a 'private' network which happens to use ipv6 addressing. Things like 6to4 won't really scale as a solution either :( if comcast's 20m clients wake up and 6to4 tunnel tomorrow someone's 6to4 tunnel server is going to be in big trouble :( (same for the 7.5m verizon dsl customers, which reminds me I need to get back to playing some more with a 6to4 gateway again)
Anyway, Terado had always seemed like a nice solution to not the ipv6 transition problem.
Those are different things and I can't agree with you. I¹m not saying that using a translator is the best thing to do. I will prefer not to go that way, and that requires the services and contents to be dual-stacked, but is better a translator than nothing if no other way. Regarding the relays (I guess you mean relay when talking about gateways), they are part of the transition, and they are required. You like it or not. Actually I think they are a very good thing. Unfortunately, we can't agree all to just switch off all the Internet, upgrade to IPv6 and disable IPv4, so transition is needed and it is a smart thing. Regards, Jordi De: Manolo Hernandez <mhernand1@comcast.net> Responder a: <mhernand1@comcast.net> Fecha: Sun, 27 May 2007 13:50:14 -0400 Para: "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> CC: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Nanog <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted I believe that using a gateway or a translation device for ipv6-ipv4 just gives people an excuse to ignore ipv6. I really do believe that if ipv6 is to go full scale we have to jump in with everything ipv6 only or ipv4 the intermediate will just postpone the inevitable. Take that from experience, give the suits an out and they will take it rather than taking the advised path which may cost more now but less down the road when you have to pry it out of people to abandon the translation servers. Manolo Chris L. Morrow wrote:
On Sun, 27 May 2007, JORDI PALET MARTINEZ wrote:
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.
is there a global-ipv6 -> terado gateway in existence yet? If not... it's not ipv6 connectivity. It's nat-traversal to a 'private' network which happens to use ipv6 addressing. Things like 6to4 won't really scale as a solution either :( if comcast's 20m clients wake up and 6to4 tunnel tomorrow someone's 6to4 tunnel server is going to be in big trouble :( (same for the 7.5m verizon dsl customers, which reminds me I need to get back to playing some more with a 6to4 gateway again)
Anyway, Terado had always seemed like a nice solution to not the ipv6 transition problem.
********************************************** 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.
At 3:30 PM +0000 5/27/07, Chris L. Morrow wrote:
what's going to change this in the near future?
At some point in the near future (e.g. 3 to 5 years), an ISP is going to be connecting some customers to the 'Internet' using just IPv6 addresses. It may not be your ISP doing it first, but it will very quickly go from just one ISP connecting IPv6-only customers to lots of ISP's doing IPv6-only customers. This changeover will not: 1) Fix the routing problem inherent with present locator/endpoint binding, nor 2) solve your favorite fib/rib/cam/convergence limit, nor 3) make the infrastructure inherently either easier to operate or more secure. One can argue with the date when this occurs, based on your particular address reclamation, reuse, and market expectations, but it's still going to happen since there's no other game in town. (*) 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. We've have to move efficiently towards readiness for the IPv6-only customer that will be told this is his only choice for Internet connectivity. While some customers may shop around or buy their way of that honor, that only works for a very short time until the answer is the same throughout the network. Actual behavior of ISPs will change as they realize even if they're not the first ISP to have to connect customers via IPv6-only, they will be face that situation in time. /John (*) Anyone advocating staying with IPv4 and relying on NAT and market demand as an alternative needs to consider the completely deaggregated address usage pattern (and routing table explosion) that results. P.S. I'm not at this NANOG, and it's probably too late to round up presentations, but what might be really helpful to most folks would be presentations which cover some or most aspects (getting transit, address planning, routing, firewall, DNS/DHCP) of dropping IPv6 into existing IPv4 service providers with destroying today's production services by accident. Real world experience is preferred over vendor thoughts, but at this point well-conceived plans would be helpful from any quarter. I would be happy to volunteer my services to recruit for presenters for future meetings; if anyone has an a thought for folks qualified to speak on such plans, drop me a note and I will encourage they find their way to the NANOG PC with the right enthusiasm.
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
On 29-mei-2007, at 15:21, Donald Stahl wrote:
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.
Actually IPv6 has the potential to be very important in the peer-to- peer space. That doesn't just mean bittorrent, but also less suspect services such as anything built on top of IM, such as direct file transfers and audio and video chats. It would help if those applications supported v6, though.
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?
You mean other than setting it up once, forgetting about it and then calling the support line when it stops working? Don't forget that changing mail settings isn't something you'll want to do too often (speaking as the owner of an IPv6 mail server and a mail client that won't fall back to IPv4 when IPv6 is present but doesn't work). I'm not saying this type of testing shouldn't be done, but personally I would try to find services that see enough use to flush out any problems, but aren't important enough to cause real trouble when they don't work. I don't know that an example of that would be, though.
On 5/29/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 29-mei-2007, at 15:21, Donald Stahl wrote:
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?
You mean other than setting it up once, forgetting about it and then calling the support line when it stops working? Don't forget that changing mail settings isn't something you'll want to do too often (speaking as the owner of an IPv6 mail server and a mail client that won't fall back to IPv4 when IPv6 is present but doesn't work).
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?
On 29 May 2007, at 14:49, Alexander Harrowell wrote:
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. Some of my colleagues wont even know how to. Andy
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 R&E 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
:: 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? 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 stable version of code that does IPv4 SACK/other useful tcp options in some LB modes). Once we get past that, I'm sure something else will be an issue (as it has in the past), but believe me, we *are* actively working towards v6, it is just a slow process right now with a lot of moving pieces, and an obvious mandate not to negatively impact the current v4 infrastructure... Thanks, -igor
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
On Sun, 3 Jun 2007, Donald Stahl wrote: :: > 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. 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... :: 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. Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement. 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. My stance is that simply enabling v6 on a server in "not interesting", v6 has to be enabled on the *service*, and for that to happen, the v4 feature-sets that the service is using has to be mirrored (and then tested/debugged) in v6, otherwise no real point to the test. 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... -igor
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
Agree, and in fact, a quick though is that as you may expect *much less* IPv6 traffic today, not having load balancing may not be an issue, and you can always actively measure if the traffic is going high, etc. If the time arrives when the traffic is so high and your preferred vendor doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the sense that you can just delete the AAAA records, but meanwhile you have a very realistic test environment and motivation to push your vendors, or considering the traffic, decide if moving to other vendors, etc. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <owner-nanog@merit.edu> Fecha: Sun, 3 Jun 2007 23:01:57 +0100 Para: <nanog@nanog.org> Conversación: IPv6 transition work was RE: NANOG 40 agenda posted Asunto: 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
********************************************** 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.
What I guess have not been clear on is the fact that loadbalancers for many people are an integral (and required) part of the *architecture* (and not just something u need to distribute load), and as such, are a component that must support v6 for the *service* to then be able to support it (much like basic logging now would need to be v6 capable, etc). There is simply no easy way of taking 1 machine and making it mail.ipv6.yahoo.com (as an example), not to mention that nobody is going to invest the time and resources into building a completely different architecture (a single server is a complete one-off) to support a test rollout of v6 (and then having to sync different code trees, etc), when that time and resources could be better invested in coming up with a real solution for the long-term. Again, we are working on it, it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, and in fact, I've said all I can. Thanks, -igor On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote: :: :: Agree, and in fact, a quick though is that as you may expect *much less* :: IPv6 traffic today, not having load balancing may not be an issue, and you :: can always actively measure if the traffic is going high, etc. :: :: If the time arrives when the traffic is so high and your preferred vendor :: doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the :: sense that you can just delete the AAAA records, but meanwhile you have a :: very realistic test environment and motivation to push your vendors, or :: considering the traffic, decide if moving to other vendors, etc. :: :: Regards, :: Jordi :: :: :: :: :: > De: <michael.dillon@bt.com> :: > Responder a: <owner-nanog@merit.edu> :: > Fecha: Sun, 3 Jun 2007 23:01:57 +0100 :: > Para: <nanog@nanog.org> :: > Conversación: IPv6 transition work was RE: NANOG 40 agenda posted :: > Asunto: 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 :: :: :: :: :: ********************************************** :: 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. :: :: ::
At 7:16 PM -0400 6/3/07, Igor Gashinsky wrote:
Again, we are working on it,
Good to know...
it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, ...
Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... /John
John Curran wrote:
Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market...
I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. Rock on Citrix.
This is one of the ways some load-balancer vendors do IPv6 today. They still talk IPv4 to the servers, so you don't need to modify anything, just add an AAAA managed by the load balancer. It is a kind of combination between NAT-PT and load-balancer. Regards, Jordi
De: matthew zeier <mrz@velvet.org> Responder a: <owner-nanog@merit.edu> Fecha: Sun, 03 Jun 2007 22:58:37 -0700 Para: John Curran <jcurran@mail.com> CC: Igor Gashinsky <igor@gashinsky.net>, <nanog@merit.edu> Asunto: Re: IPv6 transition work was RE: NANOG 40 agenda posted
John Curran wrote:
Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market...
I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend.
Rock on Citrix.
********************************************** 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.
On Sun, 3 Jun 2007, matthew zeier wrote:
John Curran wrote:
Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market...
I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend.
While I understand that some place may want to put policies that every v4 part must be exactly same as v6 I think more realistic view is better. You should have servers ready to answer v6 but look at your traffic - is it really necessary to add v6 to your load-balancer or would it be ok to just have AAAA record pointing to particular system (even if 7 others are available) because the amount of traffic makes more sense. Now when v6 traffic increase there would be more pressure for vendors to make load-balancers support v6 as well and you'd not have problems then. But if you're still thinking about v6 load-balancers, then I recommend taking a look at http://kb.linuxvirtualserver.org/wiki/IPVS -- William Leibzon Elan Networks william@elan.net
william(at)elan.net wrote: .
I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend.
While I understand that some place may want to put policies that every v4 part must be exactly same as v6 I think more realistic view is better. You should have servers ready to answer v6 but look at your traffic - is it really necessary to add v6 to your load-balancer or would it be ok to just have AAAA record pointing to particular system (even if 7 others are available) because the amount of traffic makes more sense. Now when v6 traffic increase there would be more pressure for vendors to make load-balancers support v6 as well and you'd not have problems then. But if you're still thinking about v6 load-balancers, then I recommend taking a look at http://kb.linuxvirtualserver.org/wiki/IPVS
For me, this seriously comes down to ease of deployment. I don't have to duplicate servers just for v6. Infact, all I have to do is add a v6 vip and I'm done. Oh, and it lets me roll v6 out in a production manner, HA and all. I do agree that the traffic level is nearly insignificant but the fact that my vendor supports it and I don't have to manage yet another system, makes my life easier. - mz
Understood. One more alternative to just keep the existing load-balancer infrastructure is to setup a NAT-PT box. Again, even if this may not scale for millions of users, it may be a good solution for the few users that can be accessing with IPv6 your contents. Of course, all this may not necessarily work for your infrastructure, I'm talking in "raw mode", not knowing your network details, etc. Regards, Jordi
De: Igor Gashinsky <igor@gashinsky.net> Responder a: <igor@gashinsky.net> Fecha: Sun, 3 Jun 2007 19:16:06 -0400 (EDT) Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <nanog@merit.edu> Asunto: Re: IPv6 transition work was RE: NANOG 40 agenda posted
What I guess have not been clear on is the fact that loadbalancers for many people are an integral (and required) part of the *architecture* (and not just something u need to distribute load), and as such, are a component that must support v6 for the *service* to then be able to support it (much like basic logging now would need to be v6 capable, etc).
There is simply no easy way of taking 1 machine and making it mail.ipv6.yahoo.com (as an example), not to mention that nobody is going to invest the time and resources into building a completely different architecture (a single server is a complete one-off) to support a test rollout of v6 (and then having to sync different code trees, etc), when that time and resources could be better invested in coming up with a real solution for the long-term.
Again, we are working on it, it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, and in fact, I've said all I can.
Thanks, -igor
On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote:
:: :: Agree, and in fact, a quick though is that as you may expect *much less* :: IPv6 traffic today, not having load balancing may not be an issue, and you :: can always actively measure if the traffic is going high, etc. :: :: If the time arrives when the traffic is so high and your preferred vendor :: doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the :: sense that you can just delete the AAAA records, but meanwhile you have a :: very realistic test environment and motivation to push your vendors, or :: considering the traffic, decide if moving to other vendors, etc. :: :: Regards, :: Jordi :: :: :: :: :: > De: <michael.dillon@bt.com> :: > Responder a: <owner-nanog@merit.edu> :: > Fecha: Sun, 3 Jun 2007 23:01:57 +0100 :: > Para: <nanog@nanog.org> :: > Conversación: IPv6 transition work was RE: NANOG 40 agenda posted :: > Asunto: 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 :: :: :: :: :: ********************************************** :: 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. :: :: ::
********************************************** 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.
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
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 AAAA, 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.
Valdis.Kletnieks@vt.edu 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 AAAA, 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.
ipv6 load balancers exist, one's current load balancer is/may probably not be up to the task.
my favourite load balancer is OSPF ECMP, since there are no extra boxes, just the routers and switches and hosts i'd have to have anyway. quagga ospf6d works great, and currently lacks only a health check API. -- Paul Vixie
my favourite load balancer is OSPF ECMP, since there are no extra boxes, just the routers and switches and hosts i'd have to have anyway.
quagga ospf6d works great, and currently lacks only a health check API. Health checks are unfortunately the most important aspect of a LB for some
people. Can you elaborate on where you use ECMP and specifics about your implementation that might interest people? -Don
two replies here. i (paul@vix.com) said:
quagga ospf6d works great, and currently lacks only a health check API.
Donald Stahl <don@calis.blacksun.org> answered:
Health checks are unfortunately the most important aspect of a LB for some people.
understood.
Can you elaborate on where you use ECMP and specifics about your implementation that might interest people?
i could, but joe abley already did, and i wouldn't want to plagiarize him. plz see <http://www.isc.org/pubs/tn/index.pl?tn=isc-tn-2004-1.html>. --- Colm MacCarthaigh <colm@stdlib.net> answered:
If you're load-balancing N nodes, and 1 node dies, the distribution hash is re-calced and TCP sessions to all N are terminated simultaneously.
i could just say that since i'm serving mostly UDP i don't care about this, but then i wouldn't have a chance to say that paying the complexity and bug and training cost of an extra in-path powered box 24x365.24 doesn't weigh well against the failure rate of the load balanced servers. somebody could drop an anvil on one of my servers twice a day (so, 730 times per year) and i would still come out ahead, given that most TCP traffic comes from web browsers and many users will click "Reload" before giving up. then there's CEF which i think keeps existing flows stable even through an OSPF recalc. finally, there's the fact that we see less than one server failure per month among the 100 or so servers we've deployed behind OSPF ECMP. i know a lot of people who get paid well for building and selling and supporting Extra Powered Boxes, and a lot of other people who will never get fired for buying one... but that doesn't make it right.
On Mon, Jun 04, 2007 at 07:29:03AM +0000, Paul Vixie wrote:
If you're load-balancing N nodes, and 1 node dies, the distribution hash is re-calced and TCP sessions to all N are terminated simultaneously.
i could just say that since i'm serving mostly UDP i don't care about this, but then i wouldn't have a chance to say that paying the complexity and bug and training cost of an extra in-path powered box 24x365.24 doesn't weigh well against the failure rate of the load balanced servers. somebody could drop an anvil on one of my servers twice a day (so, 730 times per year) and i would still come out ahead, given that most TCP traffic comes from web browsers and many users will click "Reload" before giving up.
It depends on the length of those TCP sockets. If you were load-balancing the increasingly common video-over-http, it would be very unacceptable. You also ignore the "thundering herd" problem that arises when you suddenly get all of your active clients re-requesting in a very short time-window like that. If I have 1000 active flows that last 10 seconds each, I can expect a peak rate of about 200 new flows per second. Kill them all in one go and I can expect a peak rate of 5 times that. That's a significant difference to plan for, and very different from the load you expect after an extended outage or initial switch on. This problem also gets increasingly worse the longer the TCP sockets live.
then there's CEF which i think keeps existing flows stable even through an OSPF recalc.
No CEF table I've used does that. Also, if you restrict yourself to CEF, you have to accept a decrease in the ammount of nodes you can balance Vs something like quagga on *nix. The limits are anywhere from just 6 ECMP routes to 32 (though of course you could do staggered load-balancing using multiple CEF devices). I'm open to correction on the 32, but it's the highest I've yet come accross. The routes get distributed accross the slots of the CEF table as evenly as possible, but when they dissappear the hashing completely changes (at least it does for me operationally, and if I use "show ip cef exact-route". Interestingly, there is a CEF table state that /could/ enable this functionality, the "punt" state promises to have an unswitchable packet get punted out of the CEF table and fall back to higher-level software switching. If the CEF slots occupied by a now-down node could be forced into the punt state then only traffic toward that node would be affected. But despite questions to Cisco dev teams and much experimentation, I can't see a reliable way to get a CEF table entry into the punt state (unlike say the "glean" state, which isn't good enough).
finally, there's the fact that we see less than one server failure per month among the 100 or so servers we've deployed behind OSPF ECMP.
Failure rates can and should be low indeed, but that's not where I see the primary utility of high-availability load-balancers. If I have 20 web-servers in a load-balanced cluster and I need to upgrade them to the latest version of Apache for security reasons, I want to do it one by one without losing a single HTTP session. This *is* possible with many load-balancers (plug: Including Apache's own load-balancing proxy), but with OSPF I'm forced to drop *all* sessions to the cluster 20 times (or yes I could do 10 nodes at a time, but you get the picture). I *like* OSPF ECMP load-balancing, it's *great*, and I use it in production, even load-balancing a tonne of https traffic, but in my opinion you are over-stating its abilities. It is not close to the capabilities of a good intelligent load-balancer. It is however extremely cost-effective and good enough for a lot of usage, as long as it's taken with some operational and engineering considerations. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
It depends on the length of those TCP sockets. If you were load-balancing the increasingly common video-over-http, it would be very unacceptable.
yes. i believe i said that my preferred approach works really well with UDP and marginally well with current WWW. video over http is an example of an application who wouldn't like its ECMP recalced many times per month (which is the worst case; my actual experience is less-than-once-per-month.)
... The limits are anywhere from just 6 ECMP routes to 32 (though of course you could do staggered load-balancing using multiple CEF devices). I'm open to correction on the 32, but it's the highest I've yet come accross.
this is the more interesting scaling limit. i know of a company with ~150 recursive name servers all answering at the same IP address. ECMP won't help at that level. i believe that even a hardware load balancer would have to be multistage at that level, but once you've got multiple levels then the Powered Boxes aren't Extra any more and i wouldn't prefer an ECMP design.
... This *is* possible with many load-balancers (plug: Including Apache's own load-balancing proxy), but with OSPF I'm forced to drop *all* sessions to the cluster 20 times (or yes I could do 10 nodes at a time, but you get the picture).
yes.
I *like* OSPF ECMP load-balancing, it's *great*, and I use it in production, even load-balancing a tonne of https traffic, but in my opinion you are over-stating its abilities. It is not close to the capabilities of a good intelligent load-balancer. It is however extremely cost-effective and good enough for a lot of usage, as long as it's taken with some operational and engineering considerations.
or if, as in my case, the primary app is UDP based. your points are well taken in the case of large scale TCP though.
On Mon, Jun 04, 2007 at 02:53:52AM +0000, Paul Vixie wrote:
ipv6 load balancers exist, one's current load balancer is/may probably not be up to the task.
my favourite load balancer is OSPF ECMP, since there are no extra boxes, just the routers and switches and hosts i'd have to have anyway.
quagga ospf6d works great, and currently lacks only a health check API.
If you're load-balancing N nodes, and 1 node dies, the distribution hash is re-calced and TCP sessions to all N are terminated simultaneously. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
On 4-Jun-2007, at 02:03, Colm MacCarthaigh wrote:
On Mon, Jun 04, 2007 at 02:53:52AM +0000, Paul Vixie wrote:
ipv6 load balancers exist, one's current load balancer is/may probably not be up to the task.
my favourite load balancer is OSPF ECMP, since there are no extra boxes, just the routers and switches and hosts i'd have to have anyway.
quagga ospf6d works great, and currently lacks only a health check API.
If you're load-balancing N nodes, and 1 node dies, the distribution hash is re-calced and TCP sessions to all N are terminated simultaneously.
Yep. This is a disadvantage that was mentioned in both <http:// www.nanog.org/mtg-0505/abley.cluster.html> and <http://www.isc.org/ pubs/tn/isc-tn-2004-1.txt>. I seem to think there's general text about this in RFC 4786, too. From the ISC tech note: CEF's route selection algorithm is stateless and deterministic for a stable set of ECMP routes. In general, however, a change in the number or ordering of those routes may cause the route selected for a particular (source, destination) hash to change. This fragility should be considered when gauging whether this load distribution approach is appropriate to particular protocols. I have used dedicated load-balancing appliances for this kind of application. They have the disadvantages that (a) they are not cheap, and (b) sometimes the non-cheapness encourages people to use them in a fashion which exposes a single point of failure. They have many advantages, too, including (often) a sufficiently-capable state engine that the issue you mention does not arise. As with all things, the trick is to weigh the risk of disaster against the probability of benefit and do whatever makes sense within your own particular constraints. Joe
As with all things, the trick is to weigh the risk of disaster against the probability of benefit and do whatever makes sense within your own particular constraints.
is nobody using a host based solution to this? that is, are times when HA LB is needed for TCP (like video over http) also seen as times when a single UNIX host is too unreliable, even if it's fast enough, and an appliance is better? even last year's model of BSD or Linux 1U with a couple of broadcom GigE ports can run proxynetd at near wire speed. so performance isn't the issue unless we're talking 10GE, and there can't be many appliances operating at 10GE yet. or is the problem simply that there isn't a port or pkg or rpm of proxynet, and in spite of being 12 years old, nobody but me runs anything like it? (so, this boils down to, are folks only using proxies on outbound, still, in 2007?) ((and did you think squid was your only inbound proxying option?))
or is the problem simply that there isn't a port or pkg or rpm of proxynet, and in spite of being 12 years old, nobody but me runs anything like it? (so, this boils down to, are folks only using proxies on outbound, still, in 2007?) ((and did you think squid was your only inbound proxying option?))
As someone who has used both the appliance route (ie: Foundry ServerIron or F5 BigIP) and nix box (ie: pound or OpenBSD's hoststated), they each have their advantages/disadvantages as Joe kindly points out. Cost comes down as a factor normally.. spend 10 hours tweaking the perfect MythTV box or an hour @ Fry's to buy a Tivo - weigh your own time against your wallet. I find that appliance route still has a number of major advantages for "serious" or enterprise use - SNMP agent (graph # of connections per VIP), failover (though CARP fixes this in the OpenBSD land), fancy healthchecks (developers aren't always clueful enough to code errors in the form of HTTP codes), security features (limit req/sec based on a cookie, CIDR or some other metric), etc. Ironically in the 10gig range, the available products to do L7 traffic fudging are limited and quite costly - a lot of folks with lots of bits to push (I do video) tend to take the "Direct Server Return"/nPath/etc route. Appliances tend to have support contracts and that allows the suits to sleep at night too. --Matt
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 AAAA, 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
On 4/06/2007, at 12:43 PM, Valdis.Kletnieks@vt.edu 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 AAAA, 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 AAAA 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 AAAA 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
Nathan Ward <nanog@daork.net> wrote:
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 AAAA for the time being.
Actually I would do it the other way around, adding AAAA to the MX set is rather painless, as only full-blown MTAs with well-defined fallback procedures (and without a user sitting in front of it wondering why the hell it is so slow) use it anyway. Traffic won't be high, I think you won't need an LB from day 0, one server should be sufficient for current traffic (and if not, you can always add multiple AAAA records). Enabling IPv6 on customer-facing services is harder, as you will almost certainly run into some broken client. A dedicated hostname for tests is good, but that won't help you find the people that are completely unaware of the existence of IP at all, but somehow got a broken IPv6 stack installed (old Linux kernels with on-link assumption for example). Regards, Bernhard
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 <don@calis.blacksun.org> Responder a: <owner-nanog@merit.edu> Fecha: Tue, 29 May 2007 09:21:49 -0400 (EDT) Para: John Curran <jcurran@istaff.org> 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.
This is useless. Users need to use the same name for both IPv4 and IPv6, they should not notice it. It is not useless- I am specificallyt talking about setting it up initially so that technically capable people can use and test the infrastructure without breaking anything for those people on v4 that have misconfigured v6 tunnels and the like (something that is not at all uncommon with Vista). If you just turn on AAAA records for www.google.com right now, lots of people will end up being unable to connect to www.google.com because of a broken tunnel- and right now ISP's are not
primed to help their customers fix the problem.
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. Agreed.
-Don
At 10:31 -0400 5/29/07, Donald Stahl wrote:
This is useless. Users need to use the same name for both IPv4 and IPv6, they should not notice it. It is not useless- I am specifically talking about setting it up initially so that technically capable people can use and test the infrastructure without breaking anything for those people on v4 that have misconfigured v6 tunnels and the like (something that is not at all uncommon with Vista). If you just turn on AAAA records for www.google.com right now, lots of people will end up being unable to connect to www.google.com because of a broken tunnel- and right now ISP's are not primed to help their customers fix the problem.
From experience, (see: http://www.nanog.org/mtg-0405/pdf/lewis.pdf) I have done this. I don't think I spent much time on that in the slides, but we did start with things like "ww6." and "ftp6." It let us put up servers in a production environment and see them functionally work. But the value in doing this is limited. First, it can't/doesn't draw enough load to give an accurate feeling of whether "IPv6 works" because the only ones that know about it are those you tell. (Not that IPv6 volume is all that great.) Second, it isn't stable (long run) because you have to eventually use the same names for all network (IP) versions. You'll have to ween the early adopters off the special names at some point. I would say that this is something folks should just do to make sure the servers come up and answer. But it not much of a "coming of age" step. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale.
This is useless. Users need to use the same name for both IPv4 and IPv6, they should not notice it.
This is *NOT* useless. If a user network is connected to an ISP only through IPv6, then it is very useful indeed, if they can access email services or any other service provided by Yahoo, Google and others. Remember, that the day will come when users must choose between a purely IPv6 Internet connnection, or no new connection at all. In that scenario, access to services is what counts. It would be nice if the setup was effortless, but that is not necessary. But look at it from a different point of view. That day has not yet arrived so ISPs do not currently have to provide services to users over a pure IPv6 connection. The suggestion for Yahoo was made with the intention of TRIALING IPv6. That is most definitely *NOT* useless to ISPs and content providers. Nobody was saying that ISPs should begin to move customers onto IPv6 right now using special ipv6 subdomains. Your statement about what users should and should not do, reminds me of Communist party thinking. Several countries have tried out central planning by "experts" on a large scale and it has been proven to be unworkable and sub-optimal. I think that there is a general consensus, among ISPs at least, that transition to IPv6 will be gradual and will be done on a needs basis, not centrally planned by governments or RIRs or experts. ISPs are, for the most part, business enterprises which make their planning decisions based on customer demand. If customers don't notice something, then they won't demand it. So, I think that the vast majority of ISPs do want customers to notice the transition to IPv6. They do want customers to understand the imperatives of IPv4 exhaustion. They do want customers to engage with them on IPv6, so that ISPs can provide the right kind of services for each different customer type. In some cases, that will involve things like IPv4-IPv6 application layer web proxies which the network engineering crowd would detest. Or maybe Akamai will come up with some kind of IPv4-IPv6 redirection scheme complete with backdoor IPv4 double-NAT tunnels. The work may be done on the base technology of IPv6, but there is still a lot of scope for work on transition of SERVICES (not networks) to an IPv6 world.
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.
What's this? You disagree with yourself? OK, I'm with you fellas... --Michael Dillon O Brother, Where Art Thou?
Jordi, On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
This is useless. Users need to use the same name for both IPv4 and IPv6,
Why? The IETF chose to create a new protocol instead of extending the old protocol. Even the way you ask for names is different (A vs. AAAA). Why should anyone assume a one-to-one mapping between the two Internets based on those protocols?
they should not notice it.
They shouldn't, but they will. Having had the fun of trying to figure out why I lost connectivity to a site (then realizing it was because I had connected via IPv6 instead of IPv4 and IPv6 routing ... changed), the current IPv6 infrastructure is, shall we say, not quite production ready.
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.
Forcing end users to be exposed to the pain of transition? This is the techno-geek mindset, not the critical communications infrastructure-geek mindset. Guess which one is more appropriate to the Internet today? Rgds, -drc
What I'm saying, across different postings, is that I'm not advocating for dual-stacking existing services immediately (there is no need for that, no new advantages at this point). It is nice to have, but I agree that we must go step by step and time will tell us when moving on or even retiring IPv4 in some cases (which will happen in a much longer term in most of the networks). The reasons why your connectivity, being dual-stacked at the client and server side fail, are typically: 1) Server side not well connected to IPv6, or not connected at all and having an AAAA. Blame the server operator ! 2) Client side connected to a network that indicates "I've an IPv6 router and this is your prefix", but it is not the case. Blame the network administrator ! 3) Client side/network correctly configured but poor connectivity due to lack of good native connectivity, a stable tunnel, or using 6to4 or Teredo and relays not correctly/enough deployed. Blame operators for not operating correctly IPv6 transition ! We can compare 1, 2 and 3 to the same situation if, in the IPv4 world, the IPv4 connectivity gets broken. So let's stop blaming IPv6. Blame ourselves. We didn't our work very well, not yet up to now. Obviously, networks route IPv6 today, so resilience is not the same as if there is an improper configuration in IPv4, but again, this is what *we* operators, need to sort out soon. We need to deploy more relays while we are unable to deploy more native connectivity (of course this one preferred). We need to be exactly the same of serious with IPv6 routing as we do with IPv4. Then, with a very small effort from our side, automatic transition traffic will not be black holed, and there will be a reason to start moving on faster on configuring AAAA in all the content providers. By the way as I indicated a few postings ago, 3) can be sorted out very easily at each ISP network with a very low cost and no impact at all. You don't need to deploy, in case you can't, IPv6 at all across the rest of your network, just a static tunnel/s from the 6to4/Teredo Relay to any upstream or set of them. And this warrantees your customers IPv6 connectivity and improve their peer-to-peer experience even if different transitions mechanisms are being used among the peers. Can we do that ? By the way, even if we don't do that, peer-to-peer traffic is already taking advantage of IPv6, even only with transition mechanism such as 6to4 and Teredo. Regards, Jordi
De: David Conrad <drc@virtualized.org> Responder a: <drc@virtualized.org> Fecha: Tue, 29 May 2007 08:22:35 -0700 Para: <jordi.palet@consulintel.es> CC: Nanog <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
Jordi,
On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
This is useless. Users need to use the same name for both IPv4 and IPv6,
Why?
The IETF chose to create a new protocol instead of extending the old protocol. Even the way you ask for names is different (A vs. AAAA). Why should anyone assume a one-to-one mapping between the two Internets based on those protocols?
they should not notice it.
They shouldn't, but they will. Having had the fun of trying to figure out why I lost connectivity to a site (then realizing it was because I had connected via IPv6 instead of IPv4 and IPv6 routing ... changed), the current IPv6 infrastructure is, shall we say, not quite production ready.
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.
Forcing end users to be exposed to the pain of transition? This is the techno-geek mindset, not the critical communications infrastructure-geek mindset. Guess which one is more appropriate to the Internet today?
Rgds, -drc
********************************************** 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.
Small clarification. I'm not either saying "don't deploy dual-stack in servers", not at all. As a matter of experience, of someone using IPv6 for everything from everyplace in the world, I don't believe there is so much problem in doing so, neither so many users will really have any problem, and this has been said by many folks that tried that in this an many other forums. Of course, if you do so, make sure to do it correctly, and make sure to pay the same attention to the global routability of your IPv6 prefix, the same as you do with IPv4. I'm sure that more users get actually problems with NAT and the support cost is much higher than if we start supporting instead IPv6 services. So, if as a kind of self-assessment, you prefer to use ipv6.yourdomain.com for testing, that's fine, but it is not what the users should look for (something different), so make sure to make it just a starting point. Regards, Jordi
De: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fecha: Tue, 29 May 2007 18:09:17 +0200 Para: Nanog <nanog@nanog.org> Conversación: NANOG 40 agenda posted Asunto: Re: NANOG 40 agenda posted
What I'm saying, across different postings, is that I'm not advocating for dual-stacking existing services immediately (there is no need for that, no new advantages at this point). It is nice to have, but I agree that we must go step by step and time will tell us when moving on or even retiring IPv4 in some cases (which will happen in a much longer term in most of the networks).
The reasons why your connectivity, being dual-stacked at the client and server side fail, are typically: 1) Server side not well connected to IPv6, or not connected at all and having an AAAA. Blame the server operator ! 2) Client side connected to a network that indicates "I've an IPv6 router and this is your prefix", but it is not the case. Blame the network administrator ! 3) Client side/network correctly configured but poor connectivity due to lack of good native connectivity, a stable tunnel, or using 6to4 or Teredo and relays not correctly/enough deployed. Blame operators for not operating correctly IPv6 transition !
We can compare 1, 2 and 3 to the same situation if, in the IPv4 world, the IPv4 connectivity gets broken. So let's stop blaming IPv6. Blame ourselves. We didn't our work very well, not yet up to now.
Obviously, networks route IPv6 today, so resilience is not the same as if there is an improper configuration in IPv4, but again, this is what *we* operators, need to sort out soon.
We need to deploy more relays while we are unable to deploy more native connectivity (of course this one preferred).
We need to be exactly the same of serious with IPv6 routing as we do with IPv4.
Then, with a very small effort from our side, automatic transition traffic will not be black holed, and there will be a reason to start moving on faster on configuring AAAA in all the content providers.
By the way as I indicated a few postings ago, 3) can be sorted out very easily at each ISP network with a very low cost and no impact at all. You don't need to deploy, in case you can't, IPv6 at all across the rest of your network, just a static tunnel/s from the 6to4/Teredo Relay to any upstream or set of them. And this warrantees your customers IPv6 connectivity and improve their peer-to-peer experience even if different transitions mechanisms are being used among the peers.
Can we do that ?
By the way, even if we don't do that, peer-to-peer traffic is already taking advantage of IPv6, even only with transition mechanism such as 6to4 and Teredo.
Regards, Jordi
De: David Conrad <drc@virtualized.org> Responder a: <drc@virtualized.org> Fecha: Tue, 29 May 2007 08:22:35 -0700 Para: <jordi.palet@consulintel.es> CC: Nanog <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
Jordi,
On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
This is useless. Users need to use the same name for both IPv4 and IPv6,
Why?
The IETF chose to create a new protocol instead of extending the old protocol. Even the way you ask for names is different (A vs. AAAA). Why should anyone assume a one-to-one mapping between the two Internets based on those protocols?
they should not notice it.
They shouldn't, but they will. Having had the fun of trying to figure out why I lost connectivity to a site (then realizing it was because I had connected via IPv6 instead of IPv4 and IPv6 routing ... changed), the current IPv6 infrastructure is, shall we say, not quite production ready.
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.
Forcing end users to be exposed to the pain of transition? This is the techno-geek mindset, not the critical communications infrastructure-geek mindset. Guess which one is more appropriate to the Internet today?
Rgds, -drc
********************************************** 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.
On 29 May 2007, at 5:22pm, David Conrad wrote: [...]
they should not notice it.
They shouldn't, but they will. Having had the fun of trying to figure out why I lost connectivity to a site (then realizing it was because I had connected via IPv6 instead of IPv4 and IPv6 routing ... changed), the current IPv6 infrastructure is, shall we say, not quite production ready.
They already do. This popped up in my feed reader today: http://ask.metafilter.com/63532/Trouble-with-Firefox it ends with this comment: "If your hosting provider is serving your domain with IPv6, then it is time to find a new provider." Regards, Leo
On 29-mei-2007, at 18:17, Leo Vegoda wrote:
it ends with this comment: "If your hosting provider is serving your domain with IPv6, then it is time to find a new provider."
I guess they can stick with their current hosting provider then, because:
dig JournalistExpress.com aaaa
; <<>> DiG 9.3.1 <<>> JournalistExpress.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36772 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 Unfortunately, treading lightly as to not to wake the bugs means that they aren't fixed... In this regard, it would be interesting to hear from people who run non-trivial IPv6-enabled WWW sites about complaints about their reachability.
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 AAAA. I heard the same from other people. I also heard the opposite some times, but I haven't been able to debug any of those cases to understand where is the problem, except a few cases of people *not having stable IPv6 connectivity* and using AAAA in their servers: Bad practice ! Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Tue, 29 May 2007 20:39:20 +0200 Para: Leo Vegoda <leo.vegoda@icann.org> CC: NANOG list <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On 29-mei-2007, at 18:17, Leo Vegoda wrote:
it ends with this comment: "If your hosting provider is serving your domain with IPv6, then it is time to find a new provider."
I guess they can stick with their current hosting provider then, because:
dig JournalistExpress.com aaaa
; <<>> DiG 9.3.1 <<>> JournalistExpress.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36772 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
Unfortunately, treading lightly as to not to wake the bugs means that they aren't fixed... In this regard, it would be interesting to hear from people who run non-trivial IPv6-enabled WWW sites about complaints about their reachability.
********************************************** 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.
On 30/05/2007, at 9:47 AM, JORDI PALET MARTINEZ wrote:
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 AAAA.
I heard the same from other people. I also heard the opposite some times, but I haven't been able to debug any of those cases to understand where is the problem, except a few cases of people *not having stable IPv6 connectivity* and using AAAA in their servers: Bad practice !
Is there any kind of "common IPv6 transition problems" documents or collaborative places (ie. wikis) around to share learnings on this stuff? If not, should we start one? -- Nathan Ward
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 AAAA. 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
But now PI is there, no more restrictions in the path, so they can use "traditional" multihoming :-) Regards, Jordi
De: Donald Stahl <don@calis.blacksun.org> Responder a: <owner-nanog@merit.edu> Fecha: Tue, 29 May 2007 20:53:36 -0400 (EDT) Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: Nanog <nanog@nanog.org> Asunto: 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 AAAA. 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
********************************************** 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.
But now PI is there, no more restrictions in the path, so they can use "traditional" multihoming :-) If ARIN is going to assign /48's, and people are blocking anything longer
than /32- well then that's a problem :) -Don
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
That's why I was not in favor of PI neither critical infrastructures with /48. It will take time, but hopefully everybody will place the right filters. Regards, Jordi
De: Donald Stahl <don@calis.blacksun.org> Responder a: <owner-nanog@merit.edu> Fecha: Wed, 30 May 2007 10:12:54 -0400 (EDT) Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: Nanog <nanog@nanog.org> Asunto: Re: IPv6 Deployment (Was: Re: NANOG 40 agenda posted)
But now PI is there, no more restrictions in the path, so they can use "traditional" multihoming :-) If ARIN is going to assign /48's, and people are blocking anything longer than /32- well then that's a problem :)
-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.
At 8:22 -0700 5/29/07, David Conrad wrote:
Jordi,
On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
This is useless. Users need to use the same name for both IPv4 and IPv6,
Why?
The IETF chose to create a new protocol instead of extending the old protocol. Even the way you ask for names is different (A vs. AAAA). Why should anyone assume a one-to-one mapping between the two Internets based on those protocols?
I'll take a stab at "why?" First - "the way you ask for names" is not different at the application level, it is different in the "layer" in which you find where to shoot packets. It's like paying at a cash register - you pay but by cash, charge, atm, ... But why "need" - okay, need is a strong word, but, if the user is coming from a search engine result page, the search engine is going to hand a URL with a machine name. The search engine doesn't know if the user to service has a v6 pipe (or a v4 pipe even), so the URL won't be customized for v4/v6. If the user types in the domain label (like "nanog") and the application then adds on TLDs and such, the application would have to try the likely set of IPv6 labels to pre-pend. As far as any other encoding of the name, whether IPv6 is working is something that the encoder cannot know as the code will probably be run from different points of the collective IP4 and IP6 network. OTOH - in the presentation I gave in May '04 (three years ago - and I didn't think it was pioneering even then, but who knew) I did have some "gotchas" about using the same name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale.
Ed, On May 29, 2007, at 9:22 AM, Edward Lewis wrote:
First - "the way you ask for names" is not different at the application level, it is different in the "layer" in which you find where to shoot packets.
Right. The problem is, the methodology by which you shoot packets may or may not work.
If the user types in the domain label (like "nanog") and the application then adds on TLDs and such, the application would have to try the likely set of IPv6 labels to pre-pend.
What a horrible idea. Applications automatically pre- or appending crap to domain name labels shouldn't be done, period.
As far as any other encoding of the name, whether IPv6 is working is something that the encoder cannot know as the code will probably be run from different points of the collective IP4 and IP6 network.
Exactly. And since it is impossible to know whether or not there is actual IPv6 connectivity to a site that is advertising AAAA records, you get into situations where you get a connection attempt, timeout, retry, etc., resulting in people getting directives like the one Leo pointed to. The IPv6 Internet is a different network than the IPv4 Internet. Same names invites confusion and unhappiness. Rgds, -drc
At 12:01 -0700 5/29/07, David Conrad wrote:
What a horrible idea. Applications automatically pre- or appending crap to domain name labels shouldn't be done, period.
I won't argue that, but it happens. And I do make use of it. When I am back from a trip I type in "dilbert" and see the comic appear. The next time I type in "d" and my browswer fills in the whole URL.
The IPv6 Internet is a different network than the IPv4 Internet. Same names invites confusion and unhappiness.
Hmmm, I draw the opposite conclusion. The network layers are different but the service ends are the same, so I would prefer the $same_name. If you want to read Dilbert on-line and I tell you that it is available at a certain URL, would you rather I give you "http://www.dilbert.com" or that I send you "if you use IPv4 then http://www.dilbert.com" else if you use IPv6 then http://www6.dilbert.com else buy a newspaper"? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale.
Ed, On May 29, 2007, at 12:11 PM, Edward Lewis wrote:
If you want to read Dilbert on-line and I tell you that it is available at a certain URL, would you rather I give you "http:// www.dilbert.com" or that I send you "if you use IPv4 then http:// www.dilbert.com" else if you use IPv6 then http://www6.dilbert.com else buy a newspaper"?
I would prefer you to give me a mechanism by which I can reach the URL. We have tried to overlay the same transport and presentation layer onto a new network layer, but have not engineered the new network layer to facilitate this. We have new APIs and new naming attributes, requiring applications to do the heavy lifting while at the same time, not providing any reasonable mechanism to relay information back to the applications when it turns out that heavy lifting is in vain. I would agree that in the ideal world, an end user should be able to point their browser to a given URL and get back the same content irrespective of the underlying network layer protocol being used. However, in the world I live in, it doesn't work like this. 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"? Rgds, -drc
On 29-mei-2007, at 21:53, David Conrad wrote:
We have tried to overlay the same transport and presentation layer onto a new network layer, but have not engineered the new network layer to facilitate this. We have new APIs and new naming attributes, requiring applications to do the heavy lifting while at the same time, not providing any reasonable mechanism to relay information back to the applications when it turns out that heavy lifting is in vain.
Yeah, this "unreliable datagram service" can never work, let's all stick with X.25. The transition from IPv4 to IPv6 is hard enough as it is. Having different DNS names tied to each protocol pretty much guarantees it's never going to happen, because you can't expose IPv4-only users to IPv6-only names. And clients figuring out whether they have working IPv6 reachability is exactly the part that you have a problem with, so you can't use that either. The problem with applications is that many of them still manage IP addresses "manually". In that case, it's unavoidable that the application must be updated for a new version of IP. But a Java app will never know the difference because the Java language simply redefined "IP address". It's now a superclass with IPv4 and IPv6 subclasses. Ain't object orientation grand? Most higher level languages can hide the difference between IPv4 and IPv6 from most applications, leaving just the implementation of protocols that require knowledge of IP addresses, such as SIP.
I would agree that in the ideal world, an end user should be able to point their browser to a given URL and get back the same content irrespective of the underlying network layer protocol being used. However, in the world I live in, it doesn't work like this.
Repeat after me: "don't block ICMP packet too big". That's 80% of your trouble right there. I've been living the IPv6 life for some years now, and occasionally, problems crop up. This seems to be a particularly bad month, because in addition to the long standing problem with www.apnic.net where sessions start but get slower and slower until they don't move any data any more (still have to talk to the APNIC NOC about that) 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. By and large, it works well enough that I'm not tempted to turn off IPv6, but I wouldn't migrate millions of unsuspecting users just yet. If a few more content people can bring up IPv6 people like me will happily provide feedback about what doesn't work and in another year or two, things will be stable enough for a wider audience.
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.
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 AAAA records to A records. That's good, on the surface. b) If (a) happens, and the endpoint referred to by the AAAA 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 AAAA 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
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)
This is misleading. You are using IPv6 jargon (transition protocol) whose meaning is not obvious. For most ISPs, "transition" refers to the entire series of steps up to running a ubiquitous IPv6 network where IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not magic bullets because they merely deal with the first steps of such a transition. I do agree that Teredo and 6to4 are very important right now, as far as taking actions, but for planning, we need to look well beyond IPv6 transition protocols. Since we are all collectively playing catchup at this point, it would be very useful for some clear guidance on who needs to deploy Teredo and 6to4 and where it needs to be deployed. Also, the benefits of deployment versus the problems caused by not having it. Should this be in every PoP or just somewhere on your network? Are there things that can be measured to tell you whether or not lack of Teredo/6to4 is causing user problems? --Michael Dillon
On 30/05/2007, at 11:41 PM, <michael.dillon@bt.com> wrote:
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)
This is misleading. You are using IPv6 jargon (transition protocol) whose meaning is not obvious. For most ISPs, "transition" refers to the entire series of steps up to running a ubiquitous IPv6 network where IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not magic bullets because they merely deal with the first steps of such a transition.
Fair enough. Alternative suggestions? :-)
I do agree that Teredo and 6to4 are very important right now, as far as taking actions, but for planning, we need to look well beyond IPv6 transition protocols.
I don't think anyone would disagree with that.
Since we are all collectively playing catchup at this point, it would be very useful for some clear guidance on who needs to deploy Teredo and 6to4 and where it needs to be deployed. Also, the benefits of deployment versus the problems caused by not having it. Should this be in every PoP or just somewhere on your network? Are there things that can be measured to tell you whether or not lack of Teredo/6to4 is causing user problems?
A quick look through the NANOG historical slideware suggests very little mention of Teredo. Again, someone from Microsoft who can fill that gap might be useful. And probably someone who's using Miredo (an opensource/free implementation). I've been doing a lot of thinking/writing about deploying these things in the real world so I can knock up some pictures+notes, but again, better to hear from someone else who's done/doing it, rather than someone who's been playing/thinking. I assume there is someone.. -- Nathan Ward
For core networks I will suggest to use pure dual-stack or MPLS/6PE. In the worst case, if you can't do that, just use manually configured tunnels. For the upstream, dual-stack or again manually configured tunnels (6in4/protocol-41 or GRE). 6to4, in general, is useful for end users with a public IPv4 address. Teredo for those behind NAT. 6to4 and Teredo are already being used by users when their ISPs doesn't provide any IPv6 service at all. But they can also be used by ISPs as an easy and low-cost means while they can't offer dual-stack to the access, by deploying Teredo and 6to4 relays, in order to improve the availability of IPv6 in their access network w/o any major cost. As indicated a couple of days ago, I'm starting a thread about this in AfriNIC (English) and LACNIC (Spanish) in a very few days. I will drop a message here to remind about that in case people is interested to follow it (prefer to cross-post in several mail exploders). The thread will explain how to deploy those protocols and help to resolve any issues. For Teredo, we will use Miredo, the open source version. For 6to4, as it is supported in router vendors and hosts, we will explain both of them. Regarding how many boxes, I think it will be useful just staring with one in each network and monitor the traffic level. Then you will realize if it make sense to have more, such as in every PoP, or something similar. Those protocols work stand-alone, not special operational support required, and very low cost boxes can make it, at least at this stage. One more alternative, in terms of next steps planning, for access networks which can't, at the time being, deploy dual-stack (example DOCSIS 2.0, xDSL that can't be upgraded yet, etc.), is softwires (L2TP), but I'm not sure implementations are fully ready yet. I will bet that in 1-2 years, it will be the best choice and will be able to replace 6to4 and Teredo. Last, but not least, the major vendor (Microsoft) supports Teredo (as well as 6to4) in both XP and Vista. In Vista it gets enabled by default when no native IPv6 connectivity is available, but Microsoft own applications use Teredo only for peer-to-peer. If no native is present, then 6to4 is the 2nd choice for client-server apps. This is following the policy table for source/destination address selection. But other applications may use Terede as well for client-server. For example Teredo is not used by Internet Explorer if IPv4 connectivity is available, but if you use Opera, it prefers Teredo even if IPv4 is available, because is ignoring the policy table. The policy table can be manually configured. All the information about this is available at: About the policy table/XP: http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=2 About the policy table/Vista: http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=13 About 6to4: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 About Teredo: http://www.ipv6tf.org/index.php?page=using/connectivity/teredo LG at: http://www.ipv6tf.org/index.php?page=using/connectivity/looking_glass Config guides at: http://www.ipv6tf.org/index.php?page=using/connectivity/guides Hopefully all this is useful. I'm working in a tool to be able to measure all the IPv6 traffic in a network, even if it is using Teredo, 6to4, others, so we can realize, in a few months of measurements (if people different networks is volunteering fromto use this software and provide data) if IPv6 traffic (all, peer-to-peer and client-server) is growing. The tool will work EVEN if you don't support IPv6 in your network, so it will show if some transition traffic is passing thru. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <owner-nanog@merit.edu> Fecha: Wed, 30 May 2007 12:41:17 +0100 Para: <nanog@nanog.org> Conversación: why same names, was Re: NANOG 40 agenda posted Asunto: RE: why same names, was Re: NANOG 40 agenda posted
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)
This is misleading. You are using IPv6 jargon (transition protocol) whose meaning is not obvious. For most ISPs, "transition" refers to the entire series of steps up to running a ubiquitous IPv6 network where IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not magic bullets because they merely deal with the first steps of such a transition.
I do agree that Teredo and 6to4 are very important right now, as far as taking actions, but for planning, we need to look well beyond IPv6 transition protocols.
Since we are all collectively playing catchup at this point, it would be very useful for some clear guidance on who needs to deploy Teredo and 6to4 and where it needs to be deployed. Also, the benefits of deployment versus the problems caused by not having it. Should this be in every PoP or just somewhere on your network? Are there things that can be measured to tell you whether or not lack of Teredo/6to4 is causing user problems?
--Michael Dillon
********************************************** 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.
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.
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?
Both Safari and Firefox on the Mac. The delay is actually more than a minute for Firefox and about the same for Safari, though. Too long to wait for for most people, but I can't be bothered to find a workaround... 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. The IETF meetings have had IPv6 connectivity for years, but IPv6 for www.ietf.org is fairly new. Not so long ago, I couldn't connect to www.ietf.org from the meeting network over IPv6 because the /48 that the web server was hosted in was filtered by the ISP providing the meeting IPv6 transit. In that case, an unreachable was returned and there was no delay.
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.
No, not really. End-users can get IPv6 connectivity without support from their ISP, and Windows Vista will result in a big bump in IPv6- active users. The next step that we need is more IPv6 content to flush out problems like the one I'm having and make it such that those don't persist like they sometimes do now.
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 AAAA records to A records.
Note that the latter only applies to "real" IPv6 connectivity. With 6to4 or Teredo, Windows will generally prefer IPv4.
b) If (a) happens, and the endpoint referred to by the AAAA 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 AAAA records.
They aren't going to turn on AAAA records because they're not reachable over IPv6. :-)
So, it seems to me that the unreachable mentioned in (b) needs to be fixed. That's us, as network operators.
Note that these are exceptions. The only remarkable part is that they aren't fixed as quickly as the same problems are when they happen with IPv4. Iljitsch
[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*] 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. 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? 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. Thank you, I sincerely hope that this matter will finally be resolved. Greets, Jeroen
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 peering@he.net 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 GigE 206.223.119.37 2001:504:0:4::6939:1 EQUINIX-DAL UP GigE 206.223.118.37 2001:504:0:5::6939:1 EQUINIX-LAX UP GigE 206.223.123.37 2001:504:0:3::6939:1 EQUINIX-SJC UP 10GigE 206.223.116.37 2001:504:0:1::6939:1 LINX UP 10GigE 195.66.224.21 2001:7f8:4:0::1b1b:1 LINX UP GigE 195.66.226.21 2001:7f8:4:1::1b1b:2 LoNAP UP GigE 193.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 GigE 194.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 GigE 198.32.146.50 2001:504:a::a500:6939:1 PAIX New York PENDING DE-CIX PENDING NOTA PENDING 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 if that is the problem you are trying to fix. If somebody helps Bill with his IPv6 config, please remove the 3ffe prefix announcement as it is still there, we just happen to be filtering it. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
Correction, 3ffe:80a::/64 was the old PAIX Palo Alto exchange address. BTW, Jeroen does have a valid beef, ipv6@he.net used to not be handled by our normal engineering staff. It was somebody's part time side project. This has changed with the migration of our IPv6 network into our core. Since IPv6 is available via all core routers for customers on the same links as their IPv4 connection, all Hurricane network engineers are now required to be able take care of issues with it. On Wed, 30 May 2007, Mike Leber wrote:
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 peering@he.net 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 GigE 206.223.119.37 2001:504:0:4::6939:1 EQUINIX-DAL UP GigE 206.223.118.37 2001:504:0:5::6939:1 EQUINIX-LAX UP GigE 206.223.123.37 2001:504:0:3::6939:1 EQUINIX-SJC UP 10GigE 206.223.116.37 2001:504:0:1::6939:1 LINX UP 10GigE 195.66.224.21 2001:7f8:4:0::1b1b:1 LINX UP GigE 195.66.226.21 2001:7f8:4:1::1b1b:2 LoNAP UP GigE 193.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 GigE 194.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 GigE 198.32.146.50 2001:504:a::a500:6939:1 PAIX New York PENDING DE-CIX PENDING NOTA PENDING 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 if that is the problem you are trying to fix.
If somebody helps Bill with his IPv6 config, please remove the 3ffe prefix announcement as it is still there, we just happen to be filtering it.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
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
-----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. vrode@promiscious:/etc/ppp/peers$ traceroute6 www.ietf.org traceroute to www.ietf.org (2610:a0:c779:b::d1ad:35b4) from 2001:5c0:8fff:ffff::a5, 30 hops max, 16 byte packets 1 2001:5c0:8fff:ffff::a4 (2001:5c0:8fff:ffff::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-----
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.
The whois.6bone.net registry is fun of course:
inet6num: 3FFE:800::/24 netname: ISI-LAP descr: Harry Try IPv6 country: CA
one very good reason to not trust whois databases.
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.
Hi.
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?
Sure... there are only a few left. Got rid of two a couple weeks back. That said.... I will announce the prefix as long as people are using it. (whine away)
Thank you, I sincerely hope that this matter will finally be resolved.
It will, but not on your arbitrary timetable.
Greets, Jeroen
JORDI PALET MARTINEZ wrote:
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.
In the past we've used "www6" for v6 only, "www4" for v4 only, and "www" has both v6 and v4. This means people can verify their v6 connectivity by visiting www6, or they can avoid v6 if they have local problems by using www4 (since the site contains information on setting up/troubleshooting v6 it's possible they can't get to it via v6), but if they don't know/care they end up on "www" which gives them whatever their software thinks it can support.
On 30/05/2007, at 11:33 AM, Perry Lorier wrote:
JORDI PALET MARTINEZ wrote:
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.
In the past we've used "www6" for v6 only, "www4" for v4 only, and "www" has both v6 and v4. This means people can verify their v6 connectivity by visiting www6, or they can avoid v6 if they have local problems by using www4 (since the site contains information on setting up/troubleshooting v6 it's possible they can't get to it via v6), but if they don't know/care they end up on "www" which gives them whatever their software thinks it can support.
Which works fine for you and me, but not for my mother. Another suggestion I have heard is having www A-only, and www6 AAAA- only, and transparently redirecting if they have IPv6 connectivity. Of course, that requires an IPv4 bootstrap, so is rather pointless. -- Nathan Ward
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
At 9:21 AM -0400 5/29/07, Donald Stahl wrote:
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?
There are already folks who have run separate hostnames for IPv6 services, and the fact that we can still exchange email on mailing lists (lots of email ;-) ) means that it doesn't seem to be a problem. The next phase of experimentation which needs some real-world experience is using both IPv4 and IPv6 to reach existing servers, to learn all about the various "does and doesn't work" scenarios that can be setup with/out IPv6 transit/tunnelling, with IPv4 only and IPv4/IPv6 DNS servers, and the resource record preference rules in various resolver and IP stacks... So, what I'm advocating for is getting servers on both IPv4 and IPv6 asap, and figuring out how to do it safely with the same DNS names. I'm not saying that a good starting step is running IPv6 internal to your own network with separate hostnames, but we all have to move past that pretty quickly. /John
I agree with John here. I am not going to speak for content providers, but I have heard them raise serious business concerns about the lack of infrastructure deployment. They make their living on responsiveness, and an extended transition with its associated unpredictability without native routing potentially impacts business (ie: so far behind their peers in perceived quality that finances are impacted). This is a grand game of chicken. The ISPs are refusing to move first due to lack of content, and the content providers are refusing to move first due to lack of infrastructure. We are going to hit the end of the IPv4 pool and have a panic driven deployment rather than a well planned one. I just hosted a session with enterprises that are actively deploying IPv6 to start distilling best-practices, and it is clear that something similar is going to have to happen for ISPs. I am not ready to organize something just yet, but if you are interested I will hang around the beer-n-gear. Tony
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of John Curran Sent: Tuesday, May 29, 2007 7:20 AM To: Donald Stahl Cc: nanog@nanog.org Subject: Re: NANOG 40 agenda posted
At 9:21 AM -0400 5/29/07, Donald Stahl wrote:
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?
There are already folks who have run separate hostnames for IPv6 services, and the fact that we can still exchange email on mailing lists (lots of email ;-) ) means that it doesn't seem to be a problem.
The next phase of experimentation which needs some real-world experience is using both IPv4 and IPv6 to reach existing servers, to learn all about the various "does and doesn't work" scenarios that can be setup with/out IPv6 transit/tunnelling, with IPv4 only and IPv4/IPv6 DNS servers, and the resource record preference rules in various resolver and IP stacks...
So, what I'm advocating for is getting servers on both IPv4 and IPv6 asap, and figuring out how to do it safely with the same DNS names. I'm not saying that a good starting step is running IPv6 internal to your own network with separate hostnames, but we all have to move past that pretty quickly.
/John
On May 30, 2007, at 3:40 PM, 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 guess we have different definitions for "most significant backbones". Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a "significant backbone". That said, I certainly don't think content is doing well either. Nor am I trying to say which is at fault. In fact, not even sure I care who is at fault, if fault can even be apportioned. -- TTFN, patrick P.S. Don't suppose people could change the subject when, well, the subject changes?
I guess we have different definitions for "most significant backbones". Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a "significant backbone". Rather than go back and forth- can we get some real data?
Can anyone comment on the backbone IPv6 status of the major carriers? -Don
I've been trying to collect the info about services (including ISPs and transit providers) and products (software and hardware) that "say" they offer IPv6 (still in the phase of verifying one by one, but almost done !). Is still not complete, but I think provides a good picture. http://www.ipv6-to-standard.org/ Just a few examples: You can type ISP in the free search box, or TLD, or load balancer. Regards, Jordi
De: Donald Stahl <don@calis.blacksun.org> Responder a: <owner-nanog@merit.edu> Fecha: Wed, 30 May 2007 16:07:19 -0400 (EDT) Para: "Patrick W. Gilmore" <patrick@ianai.net> CC: <nanog@nanog.org> Asunto: Re: dual-stack [was: NANOG 40 agenda posted]
I guess we have different definitions for "most significant backbones". Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a "significant backbone". Rather than go back and forth- can we get some real data?
Can anyone comment on the backbone IPv6 status of the major carriers?
-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.
I've stayed out of this since I'm not following list closely right now but if there's been progress made in last 14 months on more providers in the US having IPv6-capable deployment it would be great to hear. When I was doing the v6 work for Connexions and looking at who to set up the v4/v6 eBGP sessions with only ONE provider had anything realistic. And we were announcing the /48 for about 6 months.....until the demise of a great system (Connexion) due to business reasons. Bummer. [and yeah - we were guinea pigs for what a provider would do with our own personal /48........] I talked to a few other carriers but they had nothing 'right now' in Seattle......and of course that was a year ago. Glad to hear if it was today then I wouldn't have so much of an issue finding someone? An update would definitely be interesting.... - merike On May 30, 2007, at 1:07 PM, Donald Stahl wrote:
I guess we have different definitions for "most significant backbones". Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a "significant backbone". Rather than go back and forth- can we get some real data?
Can anyone comment on the backbone IPv6 status of the major carriers?
-Don
Donald Stahl writes:
I guess we have different definitions for "most significant backbones". Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a "significant backbone". Rather than go back and forth- can we get some real data?
Yes please, I like data!
Can anyone comment on the backbone IPv6 status of the major carriers?
Our three Tier-1(?) upstreams AS1299, AS3356, and AS3549 all provide IPv6. Only one of them has dual-stack on our access link, for the other two we have to tunnel into their IPv6 "backbone" through their IPv4 backbone. I don't know exactly how their internal IPv6 networks are built, although with one of them I'm sure they use/used "6PE", i.e. IPv6 "tunneled" over an IPv6-agnostic MPLS core (learned this from trouble tickets, sigh). But all three offer decent IPv6 connectivity - e.g. we rarely observe gratuitous routing over an ocean and back, or order-of-magnitude RTT or loss-rate differences between IPv4 and IPv6. Our own backbone has been dual-stack for a couple years now, but I guess this just shows that we can't be a "major carrier" - same for many other national "academic" backbones as well as GEANT, the backbone that interconnects those. Same in the US with Internet2 and the regional research/education networks. -- Simon. (AS559)
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
It matters not if a handful of transit providers are dual-stack, access networks still prevent native IPv6 from reaching the customer. Also from what I have seen there is very little native dual-stack or 6PE in North America, even from those that claim to offer IPv6 service. Everyone is 'waiting for customer demand' before investing seriously. Consumers will not demand IPv6 by name until the IPv4 pool has run dry and their cost for connectivity goes up and press starts regularly talking about alternatives. Content providers have no incentive to demand until they can get clear native pathways to the consumer. Access providers have a pile of CPE to deal with, and the $.05 that it costs to put in dual-stack makes them non-competitive (that is the whine I hear). Transit providers can turn on dual-stack, but don't widely because they fear the impact that a few thousand more routing slots will have, and want to wait till the last possible minute to get the best potential RIB/FIB scaling. I never said the sky was falling. I am just observing the stand-off that is going on. The only way to move forward is for some collection of entities to break from their respective herd and deliver end-to-end native IPv6 service. Kevin Day's effort will provide some real info to squelch the FUD that keeps going around, but that is only a starting point. The transition tool set is out there to break any dependencies on rollout sequence, but if they are deployed in a haphazard fashion the resulting unpredictability will raise opex. What we clearly need are deployment guidelines and documentation of the pitfalls of the 'don't go there' approaches to dispel fear about the business impact of going first and getting it wrong. Tony
-----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, May 30, 2007 12:40 PM To: Tony Hain Cc: 'John Curran'; 'Donald Stahl'; nanog@nanog.org Subject: Re: NANOG 40 agenda posted
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.
randy
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.
On Tue, 29 May 2007, Mark Tinka wrote:
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.
branding
On Tue, 29 May 2007 09:21:49 EDT, Donald Stahl said:
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?
How do you get mail.ipv6.yahoo.com to actually get *used*, when your average user doesn't know where they set 'mail.yahoo.com' in their PC's configuration, and either don't understand why sometimes's it's foo.com and sometimes it's www.foo.com, or don't even bother, they just type 'foo' into the address bar and let the browser add www. and .com, or they go to google and enter 'foo' and hit "I feel lucky"? You're basically stuck that you have to provide one name with both ann A and an AAAA record, or your support desk staff will mutiny.
How do you get mail.ipv6.yahoo.com to actually get *used*, when your average user doesn't know where they set 'mail.yahoo.com' in their PC's configuration, and either don't understand why sometimes's it's foo.com and sometimes it's www.foo.com, or don't even bother, they just type 'foo' into the address bar and let the browser add www. and .com, or they go to google and enter 'foo' and hit "I feel lucky"? I don't want these sorts of people testing my systems with IPv6- I want a technically savvy user who can offer me helpful feedback- at least initially. Eventually- once I am sure the network is stable- the service is stable, etc.- then you can add A and AAAA records for the primary service.
-Don
On 30/05/2007, at 5:40 AM, Donald Stahl wrote:
How do you get mail.ipv6.yahoo.com to actually get *used*, when your average user doesn't know where they set 'mail.yahoo.com' in their PC's configuration, and either don't understand why sometimes's it's foo.com and sometimes it's www.foo.com, or don't even bother, they just type 'foo' into the address bar and let the browser add www. and .com, or they go to google and enter 'foo' and hit "I feel lucky"? I don't want these sorts of people testing my systems with IPv6- I want a technically savvy user who can offer me helpful feedback- at least initially. Eventually- once I am sure the network is stable- the service is stable, etc.- then you can add A and AAAA records for the primary service.
I've got an idea that just fell out of my brain for web content providers to get a handle on their 'ipv6-ability' - how many eyeballs they would lose by adding www AAAA records. Use Javascript, or flash, or some other fancy thing to do a GET for two files on two different servers as the page loads: a) http://ip6test.<domain>/file b) http://ip4test.<domain>/file And then compare the hit-rate for the two. Perhaps also analyse things like X-Forwarded-For headers to see if HTTP proxies are being used, and so on. Maybe an IPv4 POST happens with some kind of load time results, etc. One could use a system like this to pop up a message to those who would become unreachable, and say "Follow these steps so that you can reach us next week when we turn on www AAAA records". Or perhaps, "Contact your ISP helpdesk for assistance". My initial thought was "That means an additional GET per page, that means lots of server+network load!", but Yahoo! (for example) appears to do 35 requests for me to get their homepage, and the responses are all larger than 0b. I'll have a hunt around and see if I can get Javascript/ XMLHTTPRequest to give me return codes as to why an HTTP GET failed (ie. unreachable, "host not found", etc.). If not, maybe Flash can do it. Of course, has this sort of thing been done before? -- Nathan Ward
On Wed, May 30, 2007 at 10:55:04AM +1200, Nathan Ward <nanog@daork.net> wrote a message of 56 lines which said:
Use Javascript, or flash, or some other fancy thing to do a GET for two files on two different servers as the page loads: a) http://ip6test.<domain>/file b) http://ip4test.<domain>/file
And then compare the hit-rate for the two.
Very good idea. But you should also log the TCP RTT for the two connections because a common failure is the fact that IPv4 goes straight to the server while IPv6 goes through a tunnel in Thailand or Brazil.
On 30/05/2007, at 9:46 PM, Stephane Bortzmeyer wrote:
On Wed, May 30, 2007 at 10:55:04AM +1200, Nathan Ward <nanog@daork.net> wrote a message of 56 lines which said:
Use Javascript, or flash, or some other fancy thing to do a GET for two files on two different servers as the page loads: a) http://ip6test.<domain>/file b) http://ip4test.<domain>/file
And then compare the hit-rate for the two.
Very good idea.
But you should also log the TCP RTT for the two connections because a common failure is the fact that IPv4 goes straight to the server while IPv6 goes through a tunnel in Thailand or Brazil.
Yep, I plan to do that. Also the reason that a connection failed (timeout or reject/ unreachable). I suppose that a purpose built server could track things like half opened connections (ie. SYNACK probably dropped), open connections over which a large-ish request doesn't come (ie. MTU problems), and so on. The implementation problem I find now is that XMLHTTPRequest apparently doesn't let you talk to other domains for security reasons. I'm going to investigate using nasty iframe hacks, and Flash. Maybe Java, but that sounds a bit heavy. If anyone has experience with this sort of stuff and can lend some expertise, I'd be grateful. Probably offlist would be best for now. -- Nathan Ward
On 30/05/2007, at 10:55 AM, Nathan Ward wrote:
I've got an idea that just fell out of my brain for web content providers to get a handle on their 'ipv6-ability' - how many eyeballs they would lose by adding www AAAA records. <stuff>
I've implemented this, with some frills. Code is at http://www.braintrust.co.nz/ipv6wwwtest/ and is probably rough around the edges. I'm not really a JavaScript hacker so it probably isn't terribly amazing quality, but it seems to work OK for me - I've been running it on several of my websites with a large range of user clue+access+OS+browser+ISP as visitors and I've had no complaints. The code is running on the page above, too. The default timeout in the tarball is too high, 10000-20000 is probably adequate. Please let me know if you use it, or if you do something similar or use it for inspiration or whatever. In addition, I'm sure we'd all love to see any statistics you can share. Enjoy! -- Nathan Ward
On Tue, 29 May 2007, John Curran wrote:
At 3:30 PM +0000 5/27/07, Chris L. Morrow wrote:
what's going to change this in the near future?
At some point in the near future (e.g. 3 to 5 years), an ISP is going to be connecting some customers to the 'Internet' using just IPv6 addresses. It may not be your ISP doing it first, but it will very quickly go from just one ISP connecting IPv6-only customers to lots of ISP's doing IPv6-only customers.
This presumes that there is content or 'reason' (which I short circuited to 'content' for this discussion) available on the 'v6-internet', or atleast accessible to a v6-only client. Other wise having a connection to a network with nothing and nobody of consequence to that customer isn't going to fly.
This changeover will not: 1) Fix the routing problem inherent with present locator/endpoint binding, nor 2) solve your favorite fib/rib/cam/convergence limit, nor 3) make the infrastructure inherently either easier to operate or more secure.
but ipv6 is more secure, yes? :) (no it is not)
One can argue with the date when this occurs, based on your particular address reclamation, reuse, and market expectations, but it's still going to happen since there's no other game in town. (*)
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.
agree.
We've have to move efficiently towards readiness for the IPv6-only customer that will be told this is his only choice for Internet connectivity. While some customers may shop around or buy their way of that honor, that only works for a very short time until the answer is the same throughout the network.
i agree, though we are back to the chicken/egg scenario with users/content yes? without users of significance google isn't going to expend capex/opex to add ipv6 (i do use google in the example purely as an example, vint might have them busily working on interplanetary IP and ipv6 for all anyone knows) The same goes for every other content place. I'd venture to guess that even enterprises aren't rushing to ipv6 for very similar reasons, there are no things their users need/require on an ipv6 only stub, they have other more pressing concerns (virus updates for instance).
Actual behavior of ISPs will change as they realize even if they're not the first ISP to have to connect customers via IPv6-only, they will be face that situation in time.
i'm not disagreeing or saying that ipv6 won't ever get deployed (or even in time for ipv4 exhaustion) but... chicken/egg, sometime soon folks are going to have to take it out of hide to start down the v6 path, some one is going to have to convince their upper management that they really do need to put this 'new service' that 'no one is asking for' and is 'still somewhat experimental' (from a hardware/software/OSS perspective atleast) onto their production infrastructure that is supporting YMillions of $$.
At 2:34 PM +0000 5/29/07, Chris L. Morrow wrote:
Actual behavior of ISPs will change as they realize even if they're not the first ISP to have to connect customers via IPv6-only, they will be face that situation in time.
i'm not disagreeing or saying that ipv6 won't ever get deployed (or even in time for ipv4 exhaustion) but... chicken/egg, sometime soon folks are going to have to take it out of hide to start down the v6 path, some one is going to have to convince their upper management that they really do need to put this 'new service' that 'no one is asking for' and is 'still somewhat experimental' (from a hardware/software/OSS perspective atleast) onto their production infrastructure that is supporting YMillions of $$.
Chris - This is not a problem for the user community... The user community couldn't care less about IPv6. This is an issue for the ISP community, in that a day will come where you're going to desperately want to connect a new customer to the "Internet" via IPv6 and give them a reasonable customer experience. They're likely to to balk, and may not even have a full set of applications that work over IPv6, but that's still not going to matter. ISP's are going to have to actually *lead* the transition to IPv6 both in terms of infrastructure and setting customer expectations. /John 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.
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...
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. IPv6 should simply be a requirement of all new equipment purchases (in large ISP's this should have been the case for a while now). The bean counters don't see a cost for new equipmnent just to run IPv6- they see
the normal costs to upgrade older equipment. At least that's the way I'm doing my upgrades. -Don
On Tue, 29 May 2007, Donald Stahl wrote:
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. IPv6 should simply be a requirement of all new equipment purchases (in large ISP's this should have been the case for a while now). The bean counters don't see a cost for new equipmnent just to run IPv6- they see the normal costs to upgrade older equipment. At least that's the way I'm doing my upgrades.
grr, it ain't just buying new equipment, it's IT work, its certification of code/features/bugs, interoperatability. Provisioning, planning, configmanagement.... training... All of these things require opex/capex spend. You could buy a 'router' that did ipv6 10 years ago, that doesn't mean that anyone planned on ever deploying it.
grr, it ain't just buying new equipment, it's IT work, its certification of code/features/bugs, interoperatability. Provisioning, planning, configmanagement.... training... My apologies- I missed the "opex"-I thought you were just referring to hardware which of course makes no sense.
-Don
On Tue, 29 May 2007, Donald Stahl wrote:
grr, it ain't just buying new equipment, it's IT work, its certification of code/features/bugs, interoperatability. Provisioning, planning, configmanagement.... training... My apologies- I missed the "opex"-I thought you were just referring to hardware which of course makes no sense.
honest, despite what my wife claims I do try to make sense most of the time.
On Tue, 29 May 2007 14:34:59 -0000, "Chris L. Morrow" said:
On Tue, 29 May 2007, John Curran wrote:
This changeover will not: 1) Fix the routing problem inherent with present locator/endpoint binding, nor 2) solve your favorite fib/rib/cam/convergence limit, nor 3) make the infrastructure inherently either easier to operate or more secure.
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? Just askin', ya know?
On Tue, 29 May 2007 Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 May 2007 14:34:59 -0000, "Chris L. Morrow" said:
On Tue, 29 May 2007, John Curran wrote:
This changeover will not: 1) Fix the routing problem inherent with present locator/endpoint binding, nor 2) solve your favorite fib/rib/cam/convergence limit, nor 3) make the infrastructure inherently either easier to operate or more secure.
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.
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
On Tue, May 29, 2007, Donald Stahl wrote:
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.
You don't need to blindly spew worm traffic anymore; you can just spew based on p2p traffic. Adrian
(*) Anyone advocating staying with IPv4 and relying on NAT and market demand as an alternative needs to consider the completely deaggregated address usage pattern (and routing table explosion) that results.
not that i think this a nice approach or anything, but ... it would seem that the size of the routing table in this case, as in others, is proportional to the number of end sites, pi multi-homed if that is the dominant policy, or pa aggregated if that is the dominant policy. randy
At 5:08 AM -1000 5/29/07, Randy Bush wrote:
(*) Anyone advocating staying with IPv4 and relying on NAT and market demand as an alternative needs to consider the completely deaggregated address usage pattern (and routing table explosion) that results.
not that i think this a nice approach or anything, but ...
it would seem that the size of the routing table in this case, as in others, is proportional to the number of end sites, pi multi-homed if that is the dominant policy, or pa aggregated if that is the dominant policy.
I respectfully disagree... you'll see addresses being moved out of both PA and PI space (particularly PI & legacy) to directly end-sites and create enormous pressure on the ISPs to allow end-sites with "self-obtained" /32's to have them injected into the DFZ... (This is effectively when the utility value of unique IPv4 addresses reaches all time high) Our present routing table issues are nominal compared to the full brunt of end site non-hierarchical address usage that results. /John
At 5:08 AM -1000 5/29/07, Randy Bush wrote:
(*) Anyone advocating staying with IPv4 and relying on NAT and market demand as an alternative needs to consider the completely deaggregated address usage pattern (and routing table explosion) that results.
not that i think this a nice approach or anything, but ...
it would seem that the size of the routing table in this case, as in others, is proportional to the number of end sites, pi multi-homed if that is the dominant policy, or pa aggregated if that is the dominant policy.
I respectfully disagree... you'll see addresses being moved out of both PA and PI space (particularly PI & legacy) to directly end-sites and create enormous pressure on the ISPs to allow end-sites with "self-obtained" /32's to have them injected into the DFZ... (This is effectively when the utility value of unique IPv4 addresses reaches all time high)
Our present routing table issues are nominal compared to the full brunt of end site non-hierarchical address usage that results.
Yes, as NAT becomes ubiquitous, a larger number of private networks will be behind ever smaller prefixes that are assigned to sites so the per-site prefix length will decrease. The logical end state for this would be /32s. In some cases, multi-homed end-sites may wish to have those /32s advertised into the global routing system. If, on the other hand, those end sites were to transition to ipv6, they would instead obtain "PI" /48s and advertise those into the global routing system. How is the former any worse than the latter? If you think about it, the NAT approach actually offers the possibility of improved routing scalability: site multihomed with NATs connected to each of its providers could use topologically-significant (read "PA") global addresses on the NATs while using the same private address space on their network. This reduces any renumbering problem to just that for a NAT that moves (or is replaced) during a provider change. Yes, this sort of poor man's identifier/locator separation has all sorts of ugliness but it can probably be made to work. It may even be the path of least resistance versus fixing ipv6's routing scalability and deploying ipv6. It will certainly be interesting to see how this all plays out over the next few years. --Vince
At 5:20 PM -0700 6/1/07, Vince Fuller wrote:
Yes, as NAT becomes ubiquitous, a larger number of private networks will be behind ever smaller prefixes that are assigned to sites so the per-site prefix length will decrease. The logical end state for this would be /32s. In some cases, multi-homed end-sites may wish to have those /32s advertised into the global routing system. If, on the other hand, those end sites were to transition to ipv6, they would instead obtain "PI" /48s and advertise those into the global routing system. How is the former any worse than the latter?
For multi-homed sites, none. For the vast majority of singly-homed end locations, the PA-based sites are all going to aggregate nicely whereas all those /32's are going to come from wherever someone can find a single unique address. No ISP is going to stop serving clients for inability to get new blocks, and that means that in the IPv4 scenario you've got single /32's of indeterminate origin being routed by every ISP as things move towards conclusion... /John
For multi-homed sites, none. For the vast majority of singly-homed end locations, the PA-based sites are all going to aggregate nicely whereas all those /32's are going to come from wherever someone can find a single unique address.
most likely their provider. slicing the bits finer because of their scarcity, and putting nats behind, them does not mean that the provider will not give them to you. randy
Thus spake "Vince Fuller" <vaf@cisco.com>
Yes, as NAT becomes ubiquitous, a larger number of private networks will be behind ever smaller prefixes that are assigned to sites so the per-site prefix length will decrease.
I think you mean increase. Even without NAT, this is going to happen because big blocks will no longer be available, even if someone qualifies for one, and multiple smaller blocks will need to be assigned. Route count will grow increasingly faster as we approach and pass exhaustion as RIRs (or the black markets) have to chop up big blocks into smaller and smaller chunks to meet our needs.
The logical end state for this would be /32s. In some cases, multi-homed end-sites may wish to have those /32s advertised into the global routing system. If, on the other hand, those end sites were to transition to ipv6, they would instead obtain "PI" /48s and advertise those into the global routing system. How is the former any worse than the latter?
For one thing, the former further weakens the end-to-end principle and entrenches the idea of "servers" on public addresses and "clients" behind NATs, with those clients becoming second-class citizens. Today, this practice is voluntary for most users and under their control, so users are to blame for their own segregation, but tomorrow it will be forced on them by their ISPs*, which is a BadThing(tm). Also, a site will need dozens, perhaps reaching hundreds, of v4 prefixes to address all of their hosts if they do use public addresses, e.g. for content hosters; Already, the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one. (* If those ISPs also wisely deploy native v6 at the time they deploy NATs for v4, customers would be motivated, or would at least have the option, of getting out of the NAT jail by upgrading to v6. That might end up being the final straw that makes the masses move -- or it might have no effect except on geeks who'd find a way to use v6 even if their ISP didn't offer it natively.) (** Except perhaps for a handful of gargantuan ISPs that manage to assign more than a /32s worth of addresses, most likely residential DSL/cable providers who're going to burn through millions of /56s and /64s per month when they roll out v6. Even so, those ISPs are still going to be rare enough they shouldn't affect the average number of prefixes per AS noticeably.)
If you think about it, the NAT approach actually offers the possibility of improved routing scalability: site multihomed with NATs connected to each of its providers could use topologically- significant (read "PA") global addresses on the NATs while using the same private address space on their network. This reduces any renumbering problem to just that for a NAT that moves (or is replaced) during a provider change.
This is also what some of the IETF's ideas on v6 multihoming amount to -- though at least they leave ports and the low N bits of the address alone and thus don't break two-way connectivity, just protocols/apps that embed raw addresses in their payload, which is a marked improvement over v4 NAT if not quite perfect. One might question that approach, and it's one of the uses feared for ULAs: since you're translating the top bits anyways, you might as well use private addresses on the back side. Some who opposed SLAs and ULAs did so because they realize such enable and perhaps even encourage IPv6 NAT "solutions" like RFC1918 enables/encourages IPv4 NAT.
Yes, this sort of poor man's identifier/locator separation has all sorts of ugliness but it can probably be made to work. It may even be the path of least resistance versus fixing ipv6's routing scalability and deploying ipv6.
Unless we fix IPv6's routing and get a real EID/RID split, that's what IPv6 is going to _be_ for folks too small to get PI or who live in regions that don't have PI. That's not what the IETF promised us, and it makes many folks wonder why they should pay the costs of upgrading if the situation with v6 won't be much better than it is with v4+NAT. ARIN partially solved this, i.e. for the larger sites that will probably constitute a critical mass of clients and servers, but it doesn't solve the problem for the growing underclass of folks who are and always will be stuck on PA and have to suffer all the bad side effects of that. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one.
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6? randy
On Fri, 1 Jun 2007, Randy Bush wrote:
the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one.
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6?
wee, lookie! redistribute connected it still works! :)
On Fri, 1 Jun 2007, Randy Bush wrote:
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6? wee, lookie! redistribute connected
whee! lookie! minds disconnected, at least from public good.
Yes :( sadly I suspect that is not the only mistake/misconfig/malconfig happening in the world :(
On Saturday 02 June 2007 01:09, Chris L. Morrow wrote:
On Fri, 1 Jun 2007, Randy Bush wrote:
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6?
wee, lookie! redistribute connected
whee! lookie! minds disconnected, at least from public good.
Yes :( sadly I suspect that is not the only mistake/misconfig/malconfig happening in the world :(
Doesn't everything that require a configuration have someone who eventually screws it up? :P It's a case of Murphy's law - If something can go wrong, it will - You just have to deal with the result and recover gracefully.
Kradorex Xeron wrote:
On Saturday 02 June 2007 01:09, Chris L. Morrow wrote:
On Fri, 1 Jun 2007, Randy Bush wrote:
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6? wee, lookie! redistribute connected whee! lookie! minds disconnected, at least from public good. Yes :( sadly I suspect that is not the only mistake/misconfig/malconfig happening in the world :( Doesn't everything that require a configuration have someone who eventually screws it up? :P
yes. and with ula-c, it's exactly the same as pi. except there is one advantage, ula-c relies on the router vendor to fill in the prefix. you still have to choose the interface to which to apply it (think two external upstreams and five site links). randy
Thus spake "Randy Bush" <randy@psg.com>
the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one.
how much of the v4 prefix count is de-aggregation for te or by TWits?
A quick look at this week's CIDR Report says 35.9%, or 78,738 routes. [Update to earlier stats: The current v4 prefix/AS ratio is 8.7. However, there are ~11k ASes only announcing a single v4 route, so that means the other ~14k ASes are at a v4 ratio of 14.3. In contrast, the current v6 ratio is 1.1 and the deaggregate rate is 1.2%.]
why won't they do this in v6?
The simplistic answer is that nearly all assigned/allocated blocks will be minimum-sized, which means ISPs will be capable of filtering deaggregates if they wish. Some folks have proposed allowing a few extra bits for routes with short AS_PATHs to allow TE to extend a few ASes away without impacting the entire community. While many have derided the "classful" nature of IPv6 policies, the above was one of the reasons that it's being done. The other, obviously, is that IPv6 is big enough we can do it that way and skip all the administrative hassle of worrying about how much space people "need" and focus on whether they "need" a routing slot (as much as the RIRs pretend they don't care about routability). I said "simplistic" above because there will be a few extremely large orgs that will end up getting larger-than-minimum blocks, and they could deaggregate if they want to -- or deaggregate more bits than other folks get to. There's not much that can be done about that (without vendors inventing cool new knobs), and I already addressed why it shouldn't be that big a deal anyways in the ** footnote you snipped. However, this relies on RIRs rejecting "but we need to deaggregate" as justification for larger-than-minimum blocks. OTOH, the community may see how small the v6 table is and decide that N bits of deaggregation wouldn't hurt. After all, with ~25k ASes today, and router vendors claiming to be able to handle 1M+ routes, it seems we could tolerate up to 5 bits of deaggregation -- and 3 bits would leave us with a table smaller than v4 has today. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
[Update to earlier stats: The current v4 prefix/AS ratio is 8.7. However, there are ~11k ASes only announcing a single v4 route, so that means the other ~14k ASes are at a v4 ratio of 14.3. In contrast, the current v6 ratio is 1.1 and the deaggregate rate is 1.2%.] This is more than a little frightening :(
The simplistic answer is that nearly all assigned/allocated blocks will be minimum-sized, which means ISPs will be capable of filtering deaggregates if they wish. Some folks have proposed allowing a few extra bits for routes with short AS_PATHs to allow TE to extend a few ASes away without impacting the entire community. This is an excellent solution- is there some reason people wouldn't want to implement it? It would seem to lead directly to a more heirarchical table.
justification for larger-than-minimum blocks. OTOH, the community may see how small the v6 table is and decide that N bits of deaggregation wouldn't hurt. After all, with ~25k ASes today, and router vendors claiming to be able to handle 1M+ routes, it seems we could tolerate up to 5 bits of deaggregation -- and 3 bits would leave us with a table smaller than v4 has today. Combine this with the above system. Allow 2 bits of deagg anywhere but up to 4 bits for a short as_path for networks in the /48 range. Allow 3 bits for networks in the /32 range and up to 5 bits for a short as_path. (or whatever other numbers make sense).
Either way we seem to be looking at a much smaller table as long as we decide on some sensible rules and actually stick to them. That is going to be the biggest problem though. -Don
On 2-jun-2007, at 23:07, Donald Stahl wrote:
The simplistic answer is that nearly all assigned/allocated blocks will be minimum-sized, which means ISPs will be capable of filtering deaggregates if they wish. Some folks have proposed allowing a few extra bits for routes with short AS_PATHs to allow TE to extend a few ASes away without impacting the entire community.
This is an excellent solution- is there some reason people wouldn't want to implement it? It would seem to lead directly to a more heirarchical table.
I proposed something in a similar vein in a draft for the IETF v6ops working group: in order to allow people to multihome using PA space (which some people want to avoid having to deal directly with a RIR or for other reasons best known to themselves) there would be well- known community that indicates that a prefix is present in the routing table by design and not because of random deaggregation, and that it's part of an aggregate so it's ok to filter it out when it reaches a certain AS path length. See http://www.muada.com/drafts/draft-van-beijnum-v6ops-pa-mhome- community-01.txt and http://www.bgpexpert.com/presentations/multihoming_paspace.pdf Then I created the filter that has to do this work and I started having doubts about the practical deployability of something like this... The config below doesn't even look at AS path lengths: ! ipv6 prefix-list except-apnic seq 5 permit 2001:7fa::/32 le 64 ipv6 prefix-list except-arin seq 5 permit 2001:500::/29 le 48 ipv6 prefix-list except-lacnic seq 5 permit 2001:1200::/23 le 48 ipv6 prefix-list except-ripe seq 5 permit 2001:600::/23 le 64 ipv6 prefix-list global-pa seq 5 permit 2000::/3 le 32 ipv6 prefix-list global-pa-mhome seq 5 permit 2000::/3 le 56 ! ip community-list standard mhome-cty permit 1:1 ! route-map import permit 10 match ipv6 address except-apnic ! route-map import permit 20 match ipv6 address except-lacnic ! route-map import permit 30 match ipv6 address except-ripe ! route-map import permit 40 match ipv6 address except-arin ! route-map import permit 60 match community mhome-cty match ip address global-pa-mhome ! route-map import permit 70 match ip address global-pa !
Randy Bush wrote:
the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one.
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6?
you mean like: AS4755 AS4134 AS18566 AS4323 AS9498 AS6478 AS11492 AS22773 AS8151 AS19262 AS6197 I'm sure they'll claim they have valid business reasons.
randy
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6?
you mean like:
AS4755 AS4134 AS18566 AS4323 AS9498 AS6478 AS11492 AS22773 AS8151 AS19262 AS6197
I'm sure they'll claim they have valid business reasons.
i wish that the community had the means to do revenue sharing with such folks. carrying someone else's TE routes is a global cost for a point benefit. -- Paul Vixie
Paul Vixie wrote:
i wish that the community had the means to do revenue sharing with such folks. carrying someone else's TE routes is a global cost for a point benefit.
There are lessons to be learned from the CO2 emissions trade industry. I don't think it's really any different since the economics work exactly the same. Pete
must be the weekend, i'm posting to nanog@.
i wish that the community had the means to do revenue sharing with such folks. carrying someone else's TE routes is a global cost for a point benefit.
There are lessons to be learned from the CO2 emissions trade industry. I don't think it's really any different since the economics work exactly the same.
since a network operator has the means to refuse TE routes (for example, ISC still filters on the old smd/asp boundaries) and only hear the covering routes (if any), it's not quite the same as CO2. very similar though, since filtering the routes doesn't make us immune to the collateral damage of other people trying to install these routes, being unable to, having to buy bigger routers, going out of business, becoming uncompetitive, and so on. in CO2 land, the economics lead to a "pollution credits" model, which would have to be agreed by treaty and then enforced (neither of which is likely to happen), and i'm hoping for a better outcome wrt TE routes in the DFZ. -- Paul Vixie
On 2/06/2007, at 4:42 PM, Randy Bush wrote:
the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one.
how much of the v4 prefix count is de-aggregation for te or by TWits? why won't they do this in v6?
See slide 24 of: http://www.2007.apricot.net/presentation/apia-future-routing/apia- future-routing-vince-fuller.pdf nearby slides are interesting, too. -- Nathan Ward
On Friday 01 June 2007, Vince Fuller wrote:
If you think about it, the NAT approach actually offers the possibility of improved routing scalability: site multihomed with NATs connected to each of its providers could use topologically-significant (read "PA") global addresses on the NATs while using the same private address space on their network.
Cisco has a whitepaper entitled "Enabling Enterprise Multihoming with Cisco IOS NAT" that addresses this. See http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00... as well as RFC2260. There are indeed a few thorny issues with this approach; the largest issue is that all connectivity becomes DNS-dependent and raw IP addresses (from both the inside and outside) become virtually useless. Running servers behind this scheme, while doable, is difficult. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Cisco has a whitepaper entitled "Enabling Enterprise Multihoming with Cisco IOS NAT" that addresses this. See http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00... as well as RFC2260.
see also <http://sa.vix.com/~vixie/proxynet.pdf>.
There are indeed a few thorny issues with this approach; the largest issue is that all connectivity becomes DNS-dependent and raw IP addresses (from both the inside and outside) become virtually useless. Running servers behind this scheme, while doable, is difficult.
and also much fun to watch, once you get it working. -- Paul Vixie
There are indeed a few thorny issues with this approach; the largest issue is that all connectivity becomes DNS-dependent and raw IP addresses (from both the inside and outside) become virtually useless. Running servers behind this scheme, while doable, is difficult. When an ISP's caching name servers ignore your 3600 TTL and substitute an 86400 TTL you end up disconnected for ~12 hours instead of ~30 minutes- That's unacceptable for a almost any company willing to go through the
trouble of getting an ASN. -Don
Donald Stahl writes:
When an ISP's caching name servers ignore your 3600 TTL and substitute an 86400 TTL you end up disconnected for ~12 hours instead of ~30 minutes-
You write "when" rather than "if" - is ignoring reasonable TTLs current practice? (Ignoring routing updates for small routes used to be common practice, at least if they happen frequently enough.)
That's unacceptable for a almost any company willing to go through the trouble of getting an ASN.
Ignoring reasonable TTLs is rude and should be unacceptable for the hypothetical ISP's customers, so I assume this problem will get fixed by normal commercial pressure. Red herring? -- Simon.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 3, 2007, at 4:19 PM, Simon Leinen wrote:
You write "when" rather than "if" - is ignoring reasonable TTLs current practice?
Definitely. We've seen 15 minute TTLs regularly go 48 hours without updating on Cox or Comcast's name servers. I believe the most I've seen was 8 days (Cox). Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGYzdMElUlCLUT2d0RArCzAJ4rqL4eWxMzswEwibiZfYIk43bvpwCaA8Ix UkBbPlRGOiuL+6RSPZoNR7c= =TmiM -----END PGP SIGNATURE-----
You write "when" rather than "if" - is ignoring reasonable TTLs current practice? Definitely. We've seen 15 minute TTLs regularly go 48 hours without updating on Cox or Comcast's name servers. I believe the most I've seen was 8 days (Cox).
i wish all my competitors did that. randy
You write "when" rather than "if" - is ignoring reasonable TTLs current practice?
Definitely. We've seen 15 minute TTLs regularly go 48 hours without updating on Cox or Comcast's name servers. I believe the most I've seen was 8 days (Cox). I definitely meant "when" not if. And Cox is by no means the only ISP to do this.
-Don
Nathan Ward wrote: [..]
Isn't the driver going to be scarcity and/or expense of v4 addresses? =20 Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it.
Why not? If folks are still using Windows 98 by then I surely hope they can't have any connectivity to the Internet. The word "SpamDrone" comes to mind for those old versions.
That's just ridiculous. As far as vulnerabilities go, Win98 is a lot *less* risky than WinXP, when used properly (i.e. you don't use IE and OE, have it behind a reasonable firewall, etc). The main problem with 98 is that it is no longer supported, as of a few months ago. There are a lot of threats targetted at Windows, and a lot of threats targetted at Windows XP. There are exceedingly few targetted at Windows 98. So XP ends up being vulnerable to the general Windows threats and the Windows XP threats (two major classes), while 98 ends up being vulnerable to the general Windows threats (one major class, and largely IE/OE stuff, which you can minimize the risk of). The term "major risk of SpamDrone" comes to mind for pretty much any XP install where a user has used Internet Explorer for doing anything more than going to Mozilla or Opera's website to download a real browser and keep it up to date. Bonus points for the 1% of all users who have then used their system as a nonprivileged user (I forget the actual percentage, but it is something depressing like that). I may hate Microsoft too, but come on, you could at least be realistic about the risks. Win98 is certainly on its way out, as is 95, and that may be accelerated by an IPv6 transition.
As Windows XP is already out for the last couple of years and has fully working IPv6 support, Vista is there also with fully working IPv6 support, the OS should definitely not be a problem anymore. For folks without money, all the Open Sourcish OS's also do IPv6 perfectly fine, some even already from the installer.
The vast majority of people are going to continue to use their PC's the way that they've always used them. They got their PC with whatever was loaded on it. If it was 98, then it's probably something in the range of a Pentium 233-500 with 64 or 128MB of memory, and it works fine for their needs. The local computer shop will tell Grandma that it isn't fast enough to run XP or Vista (probably true) and Grandma isn't going to have any clue how to install Ubuntu on it and save years of pictures from the grandkids, and Grandma probably isn't going to see any value (correctly!) in spending money to buy a new PC. If anyone thinks that they are going to successfully disenfranchise Grandma of her Internet access, well, heh, it won't happen. If you try, your competitors will thank you for the new business. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
NAT-PT is not the only solution for this. In addition to that, even if deprecated, load balancers (there are quite a few), still support it. In general, this is only needed if you can't update your Apache, IIS or whatever web server to dual-stack, which normally should not be a problem at all ! A simple solution are the IPv4-IPv6 proxies, several choices, just pick your preferred one. If the "free" CPEs provided to the customers today aren't IPv6 enabled, that's is *only* a lack of adequate planning from the ISPs providing those boxes. There are a few low cost boxes in the market, which offer IPv6 (dual-stack). Yes, less than with IPv4, but the only reason for that is because we don't ask for that support to our favorite vendors when placing the orders, something that we have should done since at least 2 years ago. Moreover, there are open source solutions for MANY of those boxes, so not having support from the original vendor doesn't preclude to have other choices. Last, but not least, even if the CPE is not IPv6-enabled, there is not any issue, because the hosts can use built-in transition mechanisms, even automatic ones, such as 6to4 and Teredo, to reach the IPv6 enabled contents when they are available. And even much more important. I don't believe in a short term, in IPv6-only in the local area networks if we want a trouble-free transition. It is much easier to keep dual-stack, even by means of private IPv4+NAT and global IPv6 addresses. This way, all the existing contents, applications and services, which already work with NAT today, still will keep working. Only the time will provide most of those services enabled with IPv6 and possibly new applications taking advantage of the end-to-end capability when developers realize that developing for IPv6-only saves a lot of cost and development time that trying to sort out the NAT in each possible scenario. Regards, Jordi PS: You can find lot of boxes, applications and services which are IPv6-enabled at http://www.ipv6-to-standard.org. By the way, I just realized that some of the IPv6-enabled load-balancers are miss-classified, so tomorrow will correct that. And of course, if you know about other boxes, applications or services that support IPv6 and are not there, please let me know.
De: Nathan Ward <nanog@daork.net> Responder a: <owner-nanog@merit.edu> Fecha: Sun, 27 May 2007 22:48:30 +1200 Para: <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On 27/05/2007, at 9:05 PM, Martin Hannigan wrote:
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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?
Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it.
If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, Google (etc.) won't work until they upgrade." would you: a) Stick it out with that provider, even though there is no content for you to access. b) Hang up. If you answered (a) to the above, run through that again, from say, your Mother's perspective.
Now that NAT-PT is deprecated (ie. can't be used as an excuse to not move), we need to move the large (and small) content providers to dual-stack, before we move any customers to v6-only. Content providers have all the IPv4 addresses they need already, they're not going to be asking for more any time soon. If someone has some bright ideas on how to transition without loss of service to *someone*, I'm all ears. (IPv4 NAT is not a bright idea.)
In addition, when 2010 [1] rolls around, are the free CPE that your customers were given in the last 7 days upgradable to support IPv6?
This is, of course, assuming we don't hold off until we've got a different IPv6 architecture as a result of the RAWS stuff. [2] While we're here, can someone point me in the direction of any ongoing discussion/work in this area? I attended the APRICOT workshop, but where to go to keep up with things/get involved isn't obvious.
-- Nathan Ward
[1] http://www.potaroo.net/tools/ipv4 [2] http://tools.ietf.org/id/draft-iab-raws-report-02.txt
********************************************** 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.
I agree, it is *right now* one of the main drivers. In addition to what I'd mention yesterday about a possible workshop or panel, I've prepared an extensive document (21 pages at the time being) about the IPv4 exhaustion and all the temporary/permanent "mitigations", results they could provide and how much they could take. So I can easily prepare a slide set for that if it is interesting. Regards, Jordi
De: Martin Hannigan <hannigan@gmail.com> Responder a: <owner-nanog@merit.edu> Fecha: Sun, 27 May 2007 05:05:45 -0400 Para: "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> CC: <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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?
-M<
-M<
********************************************** 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.
On Sun, 27 May 2007, Martin Hannigan wrote:
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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.
On Sun, May 27, 2007 at 03:14:44PM +0000, Chris L. Morrow wrote:
On Sun, 27 May 2007, Martin Hannigan wrote:
On 5/26/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> 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 AAAA 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.
I think there are other hurdles that the industry is facing (or ignoring) which will be more pressing than this v4 space shortage "issue". Not the least of currently is the lack of something past 40G currently. I'm interested to see the participants in the 40G vs 100G panel, and from those that have been attending the IEEE and ITU meetings on these topics. My understanding is there's somewhat of a shift in the way things are being done this time around because the demand of increased speed has grown since 2001, and there have been no "higher speed" solutions introduced since that timeframe. (i'm taking into account engineering and product pipeline timeframes here). If you're not feeling the pinch, I suspect your transit provider may be. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Isn't the driver going to be scarcity and/or expense of v4 addresses?
and the speed bump extraordinaire is that you can not connect to the internet from a v6 only site. in the mid and long run, all else pales before this. the rest is mostly o how to configure frammistat o why does flogistrator not support o ... all ephemeral and not very deep. what are the really big issues? randy
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.
Probably doing a trial on the customer base, especially having a group of people who will give good bugreports and enabling them to use it, is a good idea. A trick that might work there is to provide those people with alternate caching DNS servers which do return AAAAs. This can thus automatically be done using DHCP, when you have a user who is IPv6 enabled, steer them to the DNS servers that return AAAAs and presto, they start using it. And when you are lucky it also actually works. Plenty of ISP's have technically savvy customers- why not leverage these people? My personal network is business class DSL from SpeakEasy terminated by a Cisco running IPv6 firmware with a tunnel for IPv6. When I opened a ticket to inquire about native IPv6 support I was told: "Currently we do not offer IPv6 connectivity. It is not know if or when we will offer this service." The response left me speechless.
That's still better than the response I got from the sales rep at AT&T hosting operations who said "What's IPv6?" In the next few years one of two things is going to happen: 1. We are going to run out of addresses- or 2. India, China, Japan or another country is going to force a migration to IPv6. The end result is that content providers like Google and Yahoo are going to be shut out of this new market while whatever provider does offer such connectivity is going to see an explosion in traffic growth. That alone should be economic incentive enough to provide IPv6 connectivity. Can someone from Google or Yahoo (or any other major provider) comment on their IPv6 plans? Testing now with a small group of technically competent people would seem to be a better idea than waiting until IPv6 is already widely deployed and then trying to test a rollout. Am I off my rocker? -Don
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 AAAA 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
Don't forget customers. Turning this thing on for customers appears to be non-trivial in many cases. The only way I can see a customer being affected is if their CPE does IPv6, it's enabled on the CPE, and it's enabled on their network. If all of those are true- then the customer probably has enough smarts to make it work. That said- AT&T hosting sales said "What's IPv6" (several people
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. Perhaps my testing is an exception that proves the rule. For my
there did) and my own ISP who I consider to be technically with it said they're not even sure the're going to offer it. personal network it consisted of enabling an IPv6 and a tunnel on my old 2621 and enabling IPv6 on my FreeBSD desktop. That was it. I can reach www.kame.net via IPv6 transparently- along with several other boxes via IPv6 through ssh. The Windows boxes on my network that don't support IPv6 but use the same nameservers get to the IPv4 version of www.kame.net with no issues. The IPv6 enabled Windows boxes also work just fine. I guess I'm curious where people are having problems. Running dual stack in my personal network has not caused a single issue so far. I've also started moving my company backbone to dual stack with no problems so far. The routers and routing protocols have not been an issue. My dual stack desktop and the few servers I have running IPv6 have no problems communicating via IPv6. The biggest problem so far is figuring out who to talk to upstream about IPv6 connectivity.
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 AAAA records tomorrow? This is here now, and if we want this to happen without pain, I think we need to be acting. I understand what you're saying but there is an option besides setting up A and AAAA records for www.google.com. They could set up AAAA records for ipv6.google.com and let those of us using IPv6 actually connect without having to revert to IPv4 or a proxy.
I'd like to see ipv6.cnn.com, ipv6.google.com, ipv6.yahoo.com, etc. I don't see where this would be a problem for anyone except those people who explicitly try to connect via IPv6- and those people should really know enough to troubleshoot the problem on their own. -Don
On Tue, May 29, 2007 at 12:25:21AM -0400, Donald Stahl wrote:
I'd like to see ipv6.cnn.com, ipv6.google.com, ipv6.yahoo.com, etc. I don't see where this would be a problem for anyone except those people who explicitly try to connect via IPv6- and those people should really know enough to troubleshoot the problem on their own.
Some providers (eg: www.us.ntt.net) have their sales/marketing path ipv6 enabled. Perhaps this will help self-select customers that are clued? ;) I think we're going to gradually see more of the ipv6 stuff enabled over time. And not just from folks that were able to figure out how to navigate the FAR (http://www.arnet.gov/far/). 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. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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
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 AAAA records tomorrow? This is here now, and if we want this to happen without pain, I think we need to be acting.
I'd actually be interested in what the right answer is for that - Over at Mozilla, I'm working to flip on v6 versions of some web properties and other services but haven't yet gotten to the supportability issues and what it means for Joe End User.
That is, of course, after I find some way to get my /48 announced... none of my upstreams currently offer native v6 (not sure about tunnels yet) so I'm a content provider without any global v6 connectivity :( matthew zeier wrote:
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 AAAA records tomorrow? This is here now, and if we want this to happen without pain, I think we need to be acting.
I'd actually be interested in what the right answer is for that -
Over at Mozilla, I'm working to flip on v6 versions of some web properties and other services but haven't yet gotten to the supportability issues and what it means for Joe End User.
On 29-mei-2007, at 3:35, Donald Stahl wrote:
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.
I don't know what kinds of weird management and billing systems are out there, so I won't say that's not relevant, but the most difficult part about IPv6 deployment today is provisioning, in my opinion. If you as a service provider have a router and a customer has a host (or more than one for either) then you can do stateless autoconfig and life is good. However, when the customer has a router then there is no way to make that work automatically without manual configuration similar to what you get now with a CPE that receives a single IPv4 address over PPP or DHCP on the WAN side and does NAT on the LAN side. Then there is the DNS issue: since you can't predict what addresses your customer's machines are going to have, you can't pre-populate the DNS. DHCP for IPv6 is largely missing in action so that's not a 100% solution. It is possible to have clients register their addresses in the DNS using dynamic DNS updates, but that's not all that widely supported either and either you have no security or you have confused customers. But you can always delegate the reverse DNS to the customer and make it their problem. :-)
Testing now with a small group of technically competent people would seem to be a better idea than waiting until IPv6 is already widely deployed and then trying to test a rollout.
# 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 don't really agree 100%. There is DHCPv6 Prefix Delegation, and it just works ! Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Tue, 29 May 2007 10:46:47 +0200 Para: Donald Stahl <don@calis.blacksun.org> CC: Jeroen Massar <jeroen@unfix.org>, "Steven M. Bellovin" <smb@cs.columbia.edu>, Randy Bush <randy@psg.com>, Martin Hannigan <hannigan@gmail.com>, <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On 29-mei-2007, at 3:35, Donald Stahl wrote:
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.
I don't know what kinds of weird management and billing systems are out there, so I won't say that's not relevant, but the most difficult part about IPv6 deployment today is provisioning, in my opinion. If you as a service provider have a router and a customer has a host (or more than one for either) then you can do stateless autoconfig and life is good. However, when the customer has a router then there is no way to make that work automatically without manual configuration similar to what you get now with a CPE that receives a single IPv4 address over PPP or DHCP on the WAN side and does NAT on the LAN side.
Then there is the DNS issue: since you can't predict what addresses your customer's machines are going to have, you can't pre-populate the DNS. DHCP for IPv6 is largely missing in action so that's not a 100% solution. It is possible to have clients register their addresses in the DNS using dynamic DNS updates, but that's not all that widely supported either and either you have no security or you have confused customers. But you can always delegate the reverse DNS to the customer and make it their problem. :-)
Testing now with a small group of technically competent people would seem to be a better idea than waiting until IPv6 is already widely deployed and then trying to test a rollout.
# 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.
********************************************** 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.
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.
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 AAAA record for www.nanog.org yet. -Larry Blunk Merit
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 AAAA 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? :)
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 AAAA record for www.nanog.org yet.
wow, with dns-sec sig stuff too I see? :) Thanks!
Can someone from Google or Yahoo (or any other major provider) comment on their IPv6 plans?
Few weeks ago I had interesting discussion with *unnamed* Google VIP. His answer has been: "Google engineers doesn't see need to spend money on building IPv6 infrastructure. You, as user, can motivate them by sending request supporting this idea." So did you write your e-mail to Google techies? BTW there is probably a way to motivate users to use IPv6. If some players (and I think there are some in this list) will make some "premium" services available only over IPv6 and do it for free, this can motivate users to go forward. Yes, this costs money, but ... everything costs money. Nice example is to stream video over IPv6 in better quality or provide IPv6 peering for better conditions than for IP. MK
On Wed, 30 May 2007, Michal Krsek wrote:
Few weeks ago I had interesting discussion with *unnamed* Google VIP. His answer has been: "Google engineers doesn't see need to spend money on building IPv6 infrastructure. You, as user, can motivate them by sending request supporting this idea."
So did you write your e-mail to Google techies?
Why would Google techies care. However you might point out to Google advertisers how many eyeballs no longer get their advertising because they are on IPv6 connections. Oh, that's right. User's probably don't know or care whether its IPv6, IPv4 or IPX. After a while, when the IPv4toIPV6 tunnels and translators are overloaded, some eyeballs and content will discover each other gets better performance going "native." And it will happen. Trying to force it before just makes it grumpy. The Internet has always been an example of just-in-time engineering. -- Caution buying from UltraDNS/Neustar. Its monthly rates aren't actually monthly.
On 5/30/07, Michal Krsek <michal@krsek.cz> wrote:
Few weeks ago I had interesting discussion with *unnamed* Google VIP. His answer has been: "Google engineers doesn't see need to spend money on building IPv6 infrastructure. You, as user, can motivate them by sending request supporting this idea."
I see three main ways Google might use IPv6 infrastructure -- Using IPv6 for scanning IPv6-distributed web pages, at least for IPv6only pages -- Accepting search requests over IPv6 http for users who want that -- Glue, internal applications, etc. The first application is probably the most important - if there's (ostensibly, at least) content on the web that's only available via IPv6, they may still want it (though IPv4-only search engine users may not be able to get it except via Google's cache.) Internal applications might benefit from IPv6, but there's probably enough room in IPv4 10.0.0.0/8 for Google, at least for a while. IPv6 web users will need IPv6-to-IPv4 gateways for a while... ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
For core links it should IMHO be mostly possible to keep them IPv4/IPv6 dual-stack.
What's wrong with MPLS in the core and 6PE at the edge? Right there you have two possible tactics that are worthy of being publicly discussed and compared.
Towards endusers it can become nasty, eg it would require upgrades of the CPE and also the infrastructure might need to be upgraded.
On the other hand, there are vendors like Hexago that sell gateways which can simplify this. Perhaps Hexago and other vendors should be invited to showcase their boxes at a NANOG meeting. The great power of NANOG has always been that the operations, research and vendor community meet together and share information. Vendors go away and build better boxes/software, researchers go away and follow new avenues of investigation, operators go away and change their processes and network designs. Back in the day, there was something called Interop where vendors were put under the thumb. Since there is no such thing for IPv6, perhaps NANOG could step into that vacuum.
For Cable systems only recently the Docsis 3.0 standard was released and that would still require a lot of upgrades. Tunneling those users might be a way to provide IPv6 connectivity to these users without much ado.
Cable is a consumer access technology. Realistically, IPv6 is going to kick off with deployments to research, education and business users, not consumers. Cable will catch up in their own good time as they are driven to IPv6 by RFC 1918 exhaustion. --Michael Dillon
michael.dillon@bt.com wrote: [..]
Back in the day, there was something called Interop where vendors were put under the thumb. Since there is no such thing for IPv6, perhaps NANOG could step into that vacuum.
For the "non-existing" IPv6 Interop check http://www.ipv6ready.org/ who have been doing that already for quite some time ;) Greets, Jeroen
Back in the day, there was something called Interop where vendors were put under the thumb. Since there is no such thing for IPv6, perhaps NANOG could step into that vacuum.
I've gotten a couple of replies pointing me to http://www.ipv6ready.org Although the website doesn't make it very clear that this is something other than a logo branding program, i.e. marketing, perhaps there is some level of interoperability testing being done, however it is *NOT* being done under the thumb of potential customers like Interop was in the early days of commercial IPv4 networking. That's why I suggested that NANOG run some kind of IPv6 vendor showcase in which all the vendors would be running an interoperable IPv6 network. As many have pointed out, this is not just about routers since Cisco and Juniper have had IPv6 support for years and both are in use on production IPv6 networks in Asia. People need to see things like the Hexago gateways, Teredo servers, proxies, management consoles/tools, and so on. Even the easy stuff needs to be on display because if it can't be seen then people will not believe that it is easy. Also, if NANOG does such a showcase, then content providers like Google and Yahoo should be invited. Just because they don't offer IPv6 services today on the open Internet, doesn't mean that they haven't got something running in-house. A showcase at NANOG might be an attractive venue for them to show where they are headed. --Michael Dillon
On Tue, May 29, 2007, michael.dillon@bt.com wrote:
That's why I suggested that NANOG run some kind of IPv6 vendor showcase in which all the vendors would be running an interoperable IPv6 network. As many have pointed out, this is not just about routers since Cisco and Juniper have had IPv6 support for years and both are in use on production IPv6 networks in Asia. People need to see things like the Hexago gateways, Teredo servers, proxies, management consoles/tools, and so on. Even the easy stuff needs to be on display because if it can't be seen then people will not believe that it is easy.
From someone who hasn't looked into IPv6 customer deployments:
* So is DHCPv6 the "way to go" for deploying IPv6 range(s) to end-customers? Considering the current models of L2TP over IP for broadband aggregation and wholesaling where the customer device speaks PPPoX. * Has anyone sat down and thought about the security implications for running native IPv6 addresses on end-devices which, at the moment, don't have 'direct' access to the internet (ie sitting behind a NAT.) * Has anyone looked into the effects of oppertunistic IPSEC on stuff like network IDSes? k Adrian
On 29-mei-2007, at 13:41, Adrian Chadd wrote:
* So is DHCPv6 the "way to go" for deploying IPv6 range(s) to end- customers? Considering the current models of L2TP over IP for broadband aggregation and wholesaling where the customer device speaks PPPoX.
IP6CP in PPP doesn't have the capability to negotiate actual IPv6 addresses, like IPCP can for IPv4. Also, giving out individual addresses isn't likely to be a useful model in IPv6 where the abundance of address space and the lack of NAT make giving out at least one subnet to a user a more natural model. With IPv4, DHCP gives out an address to a host, accompanied by a default gateway address and additional information such as DNS resolvers. IPv6 DHCP (DHCPv6) is capable of giving out addresses, but this isn't universally implemented because IPv6 hosts traditionally get their addresses from stateless autoconfig. DHCPv6 can't provide a default gateway, you need stateless autoconfig for that even if you use DHCPv6 for address assignment. And there is the extra info, but DNS resolvers may be availalbe in stateless autoconfig in the future as well. However, DHCPv6 also has a different mode of operation: prefix delegation. This does what the name implies. What you can do today with a Cisco router is request a prefix from a DHCPv6 server, and then, on a different interface, send out router advertisements using a subprefix from the DHCPv6 one so that hosts will receive addresses in that prefix using stateless autoconfig. When the DHCPv6 server gives out a new prefix, the router and all the hosts are automatically renumbered without much impact, if any. This is probably the way we want to do IPv6 address provisioning for end-users in the future, but that requires that home gateways that implement IPv6 routing functionality come with the DHCPv6 prefix delegation client capability and have this configured by default so it all works out of the box.
* Has anyone sat down and thought about the security implications for running native IPv6 addresses on end-devices which, at the moment, don't have 'direct' access to the internet (ie sitting behind a NAT.)
Sure: http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars
On Tue, May 29, 2007 at 02:06:54PM +0200, Iljitsch van Beijnum wrote:
DHCPv6 can't provide a default gateway, you need stateless autoconfig for that even if you use DHCPv6 for address assignment.
I think you mean "router advertisement", not stateless autoconfig. You don't need the M bit clear in order to use the router. On this topic, DHCPv6 also can't deliver a subnet prefix to clients. These are only delivered by router advertisements containing prefix options (not all router advertisements will contain prefix options, or may not include a prefix covering the allocated address), and without them, DHCPv6 implementations are justified in assuming the allocated address is a /128. Logically, they can't talk to one another without an advertising router present. So...I think how these two protocols comingle could use some work. In truth, I think we should just ditch rtadv/rtsol and add routers and subnet-mask options to DHCPv6. That's a shorter path with more finality than the pandora's box of adding options to rtadv.
And there is the extra info, but DNS resolvers may be availalbe in stateless autoconfig in the future as well.
Again, you mean in rtadv. Is it just me, or does it seem unusual for network infrastructure to advertise host configuration parameters? Maybe I'm getting old, but the idea of managing this configuration information in my routers sounds like a real chore compared to the old DHCP relayed central server model.
This is probably the way we want to do IPv6 address provisioning for end-users in the future, but that requires that home gateways that implement IPv6 routing functionality come with the DHCPv6 prefix delegation client capability and have this configured by default so it all works out of the box.
There's also a bit of a hinky issue in routing the delegated prefix to the client. Obviously, you don't trust route advertisements from the client - you're not going to run OSPF or BGP with all your broadband customers. How to "do this" in a way we can all just plug and play hasn't quite been decided yet. Would there be interest on a DHCPv6 related presentation at NANOG? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On 30-mei-2007, at 20:16, David W. Hankins wrote:
DHCPv6 can't provide a default gateway, you need stateless autoconfig for that even if you use DHCPv6 for address assignment.
I think you mean "router advertisement", not stateless autoconfig.
Sure.
On this topic, DHCPv6 also can't deliver a subnet prefix to clients.
That's not a huge deal in IPv6 because the router will redirect if you communicate with someone on the same physical subnet.
These are only delivered by router advertisements containing prefix options (not all router advertisements will contain prefix options,
It's common that routers automatically include the prefixes for their own addresses in RAs. Ciscos even automatically enable RAs as soon as they have a global address.
Logically, they can't talk to one another without an advertising router present.
If you can spare a DHCPv6 server, then a router wouldn't be too much of a problem, I'd assume. There is also the on-link assumption, although that's not universally implemented, and the ability to run things on link-local addresses.
So...I think how these two protocols comingle could use some work.
DHCPv6 itself needs work, it's basically two protocols: stateful and stateless, and the client needs to know which to use. You need the RAs anyway so do stateless autoconf and save yourself the trouble of running another rather complex binary UDP protocol, which don't have great security track records.
In truth, I think we should just ditch rtadv/rtsol and add routers and subnet-mask options to DHCPv6.
You are aware that most IPv6 implementations out there don't even support DHCPv6, right? This would take the better part of a decade. It's also the wrong thing to do. When there are several routers, and one dies, IPv6 can (fairly) seamlessly move to another by virtue of dead neighbor detection. If the router listed in the DHCP info dies, you're dead in the water.
That's a shorter path with more finality than the pandora's box of adding options to rtadv.
Adding options to DHCPv6 is easier/better than adding options to RAs why exactly?
And there is the extra info, but DNS resolvers may be availalbe in stateless autoconfig in the future as well.
Again, you mean in rtadv. Is it just me, or does it seem unusual for network infrastructure to advertise host configuration parameters?
It's not unusual at all. Pretty much all routers implement DHCP for IPv4 and are thus capable of doing this today. It's the notion that a separate server is needed to make a network usable that's strange.
Maybe I'm getting old, but the idea of managing this configuration information in my routers sounds like a real chore compared to the old DHCP relayed central server model.
If you like DHCP, fine, run DHCP. But I don't like it, so please don't force _me_ to run it.
This is probably the way we want to do IPv6 address provisioning for end-users in the future, but that requires that home gateways that implement IPv6 routing functionality come with the DHCPv6 prefix delegation client capability and have this configured by default so it all works out of the box.
There's also a bit of a hinky issue in routing the delegated prefix to the client. Obviously, you don't trust route advertisements from the client - you're not going to run OSPF or BGP with all your broadband customers.
I think with the Cisco implementation this is taken care of if you run a DHCPv6 prefix delegation server in the access router that talks to your customer's routers.
How to "do this" in a way we can all just plug and play hasn't quite been decided yet.
Right.
On Wed, May 30, 2007 at 09:10:02PM +0200, Iljitsch van Beijnum wrote:
If you like DHCP, fine, run DHCP. But I don't like it, so please don't force _me_ to run it.
OK, I can (and do) live with that. I tend to prefer technical reasons to choose a technology (and in so doing, hope to avoid "throwing spaghetti at the wall"), but if you'd rather base your decisions on what you like (or not), you have every right to do so. In my opinion there are a bulk of technical merits that place DHCPv6 ahead of RTadv. I don't like either protocol, but they're what we've got. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On Wed, 30 May 2007, David W. Hankins wrote:
Maybe I'm getting old, but the idea of managing this configuration information in my routers sounds like a real chore compared to the old DHCP relayed central server model.
not 'old' just 'sane'. or 'taking the same crazypills chris is', your call.
Would there be interest on a DHCPv6 related presentation at NANOG?
it would be nice perhaps a lightning talk? :) It is interesting that v6 went from 'eh, yea that's nice' to "holy crap, maybe I should figure this out?" in 4 months though...
On Tue, 29 May 2007 michael.dillon@bt.com wrote:
For core links it should IMHO be mostly possible to keep them IPv4/IPv6 dual-stack.
What's wrong with MPLS in the core and 6PE at the edge?
Right there you have two possible tactics that are worthy of being publicly discussed and compared.
stewart bamford gave a good presentation about this very thing 4 nanogs ago (or maybe 5)> There are some support issues to keep in mind of course.
For Cable systems only recently the Docsis 3.0 standard was released and that would still require a lot of upgrades. Tunneling those users might be a way to provide IPv6 connectivity to these users without much ado.
Cable is a consumer access technology. Realistically, IPv6 is going to kick off with deployments to research, education and business users, not consumers. Cable will catch up in their own good time as they are driven to IPv6 by RFC 1918 exhaustion.
what's interesting is the chicken/egg problem of users/content/ipv6. What's driving v6 deployment?
what's interesting is the chicken/egg problem of users/content/ipv6. What's driving v6 deployment?
Currently, it is IPv4 exhaustion. As for content, that can be tied to users in some situations, for instance VPNs. That's why I think that a lot of the worry is premature. Instead of figuring out how to deploy IPv6 to grandma we should be thinking of which early-adopter communities could use IPv6 services and help us, the network operators, climb up the IPv6 learning curve so that we will be ready when IPv4 shortages start to cause pain to us and the average customer. Before we run out of IPv4 addresses, some of you will be explaining to Joe Sixpack why he cannot get his DSL line moved to the new house that he just bought because it is served by a PoP that has run out of v4 addresses. Or you will be explaining the additional $30/month v4 addressing surcharge that he will have to pay if he doesn't take the v6 option at the new house. Today we only have to solve today's problems in order to learn what we need to do to solve tomorrows problems. We may learn that tomorrows problems are a lot easier to solve than we thought. --Michael Dillon
For core links it should IMHO be mostly possible to keep them IPv4/IPv6 dual-stack.
What's wrong with MPLS in the core and 6PE at the edge?
Right there you have two possible tactics that are worthy of being publicly discussed and compared.
stewart bamford gave a good presentation about this very thing 4 nanogs ago (or maybe 5)> There are some support issues to keep in mind of course.
Perhaps it was this one? http://www.nanog.org/mtg-0510/pdf/bamford.pdf Note that Level3 did choose to use 6PE for their deployment rather than dual-stacking. --Michael Dillon
On Tue, 29 May 2007 michael.dillon@bt.com wrote:
For core links it should IMHO be mostly possible to keep them IPv4/IPv6 dual-stack.
What's wrong with MPLS in the core and 6PE at the edge?
Right there you have two possible tactics that are worthy of being publicly discussed and compared.
stewart bamford gave a good presentation about this very thing 4 nanogs ago (or maybe 5)> There are some support issues to keep in mind of course.
Perhaps it was this one? http://www.nanog.org/mtg-0510/pdf/bamford.pdf
indeed, thanks!
Note that Level3 did choose to use 6PE for their deployment rather than dual-stacking.
I think he stated that initial deployment was 6pe, but they had planned to re-deploy native v6 at a later date.
Furlly agree. Time is very short, but if that help I will volunteer to work on something (workshop, panel, etc., or even all together). Of course, it will need to be agreed *immediately*. Regards, Jordi
De: "Steven M. Bellovin" <smb@cs.columbia.edu> Organización: Columbia University Responder a: <owner-nanog@merit.edu> Fecha: Sat, 26 May 2007 11:31:28 -0400 Para: Randy Bush <randy@psg.com> CC: Martin Hannigan <hannigan@gmail.com>, <nanog@nanog.org> Asunto: Re: NANOG 40 agenda posted
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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
********************************************** 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.
On 5/26/07, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> 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<
On Sat, 26 May 2007, Martin Hannigan wrote:
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.
it is possible that vendors might not want that story told on their behalf... there are still a significant number of vendors without any story for v6 :( (without a reasonable story I'd say)
participants (58)
-
Adrian Chadd -
Alexander Harrowell -
Andy Davidson -
Bernhard Schmidt -
Bill Stewart -
bmanning＠karoshi.com -
Chris L. Morrow -
Chris Owen -
Colm MacCarthaigh -
David Conrad -
David W. Hankins -
Donald Stahl -
Edward Lewis -
Igor Gashinsky -
Iljitsch van Beijnum -
James Jun -
Jared Mauch -
Jeroen Massar -
Joe Abley -
Joe Greco -
Joel Jaeggli -
John Curran -
John Curran -
JORDI PALET MARTINEZ -
Kevin Day -
Kevin Loch -
Kradorex Xeron -
Krichbaum, Eric -
Lamar Owen -
Larry J. Blunk -
Leo Vegoda -
Manolo Hernandez -
Mark Tinka -
Martin Hannigan -
Matt Peterson -
matthew zeier -
Merike Kaeo -
michael.dillon＠bt.com -
Michal Krsek -
Mike Leber -
Nathan Ward -
Patrick W. Gilmore -
Paul Vixie -
Paul Vixie -
Perry Lorier -
Petri Helenius -
Randy Bush -
Sean Donelan -
Simon Leinen -
simon＠limmat.switch.ch -
Stephane Bortzmeyer -
Stephen Sprunk -
Steven M. Bellovin -
Tony Hain -
Valdis.Kletnieks＠vt.edu -
Vince Fuller -
virendra rode // -
william(at)elan.net