IPv6 consumer perception
With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems. http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent... It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed. The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off. - Zed
On Jun 18, 2010, at 12:04 PM, Zed Usser wrote:
With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems.
http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent...
It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed.
The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off.
I think that the idea that your communications are purely anonymous is something that has been put out there by people that do not get the technology. I recall explaining to some nice folks at the Secret Service back in the 90's where some emails came from, and how to actually get in contact with the real person who made threats against the president. Do these people take their license plates off their cars while they drive on the streets, or scratch out their VINs? To think it's impossible to determine attribution on the internet is foolish. - Jared (While there are legal torrents, and that's *surely* the only reason for piratebay to be used, it does not excuse the criminal activity if you *think* you can't be tracked).
On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote:
In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01
There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64" http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? - Zed
On 18 feb 2011, at 9:24, Zed Usser wrote:
Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.)
You forget: - no IPv6 tunnels Deploying NAT444 without IPv6 is a very bad thing.
On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser <zzuser@yahoo.com> wrote:
Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
I'd compare it with borrowing some money: When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month. Both are borrowing. Depending on the circumstances you may need both. cheers, andrew
On Feb 18, 2011, at 3:33 AM, Andrew Yourtchenko wrote:
On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser <zzuser@yahoo.com> wrote:
Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
I'd compare it with borrowing some money:
When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month.
Both are borrowing.
Depending on the circumstances you may need both.
cheers, andrew
If you are in a circumstance where you need to borrow money this month to repay your debt from last month, then, generally, you are on the fast track to bankruptcy court or a congressional investigation, perhaps both, depending on the size of debt snowball you are able to build. In the first case, you borrow money to leverage equity and there is a reasonable chance that by the time you pay off the loan, the value of what you built exceeds the amount borrowed. In the second case, you end up in a lather-rinse-repeat process where your debt load continues to grow and grow until it overpowers you. It's a good analogy, but, the second form of borrowing is far worse than the first. Owen
On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote:
In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01
There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.
"draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:
* NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64"
I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful.
http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :)
I guess that depends on whether you like having customers or not.
Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.)
You might take a hit on online gaming, but what else is there not to love? :)
+ More support phone calls + More unhappy customers + More cancellations + Less revenue + More costs + CALEA joy
Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way.
An interesting theory.
Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. Owen
--- On Fri, 2/18/11, Owen DeLong <owen@delong.com> wrote:
Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely.
Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution?
Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. - Zed
On Feb 18, 2011, at 7:34 AM, Zed Usser wrote:
--- On Fri, 2/18/11, Owen DeLong <owen@delong.com> wrote:
Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely.
That depends on the number of IPv4 only networks vs. dual stack networks when that happens.
Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution?
Dual stacking all the IPv4 networks is the alternative solution. Initially it will be the IPv6 only users that are lonely. Relatively quickly, it will be the IPv4 only networks that are lonely as the bulk of users will, I suspect, become IPv6 preferred relatively quickly once there is no more IPv4 at the RIR level.
Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT.
I think that effort spent trying to solve those problems is better spent moving existing IPv4 things forward to dual stack. You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Move them to dual stack and the problem goes away. Owen
--- On Sat, 2/19/11, Owen DeLong <owen@delong.com> wrote:
You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts?
- Zed
On Feb 18, 2011, at 12:50 PM, Zed Usser wrote:
--- On Sat, 2/19/11, Owen DeLong <owen@delong.com> wrote:
You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts?
- Zed
No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. Owen
--- On Sat, 2/19/11, Owen DeLong <owen@delong.com> wrote:
Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way?
- Zed
On Feb 19, 2011, at 12:41 AM, Zed Usser wrote:
--- On Sat, 2/19/11, Owen DeLong <owen@delong.com> wrote:
Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way?
- Zed
I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. I'm advocating not expending significant development resources on enhancing that situation when it's pretty clear they are better spent facilitating IPv6 deployment to obviate the need for this level of hackery. Owen
--- On Sun, 2/20/11, Owen DeLong <owen@delong.com> wrote:
So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way?
I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words.
This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. - Zed
On Feb 19, 2011, at 11:31 AM, Zed Usser wrote:
--- On Sun, 2/20/11, Owen DeLong <owen@delong.com> wrote:
So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way?
I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words.
This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold.
- Zed
Oh, I expect CGN/LSN to be connectivity of last resort, no question. However, I don't expect it to work. I don't expect us to be able to resolve the issues with it, and I expect that to fairly rapidly serve as motivation for content providers to adopt IPv6. Owen
--- On Sun, 2/20/11, Owen DeLong <owen@delong.com> wrote:
Oh, I expect CGN/LSN to be connectivity of last resort, no question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier.
- Zed
On Feb 20, 2011, at 3:27 AM, Zed Usser wrote:
--- On Sun, 2/20/11, Owen DeLong <owen@delong.com> wrote:
Oh, I expect CGN/LSN to be connectivity of last resort, no question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier.
- Zed
Again, I think that it is unfixable and that development efforts are better focused on getting the IPv4 only hosts onto IPv6 as that IS a workable solution to the problem where NAT444 is an awful hack made worse by layering. IPv6 deployment is the only thing that will cut down on the operational and support issues enumerated. Trying to fix NAT444 is like trying to use more gas to get yourself out of the mud in a 2-wheel drive automobile. If you take a limited view, you might think that pushing harder will help, but, in reality, you're just digging a deeper hole. Owen
On 18 Feb 2011, at 20:55, "Zed Usser" <zzuser@yahoo.com> wrote:
--- On Sat, 2/19/11, Owen DeLong <owen@delong.com> wrote:
You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts?
- Zed
IPv6 only hosts are a good thing to speed up v6 adoption. Nothing like a good carrot to get the donkeys moving. -- Leigh
On Fri, Feb 18, 2011 at 2:31 PM, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
...
IPv6 only hosts are a good thing to speed up v6 adoption. Nothing like a good carrot to get the donkeys moving.
-- Leigh
Well, speaking of carrots...a few years back we _did_ have http://ipv6experiment.com/ though, unfortunately, the original content of the experiment has changed somewhat, and the delta between the A record and the quad-A has diminished. :/ Would be nice to see if someone was willing to host some v6-only content, and see what level of penetration was achieved... Matt
On Fri, Feb 18, 2011 at 10:34 AM, Zed Usser <zzuser@yahoo.com> wrote:
Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely.
I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads. Since these search engine companies have figured out white-listing users into "good IPv6," it's no great leap to suggest that they'll eventually black-list IPv4 users into "bad," and tie that into their advertising system for ISPs to purchase nicely-targeted banners/links. If my ISP is reading this, please tell both your residential and business technical and sales departments to come up with a better answer than "we are not going to support IPv6 because that's only for ISPs that run out of IPv4." Otherwise, I'd bet Google will be more than willing to let your competitors give customers a different answer in the near future! -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
From: Jeff Wheeler Sent: Friday, February 18, 2011 8:13 AM To: nanog@nanog.org Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...)
I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads.
One thing they can do, and I would live to see some popular destination site do this, is to say something like: "we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only". That would result in eyeballs demanding access to that content and nothing drives innovation like customer demand does.
Given that virtually all of the "popular" applications are ignorant of the underlying infrastructure I don't see this happening. Its simply too expensive to build something and not get it in front of as many eyeballs as possible even (perhaps especially) if your application is free (ad supported). We've only seen the large scale shift to applications really being mobile aware in the last few years. Anyone else remember when WAP was supposed to (and didn't) make a huge splash on mobile web use?
One thing they can do, and I would live to see some popular destination site do this, is to say something like:
"we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only".
That would result in eyeballs demanding access to that content and nothing drives innovation like customer demand does.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Fri, Feb 18, 2011 at 10:14:04AM -0800, George Bonser wrote:
From: Jeff Wheeler Sent: Friday, February 18, 2011 8:13 AM To: nanog@nanog.org Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...)
I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads.
One thing they can do, and I would live to see some popular destination site do this, is to say something like:
"we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only".
That would result in eyeballs demanding access to that content and nothing drives innovation like customer demand does.
You never been told something like "We don't do (or stock) that because there's no demand for it! You know, you're the Nth person to ask about it today." I have, and many more times than merely once. -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
You never been told something like "We don't do (or stock) that
because
there's no demand for it! You know, you're the Nth person to ask about it today." I have, and many more times than merely once.
-- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
Right, so what it takes is someone out there to create the demand. It would actually be a great public service if someone were to do that. Some social networking, gaming, or some other sort of site that only the "cool kids" can access via v6, maybe. Nothing drives people nuts more than knowing there is something out there that they can't access. Create something like that AND generate some buzz surrounding it, particularly if someone hears people talking about it and they can't access it themselves to see what the buzz is all about, and you have just built the required demand for v6 migration. It is going to take v6-only content to do that, I think. Frankly, a v6 only service is easier to build and deploy. Dual stacking causes problems with many applications, if it is native v6 and v6 only, it removes a lot of the "issues" with v6 migration.
http://www.jetcafe.org/~npc/isp/large.html If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only. I think google and others will notice some serious traffic happening. It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles. If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core. Toute connaissance est une réponse à une question
On 2/18/2011 1:53 PM, Franck Martin wrote:
http://www.jetcafe.org/~npc/isp/large.html
If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.
I think google and others will notice some serious traffic happening. We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems.
It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.
Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does.
If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.
I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
----- Original Message -----
From: "Scott Helms" <khelms@ispalliance.net> To: nanog@nanog.org Sent: Saturday, 19 February, 2011 8:07:54 AM Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) On 2/18/2011 1:53 PM, Franck Martin wrote:
http://www.jetcafe.org/~npc/isp/large.html
If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.
I think google and others will notice some serious traffic happening. We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems.
May be, may be not, but yes non of them are ready like free did to "switch on" IPv6 on their CPE. US ISPs have been caught their pants down. It is going to be ugly.
It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.
Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does.
Yes there is no demand from consumers, but a consumer on IPv6 is a consumer on IPv6, and that will happen with IPv4 depletion, now once we reach 10% of them, then web analytic tools and email marketing tools and anything that tracks consumer behavior will have to be IPv6 compliant. You don't want to ignore 10% of your consumers, and that was my point. Google IPv6 traffic is at 0.3%, nice, but hardly significant to have a boss to ask: "I want those IPv6 consumers counted". I'm looking at where is the critical mass point, when the machine will work on itself, I say 10%.
If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.
I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate.
Sure on IPv6 day they won't light up all their customers, but they made a commitment to be there sooner than later. And yes it is a media event where many companies are saying me too, we are ready, or about to! Or "it will be in next release" which is better than "gosh, there is no demand for that and you are the first one to ask me", which is better than "it will fail".
On Feb 18, 2011, at 11:07 AM, Scott Helms wrote:
On 2/18/2011 1:53 PM, Franck Martin wrote:
http://www.jetcafe.org/~npc/isp/large.html
If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.
I think google and others will notice some serious traffic happening. We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems.
If by years, you mean 18 months and by tiny fraction you mean more than 10%, then, sure, you are correct.
It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.
Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does.
I'm betting that after IPv4 runout, users will continue to perceive a benefit in making the choice to connect to the internet even though they cannot get a unique IPv4 address.
If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.
I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate.
The problem with this type of belief is that it serves to incite others to inaction, leading it to become a self-fulfilling prophecy. Owen
On Fri, Feb 18, 2011 at 12:07, Scott Helms <khelms@ispalliance.net> wrote:
We don't have a situation where the existing infrastructure doesn't work, it does.
It does today. IPv4 addresses are still freely available today though. As soon as we introduce LSN, the infrastructure starts to stop working. When that happens, IPv6 will have demand. Hopefully we can deploy it before then and avoid the brokeness though... Cheers, ~Chris
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
On Feb 18, 2011, at 10:53 AM, Franck Martin wrote:
http://www.jetcafe.org/~npc/isp/large.html
If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only.
I think google and others will notice some serious traffic happening.
Google would probably notice significant traffic increases on IPv6 if they started providing AAAA records to non-white-listed DNS resolvers.
It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles.
If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.
They have not yet deployed to more than a handful of trial customers. In fact, I think TW has not yet started their trials.
For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core.
It's just short of 9% today and climbing rapidly.
Toute connaissance est une réponse à une question
The trick is combining the correct knowledge with the right question. Owen
In message <EFD65FF5-12C8-49BE-8243-F081949A5A08@genius.com>, Franck Martin wri tes:
http://www.jetcafe.org/~npc/isp/large.html
If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 m = illion subscribers in the US only.
I think google and others will notice some serious traffic happening.
It took a market share of 10 to 20% of Mozilla for web developers to go back= to support ALL browsers. Same for mobile web site a 10% surfing rate got ma= ny companies to develop web sites for mobiles.
If I recall Comcast and Time Warner are participating in IPv6 day. This shou= ld create enough eyeballs to show on web analytics graph and provide the shi= ft that makes nat444 irrelevant.
Comcast and Time Warner can enable it, they can't however turn it on in many cases as it requires the customer to do something.
For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passe= s 10% we will have a snow ball effect in the core.
Toute connaissance est une r=C3=A9ponse =C3=A0 une question
=20
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Feb 18, 2011 at 10:42 AM, George Bonser <gbonser@seven.com> wrote:
You never been told something like "We don't do (or stock) that
because
there's no demand for it! You know, you're the Nth person to ask about it today." I have, and many more times than merely once.
-- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
Right, so what it takes is someone out there to create the demand. It would actually be a great public service if someone were to do that. Some social networking, gaming, or some other sort of site that only the "cool kids" can access via v6, maybe.
Nothing drives people nuts more than knowing there is something out there that they can't access. Create something like that AND generate some buzz surrounding it, particularly if someone hears people talking about it and they can't access it themselves to see what the buzz is all about, and you have just built the required demand for v6 migration. It is going to take v6-only content to do that, I think. Frankly, a v6 only service is easier to build and deploy. Dual stacking causes problems with many applications, if it is native v6 and v6 only, it removes a lot of the "issues" with v6 migration.
100% agree. No volunteers yet for making their awesome new service IPv6-only :(
You can't get yourself an IPv6 Sage certification if you aren't running IPv6. http://tunnelbroker.net Owen On Feb 18, 2011, at 10:42 AM, George Bonser wrote:
You never been told something like "We don't do (or stock) that
because
there's no demand for it! You know, you're the Nth person to ask about it today." I have, and many more times than merely once.
-- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
Right, so what it takes is someone out there to create the demand. It would actually be a great public service if someone were to do that. Some social networking, gaming, or some other sort of site that only the "cool kids" can access via v6, maybe.
Nothing drives people nuts more than knowing there is something out there that they can't access. Create something like that AND generate some buzz surrounding it, particularly if someone hears people talking about it and they can't access it themselves to see what the buzz is all about, and you have just built the required demand for v6 migration. It is going to take v6-only content to do that, I think. Frankly, a v6 only service is easier to build and deploy. Dual stacking causes problems with many applications, if it is native v6 and v6 only, it removes a lot of the "issues" with v6 migration.
On Fri, Feb 18, 2011 at 1:14 PM, George Bonser <gbonser@seven.com> wrote:
One thing they can do, and I would live to see some popular destination site do this, is to say something like:
"we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only".
I doubt any top web sites or popular services will do this, because there is no commercial advantage to it. It is great to see Google, Yahoo, and other companies taking a big step by deciding to serve up AAAA by default for one day. It also should indicate to everyone how far we are from the goal line, not because Google or Yahoo aren't doing their homework, but because their end-users' ISPs aren't. If these companies are only willing to do AAAA by default for one day on a trial basis, and that with months of notice and perhaps preparation, they clearly should not be willing to make some cool new revenue-generating feature exclusive to IPv6 end-users. On Fri, Feb 18, 2011 at 1:53 PM, Franck Martin <franck@genius.com> wrote:
If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant.
I am afraid you may be a little disappointed. The number of users with IPv6-capable CPE, to say nothing of home LANs, may still be quite limited by that time. It's still progress, but I don't think anything except IPv4 depletion will increase IPv6 adoption.
For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core.
Unfortunately, many ASNs who originate IPv6 address space have few or no functioning services on IPv6. A simple "ASN ratio" is not a very useful metric. You also do not have visibility into how much infrastructure is based on tunnels, whether or not v6 even reaches customer access ports or even is enabled backbone-wide, etc. I agree it is encouraging to see new ASNs originating IPv6 routes every day, but again, this is more an indicator of "we got a /32 from the RIR and configured it on our router" than "we are using v6 in a production capacity (or are prepared to flip the switch.)" I really do think that advertising may be the thing that eventually forces some end-user ISPs to get in gear. If end-users went to www.google.com on "IPv6 day" (and perhaps after) and got a message saying "your ISP is great" or "here are some ISPs you might want to consider, because yours can no longer reach some Internet destinations," I suspect that would give ISPs a very serious reason to spend the necessary resources to get v6 done. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Feb 18, 2011, at 10:14 AM, George Bonser wrote:
From: Jeff Wheeler Sent: Friday, February 18, 2011 8:13 AM To: nanog@nanog.org Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...)
I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads.
One thing they can do, and I would live to see some popular destination site do this, is to say something like:
"we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only".
That would result in eyeballs demanding access to that content and nothing drives innovation like customer demand does.
Eyeball demand on ISPs will _NOT_ be the lagging problem in IPv6 deployment. The consumer side laggage will be CPE and Consumer Eelectronics. Consumer ISPs are going to be the first ones forced to put subscribers on IPv6 whether they're ready or not because: + Residential Internet Services is the single largest address consumer + They pay less for their services than any other class of user + In many cases they have few or no choices in provider selection + They provide the narrowest margins These factors mean that providers that are strictly residential will run out of addresses faster than other providers. Providers which are in multiple lines of business, including residential are likely to start harvesting residential addresses for higher-paying services. The question is whether content providers will recognize and prepare for this reality before it arrives, or, react to it afterwards. Owen
On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:
On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.
"draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:
* NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64"
I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful.
The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.
http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :)
I guess that depends on whether you like having customers or not.
Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. Cheers, -Benson
On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote:
On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:
On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.
"draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:
* NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64"
I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful.
The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.
NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate.
http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :)
I guess that depends on whether you like having customers or not.
Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).
I remain unconvinced of the accuracy of this statement.
Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution.
Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application providers that their customer experience in a NAT-444 environment is going to suck and they need to deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of having deployed a NAT444 solution in their network. Owen
On Feb 18, 2011, at 4:46 PM, Owen DeLong wrote:
On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote:
The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.
NAT444 is one implementation of CGN and the issues it describes all apply to NAT444.
It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate.
You continue to conflate NAT444 and CGN. I'm not sure I can say anything that hasn't already been said, but perhaps an example will help: Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.
Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).
I remain unconvinced of the accuracy of this statement.
Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity. Cheers, -Benson
On Fri, Feb 18, 2011 at 16:07, Benson Schliesser <bensons@queuefull.net> wrote:
Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.
I don't think that's a great analogy. NAT444 is CGN, the web is not DNS. If I say I can chop down a tree with a red ax, can you disprove that by saying that you can chop it down with any color ax?
Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity.
If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444). Cheers, ~Chris
Cheers, -Benson
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote:
On Fri, Feb 18, 2011 at 16:07, Benson Schliesser <bensons@queuefull.net> wrote:
Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better.
I don't think that's a great analogy. NAT444 is CGN, the web is not DNS. If I say I can chop down a tree with a red ax, can you disprove that by saying that you can chop it down with any color ax?
I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.
If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444).
Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes. Cheers, -Benson
On Fri, Feb 18, 2011 at 16:48, Benson Schliesser <bensons@queuefull.net> wrote:
I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it.
That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies.
So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.
That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?)
If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444).
Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes.
Fair enough, I still have hope. =) ~Chris
Cheers, -Benson
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
On Feb 18, 2011, at 5:59 PM, Chris Grundemann wrote:
On Fri, Feb 18, 2011 at 16:48, Benson Schliesser <bensons@queuefull.net> wrote:
I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it.
That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies.
That's a serious expansion to the testing matrix. I would rather see those other technologies get their own draft with their own testing matrix as this is far more likely to be achievable.
So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion.
That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?)
Agreed.
If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444).
Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes.
Fair enough, I still have hope. =) ~Chris
My thinking is that faced with disconnection after the fact suddenly causing me to choose between restoration by dual stacking vs. restoration by NAT444 (or almost any other form of LSN) leads any sane person to restoration by dual stacking. Owen
On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser <zzuser@yahoo.com> wrote:
Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :)
Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way.
Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase "won't care either way" Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the "always on" feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / "All dialin 'lines are busy'" / "Please use IPv6 while you wait, wait 10 minutes and try dialing in again", if there are no global IPv4 IPs available at the moment they are trying to connect. Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness; possibly with a customer choice between NAT444 and "time metered dynamic unique IP" and reasonably automatic simple means of switching between IP types on demand. -- -JH
On Feb 20, 2011, at 10:35 PM, Jimmy Hess wrote:
On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser <zzuser@yahoo.com> wrote:
Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but:
Actually, many facebook and youtube features will also be degraded.
- Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :)
You're joking, right? I don't think that most customers are going to take kindly to having their internet experience on their computer(s) reduced to what they expect from their cell phone.
Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way.
Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase "won't care either way"
Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations
Nah... Just make sure tweeting is one of the things you break along with the rest of the itner-tubes. (joking, of course).
For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the "always on" feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / "All dialin 'lines are busy'" / "Please use IPv6 while you wait, wait 10 minutes and try dialing in again", if there are no global IPv4 IPs available at the moment they are trying to connect.
As long as you give them IPv6, their Netflix and Youtube will work.
Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness;
You guys are making me very very glad that I: 1. Do not depend on my provider for IPv4 addresses. 2. Have a fully dual-stack environment at home. 3. Do not depend on my residential provider to deliver anything more than the ability to shove GRE across the internet encapsulated in whatever protocol (v4/v6) works at the time.
possibly with a customer choice between NAT444 and "time metered dynamic unique IP" and reasonably automatic simple means of switching between IP types on demand.
I encourage my competitors to try this. Owen
On 18 jun 2010, at 18:04, Zed Usser wrote:
With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems.
http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent...
It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed.
The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off.
Why do people still think consumers 'want IPv6', they want IPv6 as much as they want IPv4. They don't know what an IP addresses is, let alone will grasp the whole idea there are 2 kinds. All they want is their googles, facebooks, twitters and the occasional download to work (of course nobody would admit to filesharing). And it's our job to make it so, wether it's via IPv6 or CGN. In the end they won't have much choice and if we do our jobs correctly, 95 % of them won't even notice. Just my 2 cents, MarcoH
I'd really like to talk to the guy who presented this. Does anyone happen to have a contact for him? Feel free to send it privately if you do. Sean -----Original Message----- From: Marco Hogewoning [mailto:marcoh@marcoh.net] Sent: Friday, June 18, 2010 10:48 AM To: nanog@merit.edu Subject: Re: IPv6 consumer perception On 18 jun 2010, at 18:04, Zed Usser wrote:
With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems.
http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent...
It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed.
The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off.
Why do people still think consumers 'want IPv6', they want IPv6 as much as they want IPv4. They don't know what an IP addresses is, let alone will grasp the whole idea there are 2 kinds. All they want is their googles, facebooks, twitters and the occasional download to work (of course nobody would admit to filesharing). And it's our job to make it so, wether it's via IPv6 or CGN. In the end they won't have much choice and if we do our jobs correctly, 95 % of them won't even notice. Just my 2 cents, MarcoH
participants (19)
-
Andrew Yourtchenko -
Benson Schliesser -
Cameron Byrne -
Chris Grundemann -
Franck Martin -
George Bonser -
Iljitsch van Beijnum -
Jared Mauch -
Jeff Wheeler -
Jimmy Hess -
Leigh Porter -
Marco Hogewoning -
Mark Andrews -
Matthew Petach -
mikea -
Owen DeLong -
Scott Helms -
Sean Siler -
Zed Usser