Re: one data point regarding native IPv6 support
On Fri, Jun 10, 2011 at 7:35 AM, Hector Santos hsan...@isdg.net wrote: snip The bottom line: unless I am force to support IPv6, stack or no stack, the investment required isn't going to happen soon. You got an options now, how, when and where you want to go with IPv6, wait a few years until all you communicate with in Asia demand IPv6 connectivity, it's the only way to reach them. and it isn't that hard, just make sure all equipment you buy/invest into now can or have a plan to support IPv6, if you start with it now, or started with it ~2-3 years ago you are pretty much safe. (not all edge equipment are ready at that time but that's another story really) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a territorial threat to them. While the new or wannabe players would like the extra address space, the sad truth is that the already establish players don't like newly open spaces and prefer the territory control that comes with owning a piece of a limited land space. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
The situation in the UK appears similar to the US, with the exception of some really tech-friendly, passionate and clueful ISPs: either flat-out denial that IPv6 is important, in the smaller and well-off case, or else complete cluelessness, in the larger case. For larger ISPs, especially the resident cable pigopolist, you have to go to their user support forums to read the staff opinion, i.e., IPv6 is alarmist tripe and it'll wait, no plans to support, etc. My personal opinion is that they are simply afraid; they have too much invested in a young market, and now they're overpowered by the changes required, but without progress made or anticipated, it's a vicious circle, with investors in the lead. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Hello all, I visited *http://www.worldipv6day.org/* which is an Internet Society website and clicked on *test* which took me to http://test-ipv6.com/# to do a test online for IPv6. When *http://test-ipv6.com/#* opened for me to run a test, part of the results says: You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites. Please can some one visit http://test-ipv6.com/# and give me more explanation on the displayed result? Kind regards, Otunte Otueneh ISOC Nigeria Chapter On Fri, Jun 10, 2011 at 7:32 AM, Stefan Winter stefan.win...@restena.luwrote: Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a territorial threat to them. While the new or wannabe players would like the extra address space, the sad truth is that the already establish players don't like newly open spaces and prefer the territory control that comes with owning a piece of a limited land space. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Hello, You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites. Please can some one visit http://test-ipv6.com/# and give me more explanation on the displayed result? That message is quite clear, isn't it? You use an Internet Service Provider which only supplies you with IPv4 connectivity. If you want to visit a website which only supports IPv6, it will not work. The test website can be reached on both IPv4 and IPv6. So it can tell you: you came here via IPv4, and didn't manage to get here via IPv6. So there is no working IPv6 for you. Stefan Kind regards, Otunte Otueneh ISOC Nigeria Chapter On Fri, Jun 10, 2011 at 7:32 AM, Stefan Winter stefan.win...@restena.lu mailto:stefan.win...@restena.lu wrote: Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a territorial threat to them. While the new or wannabe players would like the extra address space, the sad truth is that the already establish players don't like newly open spaces and prefer the territory control that comes with owning a piece of a limited land space. Michel.
Re: one data point regarding native IPv6 support
Dear Stefan, Thank you for the reply. I think there should be a platform where IPv4 users and IPv6 users can interface. If this link is missing then there will be problem. Otueneh On Fri, Jun 10, 2011 at 10:09 AM, Stefan Winter stefan.win...@restena.luwrote: Hello, You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites. Please can some one visit http://test-ipv6.com/# and give me more explanation on the displayed result? That message is quite clear, isn't it? You use an Internet Service Provider which only supplies you with IPv4 connectivity. If you want to visit a website which only supports IPv6, it will not work. The test website can be reached on both IPv4 and IPv6. So it can tell you: you came here via IPv4, and didn't manage to get here via IPv6. So there is no working IPv6 for you. Stefan Kind regards, Otunte Otueneh ISOC Nigeria Chapter On Fri, Jun 10, 2011 at 7:32 AM, Stefan Winter stefan.win...@restena.lu mailto:stefan.win...@restena.lu wrote: Hi, ... when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. [multiple people essentially reporting the same] At this point in time $ISP has no immediate plans for implementation. I would say it's about time reality finally settles in. My reality is that I switched to an ISP who openly announced native IPv6 support in their offering in 2007. Up and running since then, and when I had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I wrote them an email on a Saturday, and got a config snippet back an hour later, as part of their standard customer service. That ISP operates nation-wide and uses IPv6 as a marketing instrument to get techies to subscribe. For a price of converted 15 USD per month. That's in Germany though. Apparently, realities differ depending on where you are. Greetings, Stefan Winter Keith Moore wrote: Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Ned wrote: Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Hmm that is a point of view. You think you have a solution (IPv6) to what you perceive to be a problem (shortage of IPv4 addresses). However, some ISPs (and some other companies) do not consider it a problem, but a blessing. What the IPv4 shortage does is that it prevents new large players to enter the field, while allowing existing players to continue to do business as usual. As the shortage as been predicted for a decade, some (not all) have stockpiled addresses and are now reaping the benefits. In business, this situation is worth solid gold: it's called a monopoly. I'm fat and happy, and I want it to continue. In this case, it's even better: companies who benefit from it can argue that they are not the ones who created the monopoly, it was a built-in limitation of the system as created. Some may not like the parallel, but we have failed the IPv6 migration the same way we have failed the war on drugs. A while ago, there was this thing called the Tier-1 cartel. As originally designed, a very elusive club, with almost no way in and absolutely no tears when a member gets de-peered. Some have said that the cartel has failed as a system (due to a large number of multilateral peering agreements and other factors). But now what we have is a much larger number of largely unorganized but sharing the same goals entities: those who already have IPv4 addresses. It's even worse. When a resource becomes scare or limited, the big picture is not how much of it is available, or how much it costs. The big picture is how much of the market one does control. Now we are in the situation where everyone and their sister own a piece of the pie, and as long as the price of the pie keeps going up, they're going to cling to it. On top of the marketing problem you mentioned, you have a bigger one: there are many, many organizations out there that, even if you paid them to deploy IPv6, would not. Because IPv6 is a
Re: one data point regarding native IPv6 support
On Fri, Jun 10, 2011 at 05:55, otunte otueneh otuene...@gmail.com wrote: Dear Stefan, Thank you for the reply. I think there should be a platform where IPv4 users and IPv6 users can interface. If this link is missing then there will be problem. That kind of thing can be done - Google NAT64/DNS64 or how proxies work., However, this is *not* the ideal state. Ideally, you would be provisioned with both IPv4 and IPv6 (dual stack) and thus be able to connect to content reachable over either. Call your ISP, ask them when they will be entering the right decade (read: How soon will they offer IPv6). This may not be a critical feature right now, but if your ISP hasn't even started they probably won't be ready when you start to need it. Or they will break things trying to get there rapidly, that is fun. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Sadly this is more common than it should be these days. I've been begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME now have been subjected to as Verizon sold off FIOS/dsl in those areas to them a while back. I have business service from them with static IPs and the whole 9 yards, and they still insist that I am mad when I call to ask for IPv6 siting the same reasons you are being given. --Tom I just called my ISP to ask about availability of IPv6 at my home. Me: I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6. First person: Yes, we do support Internet. We support DSL at 3 megabits and 6 megabits. Me: I understand that, but I'm asking about Internet Protocol version 6, IPv6. The Internet has been using IP version 4 since the early 1980s, but that's running out. IPv6 is the new version. First person: Let me transfer you to support. Second person: Hi, this is support. How may I help you? Me: I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6. Second person: IP version what? Me: Internet protocol version 6. Second person: I have no idea. Let me transfer you to someone else. (places me on hold for 15 minutes) Second person: I'm sorry for the wait time. I've been trying to find the answer to your question, but nobody here seems to know anything about it. We're trying to get in touch with people who run the network to ask them. Can I get your number and call you back? Granted, this is just one ISP. The other ISP that offers service in my area put me on hold for an hour and a half *before anyone ever talked to me* when I tried to get a quote from them, so I concluded that they wouldn't be a good choice. And these guys have been good about support in general. They seem to know their stuff, which is more than I can say for some ISPs I've dealt with in the past. I live in a well-settled urban area, three miles from the center of the city (and sadly, four miles from my CO, which means my DSL circuit gets around 380kbits/sec). It's not a backwater, there's plenty of lit fiber running through town. But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
I have a Business service from my ISP too. They told me that somewhere in 2012 they would look into IPv6. So I have threatened to move to another provider. But we do not have much choice in NL at the moment I believe. Although I have to re-checked recently. Bert On 6/10/11 3:04 PM, Thomas Nadeau wrote: Sadly this is more common than it should be these days. I've been begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME now have been subjected to as Verizon sold off FIOS/dsl in those areas to them a while back. I have business service from them with static IPs and the whole 9 yards, and they still insist that I am mad when I call to ask for IPv6 siting the same reasons you are being given. --Tom I just called my ISP to ask about availability of IPv6 at my home. Me: I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6. First person: Yes, we do support Internet. We support DSL at 3 megabits and 6 megabits. Me: I understand that, but I'm asking about Internet Protocol version 6, IPv6. The Internet has been using IP version 4 since the early 1980s, but that's running out. IPv6 is the new version. First person: Let me transfer you to support. Second person: Hi, this is support. How may I help you? Me: I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6. Second person: IP version what? Me: Internet protocol version 6. Second person: I have no idea. Let me transfer you to someone else. (places me on hold for 15 minutes) Second person: I'm sorry for the wait time. I've been trying to find the answer to your question, but nobody here seems to know anything about it. We're trying to get in touch with people who run the network to ask them. Can I get your number and call you back? Granted, this is just one ISP. The other ISP that offers service in my area put me on hold for an hour and a half *before anyone ever talked to me* when I tried to get a quote from them, so I concluded that they wouldn't be a good choice. And these guys have been good about support in general. They seem to know their stuff, which is more than I can say for some ISPs I've dealt with in the past. I live in a well-settled urban area, three miles from the center of the city (and sadly, four miles from my CO, which means my DSL circuit gets around 380kbits/sec). It's not a backwater, there's plenty of lit fiber running through town. But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Michel, On 2011-06-10 15:38, Michel Py wrote: ... On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Who's talking about its demise? Really all that the 6to4-historic draft does is say that it should no longer be considered as a default solution to the problem of ISPs that don't support IPv6. Changing the formal status of the RFCs is a symbolic step, but the real point is that it's now time for the reluctant ISPs to get their heads out of the sand. You're correct that some ISPs will try to get monopoly rents out of the IPv4 shortage, and use CGN to capture customers in walled gardens, but fortunately capitalism provides a solution to such misbehaviour: other ISPs can deploy IPv6 as a competitive advantage. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 10, 2011, at 9:34 AM, Brian E Carpenter wrote: Michel, On 2011-06-10 15:38, Michel Py wrote: ... On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Who's talking about its demise? Really all that the 6to4-historic draft does is say that it should no longer be considered as a default solution to the problem of ISPs that don't support IPv6. Actually it says more than that. For instance, it specifically says that new implementations shouldn't support 6to4. That, and if passed, this would be the first time I can recall that IETF has taken the symbolic step of declaring something Historic that people actually use, and for which there is not a readily available replacement that works better. Historic has historically been used for things that aren't used anymore, or for things for which there's an obvious and readily available replacement. That, and the 'no compromise' position of this draft's proponents - their unwillingness to try to build a strong consensus position - makes this look suspiciously like a denial-of-service attack. Changing the formal status of the RFCs is a symbolic step, but the real point is that it's now time for the reluctant ISPs to get their heads out of the sand. It's a step in the wrong direction. Not only does this symbolic step bring with it the potential for harm to current users of 6to4, it actually takes away some of the incentive for ISPs to get their heads out of the sand. Meanwhile, it discourages the development of IPv6-based applications. You're correct that some ISPs will try to get monopoly rents out of the IPv4 shortage, and use CGN to capture customers in walled gardens, but fortunately capitalism provides a solution to such misbehaviour: other ISPs can deploy IPv6 as a competitive advantage. Last mile (kilometer?) problems limit the ability of other ISPs to compete with established players, especially for consumer services. But IETF can't do much about that. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
--On Saturday, June 11, 2011 01:34 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... You're correct that some ISPs will try to get monopoly rents out of the IPv4 shortage, and use CGN to capture customers in walled gardens, but fortunately capitalism provides a solution to such misbehaviour: other ISPs can deploy IPv6 as a competitive advantage. Sure. Assuming that there is realistic competition, or a realistic possibility of competition, in the relevant market. Keith, Ned, and others have described a situation in which there are few realistic choices of ISPs and the attitude of all of them toward getting IPv6 deployed to endpoints runs from bad to worse. In that marketplace situation, capitalism is as likely to predict a no one goes first outcome as it is to predict that one of the ISPs will suddenly decide that deploying IPv6 will give them a competitive advantage... and give that competitive advantage even after the additional training costs for their own staffs, support costs for customers, equipment and software, etc., are considered. That situation really isn't much different than it was several years ago. If I'm in an area where competition is permitted, I'm a large enough customer to be talking about dedicated fiber to my premises in the multiple DS3 range or above, and I call up my ISP (or my router vendors, or...) and say sell me IPv6 or I'm going to find it somewhere else, the threat is credible and I'll probably set either them or their competitors scrambling. If I'm in a situation that is closer to a SOHO one, in much of the world there is no effective competition, I'm not seen as having much leverage, and the scenario for my getting native IPv6 is a lot more dependent on internal strategic decisions (or wishful thinking) in those ISPs and not on competition issues except very indirectly or at all. john john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-rfc1150bis-01.txt (Conclusion of FYI RFC Sub-series) to Informational RFC
Please consider these: http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002518.html and http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002519.html as Last Call comments. Mykyta. 10.06.2011 16:18, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Conclusion of FYI RFC Sub-series' draft-iesg-rfc1150bis-01.txt as an Informational RFC [ . . . ] ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
Keith John are hitting the crux of the issue here. The entire point of the automated tunneling technologies was to enable application development and deployment in the face of lethargic ISPs, that will refuse to move until they see a set of credible applications running in the wild. None of them will take the risk that the leap-of-faith requires without serious competitive threat, and that simply doesn't exist. I am in the 'enviable' position where both ISP options available to me are clueful and actually actively working on IPv6 deployments. That said, I am still stuck with tunneling because the one option that could get me service today can't keep their basic access network running (the other work-from-home neighbors around me struggle with it regularly for IPv4), and the one I use for service has decided to start their deployment of IPv6 in larger markets (imagine that). 6to4 continues to serve me well for all but the bone-headed places that have decided to boycott that prefix. There is no real problem with 6to4, despite the BS being propagated about failure rates. The fundamental problem is that those complaining have their heads firmly stuck in IPv4-think, and are refusing to add a second 6to4 prefix to their service. If they would simply install their own 6to4 router and be the tunnel endpoint, there would be no 3rd party in the path for either direction. The technology is simply creating an opportunity. Those complaining about it are refusing to take advantage of it because that would be a different operational practice than they do for IPv4. The herd mentality of kill-what-we-don't-like is not helping with deployment. In fact the ability to document which ISPs have customers that are trying to use IPv6 despite the edge lethargy is a very useful thing to drive deployment through blame--shame. Put the 6to4-to-historic effort on the shelf for at least 5 years. Then it will be time to talk. Tony -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, June 10, 2011 7:44 AM To: Brian E Carpenter Cc: IETF Discussion Subject: Re: one data point regarding native IPv6 support --On Saturday, June 11, 2011 01:34 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... You're correct that some ISPs will try to get monopoly rents out of the IPv4 shortage, and use CGN to capture customers in walled gardens, but fortunately capitalism provides a solution to such misbehaviour: other ISPs can deploy IPv6 as a competitive advantage. Sure. Assuming that there is realistic competition, or a realistic possibility of competition, in the relevant market. Keith, Ned, and others have described a situation in which there are few realistic choices of ISPs and the attitude of all of them toward getting IPv6 deployed to endpoints runs from bad to worse. In that marketplace situation, capitalism is as likely to predict a no one goes first outcome as it is to predict that one of the ISPs will suddenly decide that deploying IPv6 will give them a competitive advantage... and give that competitive advantage even after the additional training costs for their own staffs, support costs for customers, equipment and software, etc., are considered. That situation really isn't much different than it was several years ago. If I'm in an area where competition is permitted, I'm a large enough customer to be talking about dedicated fiber to my premises in the multiple DS3 range or above, and I call up my ISP (or my router vendors, or...) and say sell me IPv6 or I'm going to find it somewhere else, the threat is credible and I'll probably set either them or their competitors scrambling. If I'm in a situation that is closer to a SOHO one, in much of the world there is no effective competition, I'm not seen as having much leverage, and the scenario for my getting native IPv6 is a lot more dependent on internal strategic decisions (or wishful thinking) in those ISPs and not on competition issues except very indirectly or at all. john john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore mo...@network-heretics.comwrote: Indeed, that is one of its main virtues. 6to4 decouples application deployment of v6 from network deployment of v6, and helps reduce the chicken or egg problem. No, it does not - in fact, it is the opposite. Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%. We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details. So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. And if you believe the access networks, the lack of IPv6 content is one of the most significant barriers to IPv6 deployment in access networks. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore mo...@network-heretics.comwrote: Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. No, we're trying to make their lives easier, by suggesting they use something that actually *works*. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. So use a tunnel broker. You're missing something. I can connect directly from my mobile laptop to a machine in my home network using 6to4. Really? From where? On none of the networks my laptop connects to do I get a public IPv4 address. Some of them do give me have native IPv6 or manually-tunneled IPv6 though. We can disagree about the meaning of the word widespread, but the practical fact is that you can't expect people to give up something that works for them until you can provide them something that works better *for them. Available to 50% of Internet service customers is equivalent to a very small percent probability of native connectivity being able to replace 6to4 connectivity in a scenario where 6to4 is currently working. And the more hosts involved, the smaller that probability is. * You cannot claim that 6to4 is working when there is data that shows that it has a 20% failure rate. If we had that sort of connectivity in IPv4, we wouldn't have an Internet. Existing content providers are not going to drive adoption of IPv6. They're going to follow it. Nope. Look at World IPv6 day. If you look at the list of participaints, I'd say that probably more than 10% of Internet content, either by bits or by query volume, is ready for IPv6 now. Our data shows that access is at 0.3%. So you could say that in fact content *is* driving adoption of IPv6. We just need to get unreliable tunneled connectivity out of the way so we can turn it on for real. Web and email will be the last applications to migrate. Um, no. See above. WEG Well, it'd be more harmful if there weren't alternatives. There aren't any good ones. Teredo and configured tunnels are worse in many ways; though they each have their use cases. Actually, configured tunnels are much better. They have a much lower failure rate and lower latency. We published data that shows the latency impact in our PAM 2009 paper. Regards, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore mo...@network-heretics.comwrote: Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. Please point at the data behind that assertion. In many cases in the past, such assertions have comes from networks that do not have the hardware capabilities to monitor native IPv6 traffic. I remember one case at the RIPE meeting where someone from AMS-IX observed about one of these presentations, I have more native IPv6 traffic on my exchange point than you have observed in the entire Internet. How is that possible? Needless to say, that presentation did not go well. Look at http://www.google.com/intl/en/ipv6/statistics/ That obviously does not see peer-to-peer traffic, but it does see IPv6 web clients, and just under 90% of those are native. The evidence is that people are using it. You're trying to subject it to test cases that are largely meaningless - because in those cases IPv6 (of any kind) provides no marginal value in the near term. So far, you have provided solid evidence that *you* use it, but not solid evidence that people are using it. Can you point to that evidence? Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 be deprecated. Nope. As before, 90% of IPv6 is native, and it comes from a small number of large deployments. Maybe your ISP doesn't support it, but other ISPs do. It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. No, it is a barrier to ubiquitous IPv6 adoption. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.comwrote: So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Please try again. You will be pleasantly surprised. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore mo...@network-heretics.comwrote: I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then. Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of don't solve the problem, but rather, stamp out the solution. Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6. In a similar way as Geoff measured 6to4 - looking at SYNs. From where? Again, the tunnels aren't taking the variety of paths that 6to4 connections are. It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole. From the same place that he ran the 6to4 measurements from? A few months ago I was trying to set one up, but I ran out of time. I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4. Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. Er, I'm currently on 2001:388:f000:: Do you have an algorithm that will tell you whether that is native or a configured tunnel? Not perfectly. But you can look at things like MSS and MTU. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
OTOH, my cable ISP provider has an Expected IPv6 Transition Phases chart, in which Phase 3 says, Customer Premesis Equipment (CPE) IP addressing: IPv6 only. And they've started trials of IPv6 already. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
At the risk of piling on, I can't resist the opportunity to try to one-up Ned's story. While in the UK this year, I had the misfortune to need to call BT for support on my broken home Internet connection. In the middle of the usual mind-numbing we will force you to walk through every idiotic step that you already know is irrelevant after thirty years in the business, the phone support guy told me to Click on the pulldown for 'Configure one-pee-vee-six' and set it to Off. Not only was this totally irrelevant, and not only did he routinely make me turn off the very protocol we want to enable, but he called that protocol one pee v6 instead of eye pee v6. And when I was stupid enough to correct him, he wouldn't go any further until I admitted that he knew best, and that I should call it one pee v6 rather than eye pee v6.Needless to say, I didn't bother asking about BT's plans to support IPv6 -- oops, I mean 1Pv6. No need to ask. If BT can't even spell IP, we are a11 d00med. -- Nathaniel On Jun 9, 2011, at 6:13 PM, ned+i...@mauve.mrochek.com wrote: You folks have had it easy in your interactions with ISPs. When I tried not too long ago with various ISPs in my area, I was unable to reach anyone at either of the big ISPs who knew what IPv6 even meant. Both promised callbacks, neither did. The more interesting response was from a small ISP. They knew exactly what I was talking about, and told me (a) The IPv4 address shortage is nothing but a scare tactic, (b) They currently have no plans to offer IPv6, and (c) If they ever did offer it would only be with T1/T3 services, Colocation, and Managed Servers and not DSL. Those are verbatim quotes from their response. And here's another data point, this time in the SOHO router space. My new router is advertised as being IPv6 ready, but the firmware it came with has no IPv6 support whatsoever. When I contacted the vendor about this, I was informed that I could get a special firmware build that supports IPv6, but it would be an as-is thing based on an earlier release so there may be some loss of functionality in other areas. I then asked why they don't have support in their current product, I was told it's because they are worried about their support staff being inundated with questions and problems. Given the dearth of IPv6 support from other vendors in this product area, I can't say I blame them. Anyone who doesn't believe we have a major marketing problem here isn't paying attention. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Lorenzo Colitti lore...@google.com Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. ... So the existence of 6to4 is in itself a significant barrier for IPv6 deployment Surely you meant to say the _incorrect configuration_ of 6to4 is in itself a significant barrier? I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On 2011-06-11 04:03, Tony Hain wrote: ... There is no real problem with 6to4, despite the BS being propagated about failure rates. That's no BS, unfortunately. Have you studied the careful reports at https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really and http://www.potaroo.net/ispcol/2010-12/6to4fail.html ? The operational fixes for 6to4 are also essential, and documented in my draft, but how do you propose we get them implemented by the 1PV6 deniers among ISPs? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
--On Friday, June 10, 2011 12:10 -0400 Worley, Dale R (Dale) dwor...@avaya.com wrote: OTOH, my cable ISP provider has an Expected IPv6 Transition Phases chart, in which Phase 3 says, Customer Premesis Equipment (CPE) IP addressing: IPv6 only. And they've started trials of IPv6 already. Dale, I think that is part of the (rather specific) point I was trying to make. When one gets to the SOHO and small business markets, there are ISPs who have gotten with the program and are making commitments or actually deploying. Some have not, don't intend to, and don't have a clue. A few are issuing press releases about their commitment to IPv6, but have no actual deployment plan to end users. In none of the cases that are moving forward have I seen anything that can be best explained by a desire for competitive advantage. For several years, I went through the exercise that, every time one particular ISP issued a press release or make a presentation about their IPv6 efforts, I'd call their local office and say ok, I'd like IPv6 here. What is the schedule for your turning service on here and how do I get an order in? Despite all the hype, the answers I got were a lot more similar to what Keith, Ned, and Nathaniel have reported than they were to handing out charts and making commitments. YMMD... and obviously does. I think the question for the IETF is whether it is desirable to move 6to4 to historic at a time when it is the only path to IPv6 for some users in spite of whatever recognition there is that it is no longer a mechanism we want to encourage people to design into new installations or systems. Personally, I'd rather see us publish an A/S that just says generally Not Recommended any more because... than have the debate about the surface and deep semantics of Historic. Most of the text for that document could be appropriated from the current V6OPS WG draft. Much of the rest could be drawn from Tony Hain's recent note in this thread. But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, let me suggest that we need to realize that a good fraction of the reason we have as little deployed and used-routinely-in-production IPv6 as we do is not technical issues but that the IETF and some related communities have consistently gotten deployment scenarios, schedules, and plans wrong... and then made promises based on those wrong guesses. I think a little modest realism about our predictive abilities and a willingness to understand that different situations call for different scenarios would help a lot. It would help even more if our documents ran a little more in the direction of reflective and emotionally neutral scenario analysis and a little less in the direction of praise what you like and damn what you don't. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
John, On 2011-06-11 05:05, John C Klensin wrote: ... But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators while drafting draft-ietf-v6ops-advisory, the motivation is kill something that is causing real operational problems and failure modes. I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if there wasn't a very sound operational argument for it. I think nobody wants to kill the successful use of 6to4, but we need to stop the operational problems getting worse. It appears that the default help desk advice to disable 1PV6 is generally an echo of problems caused by on-by-default 6to4. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Tony == Tony Hain alh-i...@tndh.net writes: Tony There is no real problem with 6to4, despite the BS being Tony propagated about failure rates. The fundamental problem is Tony that those complaining have their heads firmly stuck in Tony IPv4-think, and are refusing to add a second 6to4 prefix to Tony their service. If they would simply install their own 6to4 Tony router and be the tunnel endpoint, there would be no 3rd party Tony in the path for either direction. The technology is simply Tony creating an opportunity. Those complaining about it are Tony refusing to take advantage of it because that would be a Tony different operational practice than they do for IPv4. +1 I have native IPv6 at home. I have multiple other sites that I work with that can only get tunnels. 6to4 (on BSD. Linux has a design bug) lets me do this to shortcut things: route add -net -inet6 2001:4830:116e:: -prefixlen 482002:84d5:ee07::1 IPv4 is my NBMA LAN :-) Tony The herd mentality of kill-what-we-don't-like is not helping Tony with deployment. In fact the ability to document which ISPs Tony have customers that are trying to use IPv6 despite the edge Tony lethargy is a very useful thing to drive deployment through Tony blame--shame. Put the 6to4-to-historic effort on the shelf Tony for at least 5 years. Then it will be time to talk. The funny part is that removing 6to4 won't reduce any code, as the 6rd code is often identical... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Lorenzo == Lorenzo Colitti lore...@google.com writes: Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. Lorenzo No, we're trying to make their lives easier, by suggesting Lorenzo they use something that actually *works*. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. Lorenzo So use a tunnel broker. My tunnel broker has a machine with broken IPv4 routing, which they can't fix. It's been down for a week+ now. We had to renumber that location in time for World IPv6 day. We only had 6 machines that were using their non-autoconfigured addresses, so the rest was just a s///g in the DNS zone file. 6to4 would have turned this into my problem (which I could have fixed), but since some places like google refuse to run their own 6to4 relay, I can't really use 6to4 to talk to. Thanks. This all reminds of how killing the mbone killed multicast. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote: This all reminds of how killing the mbone killed multicast. Getting grumpy email from van because I sourced more than 128Kb/s killed the mbone, it was a toy. joel___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-cl-edge-behaviour-08 Reviewer: Elwyn Davies Review Date: 10 June 2011 IETF LC End Date: 10 June 2011 IESG Telechat date: (if known) - Summary: In my opinion, there are a number of areas that need significant work and at least one open issue (the stability question from s3.3.1) that needs to be addressed before this document is ready for the IESG. Major issues: The draft contains partial definitions of two control protocols (egress - decision point; decision point - ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=PCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? s3.3.1: [CL-specific] The outcome of the comparison is not very sensitive to the value of the CLE-limit in practice, because when threshold- marking occurs it tends to persist long enough that threshold- marked traffic becomes a large proportion of the received traffic in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? Minor issues: s1.1: definition of PCN-Traffic etc: The same network will carry traffic of other Diffserv BAs. Just to be sure: Does this or does this not imply that *all* traffic in a PCN network must have a non-empty DSCP marking, i.e. that *all* traffic must be attached to some specific Diffserv BA? This should be clarified whichever is true. s1.1: T-fail: I notice from s3.1 that PCN-ingress nodes also have to make reports on request. Should T-fail or some other timer apply to non-return of info from ingress points? What would a (probably non-colocated) decision point do if it lost contact with the ingress? s2/s3.2.1: The use of PM and EXP codepoints for ThM and ETM appear to be reversed in these two sections!! Which way round is intended? s3.2.1/s3.2.2: Neither section mentions T-meas but I assume that this is supposed to be (either or both) the sampling period in the egress node or the period between reports. It is unclear if they are allowed to be different and if they are which one is T-meas. However s3.2.3 appears to imply that T-meas is probably the time between reports. This all needs to be much clearer. s3.2.1/3.2.2: In s3.2.2, para 2: If so configured (e.g., because multipath routing is being used, as explained in the previous section), the PCN-egress- node MUST also report the set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval. This is a requirement for a protocol that you may or may not be defining. Confusing. s3.2.3/s3.2.2: The first paragraph of s3.2.3 suggests that the report from an egress may not always contain the calculated value of the CLE, but s3.2.2 has a MUST for the report to contain this value. Consistency!!! s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. Nits/editorial comments: General: Consistency of naming for timing paramters t-meas/T-meas, etc. s1.1: I think it would be worth reproducing the CL-specific definitions: PCN-threshold-rate and threshold-marked since they are specific. s1.1: Congestion level estimate (CLE) A value derived from the measurement of PCN-packets received at a PCN-egress-node for a given ingress-egress-aggregate, representing the ratio of marked to total PCN-traffic (measured in octets) ^ ^^ received over a short period. The ratio is (hopefully) dimensionless. Maybe '(each measured in octets)' ? s2: the PCN-domain satisfies the conditions specified in [RFC5696]; This may be a bit pedantic but I am not sure that RFC 5696 actually sets out conditions for the domain. It sets out rules for encoding markings and allowed transitions. Maybe s/conditions/packet markings and allowed
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. ISATAP meets both of these conditions: http://tools.ietf.org/html/draft-templin-v6ops-isops Fred ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 9, 2011, at 9:25 PM, Randy Presuhn wrote: Your argument seems to be that the peculiar operational characteristics of 6to4 should give it additional immunity to being declared historic. I don't find that argument persuasive. That's not my argument. My argument is that declaring 6to4 Historic is inconsistent with the way we've used Historic in the past - namely to label something that either 'hardly anybody uses anymore' or something that should be abandoned because a better alternative is now generally available. The history of multiple protocols that have been declared historic shows that vendors seem to care about that designation only when it is convenient for them to do so. Installed base, customer demand, operational considerations and so on all trump whatever the IETF might say about a historic protocol. This works both ways: folks might decide to kill something before it becomes historic, or support it long after. We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of killing 6to4. We don't have that kind of power. Declaring 6to4 Historic certainly won't prevent people from implementing it. But the proposed action is clearly intended to discourage implementation of 6to4. It says so explicitly. Of course some vendors will ignore it, but some vendors will probably not ignore it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 9, 2011, at 18:47 , Masataka Ohta wrote: james woodyatt wrote: I need *native* IPv6 into my home in San Francisco for my day job, Really? Very very very few people have day jobs that require native IPv6 service to their home network today. I'm an exception because I have a requirement that IPv6 and IPv4 provide more or less *equivalent* performance characteristics. The extra 20 milliseconds of queuing delay caused by the 6over4 tunnel endpoint should be acceptable to almost everyone else, but it's a deal-breaker for me. For reasons I'm not going to discuss here, I need IPv6 to be at least as good if not better than IPv4-- today, not three years from now--- and I'm forced to leave my ISP over it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 1:15 PM, james woodyatt wrote: On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. thanks for clearing that up. I was pretty sure it wasn't true, but you saved me the trouble of reinstalling 10.6.4 to prove it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 10, 2011, at 11:20 , Keith Moore wrote: Declaring 6to4 Historic certainly won't prevent people from implementing it. But the proposed action is clearly intended to discourage implementation of 6to4. It says so explicitly. Of course some vendors will ignore it, but some vendors will probably not ignore it. I would absolutely agree that the document would be improved if this pointless recommendation were removed. I expect some perfectly reasonable people will still oppose it with understandable concerns. Nevertheless, I do think this particular recommendation is inconsistent with the consensus in IETF that a phase-out plan for 6to4 is unwarranted. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFP for Secretariat Services
The IETF Administrative Oversight Committee (IAOC) on behalf of the IETF announces this Request for Proposal for Secretariat Services. The Internet Society (ISOC) is the contractor. The Secretariat performs the following three types of services in support of the IETF: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services Supported Organizations include the Working Groups, Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF Administrative Oversight Committee (IAOC), Internet Research Task Force (IRTF), Internet Research Steering Group (IRSG), RFC Series Oversight Committee (RSOC), RFC Series Editor (RSE), Independent Submissions Editor (ISE) and the Nominating Committee (NomCom). The RFP is located at: http://iaoc.ietf.org/rfpsrfis.html The initial contract term will be for two (2) years, commencing on 1 February 2012, with an option on the part of the parties for two renewals of up to two (2) additional years each for a possible total of six years. It is the intent of the IAOC to obtain the best combination of performance and cost for the benefit of the IETF. A contract may be awarded to an Offeror providing all services, or a Prime Contractor, with subcontractors, providing all services. The closing date for submission of proposals to ietf-...@isoc.org is Monday, August 8, 2011 not later than 5:00 P.M. ET. It is expected that a contract or contracts will be completed by September 2012. The sole point of contact regarding this RFP is the IETF Administrative Director (IAD). All questions or inquiries must be submitted in writing and must be received no later than midnight ET, June 17, 2011. Questions or inquiries will be accepted by email at ietf-...@isoc.org. Responses to questions plus any changes to the RFP shall be posted on the IETF Administrative Support Activity (IASA) website at http://iaoc.ietf.org/rfpsrfis.html no later than June 24, 2011. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
--On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: John, On 2011-06-11 05:05, John C Klensin wrote: ... But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators while drafting draft-ietf-v6ops-advisory, the motivation is kill something that is causing real operational problems and failure modes. I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if there wasn't a very sound operational argument for it. I think nobody wants to kill the successful use of 6to4, but we need to stop the operational problems getting worse. It appears that the default help desk advice to disable 1PV6 is generally an echo of problems caused by on-by-default 6to4. Brian, This is not in my primary area of expertise and I am painfully aware that it has been almost a decade since I have been able to look in on these things from the viewpoint of an ISP with default-free backbone arrangements, small end-site customers, and almost everything in between. From the above and other comments you have made, I don't think we disagree very much on the substance here. I'm certainly not about to try to make the case that 6to4 is a wonderful option to be widely preferred. As a variation on your comment above, I don't want to see the IETF denounce or kill the successful use of 6to4 and don't believe anyone else does either (or at least should). Where we disagree is about a procedural matter and the stance the IETF takes formally and, perhaps still, about where the motivations to deploy IPv6 for real comes from. Let me see if I can describe my position and recommendation in another way: Even among those of us who believe that IPv6 conversion has ceased being optional and has to be considered the only option at this stage, we really have few clues about what is going to cause a given ISP, or a given end-node customer, to switch over. Most of our arguments are faulty, at least for some particular set of cases. Your capitalism/competition one is an example -- there are places where it will work and places where it won't. The applications support and availability of IPv6-capable (and IPv6-native) servers is another -- sometimes ISPs are waiting for customer demand and/or enough deployment on customer sites before they think about making the switch and the customers are waiting for more evidence that the applications issues are sorted out and will work reliably. We talk about the advantages to the folks who switch early, but we are aware that some folks don't want to be the first to switch. And so on, for a rather long list. Part of this adds up to a conclusion that we are lots better at protocol design than we are at predicting the future or gaming out the decision processes under various circumstances. We had better be -- our track record for those predictions is bad enough that, if our protocol design and engineering were worse, we should all find other occupations. At the same time, my very limited and quite anecdotal experience suggests that the decision in several dual-stack setups to automatically prefer IPv6 when it is available (following IETF advice if I recall) combines with sometimes-sketchy IPv6 connections and routing to cause connectivity problems that can overwhelm the sorts of folks who staff first-level help desks. 6to4 is certainly part of that problem --and a little worse if it is set up without user or ISP knowledge-- but the implicit argument in both ..-6to4-advice and 6to4-historic that 6to4 is the dominant cause of those problems isn't convincing. Maybe it is the case, maybe it is the dominant case (and, again, I don't have enough firsthand experience in recent years to claim to know) but certainly it is not the only one. I accept the claim that it can easily be misconfigured, but that may not be sufficient to demonize it. I don't think the technical content of either draft-ietf-v6ops-6to4-to-historic or draft-ietf-v6ops-6to4-advisory is especially bad. Indeed, the analysis in ...-6to4-advisory seems quite good to me -- the sort of thing the IETF should, IMO, be doing a lot more often. I'm just suggesting that we should not write off _any_ option that has proven useful to folks in preparing to transition, planning for transitions, or actually transitioning.To that end, the abstract of ...6to4-advisory is just the right think to do. Advising that 6to4 is a really lousy default, that implementations should allow it to be turned on only after appropriate warnings and only if the advice in Section 4 of ..-6to4-advice is followed _really_ carefully may be entirely appropriate. Put differently, your analysis appears good enough that I can see no argument against branding 6to4 as really dangerous -- use only if actually understood and needed, then with great
Re: one data point regarding native IPv6 support
On Fri Jun 10 17:15:55 2011, Nathaniel Borenstein wrote: At the risk of piling on, I can't resist the opportunity to try to one-up Ned's story. While in the UK this year, I had the misfortune to need to call BT for support on my broken home Internet connection. In the middle of the usual mind-numbing we will force you to walk through every idiotic step that you already know is irrelevant after thirty years in the business, the phone support guy told me to Click on the pulldown for 'Configure one-pee-vee-six' and set it to Off. Not only was this totally irrelevant, and not only did he routinely make me turn off the very protocol we want to enable, but he called that protocol one pee v6 instead of eye pee v6. And when I was stupid enough to correct him, he wouldn't go any further until I admitted that he knew best, and that I should call it one pee v6 rather than eye pee v6.Needless to say, I didn't bother asking about BT's plans to support IPv6 -- oops, I mean 1Pv6. No need to ask. If BT can't even spell IP, we are a11 d00med. -- Nathaniel Particularly poor as BT are actually quite clued up on IPv6: http://www.ipv6.bt.com/ (And I don't work for BT, have never worked for BT, have been in competition with BT, and I don't use their service) I would *never* judge an ISP by the clueless nature of their scripted first-line suppor, at least not beyond their existence. (The ISP I use does not have clueless script monkeys, but smart and helpful people who craft their response to fit your ability, not theirs). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
John, On one specific point: So my personal preference, in a more perfect world, would be to fold these two drafts together, I specifically pushed for the -advisory draft to be kept separate and Informational in order to get it out ASAP (in my dreams, before IPv6 Day, but that didn't prove possible). I still think that is the correct approach - decouple the practical advice from the admittedly political debate. I'm not dismissing the rest of your points - clearly there are varied opinions and Historic is, as you say, a blunt instrument. Regards Brian On 2011-06-11 09:05, John C Klensin wrote: --On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: John, On 2011-06-11 05:05, John C Klensin wrote: ... But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators while drafting draft-ietf-v6ops-advisory, the motivation is kill something that is causing real operational problems and failure modes. I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if there wasn't a very sound operational argument for it. I think nobody wants to kill the successful use of 6to4, but we need to stop the operational problems getting worse. It appears that the default help desk advice to disable 1PV6 is generally an echo of problems caused by on-by-default 6to4. Brian, This is not in my primary area of expertise and I am painfully aware that it has been almost a decade since I have been able to look in on these things from the viewpoint of an ISP with default-free backbone arrangements, small end-site customers, and almost everything in between. From the above and other comments you have made, I don't think we disagree very much on the substance here. I'm certainly not about to try to make the case that 6to4 is a wonderful option to be widely preferred. As a variation on your comment above, I don't want to see the IETF denounce or kill the successful use of 6to4 and don't believe anyone else does either (or at least should). Where we disagree is about a procedural matter and the stance the IETF takes formally and, perhaps still, about where the motivations to deploy IPv6 for real comes from. Let me see if I can describe my position and recommendation in another way: Even among those of us who believe that IPv6 conversion has ceased being optional and has to be considered the only option at this stage, we really have few clues about what is going to cause a given ISP, or a given end-node customer, to switch over. Most of our arguments are faulty, at least for some particular set of cases. Your capitalism/competition one is an example -- there are places where it will work and places where it won't. The applications support and availability of IPv6-capable (and IPv6-native) servers is another -- sometimes ISPs are waiting for customer demand and/or enough deployment on customer sites before they think about making the switch and the customers are waiting for more evidence that the applications issues are sorted out and will work reliably. We talk about the advantages to the folks who switch early, but we are aware that some folks don't want to be the first to switch. And so on, for a rather long list. Part of this adds up to a conclusion that we are lots better at protocol design than we are at predicting the future or gaming out the decision processes under various circumstances. We had better be -- our track record for those predictions is bad enough that, if our protocol design and engineering were worse, we should all find other occupations. At the same time, my very limited and quite anecdotal experience suggests that the decision in several dual-stack setups to automatically prefer IPv6 when it is available (following IETF advice if I recall) combines with sometimes-sketchy IPv6 connections and routing to cause connectivity problems that can overwhelm the sorts of folks who staff first-level help desks. 6to4 is certainly part of that problem --and a little worse if it is set up without user or ISP knowledge-- but the implicit argument in both ..-6to4-advice and 6to4-historic that 6to4 is the dominant cause of those problems isn't convincing. Maybe it is the case, maybe it is the dominant case (and, again, I don't have enough firsthand experience in recent years to claim to know) but certainly it is not the only one. I accept the claim that it can easily be misconfigured, but that may not be sufficient to demonize it. I don't think the technical content of either draft-ietf-v6ops-6to4-to-historic or draft-ietf-v6ops-6to4-advisory is especially bad. Indeed, the analysis in ...-6to4-advisory seems quite good to me -- the sort of thing the IETF should, IMO, be doing a lot more often. I'm just
Re: one data point regarding native IPv6 support
james woodyatt wrote: Very very very few people have day jobs that require native IPv6 service to their home network today. I'm an exception because I have a requirement that IPv6 and IPv4 provide more or less *equivalent* performance characteristics. Use 4 over 4 in addition to 6 over 4. I think you are not saying mobile IPv4 with 4 over 4 is not acceptable IPv4. PS If you mind performance, you should better learn how to type e-mails not to use lines longer than 72 characters. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Liaison and request for review of ITU-T document
Ralph, As far as I can tell this seems to describe some sort of a Layer 2 stateful per-flow QoS mechanism using new Ethertype headers. As such I don't see why the IETF would care. The point of it escapes me, since we have plenty of reason to believe that such solutions are impractical and do not scale, but that doesn't seem like our problem. I only looked at this to check if it impacted current work in 6MAN on the IPv6 Flow Label, and there doesn't appear to be any impact or relevance. Regards Brian Carpenter On 2011-06-08 08:27, Ralph Droms wrote: The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a Draft Recommendation. That liaison is available as https://datatracker.ietf.org/liaison/1054/. The official liaison is available at https://datatracker.ietf.org/documents/LIAISON/file1232.pdf. The liaison asks for IETF review of Draft Recommendation Signalling protocols and procedures relating to Flow State Aware QoS control in a bounded sub-network of a NGN, which is available at https://datatracker.ietf.org/documents/LIAISON/file1231.pdf. This note opens an IETF comment period on the document, ending midnight, anywhere on earth, 2011/7/5. After the comment period, a summary will be prepared and returned in a liaison to ITU-T Q5/SG-11. Of specific interest to the IETF are any ways in which the signalling protocols and procedures defined in the Draft Recommendation might interact with existing IETF Internet protocols. We are especially interested in potential adverse interactions or interference with IETF Internet protocols. The technical merits of the signalling protocols and procedures defined in the Draft Recommendation are of interest inasmuch as the IETF community might provide technical advice and recommendations to improve the Draft Recommendation itself. Please respond with any comments on the Draft Recommendation to ietf@ietf.org. Thanks in advance for your review of the Draft Recommendation. - Ralph Droms, Internet Area Director for the IESG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 10, 2011, at 10:28 AM, Brian E Carpenter wrote: John, On 2011-06-11 05:05, John C Klensin wrote: ... But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators while drafting draft-ietf-v6ops-advisory, the motivation is kill something that is causing real operational problems and failure modes. I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if there wasn't a very sound operational argument for it. I'm a content provider. I'm am prepared to turn on more ipv6 services that are visible to consumers. 6to4 is a visible and measurable source of collateral damage. If consenting adults want to use it that's fine, I would greatly appreciate it if the facility were: * off by default * considered harmful when not deliberately used. The gradually declining determinism that we fully expect to experience from ipv4 access networks and mobile broadband in particular we expect to be hard enough to manage without those users riding in over 6to4. I think the two documents at present encourage: * vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations. * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from. I think nobody wants to kill the successful use of 6to4, but we need to stop the operational problems getting worse. It appears that the default help desk advice to disable 1PV6 is generally an echo of problems caused by on-by-default 6to4. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 10, 2011, at 15:10 , Joel Jaeggli wrote: I think the two documents at present encourage: * vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations. * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from. I would say that I-D.ietf-v6ops-6to4-advisory suffices to encourage both those things with more precision and clarity than I-D.ietf-v6ops-6to4-to-historic does. In fact, I-D.ietf-v6ops-6to4-to-historic makes a more aggressive point on the first item, and sends, at best, a very mixed message about the second. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
--On Friday, June 10, 2011 15:10 -0700 Joel Jaeggli joe...@bogus.com wrote: I'm a content provider. I'm am prepared to turn on more ipv6 services that are visible to consumers. 6to4 is a visible and measurable source of collateral damage. If consenting adults want to use it that's fine, I would greatly appreciate it if the facility were: * off by default * considered harmful when not deliberately used. ok The gradually declining determinism that we fully expect to experience from ipv4 access networks and mobile broadband in particular we expect to be hard enough to manage without those users riding in over 6to4. I think the two documents at present encourage: * vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations. * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from. Actually not. That is certainly what the advice document encourages. But Historic is a sufficiently blunt instrument that moving the base 6to4 specs to Historic could be interpreted by either vendors or operators as if you had a transition strategy based on using 6to4, or are using it today, 6to4 is sufficiently bad news that it is reasonable to just disable it, and IPv6 along with it, instead until some unspecified magical event occurs. I know that isn't what you intend or how you would read it, but it is a reading of Historic that is perfectly consistent with things we have used Historic for in the past. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
As for Geoff figures. No one as far as I know has done measurements of 6to4 failure of explictly enabled 6to4. Yes Geoff figures seem scary but if vendors were to make 6to4 users do something to turn it on I truly think the failure rate would be in the noise. Lots of the perceived issues with broken 6to4 go away with reasonable application support for multi-homed servers. Just yesterday I had a dual homed site that was reachable over IPv4 but not over IPv6, routing SNAFU in Canada. Safari made me wait 30 odd seconds to connect. With Chrome I couldn't tell the site was not reachable over IPv6. This wasn't a 6to4 issue as neither end was running 6to4. However it is this delay, which is completely avoidable on the applications part, that is partially driving this push to move 6to4 to historic. Also the kill 6to4 crowd push back on anything that would make 6to4 work better for those that can't get native IPv6, whether there is a technical problem in the proposal or not. If there is not a technical problem then shut up. You may not want to work on it but others might. Making 6to4 historic will also stop us working on things that make 6to4 behave better. Whenever something is proposed in the future you will hear the kill 6to4 crowd say 6to4 is historic, we can't work on that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
In message 92f90cdd-6da4-4b7f-bbcc-5da43a43a...@bogus.com, Joel Jaeggli write s: On Jun 10, 2011, at 10:28 AM, Brian E Carpenter wrote: John, On 2011-06-11 05:05, John C Klensin wrote: ... But, to the extent to which the motivation for moving 6to4 to Historic is what Tony describes as kill-what-we-don't-like, Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators while drafting draft-ietf-v6ops-advisory, the motivation is kill something that is causing real operational problems and failure modes. I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if there wasn't a very sound operational argument for it. I'm a content provider. I'm am prepared to turn on more ipv6 services that ar e visible to consumers. 6to4 is a visible and measurable source of collateral damage. If consenting adults want to use it that's fine, I would greatly app reciate it if the facility were: * off by default * considered harmful when not deliberately used. You don't need to make the protocol historic to achieve this. The gradually declining determinism that we fully expect to experience from i pv4 access networks and mobile broadband in particular we expect to be hard e nough to manage without those users riding in over 6to4. I think the two documents at present encourage: There are at least 4 documents that address aspects of this issue. You need to add happy eyeballs to the mix (which works, see Google Chrome) and my 6to4 DHCP option draft. * vendors an implementors to consider not using or a least disabling by defau lt 6to4 auto-tunneling in existing and future implementations. We don't need vendors to stop implementing (historic). We just need it turned off by default (advisary). * the deployment of additional 6to4 anycast relays which if done would help a ddress issue that existing users of 6to4 who will be with us for a while as w ell as those who would prefer to use it would benefit from. * the ability to signal that 6to4 will not work with the address you are being give. * the ability to signal that there is a managed 6to4 relay at this address. I think nobody wants to kill the successful use of 6to4, but we need to stop the operational problems getting worse. It appears that the default help desk advice to disable 1PV6 is generally an echo of problems caused by on-by-default 6to4. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Mark Andrews wrote: Lots of the perceived issues with broken 6to4 go away with reasonable application support for multi-homed servers. True. A major design flaw of IPv6 is half hearted support for multihoming with multiple addresses by broken address selection architecture, which causes a lot of operational problems, which is partly why IPv6 is unusable. Disabling 6to4 and/or improving applications may work for some faulty cases, but it's not enough at all. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
In message 4df2ba67.9080...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Mark Andrews wrote: Lots of the perceived issues with broken 6to4 go away with reasonable application support for multi-homed servers. True. A major design flaw of IPv6 is half hearted support for multihoming with multiple addresses by broken address selection architecture, which causes a lot of operational problems, which is partly why IPv6 is unusable. Disabling 6to4 and/or improving applications may work for some faulty cases, but it's not enough at all. The next step is to make multi-homed clients also work well. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Itojun Service Award Announcement
Dear IETFers, Please note below regarding the Itojun Service Award. The deadline is July 15. Thanks in advance, Jun Murai === ANNOUNCING: CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD The Itojun Service Award is presented every year to an individual or a group who has made outstanding contributions in service to the IPv6 community. The deadline for nominations for this year's award is 15 July 2011. The award will be presented at the 82nd meeting of the IETF to be held in November 2011 in Taipei, Taiwan. About the Award The Itojun Service Award was established by the friends of Itojun and administered by the Internet Society (ISOC), recognises and commemorates the extraordinary dedication exercised by Itojun over the course of IPv6 development. The award includes a presentation crystal, a US$3,000 honorarium, and a travel grant. The award is focused on pragmatic technical contributions, especially through development or operation, with the spirit of servicing the Internet. With respect to the spirit, the selection committee seeks contributors to the Internet as a whole; open source developers are a common example of such contributors, although this is not a requirement for expected nominees. While the committee primarily consider practical contributions such as software development or network operation, higher level efforts that help those direct contributions will also be appreciated in this regard. The contribution should be substantial, but could be immature or ongoing; this award aims to encourage the contributor to keep their efforts, rather than just recognizing well established work. Finally, contributions of a group of individuals will be accepted as deployment work is often done by a large project, not just a single outstanding individual. The award is named after Dr. Jun-ichiro Itojun Hagino, who passed away in 2007, aged just 37. Itojun worked as a Senior Researcher at Internet Initiative Japan Inc. (IIJ), was a member of the board of the Widely Integrated Distributed Environment (WIDE) project, and from 1998 to 2006 served on the groundbreaking KAME project in Japan as the IPv6 samurai. He was also a member of the Internet Architecture Board (IAB) from 2003 to 2005. For additional information on the award, please visit http://www.isoc.org/awards/itojun/ Award Nomination Procedure Neither the nominee nor nominator needs to be a member of ISOC. Nominate via email to itojun-award at elists.isoc.org and include the following details: 1. Name and Email address of nominee (in case of a group nominee, names and Email addresses of representative persons of that group) 2. CV/Bio of nominee (in case of a group nominee, a summary of the group's achievements) 3. Statement of recommendation including specific acts, works, contributions, and other criteria that would show the nominee to fit the standard set by Itojun. Please include corroborating references with their name, email address, and telephone number. Conclude with your affiliation, postal address, and telephone number as well as the postal address, telephone and fax number of the nominee. Thank you in advance for your support, Jun Murai Itojun Service Award Selection Committee ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
I would say it's about time reality finally settles in. The reality is that for now and for the next several years, anyone who wants to communicate with the Internet had better figure out how to get their packets back and forth to the IPv4 Internet. This is totally unfair to new entrants who don't have a source of cheap IPv4 space. Tough. I'm all in favor of doing IPv6 experiments and opportunistically using it when you notice that a remote party supports it, but the urgency of doing so has been greatly overstated. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
Brian, Michel Py wrote: On that one I agree with Keith; where's the rush? Although imperfect, 6to4 was an obvious path and its demise would be the failure of the IETF, following a long list of things that have been killed prematurely. Brian E Carpenter wrote: Who's talking about its demise? Really all that the 6to4 historic draft does is say that it should no longer be considered as a default solution to the problem of ISPs that don't support IPv6. I'm not qualified to debate procedural issues, but I will say that, from a distance, this does smell like a kill-what-we-don't-like. As you have undoubtedly felt the irony of me defending Keith on this kind of issue, I will confess that there is a little part of me that did not mind a bit seeing him getting a taste of his own food in that matter, but I still think this is premature. but the real point is that it's now time for the reluctant ISPs to get their heads out of the sand. I don't think making 6-to-4 historic will change anything in that regard, which is why I said above that it did look like a kill-what-we-don't-like. You're correct that some ISPs will try to get monopoly rents out of the IPv4 shortage, and use CGN to capture customers in walled gardens, but fortunately capitalism provides a solution to such misbehaviour: other ISPs can deploy IPv6 as a competitive advantage. It does not matter, as long as the core of the haves don't do anything about it, as they command a big enough market share. Besides, you have not convinced me and not many ISPs either. I understand what you are trying to do here; nevertheless, 1Pv6 has not reached critical mass; although I do understand the disable 1Pv6 issue (probably better than most) and I do indeed recognize that some of the brokenness comes from 6to4, it does not change the fact that deprecating 6to4 will reduce the sub-critical mass before it starts chain reaction, if it ever does. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
08.06.2011 10:58, Dave Cridland wrote: On Wed Jun 8 05:57:15 2011, Pete Resnick wrote: On 6/7/11 11:00 PM, Peter Saint-Andre wrote: And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. [ . . . ] The best proposal I've seen - and I'd note that I can't recall now if this is Keith Moore's or Scott Bradner's, to my shame - is that of marking up specific I-D documents as being a Stable Snapshot. To my mind, this will override the basic rule of RFC 2026: * * * Under no circumstances should an Internet-Draft* * be referenced by any paper, report, or Request-* * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft.* * * whereas you propose making I-Ds almost Standards Track. As it was discussed before, there is an evidence of leaving PSs without any action/progress; introducing Stable Snapshots there might occur Stable Snapshots left without any action, like PSs. But PSs are RFCs at least and I-Ds are nothing-as-per-2026. Adopting this proposal might result in implementators claiming we implement Stable Snapshot of the Internet-Draft, which is unacceptable, IMO. Mykyta Yevstifeyev This proposal seems to have the following benefits: a) It satisfies the two paragraphs above in a non-conflicting manner. That is, it provides everything that RFC 2026's PS was intended to without being an RFC, with all that that moniker currently implies. b) It's fairly obvious, in my view, how to start to use the new grade, and how we might adapt to it in a smooth manner. Working Groups, authors, etc would be able to start to use it in a fairly ad-hoc manner, without the kinds of flag day changes to process that two-maturity-levels seems to imply. So if anyone has the patience for another I-D thrown into the soup, I'm willing to [re]write this one up, assuming the original instigator[s] of the proposal don't wish to. Dave. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-iesg-rfc1150bis-01.txt (Conclusion of FYI RFC Sub-series) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Conclusion of FYI RFC Sub-series' draft-iesg-rfc1150bis-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-07-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. The file can be obtained via http://datatracker.ietf.org/doc/draft-iesg-rfc1150bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-iesg-rfc1150bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6277 on Online Certificate Status Protocol Algorithm Agility
A new Request for Comments is now available in online RFC libraries. RFC 6277 Title: Online Certificate Status Protocol Algorithm Agility Author: S. Santesson, P. Hallam-Baker Status: Standards Track Stream: IETF Date: June 2011 Mailbox:s...@aaa-sec.com, hal...@gmail.com Pages: 11 Characters: 21682 Updates:RFC2560 I-D Tag:draft-ietf-pkix-ocspagility-10.txt URL:http://www.rfc-editor.org/rfc/rfc6277.txt The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6246 on Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges
A new Request for Comments is now available in online RFC libraries. RFC 6246 Title: Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges Author: A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest Status: Informational Stream: IETF Date: June 2011 Mailbox:saja...@cisco.com, fbroc...@cisco.com, dinmo...@hotmail.com, yetik_serb...@labs.att.com Pages: 20 Characters: 51024 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-l2vpn-vpls-bridge-interop-06.txt URL:http://www.rfc-editor.org/rfc/rfc6246.txt One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6278 on Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax
A new Request for Comments is now available in online RFC libraries. RFC 6278 Title: Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax Author: J. Herzog, R. Khazan Status: Informational Stream: IETF Date: June 2011 Mailbox:jher...@ll.mit.edu, r...@ll.mit.edu Pages: 16 Characters: 36593 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-herzog-static-ecdh-06.txt URL:http://www.rfc-editor.org/rfc/rfc6278.txt This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFP for Secretariat Services
The IETF Administrative Oversight Committee (IAOC) on behalf of the IETF announces this Request for Proposal for Secretariat Services. The Internet Society (ISOC) is the contractor. The Secretariat performs the following three types of services in support of the IETF: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services Supported Organizations include the Working Groups, Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF Administrative Oversight Committee (IAOC), Internet Research Task Force (IRTF), Internet Research Steering Group (IRSG), RFC Series Oversight Committee (RSOC), RFC Series Editor (RSE), Independent Submissions Editor (ISE) and the Nominating Committee (NomCom). The RFP is located at: http://iaoc.ietf.org/rfpsrfis.html The initial contract term will be for two (2) years, commencing on 1 February 2012, with an option on the part of the parties for two renewals of up to two (2) additional years each for a possible total of six years. It is the intent of the IAOC to obtain the best combination of performance and cost for the benefit of the IETF. A contract may be awarded to an Offeror providing all services, or a Prime Contractor, with subcontractors, providing all services. The closing date for submission of proposals to ietf-...@isoc.org is Monday, August 8, 2011 not later than 5:00 P.M. ET. It is expected that a contract or contracts will be completed by September 2012. The sole point of contact regarding this RFP is the IETF Administrative Director (IAD). All questions or inquiries must be submitted in writing and must be received no later than midnight ET, June 17, 2011. Questions or inquiries will be accepted by email at ietf-...@isoc.org. Responses to questions plus any changes to the RFP shall be posted on the IETF Administrative Support Activity (IASA) website at http://iaoc.ietf.org/rfpsrfis.html no later than June 24, 2011. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Fwd: Itojun Service Award Announcement
Begin forwarded message: From: Jun Murai j...@wide.ad.jp Date: June 10, 2011 9:43:27 PM EDT To: ietf@ietf. org i...@ietf.org Cc: chair@ietf. org ch...@ietf.org, Lynn St. Amour st.am...@isoc.org Subject: Itojun Service Award Announcement Dear IETFers, Please note below regarding the Itojun Service Award. The deadline is July 15. Thanks in advance, Jun Murai === ANNOUNCING: CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD The Itojun Service Award is presented every year to an individual or a group who has made outstanding contributions in service to the IPv6 community. The deadline for nominations for this year's award is 15 July 2011. The award will be presented at the 82nd meeting of the IETF to be held in November 2011 in Taipei, Taiwan. About the Award The Itojun Service Award was established by the friends of Itojun and administered by the Internet Society (ISOC), recognises and commemorates the extraordinary dedication exercised by Itojun over the course of IPv6 development. The award includes a presentation crystal, a US$3,000 honorarium, and a travel grant. The award is focused on pragmatic technical contributions, especially through development or operation, with the spirit of servicing the Internet. With respect to the spirit, the selection committee seeks contributors to the Internet as a whole; open source developers are a common example of such contributors, although this is not a requirement for expected nominees. While the committee primarily consider practical contributions such as software development or network operation, higher level efforts that help those direct contributions will also be appreciated in this regard. The contribution should be substantial, but could be immature or ongoing; this award aims to encourage the contributor to keep their efforts, rather than just recognizing well established work. Finally, contributions of a group of individuals will be accepted as deployment work is often done by a large project, not just a single outstanding individual. The award is named after Dr. Jun-ichiro Itojun Hagino, who passed away in 2007, aged just 37. Itojun worked as a Senior Researcher at Internet Initiative Japan Inc. (IIJ), was a member of the board of the Widely Integrated Distributed Environment (WIDE) project, and from 1998 to 2006 served on the groundbreaking KAME project in Japan as the IPv6 samurai. He was also a member of the Internet Architecture Board (IAB) from 2003 to 2005. For additional information on the award, please visit http://www.isoc.org/awards/itojun/ Award Nomination Procedure Neither the nominee nor nominator needs to be a member of ISOC. Nominate via email to itojun-award at elists.isoc.org and include the following details: 1. Name and Email address of nominee (in case of a group nominee, names and Email addresses of representative persons of that group) 2. CV/Bio of nominee (in case of a group nominee, a summary of the group's achievements) 3. Statement of recommendation including specific acts, works, contributions, and other criteria that would show the nominee to fit the standard set by Itojun. Please include corroborating references with their name, email address, and telephone number. Conclude with your affiliation, postal address, and telephone number as well as the postal address, telephone and fax number of the nominee. Thank you in advance for your support, Jun Murai Itojun Service Award Selection Committee ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-12: Call for Volunteers
The IETF nominating committee process for 2011-12 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better the chance we have of choosing a random yet representative cross section of the IETF population. The details of the nomcom process can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out (i.e. IETF76-IETF80). If you qualify, and are not seeking appointment to any of the open positions this nomcom will be filling, please consider volunteering. The list of people and posts whose terms end with the March 2012 IETF meeting, and thus the positions for which the nominating committee is responsible, are as follows: IAB === Bernard Aboba Hannes Tschofenig Andrei Robachevsky Olaf Kolkman Spencer Dawkins Ross Callon IAOC Marshall Eubanks IESG Peter Saint-Andre (Applications) Jari Arkko (Internet) Dan Romascanu (Operations Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) David Harrington (Transport) The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krish...@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag RESEND: added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-ch...@ietf.org, suresh.krish...@ericsson.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
