Big day for IPv6 - 1% native penetration
Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
Or artificially high ... On Tue, Nov 20, 2012 at 8:45 AM, Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
Owen
On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
APNIC labs have an interesting set of numbers on IPv6 uptake as well. http://labs.apnic.net/measureipv6/ On Tue, 20 Nov 2012, Owen DeLong wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
Owen
On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
wfms
So, I assume 6in4 tunnels like HE.net are included in the "native" percentage? Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Tue, Nov 20, 2012 at 9:02 AM, William F. Maton Sotomayor <wmaton@ottix.net> wrote:
APNIC labs have an interesting set of numbers on IPv6 uptake as well.
http://labs.apnic.net/measureipv6/
On Tue, 20 Nov 2012, Owen DeLong wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
Owen
On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
wfms
Hi,
So, I assume 6in4 tunnels like HE.net are included in the "native" percentage?
As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6. - Sander
On Nov 20, 2012, at 7:06 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi,
So, I assume 6in4 tunnels like HE.net are included in the "native" percentage?
As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6.
- Sander
That's only really true of the 6in4 (tunnel broker) tunnels. The 6to4 traffic that comes through our 6to4 or any other 6to4 gateways, OTOH, will have 2002::/16 addresses which makes it just as obvious as Teredo. Owen
Dr. Frederick Frankenstein: LIFE! DO YOU HEAR ME? GIVE MY CREATION... LIFE!
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
* Oliver Garraux
So, I assume 6in4 tunnels like HE.net are included in the "native" percentage?
Probably. Fortunately, they are a drop in the ocean (at least from my point of view). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
6to4 tunnels, no. 6in4 (such as tunnel broker), yes, those are part of the native count. Owen On Nov 20, 2012, at 6:57 AM, Oliver Garraux <oliver@g.garraux.net> wrote:
So, I assume 6in4 tunnels like HE.net are included in the "native" percentage?
Oliver
-------------------------------------
Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux
On Tue, Nov 20, 2012 at 9:02 AM, William F. Maton Sotomayor <wmaton@ottix.net> wrote:
APNIC labs have an interesting set of numbers on IPv6 uptake as well.
http://labs.apnic.net/measureipv6/
On Tue, 20 Nov 2012, Owen DeLong wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
Owen
On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
wfms
On Nov 20, 2012, at 08:45 , Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
AMS-IX publishes stats too: <https://stats.ams-ix.net/sflow/> This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? -- TTFN, patrick
On Nov 20, 2012, at 5:31 AM, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
And given the rate on that graph, we'll hit 2% before year-end 2013.
-- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
On 20 November 2012 16:05, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Nov 20, 2012, at 08:45 , Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
AMS-IX publishes stats too: <https://stats.ams-ix.net/sflow/>
This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%.
Why do you think Google's numbers are lower than the real total?
They are also different stats which is why they give such different numbers. In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6. If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. - Mike
On Nov 20, 2012, at 11:42 , Mike Jones <mike@mikejones.in> wrote:
On 20 November 2012 16:05, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Nov 20, 2012, at 08:45 , Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
AMS-IX publishes stats too: <https://stats.ams-ix.net/sflow/>
This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%.
Why do you think Google's numbers are lower than the real total?
They are also different stats which is why they give such different numbers.
In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6.
If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement.
There is even more complexity. Remember the 6-to-4 stuff? Suppose a user on Network A used a tunnel broker on HE, and his traffic passed over AMS-IX encapsulated in v4? He would show up as v4 to AMS-IX and v6 to Google. Lies, damned lies, and graphs. :) -- TTFN, patrick
On 20 Nov 2012, at 16:42, Mike Jones <mike@mikejones.in> wrote:
If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement.
Which ties in with the 50% or so figure you can see at http://6lab.cisco.com/stats/. tim
While looking into the NTP chaos from Monday, I noticed that my personal servers have an NTP peer running IPv6. I have no idea how long that's been going on - it was a complete non-event ;). -- Harald
Mike Jones wrote:
On 20 November 2012 16:05, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Nov 20, 2012, at 08:45 , Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
AMS-IX publishes stats too: <https://stats.ams-ix.net/sflow/>
This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%.
Why do you think Google's numbers are lower than the real total?
They are also different stats which is why they give such different numbers.
In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6.
If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement.
If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? Tony
On Nov 20, 2012, at 14:44 , "Tony Hain" <alh-ietf@tndh.net> wrote:
If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June???
"If you assume...". Kinda says it all right there. But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries. -- TTFN, patrick
We have numbers to share. We have performed two experiments at two different events LACNIC held this year: - June in Port-Au-Prince (~110 attendees) - October in Montevideo (~400 attendees) The question was: "What is the relation between IPv4 and IPv6 traffic in a fully dual-stacked network?". The answers were remarkably consistent. We got ~30% IPv6 in PAP and around 33% in MVD (actually in MVD we got over 40% in total byte counts, but we corrected for the IPv6 video feed that added a constant 1 Mbps/sec) This percentage is calculated as: 100*(bytes sent and received over IPv6) / (total bytes sent and received) In PAP we measured this using iftop and a couple of pcap filters on the Linux server we were using as 'router' (Owen was there and was of great help setting the whole thing up). In MVD we had a dual 7201s as routers and we measured traffic with Netflow. Warm regards, ~Carlos On 11/21/12 12:51 AM, Patrick W. Gilmore wrote:
On Nov 20, 2012, at 14:44 , "Tony Hain" <alh-ietf@tndh.net> wrote:
If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June???
"If you assume...". Kinda says it all right there.
But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries.
On 21/11/2012, at 3:05 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Nov 20, 2012, at 08:45 , Owen DeLong <owen@delong.com> wrote:
It is entirely possible that Google's numbers are artificially low for a number of reasons.
AMS-IX publishes stats too: <https://stats.ams-ix.net/sflow/>
This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%.
Why do you think Google's numbers are lower than the real total?
It depends on what you are trying to measure and how you are measuring it. I don't know Google's methodology, but lets say its a simple form of the experiment: "When presented with a dual stack object what percentage of users prefer to retrieve that object using IPv6 as compared to IPv4?" Up so a year or so ago if a browser had access to IPv6 and IPv4 it would first attempt to connect using IPv6 and if the connection failed then it timed out and then tried to use IPv4. So the experiment would be roughly commensurate with measuring working IPv6 systems on end sites connected to workin ipv6 access networks of one sort or another. More recently some browsers (Safari on Mac OSX, Chrome, Firefox with config settings enabled) have adopted a different strategy and when presented with a dual stack object some clients may end up trying the connection using IPv4 first and then fall back to IPv6 if IPv4 fails or times out. If the experiment simply counts the percent of clients who prefer to connect using IPv6 in a Dual Stack scenario, then some of these users running more recent versions of the browser will not be counted. There are ways to compensate for this, including running a series of tests, and this form of approach is described at http://labs.apnic.net/measureipv6/ I personally have no knowledge if the numbers published by Google reflect the "prefers to use IPv6 in dual stack mode" or "is capable of using IPv6 (by virtue of being able to retrieve a IPv6 only object)" These days the second number is larger than the first. Geoff
Tomas Podermanski wrote:
Hi,
It seems that today is a "big day" for IPv6. It is the very first time
when
native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
T.
Or one could look at it as; despite 16 years of lethargy and lack of deployment by access networks, the traffic still finds a way. ;) Tony
Tony Hain wrote:
Tomas Podermanski wrote:
Hi,
It seems that today is a "big day" for IPv6. It is the very first time
when
native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
T.
Or one could look at it as; despite 16 years of lethargy and lack of deployment by access networks, the traffic still finds a way. ;)
Tony
I say we better hope and pray that the network effect works as well for IPv6 as it did for IPv4. Otherwise 1% after 16 years represents nothing so much as ongoing failure. I have had approximately 0.01% interest from any user base. That would be an interesting number to watch change. Joe
It won't. Users do not care about IPv6 or IPv4. They want a fast and reliable Internet connection. If you think you can do that with IPv4, you don't need to do anything (well, just plan for some budget for your CGNs). If not, better start deploying IPv6. .as On 21/11/2012 12:40, Joe Maimon wrote:
I have had approximately 0.01% interest from any user base. That would be an interesting number to watch change.
Arturo is right.. Internet users could care less what protocol they use just like most of us could care less if the road we drive to work is asphalt, chip seal, or concrete. We just want it to be smooth and get us where we want to go at the speed we want to drive. I can see some things changing this, however, this sort of thing http://www.greentechmedia.com/articles/read/the-ipv6-addressable-light-bulb-... could make consumers interested in asking for IPv6. Mostly, however, if we're really waiting for folks to ask for it we're going to have to wait a very long time. ----Cathy On Wed, Nov 21, 2012 at 8:27 AM, Arturo Servin <arturo.servin@gmail.com> wrote:
It won't.
Users do not care about IPv6 or IPv4. They want a fast and reliable Internet connection.
If you think you can do that with IPv4, you don't need to do anything (well, just plan for some budget for your CGNs). If not, better start deploying IPv6.
.as
On 21/11/2012 12:40, Joe Maimon wrote:
I have had approximately 0.01% interest from any user base. That would be an interesting number to watch change.
On Nov 23, 2012, at 11:14 , Joe Maimon <jmaimon@ttec.com> wrote:
Arturo Servin wrote:
It won't.
Users do not care about IPv6 or IPv4. They want a fast and reliable Internet connection.
Which likely decreases the network effect.
Joe
I disagree. Because IPv4 will become connected to a progressively smaller fraction of the internet, eventually, users will come to care if we have not provided it for them. However, shame on any of us who allow it to reach that point. Owen
Hello, On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? Paul
On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ?
Purely anecdotally, I can say: Yes. Atleast in my case I have native IPv6 at home and via my mobile devices, but not at my client sites. *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) ... * /TJ
I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up. However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me. I keep pestering my home ISP about turning it on (since their network is now 100% DOCSIS 3), but they just seem to think I'm making up words. One can hope, though. Blair On Tue, Nov 20, 2012 at 11:53 AM, TJ <trejrco@gmail.com> wrote:
On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ?
Purely anecdotally, I can say: Yes. Atleast in my case I have native IPv6 at home and via my mobile devices, but not at my client sites. *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) ... *
/TJ
Hi, On 11/20/12 7:24 PM, Blair Trosper wrote:
I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up.
However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me.
Turning IPv6 on at the basic/core of the infrastructure is the easiest part of the job. However turning IPv6 for customers requires a lot of effort and compromises. Some of the reasons are described in: http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-per... and related presentation: http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresen... Tomas
On 21/11/2012, at 6:17 AM, Tomas Podermanski wrote:
Hi,
On 11/20/12 7:24 PM, Blair Trosper wrote:
I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up.
However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me.
Turning IPv6 on at the basic/core of the infrastructure is the easiest part of the job. However turning IPv6 for customers requires a lot of effort and compromises. Some of the reasons are described in:
http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-per...
and related presentation:
http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresen...
We (Internode), an Australian ISP, have native dual-stack enabled by default (and have done for a while) for almost all new broadband services (ADSL, FTTH, etc.). Our existing customers can turn it on via an online toolbox. All the broadband CPE that we sell, support it. It's largely a non-issue for us now. Most new customers running a 'current' operating system, who buy an ADSL or FTTH service and their modem/router from us, automatically get IPv6 from day dot without even necessarily realising it. We recently passed 5% of our customer base being on IPv6: http://www.internode.on.net/news/2012/10/288.php -- Michael
On 11/20/2012 1:24 PM, Blair Trosper wrote:
However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me.
I keep pestering my home ISP about turning it on (since their network is now 100% DOCSIS 3), but they just seem to think I'm making up words. One can hope, though.
This has partially been a vendor issue, at least for cable providers. Two of the major CMTS vendors (one starts with C, the other A) have had IPv6 related bugs in fairly recent code releases. Both of the MSOs I've worked for have had to delay IPv6 deployment while those vendors get their waterfowl properly aligned. I know we're still waiting for one vendor to get it straightened out. J
We have cable broadband operations using vendor M and we're a little gun-shy because that vendor has lagged the other two with IPv6 support, and when Comcast and TimeWarner began their production IPv6 rollouts on their CMTes it wasn't with vendor M. Frank -----Original Message----- From: Jay [mailto:tech-lists@packet-labs.net] Sent: Tuesday, November 20, 2012 10:52 PM To: nanog@nanog.org Subject: Re: Big day for IPv6 - 1% native penetration On 11/20/2012 1:24 PM, Blair Trosper wrote:
However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me.
I keep pestering my home ISP about turning it on (since their network is now 100% DOCSIS 3), but they just seem to think I'm making up words. One can hope, though.
This has partially been a vendor issue, at least for cable providers. Two of the major CMTS vendors (one starts with C, the other A) have had IPv6 related bugs in fairly recent code releases. Both of the MSOs I've worked for have had to delay IPv6 deployment while those vendors get their waterfowl properly aligned. I know we're still waiting for one vendor to get it straightened out. J
On Tue, Nov 20, 2012 at 11:51:50PM -0500, Jay scribbled: # On 11/20/2012 1:24 PM, Blair Trosper wrote: # >However, I still scratch my head on why most major US ISPs *have* robust # >IPv6 peering and infrastructure and are ready to go, but they have not # >turned it on for their fiber/cable/DSL customers for reasons that are not # >clear to me. # > # >I keep pestering my home ISP about turning it on (since their network is # >now 100% DOCSIS 3), but they just seem to think I'm making up words. One # >can hope, though. # # This has partially been a vendor issue, at least for cable # providers. Two of the major CMTS vendors (one starts with C, the # other A) have had IPv6 related bugs in fairly recent code releases. # Both of the MSOs I've worked for have had to delay IPv6 deployment # while those vendors get their waterfowl properly aligned. I know # we're still waiting for one vendor to get it straightened out. I know it to be a vendor issue for GPON FTTH gear, as well. At least with one major vendor (begins with a C also). They're definitely lagging. We have an IPv6 deployment in the core natively, as well built as our IPv4 infrastructure, and yet nothing on the access side. Any quarter now, I'm still hearing. Until then, we wait, and the pool of IPv4 dwindles. -- Jonathan Towne
On 11/20/12 7:32 AM, Paul Rolland (ポール・ロラン) wrote:
Hello,
On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? from goeff huston's data they have more v6 at home. Paul
On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote:
from goeff huston's data they have more v6 at home.
And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/24/12 8:29 PM, Dobbins, Roland wrote:
On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote:
from goeff huston's data they have more v6 at home. And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. In their defense, they don't know they have ipv4 connectivity either.
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
joel jaeggli (joelja) writes:
On 11/24/12 8:29 PM, Dobbins, Roland wrote:
On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote:
from goeff huston's data they have more v6 at home. And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. In their defense, they don't know they have ipv4 connectivity either.
They don't know it's not real IPv4 either :) But yeah, if Joe Random enables 6to4 on his Airport Express without understanding what it means, it still translates to more IPv6 traffic during evenings and weekend from residential connections. It's be interesting to come up with a metric to compare "inadvertently" vs "on purpose" v6 traffic. Free.fr, for instance, enables v6 by default on their 6th gen freebox (set top box). Is that inadvertent ? For whom ? Phil
Subject: Re: Big day for IPv6 - 1% native penetration Date: Sun, Nov 25, 2012 at 04:29:15AM +0000 Quoting Dobbins, Roland (rdobbins@arbor.net):
On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote:
from goeff huston's data they have more v6 at home.
And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional.
This is excellent! It is not likely that any end-user traffic over IPv4 is intentionally sent over IPv4. It is sent to Facebook. (eh, faceb00c, of course) Likewise, the -4 and -6 options for SSH are there for debugging and fault mitigation, nothing else. I'm quite satisfied that this now is the norm. It's the only way we'll be able to restore e2e on the Internet and evolve beyond simple client-server models like TN3270^H^H^H^Hthe web. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I didn't order any WOO-WOO ... Maybe a YUBBA ... But no WOO-WOO!
My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional.
almost all ip traffic is unintentional. "i want my mtv. money for nothin' and the chicks are free." < from a friend in a big broadband provider > when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. the brick wall is 'smart' tee vees etc, which do not speak v6, and will have a five+ year lifetime. randy
On Nov 26, 2012, at 5:57 PM, Randy Bush wrote:
almost all ip traffic is unintentional.
Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct.
when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix.
'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
What do you mean with "deliberate migration"? Users do not care and they will never have a "deliberate migration". However ISPs do, if the user have IPv6 it is because the ISP deliberate migrate to v6 by enable it in their backbone, networks and user's CPEs. IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. .as On 26/11/2012 09:24, Dobbins, Roland wrote:
On Nov 26, 2012, at 5:57 PM, Randy Bush wrote:
almost all ip traffic is unintentional.
Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct.
when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix.
'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote:
Users do not care and they will never have a "deliberate migration".
I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not.
IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users.
I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, 26 Nov 2012, Dobbins, Roland wrote:
I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not.
We'll all be better off if we all move to IPv6 and don't go the NAT44(44....) road longer than necessary. We can decide we want to wait for everybody else, which means we won't all be better off, ever.
I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise.
Why is that a significant question? If they have IPv6, they will access a significant amount of content via IPv6. If they don't, then it's nothing. I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. There is so little traffic because ISPs do not turn on IPv6. The content is there now. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote:
Why is that a significant question?
It is significant because it provides some rough measure of the relative *importance* of IPv6 connectivity to the users and to the content/app/services networks. We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs. We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes. Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another. I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for them to do so.
If they have IPv6, they will access a significant amount of content via IPv6.
The definition of 'have IPv6' is somewhat nebulous, at present - that's part of the problem.
I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic.
I'm not making that argument.
There is so little traffic because ISPs do not turn on IPv6. The content is there now.
As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play. Again, where're the compelling IPv6-only content/apps/services? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only. Stalemate. Damian
On Mon, Nov 26, 2012 at 06:25:47AM -0800, Damian Menscher wrote:
On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only.
Recently, due to IPv4 scarcity some large mass hosters (OVH, and soon Hetzner) have started to charge for IP use, with pricing probably moving from current 1 EUR/IPv4 address/month to somewhere 2-5 EUR/IPv4 address/month. This price pressure both allows an efficient use of existing networks (by forcing customers to relinquish unused resources) and also will drive adoption of IPv6-only models, as these addresses remain free, for time being.
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content.
Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Hi,
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content.
Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found.
Wow. Nice one! Sander
On 11/26/12 15:53, sthaug@nethelp.no wrote:
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found.
http:///thepiratebay/.se./ipv6/.sixxs.org was popular for a while, when major ISP's in the Netherlands where forced to block 'The Piratebay' overhere in the Netherlands, I believe... -- Marco
Compulsion won't come from IPv6-only content. It will come from IPv6-only users. Any content/apps/service providers who fail to provide for this fact before we reach that point are making a bet-the-business gamble on the theory that NAT44(4...) will somehow scale well beyond what is likely IMHO. When we reach compulsion, it will not happen slowly or gracefully. We will have hit a wall with IPv4 and IPv4 will simply and suddenly stop growing. Likely in a rather graphic and unpleasant way because it will likely be when we hit some form of scaling limit on the NAT infrastructure where it suddenly keels over and IPv4 only users are down for a series of outages while everyone scrambles to remove load from the IPv4 network in order to get it running again. The alternative is to recognize the coming problem, deploy IPv6 proactively to content/apps/services and then wait for ISPs and end-users to catch up and begin using those IPv6 capabilities. Owen On Nov 26, 2012, at 06:25 , Damian Menscher <damian@google.com> wrote:
On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
Again, where're the compelling IPv6-only content/apps/services?
To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only.
Stalemate.
Damian
On Mon, 26 Nov 2012, Dobbins, Roland wrote:
Again, where're the compelling IPv6-only content/apps/services?
There is none. Why is it needed? We need IPv6 to make the Internet continue working and scale for the future. We don't need IPv6 to solve an individuals need, we need it for the long term common good of the Internet. Nobody is going to have IPv6 only content in the near future. This is no reason to have it. Users and content providers are going to be dual stacked. -- Mikael Abrahamsson email: swmike@swm.pp.se
Sent from ipv6-only Android On Nov 26, 2012 5:54 AM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote:
Why is that a significant question?
It is significant because it provides some rough measure of the relative
*importance* of IPv6 connectivity to the users and to the content/app/services networks.
Ipv6 is not important for users, it is important for network operators who want to sustain their business.
We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs.
We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes.
Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another.
I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for
Dont hold your breath. It wont happen, and in the end means nothing. them to do so.
If they have IPv6, they will access a significant amount of content via IPv6.
The definition of 'have IPv6' is somewhat nebulous, at present - that's
Nope. Nobody will leave money on the table by alienating users. part of the problem.
Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective.
I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic.
I'm not making that argument.
Good.
There is so little traffic because ISPs do not turn on IPv6. The content is there now.
As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play.
Again, where're the compelling IPv6-only content/apps/services?
Does not matter. And it will not happen. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). CB
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote:
Ipv6 is not important for users, it is important for network operators who want to sustain their business.
I agree with the first part; not sure I agree with the second part.
Nope. Nobody will leave money on the table by alienating users.
I think it may be possible to make money with compelling IPv6-only content/services/applications.
Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective.
I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks.
Does not matter. And it will not happen.
Proof by repeated assertion doesn't sway me.
The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ?
These are important, yes.
Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype).
It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote:
Ipv6 is not important for users, it is important for network operators who want to sustain their business.
I agree with the first part; not sure I agree with the second part.
Nope. Nobody will leave money on the table by alienating users.
I think it may be possible to make money with compelling IPv6-only content/services/applications.
I disagree, i simply see an additional fee for IPv4 coming about.
Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective.
I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks.
Does not matter. And it will not happen.
Proof by repeated assertion doesn't sway me.
The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ?
These are important, yes.
Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype).
It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have.
In face of your speculation i present to you facts: Google, Yahoo, Facebook, Bing (... other content and app providers) along with many access networks (VZW, Comcast, AT&T DSL, KDDI, DT, Free ...) now have quite meaningful IPv6 deployments. AT&T DSL and VZW LTE are in the millions of subs with IPv6 at this point. These are not the result of an IPv6-only service (i think there was some v6 p2p service at Free), and they are likely also not motivated by Grandma calling up and asking for IPv6 or she is switching providers. Why did they do this? Because IPv4 is run out and NAT is bad. I am not listing my own deployment since we are not default-on for IPv6 yet, but will be RSN. CB
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Mon, Nov 26, 2012 at 12:15 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote:
Ipv6 is not important for users, it is important for network operators
who want to sustain their business.
I agree with the first part; not sure I agree with the second part.
Nope. Nobody will leave money on the table by alienating users.
I think it may be possible to make money with compelling IPv6-only
content/services/applications.
I disagree, i simply see an additional fee for IPv4 coming about.
+1 And that in itself seems like it would make IPv6-reachable things a lot more compelling.
I disagree, i simply see an additional fee for IPv4 coming about. And that in itself seems like it would make IPv6-reachable things a lot more compelling.
could be. but ... i am a consumer end user. i wish to keep my bill down. unless there is a means for the user to exercise a meaningful method of billable v4 use minimization, given that there is still v4-only content out there, there is no economic incentive. randy
On Nov 27, 2012, at 12:15 AM, Cameron Byrne wrote:
NAT is bad.
I agree wholeheartedly with this sentiment. I'm unsure whether or not this is the prevalent view amongst those who control the pursestrings within network operators, however. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Dobbins, Roland wrote:
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote:
Ipv6 is not important for users, it is important for network operators who want to sustain their business.
I agree with the first part; not sure I agree with the second part.
Operators are all free to choose their own planning horizons. History is littered with the remnants of those with limited vision.
Nope. Nobody will leave money on the table by alienating users.
I think it may be possible to make money with compelling IPv6-only content/services/applications.
If you believe that is true you should do it and prove the point. Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches.
Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective.
I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks.
The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to making progress.
Does not matter. And it will not happen.
Proof by repeated assertion doesn't sway me.
It will happen, just not anytime soon. As the access networks get deployed, traffic will shift, so eventually the question about the expense of maintaining an ever more complex IPv4 version of the app to deal with multi-layer nat to support a dwindling user base will have to be answered.
The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ?
These are important, yes.
Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype).
It's my contention that IPv6 won't be widely deployed unless/until end- customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have.
And it is the contention of app developers that they can't make money on an app that that can't reach 99% of the intended user base. The entire point of tunnels is to break this absurd deadlock where access won't deploy without apps and apps won't deploy without access. Instead of getting on with it, there is an ongoing entrenchment and search for the utopian one-size-fits-all zero-cost transition plan. All this does is show how widespread the denial is, where people are refusing to let go of an entire career's worth of 'expertise' to keep up with the technology changes. Fortunately some have moved on, and are deploying despite the extra effort required in the short term. Once there are a substantial number of IPv6 access networks, the traffic volume will shift rapidly and people will start asking why the core is even aware of IPv4. At that point maintaining IPv4 will become the end user's problem, and they will have to find legacy tunnel providers if they want to keep that going. IPv4 won't die, it will just become an edge problem because the only reason to keep it running will be devices with embedded IPv4-only stacks which won't be replaced for 10 years. Tony
On Nov 27, 2012, at 12:38 AM, Tony Hain wrote:
Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches.
AFAICT, most people who actually develop, deploy, and support applications don't do the math at all. It isn't an issue of perceived importance within their worldviews. In fact, it isn't an issue of which most of them are even peripherally aware.
The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to making progress.
Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? Maybe they're hiding in plain sight. But I don't think so. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/26/2012 03:18 PM, Dobbins, Roland wrote:
Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases?
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6. I'm all for bagging on those two, but it seems pretty unjustified here.
How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA?
Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities?
Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. I turned it on and it was pretty much a big ho-hum, cool it works. Mike
On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote:
Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of.
Where are the *deployments*, though? And lighting up IPv6 within enterprises is not a trivial task. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/26/2012 04:24 PM, Dobbins, Roland wrote:
On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote:
Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. Where are the *deployments*, though?
Google and Facebook support ipv6. What more do we need?
And lighting up IPv6 within enterprises is not a trivial task.
Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. Mike
On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote:
Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's.
It's hugely problematic to accomplish internally, never mind for external connectivity. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/26/2012 04:38 PM, Dobbins, Roland wrote:
On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote:
Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. It's hugely problematic to accomplish internally, never mind for external connectivity.
But not because servers and client devices don't support it; they do. Bag on where the problem actually is: the death spiral of network vendors, ISP's and IT departments not wanting to commit and blaming each other. I primarily fault ISP's because they are, you know, the backbone. If they don't commit, the game of chicken continues. Mike
On Nov 27, 2012, at 7:53 AM, Michael Thomas wrote:
If they don't commit, the game of chicken continues.
Right - so, what new capabilities/economies of scale/essential conveniences are made possible by IPv6 but not IPv4, pour encourager les autres? This is not a rhetorical question. I believe it is a very relevant question that most of those who have the most pecuniary interests in ubiquitous IPv6 deployment are not even considering. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/26/2012 03:18 PM, Dobbins, Roland wrote:
Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases?
How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA?
Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities?
How much of a priority? I would say lots for Apple. Have you looked at the current Apple software? It pretty much "just works" on IPv6. IPv6 is on by default on end systems. Airport Extreme is listed as IPv6 compatible by, among other companies, Comcast. In Terminal, open an New Remote Connection to another Mac, do netstat -f inet6 and see that it is an IPv6 connection. Actually, it is more than a priority. It is pretty much a done deal. As for corporate IT departments, it depends on whether management is measured on monthly cash flow or by long term growth. I must note that many corporate IT departments have evolved from "No one gets fired for buying IBM." to "One might get fired for not buying Microsoft." This also automatically brings along IPv6 capabilities. <DIGRESSION> Elsewhere it has been said that end users don't care about IPv6. Well, that is generally true. They also don't care about IPv4, DOCSIS 3, ATM, PPPOE, and lots of other technical acronyms. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. To meet these expectations in a long term cost-effective manner, it behooves us network and content providers to remove all IPv4-forced hacks impeding easy end-system to end-system connections like all those 'wonderful' variants of NAT and artificially high pricing for IPv6. When the marketing folks begins to treat IPv6 as a sales enabler rather than a fanciful cost item, then we may see accelerated deployment of IPv6 alongside IPv4. </DIGRESSION>
On Nov 27, 2012, at 7:27 AM, Cutler James R wrote:
Have you looked at the current Apple software? It pretty much "just works" on IPv6.
Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4.
This also automatically brings along IPv6 capabilities.
Capabilities <> deployment. Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it.
What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family.
And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Nov 26, 2012, at 7:47 PM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Nov 27, 2012, at 7:27 AM, Cutler James R wrote:
Have you looked at the current Apple software? It pretty much "just works" on IPv6.
Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4.
This also automatically brings along IPv6 capabilities.
Capabilities <> deployment.
Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it.
What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family.
And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks.
The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before.
My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus.
Well, at least you and I agree that IPv6 and IPv4 are simply Layer 3 protocols. Regarding "there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6", your viewpoint ignores the millions and millions of end users/systems which will join networks around the globe in the near future. Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. Please note that this does not imply instant turndown of existing IPv4.
On Nov 27, 2012, at 8:07 AM, Cutler James R wrote:
Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space.
Our views differ in that it is my belief that said truly horrendous and costly mismanagement of IPv4 address space is the norm now and will continue to be the norm for the foreseeable future, absent some positive economic stimulus to do otherwise.
From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned.
When considering the entire value chain of Internet connectivity, I'm not sure if that's a true statement, or that it will become a true statement in the foreseeable future.
Please note that this does not imply instant turndown of existing IPv4.
Which is part of the problem. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, 26 Nov 2012, Michael Thomas wrote:
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6.
Not on the mobile side. Wifi yes, mobile no.
I'm all for bagging on those two, but it seems pretty unjustified here.
What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access. -- Mikael Abrahamsson email: swmike@swm.pp.se
In message <alpine.DEB.2.00.1211270558340.27834@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Mon, 26 Nov 2012, Michael Thomas wrote:
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6.
Not on the mobile side. Wifi yes, mobile no.
I'm all for bagging on those two, but it seems pretty unjustified here.
What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access.
One could just start adding negative reviews to any product that doesn't work in a IPv6 only network.
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Nov 26, 2012 at 9:34 PM, Mark Andrews <marka@isc.org> wrote:
In message <alpine.DEB.2.00.1211270558340.27834@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Mon, 26 Nov 2012, Michael Thomas wrote:
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6.
Not on the mobile side. Wifi yes, mobile no.
I'm all for bagging on those two, but it seems pretty unjustified here.
What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access.
One could just start adding negative reviews to any product that doesn't work in a IPv6 only network.
Yes, you can start your reviews on Android with Skype, Netflix, and Spotify all fail to work in an IPv6-only NAT64/DNS64 3G/4G network This list needs to be updated, but it is a fair starting point https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5... It is also worth noting that folks can certainly test IPv6-only apps using T-Mobile in the USA https://sites.google.com/site/tmoipv6/lg-mytouch, that's just one data point. And, 464XLAT on Android does enable these broken application to work correctly on an IPv6-only NAT64/DNS64 network http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 464XLAT and IPv6 tethering code for Android here http://dan.drown.org/android/clat/ CB
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 11/26/12 8:59 PM, Mikael Abrahamsson wrote:
On Mon, 26 Nov 2012, Michael Thomas wrote:
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6.
Not on the mobile side. Wifi yes, mobile no.
You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular).
I'm all for bagging on those two, but it seems pretty unjustified here.
What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access.
Is this the app's fault? What are they doing wrong? Mike
On Tue, Nov 27, 2012 at 11:28 AM, mike <mike@mtcc.com> wrote:
On 11/26/12 8:59 PM, Mikael Abrahamsson wrote:
On Mon, 26 Nov 2012, Michael Thomas wrote:
I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6.
Not on the mobile side. Wifi yes, mobile no.
You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular).
I'm all for bagging on those two, but it seems pretty unjustified here.
What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access.
Is this the app's fault? What are they doing wrong?
Yes, it is the app's fault. They are either doing IPv4 literals or IPv4-only sockets The IPv4 literal issues is when they do "wget http://192.168.1.1" ... hard coding IPv4 addresses... instead of using an FQDN like "wget http://example.com". Using an FQDN allows the DNS64 to work correctly. The IPv4 literals fail since the IPv6-only host do not have an ipv4 address to bind to or an ipv4 route to follow. This is the issue that i believe Skype has ... since they use IPv4 addresses as part of their signalling. Another one is the URL re-director http://cs.co at Cisco. For example http://cs.co/6017pZhN will bounce you via an IPv4 address literal .... which means an IPv6-only user gets a webpage that tries to load an IPv4 address and fails. The other issue is that the developers choose to use IPv4-only socket APIs instead of a generic network socket APIs that would allow v4 or v6. This is usually an education issue. This is what i think is wrong with the Netflix Android app, they tried to do some low level network tweaks using the Android NDK but in doing these tweaks they only used IPv4 socket APIs and fail to work on IPv6 natively or via NAT64/DNS64. CB
Mike
On 11/27/2012 11:58 AM, Cameron Byrne wrote:
On Tue, Nov 27, 2012 at 11:28 AM, mike <mike@mtcc.com> wrote:
Is this the app's fault? What are they doing wrong?
Yes, it is the app's fault.
They are either doing IPv4 literals or IPv4-only sockets
The IPv4 literal issues is when they do "wget http://192.168.1.1" ... hard coding IPv4 addresses... instead of using an FQDN like "wget http://example.com". Using an FQDN allows the DNS64 to work correctly.
I can understand spotify, but don't really understand why waze would have a problem unless they're doing some sort of rendezvous like protocol that embeds ip addresses. That said, I'd say that the vast majority of apps don't have this sort of problem and will quite unknowingly and correctly work with v6. Mike
On Tue, Nov 27, 2012 at 12:30 PM, Michael Thomas <mike@mtcc.com> wrote:
On 11/27/2012 11:58 AM, Cameron Byrne wrote:
On Tue, Nov 27, 2012 at 11:28 AM, mike <mike@mtcc.com> wrote:
Is this the app's fault? What are they doing wrong?
Yes, it is the app's fault.
They are either doing IPv4 literals or IPv4-only sockets
The IPv4 literal issues is when they do "wget http://192.168.1.1" ... hard coding IPv4 addresses... instead of using an FQDN like "wget http://example.com". Using an FQDN allows the DNS64 to work correctly.
I can understand spotify, but don't really understand why waze
Why can you understand Spotify not working on IPv6? Are they known for having a generally shoddy product? Pandora works fine on my IPv6-only NAT64/DNS64 setup. As does Youtube and many other multimedia services. Is Waze much different from Google Maps? Google Maps works great, as does Mapquest on ipv6-only And this is the conversation folks will have...: "Oh... Waze does not work, you should try their competitor it works great" and " I used to use Spotify, then i changed networks and it stopped working... now i use Pandora or Google Music"
would have a problem unless they're doing some sort of rendezvous like protocol that embeds ip addresses. That said, I'd say that the vast majority of apps don't have this sort of problem and will quite unknowingly and correctly work with v6.
Yes, 85% of the Android apps i have tested (sample of over 200) work fine on IPv6-only ... likely due to just good coding practices ... not due to specific IPv6 engineering. CB
Mike
On Tue, 27 Nov 2012, mike wrote:
You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular).
I am in Europe. None of Apple och Microsoft mobile devices will do IPv6 on the mobile side. I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work.
Is this the app's fault? What are they doing wrong?
They try to detect if there is Internet connectivity and check only IPv4, they use IPv4 literals and other things. I am not an app developer, I do networking, and when I connect IPv6 only to Android or Windows, a lot of things stop working. I haven't tried iPhone but I would believe the situation is similar there. -- Mikael Abrahamsson email: swmike@swm.pp.se
Sent from ipv6-only Android On Nov 27, 2012 8:39 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Tue, 27 Nov 2012, mike wrote:
You're saying there are no cellular v6 deployments? I'm about 99%
certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular).
I am in Europe. None of Apple och Microsoft mobile devices will do IPv6
on the mobile side. I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work.
Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for it the same way all Android Samsung devices on t-mobile now have ipv6 as a user option because it is part of the requirements for the oems. Win phone 8 has a menu option for ipv6 but I don't think it works ....
Is this the app's fault? What are they doing wrong?
They try to detect if there is Internet connectivity and check only IPv4,
they use IPv4 literals and other things. I am not an app developer, I do networking, and when I connect IPv6 only to Android or Windows, a lot of things stop working. I haven't tried iPhone but I would believe the situation is similar there.
Just to quantify, a lot of things stop working = about 15% of the top 200 apps ... names like Skype, Spotify, tango and Netflix fail. Sorry to nit pick, but I want to make sure the scope of the issue is well understood. Meanwhile, 85% of the apps work fine like email (smtp, pop, imap, exchange), gmail, chrome/firefox/opera, facebook, twitter, youtube, words with friends, Google maps, mapquest ... I have been v6-only on mobile for 2 years now, and I feel fine. I am sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat. CB
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, 27 Nov 2012, Cameron Byrne wrote:
Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for it the same way all Android Samsung devices on t-mobile now have ipv6 as a user option because it is part of the requirements for the oems.
I have been trying to locate someone within Apple for months now to speak about IPv6 on their mobile devices. The wall of silence is impressive. The android manufacturers at last respond, even though it's not always the answer I want :P
Win phone 8 has a menu option for ipv6 but I don't think it works ....
Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you use it it asks for an IPv4 PDP context and when it gets it, it falls over and needs to be rebooted.
I have been v6-only on mobile for 2 years now, and I feel fine. I am sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat.
Any progress with this, to get this into mainline? Then again, I feel we'll have proper IPv4v6 PDP context before there is any worthwile 464XLAT deployment, but for the long tail I would like to have 464XLAT in all devices. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi,
-----Message d'origine----- De : Mikael Abrahamsson [mailto:swmike@swm.pp.se] Envoyé : mercredi 28 novembre 2012 07:57 À : nanog@nanog.org Objet : Re: Big day for IPv6 - 1% native penetration
On Tue, 27 Nov 2012, Cameron Byrne wrote:
Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for it the same way all Android Samsung devices on t-mobile now have ipv6 as a user option because it is part of the requirements for the oems.
I have been trying to locate someone within Apple for months now to speak about IPv6 on their mobile devices. The wall of silence is impressive.
The android manufacturers at last respond, even though it's not always the answer I want :P Mobile operators have some difficulties to get some IPv6 terminals.It is the reason why we have proposed an IETF draft to define some IPv6 profile for mobile terminals (https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirement...) IMHO it is strategic to get a document that specifies such profile. It is important that such draft becomes a WG document so all support for such draft on IETF v6ops ML is welcome.
Such document will not replace discussions we may have with vendors but it is for sure a useful contribution to our common objective.
Win phone 8 has a menu option for ipv6 but I don't think it works ....
Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you use it it asks for an IPv4 PDP context and when it gets it, it falls over and needs to be rebooted.
I have been v6-only on mobile for 2 years now, and I feel fine. I am sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat.
Any progress with this, to get this into mainline?
Then again, I feel we'll have proper IPv4v6 PDP context before there is any worthwile 464XLAT deployment, but for the long tail I would like to have 464XLAT in all devices.
-- Mikael Abrahamsson email: swmike@swm.pp.se
_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Sent from ipv6-only Android On Nov 27, 2012 10:57 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Tue, 27 Nov 2012, Cameron Byrne wrote:
Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for it the same way all Android Samsung devices on t-mobile now have ipv6 as
user option because it is part of the requirements for the oems.
I have been trying to locate someone within Apple for months now to speak about IPv6 on their mobile devices. The wall of silence is impressive.
The android manufacturers at last respond, even though it's not always
a the answer I want :P
Win phone 8 has a menu option for ipv6 but I don't think it works ....
Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you
use it it asks for an IPv4 PDP context and when it gets it, it falls over and needs to be rebooted.
I have been v6-only on mobile for 2 years now, and I feel fine. I am
sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat.
Any progress with this, to get this into mainline?
Yes, there has been progress. These code parts have been merged into mainline Android code base. Time to start bugging the oems, since it is merged at the aosp level. There are still a peice pending review, but there is enough merged code to get the ball rolling for sure https://android-review.googlesource.com/#/q/owner:dan-android%2540drown.org+...
Then again, I feel we'll have proper IPv4v6 PDP context before there is any worthwile 464XLAT deployment, but for the long tail I would like to have 464XLAT in all devices.
Maybe. But the goal is to get rid of ipv4 constraints on the ue, not simply a foot race. But if 464xlat wins that race too, great. CB
-- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson <swmike@swm.pp.se> writes:
On Tue, 27 Nov 2012, mike wrote:
You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular).
I am in Europe. None of Apple och Microsoft mobile devices will do IPv6 on the mobile side.
They won't do maps either. Does that mean that maps don't exist? Try to keep device bugs and network deployment issues separate.
I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work.
IPv6 work just fine in 3GPP networks. Also in Europe. Bjørn
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Try to keep device bugs and network deployment issues separate.
Please elaborate. What is a "bug" here? That Galaxy Nexus exposes "IPv4v6" when the baseband module doesn't support it?
I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work.
IPv6 work just fine in 3GPP networks. Also in Europe.
I am well aware of this, I work for a mobile provider, trying to deploy IPv6. I have a few devices (usb dongles) that work properly, I have a lot of others that do not. But in order to deploy this in any meaningful way, there need to be handsets that support IPv4v6 bearer continuity on 2G/3G/4G. Until that happens, NAT44 using CGN gives better customer experience. -- Mikael Abrahamsson email: swmike@swm.pp.se
Subject: Re: Big day for IPv6 - 1% native penetration Date: Mon, Nov 26, 2012 at 11:18:13PM +0000 Quoting Dobbins, Roland (rdobbins@arbor.net):
How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA?
I am -- in addition to running eBGP for my employer -- also the acting network strategist and proper IP networking evangelist at my employer. We have been buying v6 compatible gear and connections for four years now. We are configuring IPv6 on all backbone links and are carefully deploying v6 to workstation and server networks all over the enterprise.
Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities?
There are no v6-only deployments of SQL Server. The admins request and setup v4, the server requests and sets up v6, and the clients use whatever is in the DNS. The server will register in DNS so v6 has a fair chanche of getting chosen.
Maybe they're hiding in plain sight. But I don't think so.
We discovered that the HUB/TRANSPORT nodes in the Exchange collective talked Link-local v6 to the MBOX nodes. Service discovery. Magic. The Exchange admins had no idea, but that probably was because they are good, obedient employees and use the mandated email client, which makes viewing headers something of a challenge. V6 will, given a few careful pushes, deploy itself. Slightly exaggerated, but that's how it is. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!!
On Nov 27, 2012, at 2:29 PM, Måns Nilsson wrote:
I am -- in addition to running eBGP for my employer -- also the acting network strategist and proper IP networking evangelist at my employer.
Thereby demonstrating how far out of the mainstream your enterprise is, given that those roles generally don't exist even within the largest enterprises. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ?
These are important, yes.
Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype).
It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have.
There are two basic value propositions: IPv6 is better, or IPv6 is cheaper. You argue that it must be better. I presented my argument in Dallas, that IPv6 will be cheaper than IPv4 when ISPs' costs to expand an IPv4 network rise. Some ISPs will, no doubt, raise prices for IPv4 service. Then IPv6 will be in demand. We can even express this now to app developers and consumer electronics makers: "Don't let your app/device be the one that costs your customer extra dollars every month. Especially if your competitor's app/device does support IPv6." There are significant deployments of residential IPv6 now. http://www.worldipv6launch.org/measurements/ I'm not expecting content over IPv6 just yet (unless it's a pre-release publicity stunt). I do expect some ISP in the next two years to offer an IPv6-only service at a discount to dual-stack. Lee
On Nov 26, 2012, at 14:53, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
It is significant because
Why*) do you believe it is important to waste everybody's time with these kinds of arguments? We have seen your kind of thinking. First, the Internet was never going to replace X.25/Frame Relay/leased lines and baling wire. Then you didn't need a web presence. Then it wasn't necessary to enable Web access out of the corporate networks. Then it wasn't necessary to accommodate user-owned equipment in enterprise networks. And so on, and so on. While these great arguments are going on in the board rooms, we are building out the technology. So it's there when you finally decide to shut up and give us the money. You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing. Grüße, Carsten *) Well, I think I can guess the answer, so this is mostly a rhetorical question. The need for rationalizing one's own bad decisions is one of the most powerful ways to cloud critical thinking.
On Nov 27, 2012, at 7:12 AM, Carsten Bormann wrote:
We have seen your kind of thinking.
You totally mischaracterize my 'kind of thinking'. My entire career arc has been that of a technological evangelist. Yes, I think there's a lot that's wrong with IPv6, but it appears that it's the only path forward we have, for the foreseeable future. It is very interesting that merely expressing skepticism regarding the rate, breadth, and depth of IPv6 deployment, and floating the proposition that some 'killer app' is needed in order to stimulate IPv6 deployment, is met with such over-the-top rhetoric and vitriol.
So it's there when you finally decide to shut up and give us the money.
As a consumer, I currently don't have the choice of paying for native IPv6 connectivity because it simply isn't available in the part of the world where I reside. Which is the part of the world that everyone says should benefit the most from IPv6 - i.e., Asia - but is also a part of the world which has practically zero consumer-grade IPv6 connectivity options, and precious few commercial-grade ones.
You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing.
Why do you think I am 'doing nothing'? When I was at Cisco, I relentlessly pushed for IPv4/IPv6 feature and performance parity, especially with regards to security and resiliency (much good that it did me, heh). I continue to advocate this stance. I am trying to point out that there are a lot of barriers to the near-universal deployment, or at least availability, of end-to-end IPv6 connectivity. It seems to me that many folks are overly optimistic in this regard, and that there must be some kind of incentive for ordinary users to push for IPv6 connectivity in order for it to achieve critical mass. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Nov 26, 2012, at 04:57 , "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote:
Users do not care and they will never have a "deliberate migration".
I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not.
There is, actually. The fact that more users are constantly connecting more devices creates an industry imperative to light up a larger address space. CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. Any ISP that fails to light up its customers with IPv6 in the next 3 years is at serious risk of having its customers notice that they are no longer connected to the entire internet. Since 2011, IPv4 has been becoming a progressively smaller fraction of the internet. Today, that progression is very slow and it's still north of 99%. However, there is notable acceleration and given the rate of internet growth, within 5 years, I suspect that even if everything that is currently IPv4 remains IPv4 and all new services are still deployed with IPv4 in addition to IPv6, less than 60% of the internet will still be IPv4 at that time.
IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users.
I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise.
Really, this isn't the important question, either. The important question is what is the rate of growth of the ability of users to access content/apps/services via IPv6? Further, what is the rate of growth in the provision of content/apps/services on dual-stack vs. IPv4-only? Later, the important question will become what fraction of users can still access the IPv4 internet through <2 layers of NAT? As I said, at current growth rates, by q4 2017, that final figure will be less than 60%. If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention. Owen [1] Things causing growth in the rate of internet attachment: IPv6-enabled light bulbs and other small appliances/sensors/etc. Smart-Grid/Smart-Meters Environmental Monitoring Sensor Arrays (things like projects to deploy literally millions of sensors in the oceans) Various 6lowpan based projects The eventual migration of what is currently Zigbee towards 6lowpan (OK, this one might be questionable, but it's certainly better for everyone except the Zigbee licensing folks if it goes that way) Public Safety applications (think telemetry-enabled ambulances) Bio-sensors (think remote patient monitoring, IPv6-enabled pace-makers and automatic-internal-defibrulators, etc.) Home automation Applications we haven't even thought of yet
Owen DeLong wrote:
less than 60% of the internet will still be IPv4 at that time.
Do you mean "IPv4" or "IPv4 Only"? Because unless the remaining percentage of IPv4 is noticeably less usable, it will still not incur any user demand, and IPv6 is still a cost mitigation strategy, and unless you wish to give up on connecting your users to that 40% you still need CGN, 644, what have you. Joe
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention.
What people ought to do and what they actually do are often quite different things. Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, 26 Nov 2012, Dobbins, Roland wrote:
Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities.
The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs). IPv6 is not today a viable alternative to CGN, one has to do both for a while before hopefully devices can do IPv6-only access and one can then have a centrally placed NAT64 (or similar) gateway. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Nov 27, 2012, at 11:57 AM, Mikael Abrahamsson wrote:
The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs).
Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. It sort of reminds me of how artificial intelligence has been only 10 years away for the last 60 years or so. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh.
Dual stack works with "everything". IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. -- Mikael Abrahamsson email: swmike@swm.pp.se
2013 - the year of the NAT. (the only way a single stacked address family is going to be able to talk to a single stacked member of a different address family... and unless we start agressive reuse of v4, this will happen sooner than later (dual-stack is rate limited to the smaller of the address families -UNLESS- NAT makes reuse possible... :) But since NAT is going to be required -anyway-.... 2013 will be the year of the NAT. /bill On Tue, Nov 27, 2012 at 06:32:27AM +0100, Mikael Abrahamsson wrote:
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh.
Dual stack works with "everything". IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far.
People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only.
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
-- Mikael Abrahamsson email: swmike@swm.pp.se
In message <alpine.DEB.2.00.1211270628380.27834@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh.
Dual stack works with "everything". IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far.
People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only.
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
IPv6 only is easy to setup if you already have dual stack. On my Mac it is "System Preferences", "Network Preferences", "Advanced", "TCP/IP", "IPv4 -> Off" then reboot to clear any lingering IPv4 references. It's about as easy on a Linux and a *BSD box. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 27 Nov 2012, Mark Andrews wrote:
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
IPv6 only is easy to setup if you already have dual stack.
On my Mac it is "System Preferences", "Network Preferences", "Advanced", "TCP/IP", "IPv4 -> Off" then reboot to clear any lingering IPv4 references.
It's about as easy on a Linux and a *BSD box.
Well, they don't really have access to dual stack either, so... -- Mikael Abrahamsson email: swmike@swm.pp.se
On 11/26/12 9:32 PM, Mikael Abrahamsson wrote:
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around with, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life. Mike
In message <50B512B6.1010701@mtcc.com>, mike writes:
On 11/26/12 9:32 PM, Mikael Abrahamsson wrote:
The main problem with IPv6 only is that most app developers (most programme
rs totally) do not really have access to this, so no testing is being done.
This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around wi th, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life.
Mike
I've had IPv6 for nearly a decade with no help from my ISP. I needed it to do IPv6 developement. It isn't hard to get IPv6 if you need it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 11/27/2012 12:41 PM, Mark Andrews wrote:
In message <50B512B6.1010701@mtcc.com>, mike writes:
The main problem with IPv6 only is that most app developers (most programme rs totally) do not really have access to this, so no testing is being done. This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around wi
On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: th, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life.
Mike I've had IPv6 for nearly a decade with no help from my ISP. I needed it to do IPv6 developement. It isn't hard to get IPv6 if you need it.
The point is that most developers and others don't think they "need" it so they don't seek it out. If there were far more native v6 (ie, that it's there without having to do something proactive), the app problems would almost certainly work themselves out because it would become apparent. Mike
On 2012-11-27 20:21, mike wrote:
On 11/26/12 9:32 PM, Mikael Abrahamsson wrote:
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around with, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life.
I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6. Especially as APIs like getaddrinfo() make it really easy to do so. The following excellent article by our beloved true IPv6 Samuarai Itojun is from 1998: http://www.kame.net/newsletter/19980604/ Thus it is not like the information is not out there either. As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse. (It might not be native, so wh00p, you can test fine also on a local link in the extreme case) Remember that silly thing called the 6bone and what the purpose of that was back then, indeed, for getting connectivity to the people so that they could fix their code and that ran from 1996 till 2006, 10 years where one could have fixed up those apps that was already 6 years ago again. As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care... Greets, Jeroen who proudly has been providing IPv6 connectivity and IPv6 patches for over more than a decade...
On 2012-11-27, at 21:07, Jeroen Massar wrote:
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
Or do care. From http://wiki.apache.org/hadoop/HadoopIPv6:
Apache Hadoop does not currently support IPv6 networks, it uses IPv4 addresses for communicating between nodes. This is because Hadoop is designed to work in private datacenters, which usually have private IP addresses in the 10.x.x.x address space.
• Using IPv4 addresses everywhere provides a single form of TCP addressing for all our tests. Different network configurations (DNS, reverse DNS, DNS caching) still provide lots of problems and performance issues, but there is no need to worry about which IP protocol version is used. • Shorter addresses make for shorter packets, which can have a benefit on busy networks.
This does not mean that the Hadoop team thinks that IPv4 is the best ever network protocol and that there is no reason to upgrade ever, only that it works well in datacenters.
(Yes, I am technically trolling. But mostly because I don't have the energy to fight for IPv6 any more. Maybe you do?) -- http://josephholsten.com
Personally I have ran into this dilema a few times. The code just like network equipment needs dual stacks which is double the amount of code and since IPv4 and IPv6 do not share a native topology just supporting both kinds of addresses isnt sufficient. I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly. In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do. Just my thoughts. On Tue, Nov 27, 2012 at 2:23 PM, Joseph Holsten <joseph@josephholsten.com> wrote:
On 2012-11-27, at 21:07, Jeroen Massar wrote:
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
Or do care.
From http://wiki.apache.org/hadoop/HadoopIPv6:
Apache Hadoop does not currently support IPv6 networks, it uses IPv4 addresses for communicating between nodes. This is because Hadoop is designed to work in private datacenters, which usually have private IP addresses in the 10.x.x.x address space.
• Using IPv4 addresses everywhere provides a single form of TCP addressing for all our tests. Different network configurations (DNS, reverse DNS, DNS caching) still provide lots of problems and performance issues, but there is no need to worry about which IP protocol version is used. • Shorter addresses make for shorter packets, which can have a benefit on busy networks.
This does not mean that the Hadoop team thinks that IPv4 is the best ever network protocol and that there is no reason to upgrade ever, only that it works well in datacenters.
(Yes, I am technically trolling. But mostly because I don't have the energy to fight for IPv6 any more. Maybe you do?) -- http://josephholsten.com
-- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
On Nov 27, 2012, at 4:30 PM, Bryan Tong <contact@nullivex.com> wrote:
Personally I have ran into this dilema a few times.
The code just like network equipment needs dual stacks which is double the amount of code and since IPv4 and IPv6 do not share a native topology just supporting both kinds of addresses isnt sufficient.
I reject the above statement having operated networks with congruent v4+v6 topologies for over a decade. Doing dual-stack is the easiest method. Any modern hardware supports it. If your upstream doesn't support IPv6, replace them. There are plenty of choices these days for IPv6 services. I've seen very large customer flows on single ports of IPv6 traffic (8-10Gb/s), so there is real traffic out there. While this may not be feasible for all use cases, I found myself looking for internet access about a year ago and each ISP I contacted had simple checkboxes on their forms for IPv6 and it was a breeze to turn up. (174/6461). I know many others can deliver this service as well (7922, 2914, 3561, 7018, 3549, 6453) amongst others. Even server hosting folks offer it as a checkbox as seen here: https://outlet.softlayer.com/Sales/orderServer/35/14015 Single IPv6 address is free.. a /64 is $5/mo Its readily available and you can get it via VPN while traveling if it's not already native (my Verizon LTE iPad does native IPv6). It sounds like the threshold is "Didn't pay for a server to host my application with IPv6 and can't spend $20/mo for LTE access to have native IPv6".
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly.
Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be. - Jared
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly.
Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples.
http://owend.corp.he.net/ipv6 Pretty much everything you need to know about taking your applications from mono-stack to dual-stack. Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be.
It's actually pretty easy to change the datatype in an SQL database, so that shouldn't be that much of an impediment. Owen
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, November 27, 2012 6:48 PM To: Jared Mauch Cc: nanog@nanog.org Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly.
Sure, using gethostbyname() is certainly easier to find code examples,
but not impossible to find other examples.
Pretty much everything you need to know about taking your applications from mono-stack to dual-stack.
Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and- over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be.
It's actually pretty easy to change the datatype in an SQL database, so
I think that we are missing a significant part of this conversation. Even if programmers never write a line of code that invokes IPv6, they need to accommodate the effects of all the other programmers who aren't writing a line of IPv6 code. CGN renders most application logs useless unless they record source port as well as address. For many industries, logging of transactions in a manner that allows you to track back to the originator of the transaction is not optional. And yes that does translate to track back to the ISP who (when presented with the appropriate piece of paper) can convert the timestamp /IP address/ port combination to the customer who is responsible for the account. Even if programmers never write a line of code that invokes IPv6, they had better be testing their Internet facing applications against users in pure IPv4 environments; users in pure IPv6 environment using each of the transition mechanism, and users in dual-stack environments. I've spent more than a small amount of time explaining to vendors that AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded that the change would require retesting everything. I'm afraid that he wasn't happy when I pointed out that they obviously hadn't tested the first time and that as the customer, I was entitled to at least one full set of (successful) pre-delivery testing. --Dave that
shouldn't be that much of an impediment.
Owen
On Nov 27, 2012, at 19:18 , "Dave Edelman" <dedelman@iname.com> wrote:
I think that we are missing a significant part of this conversation.
Even if programmers never write a line of code that invokes IPv6, they need to accommodate the effects of all the other programmers who aren't writing a line of IPv6 code. CGN renders most application logs useless unless they record source port as well as address. For many industries, logging of transactions in a manner that allows you to track back to the originator of the transaction is not optional. And yes that does translate to track back to the ISP who (when presented with the appropriate piece of paper) can convert the timestamp /IP address/ port combination to the customer who is responsible for the account.
That won't help. Think about it this way. A session state log entry is roughly 512 bytes. I'm told (by several of the large residential providers) that the average session rate per subscriber is around 33,000 connections/subscriber/day for roughly 17Kbytes/day of log entries per day. Take a carrier like Comcast that has ~20,000,000 subscribers. That's 660,000,000,000 or 660 Terabytes per day of log files. Now, imagine trying to keep that data set for 7 years worth of data. That's a 660*365*7 = 1,686,300 Terabyte (or 1.7 Exabyte) storage array. I'm sure EMC would love to build something like that, but, I'm willing to bet that any economic analysis of that problem against CALEA reveals the relatively swift conclusion that the fines cost less than the infrastructure to preserve the logs. Even if you can cut the session state log entry down to 26 octets (which is only room for 2xSource IPv4 address, 1x destination IPv4 address, 2x Source port#, 1x destination port#, a 32-bit timestamp and a 32-bit subscriber ID), you're still looking at roughly 85 Petabytes of storage required to meet CALEA standards. This doesn't account for the additional costs involved in managing that kind of logging infrastructure, etc.
Even if programmers never write a line of code that invokes IPv6, they had better be testing their Internet facing applications against users in pure IPv4 environments; users in pure IPv6 environment using each of the transition mechanism, and users in dual-stack environments.
That would be ideal, but if they aren't writing any IPv6 code, they probably lack the understanding required in order to do so.
I've spent more than a small amount of time explaining to vendors that AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded that the change would require retesting everything. I'm afraid that he wasn't happy when I pointed out that they obviously hadn't tested the first time and that as the customer, I was entitled to at least one full set of (successful) pre-delivery testing.
ROFL Owen
--Dave
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, November 27, 2012 6:48 PM To: Jared Mauch Cc: nanog@nanog.org Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly.
Sure, using gethostbyname() is certainly easier to find code examples,
but not impossible to find other examples.
Pretty much everything you need to know about taking your applications from mono-stack to dual-stack.
Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and- over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be.
It's actually pretty easy to change the datatype in an SQL database, so that shouldn't be that much of an impediment.
Owen
In message <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com>, Owen DeLong write s:
On Nov 27, 2012, at 19:18 , "Dave Edelman" <dedelman@iname.com> wrote:
I think that we are missing a significant part of this conversation.=20=
=20 Even if programmers never write a line of code that invokes IPv6, they = need to accommodate the effects of all the other programmers who aren't = writing a line of IPv6 code. CGN renders most application logs useless unless = they record source port as well as address. For many industries, logging of transactions in a manner that allows you to track back to the = originator of the transaction is not optional. And yes that does translate to track = back to the ISP who (when presented with the appropriate piece of paper) = can convert the timestamp /IP address/ port combination to the customer = who is responsible for the account. =20
That won't help. Think about it this way. A session state log entry is = roughly 512 bytes.
I'm told (by several of the large residential providers) that the = average session rate per subscriber is around 33,000 connections/subscriber/day for roughly = 17Kbytes/day of log entries per day.
Take a carrier like Comcast that has ~20,000,000 subscribers. That's = 660,000,000,000 or 660 Terabytes per day of log files. Now, imagine trying to keep that = data set for 7 years worth of data. That's a 660*365*7 =3D 1,686,300 Terabyte (or 1.7 = Exabyte) storage array. I'm sure EMC would love to build something like that, = but, I'm willing to bet that any economic analysis of that problem against CALEA reveals = the relatively swift conclusion that the fines cost less than the = infrastructure to preserve the logs.
The fine will be first then the court order to move all the customers to IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com]
That won't help. Think about it this way. A session state log entry is roughly 512 bytes. [math redacted] you're still looking at roughly 85 Petabytes of storage required to meet CALEA standards.
I've done my share of shoveling dirt on the CGN coffin, but in the interest of fact-based decision-making: nobody is going to create a separate log entry for every session/flow. You do bulk port assignment or deterministic NAT, so whenever you assign an address, you know what ports you'll be mapping that address to. One entry per Lease_Time. Doesn't matter, because the servers aren't logging port number, so nobody will ever need to see those logs. * Unless Geoff Huston's wackiness finds support, and somebody will pay you to keep that kind of log. Although if somebody would pay, I'd expect them to be paying for DPI deployment already. Lee
In message <009301cdcdb2$e4f55ad0$aee01070$@asgard.org>, "Lee Howard" writes:
Doesn't matter, because the servers aren't logging port number, so nobody will ever need to see those logs.
We log port numbers along with addresses in named as it is necessary to trouble shoot problems. We have been doing this for over a decade. I'm sure you will find other applications that log port number as well as the address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 11/27/2012 11:48 PM, Owen DeLong wrote:
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly. Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples.
Pretty much everything you need to know about taking your applications from mono-stack to dual-stack.
"Everything you need to know" except for how to actually accomplish this task in the real world. In order to accomplish this in the real world using present-day software development methodologies you would need to do a few more things: - Generate some user stories that explain why the IPv6-supporting code needs to be written - Break these user stories down into backlog items and convince the product manager to place these items into the backlogs of the dozens or more interacting teams that need to write the code - Add all of the backlog items for all of the interworking pieces so that, for instance, automated monitoring tools that are watching the IPv4 services will now be watching the IPv6 services as well... capacity planning will be able to account for IPv6 growth... etc. - Convince the product manager (along with other departments like marketing and executive management) that adding support for IPv6 to an existing working product is *more important* than meeting internal and external requests for features and fixing known bugs - Develop a test plan so that the various interworking parts of your system may be tested internally once IPv6 support is added to ensure that not only does IPv6 now work but that the existing IPv4 functionality is not broken as a result - Write the code when the work makes its way to the top of the backlog - Wait for the infrastructure environment to be upgraded to support running IPv6 in production - Test the new IPv6 functionality and verify that none of the IPv4 functionality is broken - Deploy to customers - Receive bug reports - Prioritize bugs that have been created that affect IPv4 customers and IPv6 customers appropriately such that the IPv6 bugs ever get fixed - Iterate I'm sure I've missed a few steps.
Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python.
Unfortunately the "example application" is less than 1M lines of code and fewer than a a few hundred different servers plus client applications.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
+1 on this for sure.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be.
One of many issues that will come up. Along with the lack of support for IPv6 in the infrastructure, or the monitoring tools, or the automated test systems, or whatever.
It's actually pretty easy to change the datatype in an SQL database, so that shouldn't be that much of an impediment.
If only A) it were that simple and B) going in and changing data types for columns didn't have audit implications, data replication implications, data warehousing and analysis system implications, etc. Matthew Kaufman ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers. pps. And until we were last acquired, we *didn't* have IPv6 at our developer's desktops. Now we do, but it doesn't connect to the global IPv6 Internet (yet).
ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers.
Yes, but unlike Skype, most popular applications have competitors and whichever competitor provides the better user experience will cut the others off from a meaningful proportion of their customers. Owen
On 12/1/2012 11:55 PM, Owen DeLong wrote:
Yes, but unlike Skype, most popular applications have competitors and whichever competitor provides the better user experience will cut the others off from a meaningful proportion of their customers. Owen
I think you're assuming some magic that lets one of the competitors bypass all the steps I outlined in order to support IPv6 while the other takes "forever" to get to it. Matthew Kaufman
On 12/01/2012 11:55 PM, Owen DeLong wrote:
ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers.
Yes, but unlike Skype, most popular applications have competitors and whichever competitor provides the better user experience will cut the others off from a meaningful proportion of their customers.
You have a really strange metric of what constitutes a "better user experience". I look at things like enrollment/take rates, friending, reviews, etc to determine whether people are having a better user experience. I can with all sincerity say that ipv6 is not something that provides a "better user experience". I enabled it for my site just because I was curious and linode makes getting v6 dead simple and I didn't think I had anything that would puke on v6 (I didn't). If it took any more effort than that, I'd have gone and found something else to be curious about because it wouldn't have been worth my time given things that really do impact user experience. Mike
Adding IPv6 support isn't like adding most new features. It doesn't give most people something extra. It doesn't "enhance the experience". It is insurance for when the CGN is deployed by the ISP or when the ISP goes IPv6 only and like most insurance you don't know when you will needed and you will be happy you have it when it is needed. It will stop you loosing customers because when either of those events happen and they impact on the functionality of the product your customers won't be in a position to wait for your next release. Cost wise adding IPv6 support is cheaper than adding most other features. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
"Everything you need to know" except for how to actually accomplish this task in the real world.
In order to accomplish this in the real world using present-day software development methodologies you would need to do a few more things: - Generate some user stories that explain why the IPv6-supporting code needs to be written - Break these user stories down into backlog items and convince the product manager to place these items into the backlogs of the dozens or more interacting teams that need to write the code - Add all of the backlog items for all of the interworking pieces so that, for instance, automated monitoring tools that are watching the IPv4 services will now be watching the IPv6 services as well... capacity planning will be able to account for IPv6 growth... etc. - Convince the product manager (along with other departments like marketing and executive management) that adding support for IPv6 to an existing working product is *more important* than meeting internal and external requests for features and fixing known bugs - Develop a test plan so that the various interworking parts of your system may be tested internally once IPv6 support is added to ensure that not only does IPv6 now work but that the existing IPv4 functionality is not broken as a result - Write the code when the work makes its way to the top of the backlog - Wait for the infrastructure environment to be upgraded to support running IPv6 in production - Test the new IPv6 functionality and verify that none of the IPv4 functionality is broken - Deploy to customers - Receive bug reports - Prioritize bugs that have been created that affect IPv4 customers and IPv6 customers appropriately such that the IPv6 bugs ever get fixed - Iterate
I'm sure I've missed a few steps.
There is another case where the customer does not ask for it. I don't think Google or Facebook's or Bing's customers meaningfully asked for v6, yet they did it. Same thing with Verizon LTE. Maybe the Bing folks can help you with internal strategies for getting support.
<snip>
Matthew Kaufman
ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and
Nonexistent demand? Let's bing it and decide http://www.bing.com/search?q=skype+ipv6 Interesting hits my query are http://community.skype.com/t5/Android/Skype-not-working-on-T-Mobile-USA-IPv6... http://www.zdnet.com/voip-and-instant-messaging-problem-looming-skype-doesnt... http://www.gossamer-threads.com/lists/nsp/ipv6/33334 http://www.change.org/petitions/skype-add-ipv6-support-to-skype http://www.gossamer-threads.com/lists/nsp/ipv6/41499 But, this is just the same old carping. Skype / Microsoft should add IPv6 support because it is the right thing to do for the Internet. Microsoft, like Google and Facebook, was part of world v6 launch and knows ipv6 is about making the internet better and bigger. The Skype issue is so serious, that it is specifically blocking IPv6-only architectures since it is THE most major app that breaks in IPv6-only. Skype is the killer app for 464XLAT ... which means that since Skype refuses to evolve their product, the OS now has to have hacks to fix it. CB
other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers.
pps. And until we were last acquired, we *didn't* have IPv6 at our developer's desktops. Now we do, but it doesn't connect to the global IPv6 Internet (yet).
In message <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com>, Joseph Hol sten writes:
On 2012-11-27, at 21:07, Jeroen Massar wrote:
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
Or do care.=20
Apache Hadoop does not currently support IPv6 networks, it uses IPv4 = addresses for communicating between nodes. This is because Hadoop is = designed to work in private datacenters, which usually have private IP = addresses in the 10.x.x.x address space. =20 =95 Using IPv4 addresses everywhere provides a single form of = TCP addressing for all our tests. Different network configurations (DNS, = reverse DNS, DNS caching) still provide lots of problems and performance = issues, but there is no need to worry about which IP protocol version is = used. =95 Shorter addresses make for shorter packets, which can have a = benefit on busy networks. =20 This does not mean that the Hadoop team thinks that IPv4 is the best = ever network protocol and that there is no reason to upgrade ever, only =
=46rom http://wiki.apache.org/hadoop/HadoopIPv6: that it works well in datacenters.=20
(Yes, I am technically trolling. But mostly because I don't have the = energy to fight for IPv6 any more. Maybe you do?)
Most of which is just FUD. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer. oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc. Until the orgs that support the developers find that v6 is a priority (through whatever means it happens - neteng/IT/etc pushing it up the chain or politics/marketing pushing it down the chain) and it's functional on the typical corp desktop, the typical corp application engineer is going to have no motivation (not to mention no time in his/her schedule to reengineer their platform) to support v6. ...david (who hasn't read the rest of the thread. but is it really any different than any other?) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
In message <alpine.BSF.2.00.1211271621190.85108@murf.icantclick.org>, david rai strick writes:
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer.
If they are writing network based code a tunnel broker should not be a issue. Tunnel brokers are not that hard to use. They are after all just a VPN and millions of road warriers use them everyday.
oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc.
And if they are developing a product for the company there are procedures to get the changes needed to do the development.
Until the orgs that support the developers find that v6 is a priority (through whatever means it happens - neteng/IT/etc pushing it up the chain or politics/marketing pushing it down the chain) and it's functional on the typical corp desktop, the typical corp application engineer is going to have no motivation (not to mention no time in his/her schedule to reengineer their platform) to support v6.
...david (who hasn't read the rest of the thread. but is it really any different than any other?) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 28 Nov 2012, Mark Andrews wrote:
oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc.
And if they are developing a product for the company there are procedures to get the changes needed to do the development.
...only if v6 support is on their development roadmap. For our latest released product, which had a 3 month timeline, there definitely would have been no software engineering support for building v6 support into a server framework that never had to support it before, nor 2 (or 3) client frameworks. ...david (who supports a bunch of software engineers for one of many arms of an F500 company) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote:
If they are writing network based code a tunnel broker should not be a issue. Tunnel brokers are not that hard to use. They are after all just a VPN and millions of road warriers use them everyday.
Oh, for crumb's sake. You're quite right: millions of road worriers use VPNs every day, because they involve downloading a program and the config your IT dept says to use and that's it. Tunnel brokers are the moral equivalent of telling the road warriors, "Go download OpenVPN. Here are credentials. Have a nice day." This is not to criticise tunnel brokers: they're providing a useful service. But really, saying, "Stupid users," is not going to help deployment. Yes, those users include application developers. There is no -- "approaching zero" -- reason for someone in the user-application layer of the stack to care about this today. So the intellectual burden on checking that it works needs to be close to zero, rather than close to whatever the burden is for being an IPv6 early implementer. Manning is right upthread. If the entire deployment path automatically requires 84 layers of NAT sludge, that's what gets tested, cause it "works" for "everybody". A -- Andrew Sullivan Dyn Labs asullivan@dyn.com
On Nov 28, 2012, at 11:18 AM, Andrew Sullivan wrote:
If the entire deployment path automatically requires 84 layers of NAT sludge, that's what gets tested, cause it "works" for "everybody".
Hence my questions regarding the actual momentum behind end-to-end native IPv6 deployment. Inertia is generally only overcome when there's a clear positive economic benefit to doing so - 'savings', assuming there actually are any, are a) almost always exaggerated and b) generally not a powerful enough incentive to alter the status quo. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Dobbins, Roland wrote:
On Nov 28, 2012, at 11:18 AM, Andrew Sullivan wrote:
If the entire deployment path automatically requires 84 layers of NAT sludge, that's what gets tested, cause it "works" for "everybody".
Hence my questions regarding the actual momentum behind end-to-end native IPv6 deployment. Inertia is generally only overcome when there's a clear positive economic benefit to doing so - 'savings', assuming there actually are any, are a) almost always exaggerated and b) generally not a powerful enough incentive to alter the status quo.
That is why the preference is biased toward IPv6 when it is available. If you expect the end users to make a conscious choice it will never happen. If the underlying OS components make that choice for them, you end up with a transition. Open the page that Tim Chown sent out : http://6lab.cisco.com/stats/ Select World-scale data : then open IPv6 Prefix & User graphs. Look at the correlation between IPv6-alive prefixes & user %. Those users never made a conscious choice, the OS did it as soon as it had a path to the target. As more prefixes light up, the 'unconscious pent up demand' will make that User curve even steeper. The primary bottleneck at this point is and will be CPE. Fixing that will likely require a financial incentive to get consumers to 'upgrade' their working box. Normal lifecycle replacements will take a long time, requiring larger investments in cgn's, so as soon as the new cpe is available in sufficient quantity at a reasonable price point, any MBA can go make the case you are looking for about why it is cheaper to do a cpe subsidy than it is to invest in a never-ending cgn saga (if they can't figure it out have someone hire an MBA from the mobile providers who transition handsets off the old network all the time). Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing". As long as there are voices calling for 444nat in the flavor-of-the-week, cpe vendors will not focus on the long term goal, because they will see the interim steps as opportunity to extract more cash for short-life products. So will infrastructure vendors for that matter. Indecision and scatter-shot approaches only increase the number of things that need to be bought, deployed, and operated. That overall additional cost is a complete waste to the operator / end user, and clear profit for the vendors. You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a legacy technology. The same thing happened with the SNA faithful 15 years ago, and history shows what happened there. Tony
On Nov 29, 2012, at 3:04 AM, Tony Hain wrote:
Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing".
Do you see any evidence of that occurring? I don't. Also, a lot of broadband consumers and enterprise organizations buy and deploy their own CPE. Do you see a lot of IPv6 activity there? I don't, excepting an IPv6 RFP checkbox for enterprises, which doesn't have any formal requirements and is essentially meaningless because of that fact.
You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a legacy technology.
No. What I am looking for is an economic incentive which will justify the [IMHO] wildly overoptimisitic claims which some are making in re ubiquitous end-to-end native IPv6 deployment. Otherwise, I believe it will be a much more gradual adoption curve, as you indicate.
The same thing happened with the SNA faithful 15 years ago, and history shows what happened there.
You attribute circumstances and motivations to me which do not apply. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Nov 28, 2012, at 4:17 PM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Nov 29, 2012, at 3:04 AM, Tony Hain wrote:
Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing".
Do you see any evidence of that occurring? I don't.
Yes. Comcast, Cable Labs, Time Warner are doing pretty well at this now. Others there is room for improvement, but it's definitely better than a year ago.
Also, a lot of broadband consumers and enterprise organizations buy and deploy their own CPE. Do you see a lot of IPv6 activity there? I don't, excepting an IPv6 RFP checkbox for enterprises, which doesn't have any formal requirements and is essentially meaningless because of that fact.
Very little, but, most of those buy based on the "supported device" list from their carrier, so…
You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a legacy technology.
No.
What I am looking for is an economic incentive which will justify the [IMHO] wildly overoptimisitic claims which some are making in re ubiquitous end-to-end native IPv6 deployment.
Otherwise, I believe it will be a much more gradual adoption curve, as you indicate.
The inability to add customers to IPv4 will become a factor in this. 60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years. Owen
On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote:
60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years.
I live and work in a part of the world which contains a sizable subset of that 60% - i.e., Asia. I see just about zero IPv6 awareness, much less deployment, except peripherally in Japan and, to an even lesser degree, the RoK. I see so many other challenges facing so many IPv4 networks in this region that it's inconceivable that they would be deploying IPv6 within the next 2-4 years, or even the foreseeable future. Also, it appears to me that a large proportion of the population in this region who have both a sufficient amount of disposable income (it doesn't require much here, especially via mobile wireless, but it's still more than a lot of people have) and a corresponding degree of interest to obtain and benefit from Internet access, and who are in fact likely to ever get Internet access, already have it. So, I'm not so sure that there are still these vast numbers of underserved yet eager potential Internet users out there, as is commonly mooted. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 2012-12-01 00:00, Dobbins, Roland wrote:
On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote:
60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years.
I live and work in a part of the world which contains a sizable subset of that 60% - i.e., Asia.
I see just about zero IPv6 awareness, much less deployment, except peripherally in Japan and, to an even lesser degree, the RoK.
Japan and South Korea are doing quite well indeed and China has CERNET of course which is doing mostly IPv6. There are some ISPs in various other Asian countries doing IPv6, but I guess indeed that they don't push that much traffic, but counting that is hard to tell anyway.
I see so many other challenges facing so many IPv4 networks in this region that it's inconceivable that they would be deploying IPv6 within the next 2-4 years, or even the foreseeable future.
Can you divulge some of these hurdles? Would be interesting to know what they are running into. Greets, Jeroen
On Dec 1, 2012, at 6:09 AM, Jeroen Massar wrote:
Japan and South Korea are doing quite well indeed
I guess that depends upon how one defines 'quite well', heh. They're certainly ahead of other countries in the region with regards to IPv6, but it's questionable how deeply/broadly it is both available and utilized by their user bases. And AFAICT, the emphasis is on clients, not servers.
and China has CERNET of course which is doing mostly IPv6.
But which does not serve China's user base.
Can you divulge some of these hurdles? Would be interesting to know what they are running into.
Architectural issues, operational issues, educational issues, organizational issues, resiliency issues, scalability issues, security issues, economic issues, layer-8, etc. If one encounters significant challenges in designing, building, and operating an IPv4 network, one is unlikely to expend a significant amount of time and resources on IPv6. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Japan and South Korea are doing quite well indeed I guess that depends upon how one defines 'quite well', heh. They're certainly ahead of other countries in the region with regards to IPv6
i can only speak about japan, and it's embarrassing big-time. europe is in better shape. see, for example, erik kline's talk at apnic busan [0].
and China has CERNET of course which is doing mostly IPv6. But which does not serve China's user base.
i am pretty sure cernet-2 serves a few times as many people than the entire population of the united states of jingoism. randy -- [0] - if you have trouble finding it, write to apnic marketing. they seem to run the web site as it is all gloss and hard as hell to find content you want.
On Dec 1, 2012, at 10:32 AM, Randy Bush wrote:
i am pretty sure cernet-2 serves a few times as many people than the entire population of the united states
I'm certain that it does not. China did a fantastic job of showcasing IPv6 with the Beijing Olympics, but it's not widely deployed for ordinary users. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
I would guess that a lot of the access growth going forward is going to be a lot of what I would term "incidental access". More and more devices and technology requires or supports Internet access. So while a lot of people may not ask for internet service that don't already have it, it will be more of an enabling technology that allows them to do other stuff that they are interested in. My aunt could care less about "the Internet" but she sure loves being able to turn on the heat at her vacation home and monitor stuff there. For example, Joe Schmo may not care about web browsing but wants remote video surveillance, power saving technologies from his power company, smart appliances, and a car that calls in for service by itself. In education, consider that in the third world schools are finding it much more cost effective to build a computer lab than to provide up to date text books and libraries. In that case, the economics are in favor of technology adoption. A lot of these will require Internet access and more importantly this guy is going to get more and more device such that there will be an explosion in address needs. Since he is mobile with all this cool stuff, NATing it all is going to get ugly fast. IPv6 might really be a good idea to new build outs since some of the most difficult issues are with transition strategies and devices consumers will have to configure. I think my life would be much easier if I were to deploy IPv6 from day 1. Cell phones that can be auto configured or embedded devices that the consumer does not have to deal with are the best places to put IPv6. This is a lot like fiber deployment. I put a lot of fiber into countries that did not have good wire line infrastructure. It was cheaper, easier to maintain, and was not as marketable on the black market as copper is. Some of the last countries to get technology have the best infrastructure now because they started with the last generation of stuff. It is a lot harder to justify replacement of old tech than a Greenfield installation. Steven Naslund -----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Friday, November 30, 2012 5:01 PM To: NANOG list Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote:
60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years.
I live and work in a part of the world which contains a sizable subset of that 60% - i.e., Asia. I see just about zero IPv6 awareness, much less deployment, except peripherally in Japan and, to an even lesser degree, the RoK. I see so many other challenges facing so many IPv4 networks in this region that it's inconceivable that they would be deploying IPv6 within the next 2-4 years, or even the foreseeable future. Also, it appears to me that a large proportion of the population in this region who have both a sufficient amount of disposable income (it doesn't require much here, especially via mobile wireless, but it's still more than a lot of people have) and a corresponding degree of interest to obtain and benefit from Internet access, and who are in fact likely to ever get Internet access, already have it. So, I'm not so sure that there are still these vast numbers of underserved yet eager potential Internet users out there, as is commonly mooted. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Dec 1, 2012, at 6:28 AM, Naslund, Steve wrote:
A lot of these will require Internet access and more importantly thiscguy is going to get more and more device such that there will be an explosion in address needs.
I agree that spimes and M2M in general certainly have the potential for explosive growth, if they're ever adopted for various large-scale applications. Right now, at least, this is largely theoretical (again, waiting for the 'killer app'). ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/28/12 4:17 PM, Dobbins, Roland wrote:
On Nov 29, 2012, at 3:04 AM, Tony Hain wrote:
Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing". Do you see any evidence of that occurring? I don't.
Also, a lot of broadband consumers and enterprise organizations buy and deploy their own CPE. Do you see a lot of IPv6 activity there? As a product of having a motorola sb6121 and a netgear wndr3700 both of which I bought at frys I have ipv6 in my house with dhcp pd curtesy of commcast. If it was any simpler somebody else would have had to install it. I don't, excepting an IPv6 RFP checkbox for enterprises, which doesn't have any formal requirements and is essentially meaningless because of that fact.
You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a legacy technology. No.
What I am looking for is an economic incentive which will justify the [IMHO] wildly overoptimisitic claims which some are making in re ubiquitous end-to-end native IPv6 deployment.
Otherwise, I believe it will be a much more gradual adoption curve, as you indicate.
The same thing happened with the SNA faithful 15 years ago, and history shows what happened there. You attribute circumstances and motivations to me which do not apply.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Jan 30, 2013, at 12:43 PM, joel jaeggli <joelja@bogus.com> wrote:
As a product of having a motorola sb6121 and a netgear wndr3700 both of which I bought at frys I have ipv6 in my house with dhcp pd curtesy of commcast. If it was any simpler somebody else would have had to install it.
Except that Apple Airport Extreme users must have one of the newer hardware versions, that is my experience as well. And, even before Comcast and new AEBS, Hurricane Electric removed all other excuses for claiming "no IPv6".
On 01/30/2013 01:51 PM, Cutler James R wrote:
On Jan 30, 2013, at 12:43 PM, joel jaeggli <joelja@bogus.com> wrote:
As a product of having a motorola sb6121 and a netgear wndr3700 both of which I bought at frys I have ipv6 in my house with dhcp pd curtesy of commcast. If it was any simpler somebody else would have had to install it.
Except that Apple Airport Extreme users must have one of the newer hardware versions, that is my experience as well.
And, even before Comcast and new AEBS, Hurricane Electric removed all other excuses for claiming "no IPv6".
"Remove excuses" != "Create incentive". There are an infinite number of things I can do to "remove excuses". Unless they're in my face (read: causing me headaches), they do not "create incentive". My using my or my company's software which doesn't work in my own environment (= work, home, phone, etc) "creates incentive". Lecturing me about how I can get a HE tunnel and that if I don't i'm ugly and my mother dresses me funny, otoh, just "creates vexation". Mike
In message <51099C0F.5040507@mtcc.com>, Michael Thomas writes:
On 01/30/2013 01:51 PM, Cutler James R wrote:
On Jan 30, 2013, at 12:43 PM, joel jaeggli <joelja@bogus.com> wrote:
As a product of having a motorola sb6121 and a netgear wndr3700 both of wh ich I bought at frys I have ipv6 in my house with dhcp pd curtesy of commcast . If it was any simpler somebody else would have had to install it.
Except that Apple Airport Extreme users must have one of the newer hardware versions, that is my experience as well.
And, even before Comcast and new AEBS, Hurricane Electric removed all other excuses for claiming "no IPv6".
"Remove excuses" != "Create incentive". There are an infinite number of things I can do to "remove excuses". Unless they're in my face (read: causing me headaches), they do not "create incentive". My using my or my company's software which doesn't work in my own environment (= work, home, phone, etc) "creates incentive". Lecturing me about how I can get a HE tunnel and that if I don't i'm ugly and my mother dresses me funny, otoh, just "creates vexation ".
Mike
Just having IPv6 doesn't create incentives to make their code work with IPv6. People just trundle along using IPv4. Turning off IPv4 creates incentives. Reducing IPv4's capabilities creates incentives. Being told this needs to work and be tested with IPv6 creates incentives. Broken networks get people to fix things. Unfortunately most developers don't test with broken networks. If they did "Happy Eyeballs" would not have happened. The applications would have coped with only some address of a multi-homed server working. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <20121128041816.GF1304@dyn.com>, Andrew Sullivan writes:
On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote:
If they are writing network based code a tunnel broker should not be a issue. Tunnel brokers are not that hard to use. They are after all just a VPN and millions of road warriers use them everyday.
Oh, for crumb's sake. You're quite right: millions of road worriers use VPNs every day, because they involve downloading a program and the config your IT dept says to use and that's it.
And using some tunnel brokers are just as easy. Even manual config isn't that hard and is a lot easier that getting dialup networking was before ppp was available. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 11/27/2012 09:00 PM, Mark Andrews wrote:
In message <20121128041816.GF1304@dyn.com>, Andrew Sullivan writes:
If they are writing network based code a tunnel broker should not be a issue. Tunnel brokers are not that hard to use. They are after all just a VPN and millions of road warriers use them everyday. Oh, for crumb's sake. You're quite right: millions of road worriers use VPNs every day, because they involve downloading a program and
On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote: the config your IT dept says to use and that's it. And using some tunnel brokers are just as easy.
Even manual config isn't that hard and is a lot easier that getting dialup networking was before ppp was available.
Let's be clear: nobody sets up a VPN because they want to. Mike
On Tue, Nov 27, 2012 at 09:04:56PM -0800, Michael Thomas wrote:
Let's be clear: nobody sets up a VPN because they want to.
And further, only people who think cell phones are newfangled think that "configuring dial-up before ppp was available" is a test we can apply to _anything_ for the quality "being easy". If any of us seriously thinks that "set up VPN", "configure dial-up by hand", or any other such "easy" things are the bar we have to jump, we are doomed. Big Fat Checkbox that says "Disable Old-Fashioned Network" is about the level we can expect. Past that, forget it. Too much work. Too risky. Boss won't authorize the time. The question upthread about costs is dead on. One of those costs is, "How much do I need to think?" If the answer is, "Oh, just set up a tunnel," the fish is already off the hook and in another river. If your response to that is, "I've been an application developer, and they need to be more responsible," I would like to know your company's stock symbol so I may bet against you. Best, A -- Andrew Sullivan Dyn Labs asullivan@dyn.com
On Nov 28, 2012, at 12:00 PM, Mark Andrews wrote:
And using some tunnel brokers are just as easy.
<http://en.wikipedia.org/wiki/Curse_of_knowledge> ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 11/27/2012 09:20 PM, Dobbins, Roland wrote:
On Nov 28, 2012, at 12:00 PM, Mark Andrews wrote:
And using some tunnel brokers are just as easy.
<http://en.wikipedia.org/wiki/Curse_of_knowledge>
;>
When I subscribed I never dreamed I would post anything, as I am not a network engineer, but that also means I'm not cursed in the sense above ;) Just to add some anecdotal fuel to the fire, I'm a programmer who has had an HE tunnel working for several years. None of the programmers I know would have difficulty with that level of configuration. Programmers very often use various kinds of UNIX, and to my eye tunnel configuration is right about at the level of typical UNIX administration. We are also used to reading man pages. So there's one data point with the promise of others.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
-- 1024D/AA1FE38A http://www.atistar.net/~stepp/pgp.html :wq
On Nov 28, 2012, at 12:32 PM, Nigel Stepp wrote:
So there's one data point with the promise of others.
You are atypical in comparison the the legions of ordinary developers within enterprise organizations, in terms of your skillset, your breadth of perspective, and your ability to effectuate change within your organization.. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Nov 27, 2012, at 1:26 PM, david raistrick <drais@icantclick.org> wrote:
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer.
Given the number of network engineers compared to the number of tunnel broker subscribers just at Hurricane Electric, I don't think that argument holds water. We have actually made using a tunnel broker very easy and provide pretty complete configuration examples for many many platforms. The examples are customized to contain the configuration elements for your particular tunnel so in most cases they are basically copy-and-paste configurations.
oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc.
At work you may be limited to Teredo or not at all. In such a case, it's time to have a conversation with your networking group and raise awareness.
Until the orgs that support the developers find that v6 is a priority (through whatever means it happens - neteng/IT/etc pushing it up the chain or politics/marketing pushing it down the chain) and it's functional on the typical corp desktop, the typical corp application engineer is going to have no motivation (not to mention no time in his/her schedule to reengineer their platform) to support v6.
I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives. Owen
On 27 Nov 2012, at 23:44, Owen DeLong <owen@delong.com> wrote:
Given the number of network engineers compared to the number of tunnel broker subscribers just at Hurricane Electric, I don't think that argument holds water.
We have actually made using a tunnel broker very easy and provide pretty complete configuration examples for many many platforms. The examples are customized to contain the configuration elements for your particular tunnel so in most cases they are basically copy-and-paste configurations.
Indeed. Our students find it pretty straightforward, and they're (relatively) novice developers.
I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives.
I would hope so too. That said if applications are written well, much of the problems can be abstracted. There's been guidance out there for several years, e.g. RFC4038 and many similar white papers etc etc. Tim
On 11/27/2012 03:44 PM, Owen DeLong wrote:
I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives.
the only pushing that is generally possible is of the 'on string' variety. Mike
david raistrick <drais@icantclick.org> writes:
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer.
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all. Bjørn
On Nov 28, 2012, at 4:52 PM, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network?
If you don't think you're running some piece or another of software right this minute which was coded by someone incapable of setting up a test network, you're mistaken. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
"Dobbins, Roland" <rdobbins@arbor.net> writes:
On Nov 28, 2012, at 4:52 PM, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network?
If you don't think you're running some piece or another of software right this minute which was coded by someone incapable of setting up a test network, you're mistaken.
Maybe so. But do I _want_ do run that software? No. Anyway, I am not sure which programs that would be. The applications with open sockets on my laptop are currently: cupsd dhclient emacs gpsd gvfsd-http inetd mysqld named netserver ntpd rpcbind rpc.statd (squid) ssh sshd This is of course not a complete list of all applications I need to verify. I should add a number of client applications not currently running, and inetd may fire up proftpd and atftpd when necessary. But FWIW the only suspicious application I can see on that initial list is gvfsd-http. I don't know anything about the programmers behind that. I am pretty sure the people behind the rest of the software are capable of setting up a test network. Bjørn
On Nov 28, 2012, at 7:23 PM, Bjørn Mork wrote:
Anyway, I am not sure which programs that would be.
You run a lot more than that in your everyday life. And if you don't, you're atypical. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Maybe so. But do I _want_ do run that software? No.
Anyway, I am not sure which programs that would be. The applications with open sockets on my laptop are currently:
I take it you're in the minority who don't play games, use mobile apps on your phone, use a dvr....... or any SaaS applications accessable via the web, or indeed visit websites with shopping cart software, or CRM software, or blogs, or.... the large majority of software that interfaces to v4 networks does so through libraries and frameworks that seperate that part of the application stack from the part that the developer is building his code in. So really and truly most software is written by developers who can barely plug and play their home networks, much less actually understand what dhcp means. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
On Wed, Nov 28, 2012 at 2:52 AM, Bjørn Mork <bjorn@mork.no> wrote:
david raistrick <drais@icantclick.org> writes:
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer.
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all.
I would argue that creating software accesses the network requires some network engineering knowledge to some degree. And if a developer doesnt have that they can depend on a library written by someone who does.
Bjørn
-- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all.
So the software engineer should now -also- be responsible for, and capable of, recreating both the network as well as 3rd party systems that he/she has to code against? again focusing on just our last title release - 20+ 3rd party interfaces run by 6 different companies. Is the software engineer really responsible for faking things like xbox live, PSN, facebook, twitter, google, etc on a test network? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
On 2012-11-28 17:30 , david raistrick wrote:
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all.
So the software engineer should now -also- be responsible for, and capable of, recreating both the network as well as 3rd party systems that he/she has to code against?
again focusing on just our last title release - 20+ 3rd party interfaces run by 6 different companies. Is the software engineer really responsible for faking things like xbox live, PSN, facebook, twitter, google, etc on a test network?
Not for faking it, but in the case you mention it is very obvious that the software engineer should be able to ask their network team to make sure that they can access those API's if only for testing... In IPv6 that goes the same way: - either ask the local network team to get it for you - do it yourself Which might mean the person actually arranging it gets native or some kind of tunnel. And still, if you as a proper engineer where not able to test/add IPv6 code in the last 10++ years, then you did something very very wrong in your job, the least of which is to file a ticket for IPv6 support in the ticket tracking system so that one could state "I thought of it, company did not want it". Oh and remember: one can EASILY test this on a local network, link-local works fine, and one can also set up ULA or heck fake addresses to test this, or heck, loopback is also a great thing. Yes, that does not cover all scenarios, but it does cover most basic connectivity. Greets, Jeroen
On Wed, 28 Nov 2012, Jeroen Massar wrote:
Not for faking it, but in the case you mention it is very obvious that the software engineer should be able to ask their network team to make sure that they can access those API's if only for testing...
You're assuming, now, that the network team either a) works for the same arm of the company as the development team, and therefor can apply pressure on them or b) has support to build v6 into the system already (so they have time and resources to support the dev team), or c) gives a foo at all. Not to mention the time the dev team will spend spinning its wheels. Now, yes - if "ipv6 support" is a feature of the product they're building (and so driven and supported by management or marketing teams) then things could work as you suggest. But until such time as v6 support is something that they care about upstream...well. The 2 days of time you were budgeted to build the tool/feature/etc you're supposed to be working on isn't really going to include time to get v6 support in.
your job, the least of which is to file a ticket for IPv6 support in the ticket tracking system so that one could state "I thought of it, company did not want it".
funnily enough that's -exactly- what I've been doing for the last 3 years. So, until it comes down from the top, the company doesn't want it. ...david (who is not a developer and is a network engineer, but not in this job) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
On 11/28/2012 09:00 AM, Jeroen Massar wrote:
And still, if you as a proper engineer where not able to test/add IPv6 code in the last 10++ years, then you did something very very wrong in your job, the least of which is to file a ticket for IPv6 support in the ticket tracking system so that one could state "I thought of it, company did not want it".
It's very presumptuous for you to tell me what my development/test priorities ought to be, and I can tell you for absolute certain that any such badgering will be met with rolled eyes and quick dismissal. The only way that things will get fixed is if there's a perceived need to fix them. Getting corpro-IT to upgrade to v6 -- as if there is even a corpro-anything with most phone apps -- just to be able to test against v6 is a fantasy. Any developer who told me that we can't ship because we don't have a v6 testbed without clear feedback via bug reports, etc would be instructed on the difficulties of applying sufficient thermal energy to large bodies of water. The only way things are going to change is to make v6 a part of everybody's day-to-day life. That means ISP's giving me and every other developer a /64 at home at the very least. Mike
On 2012-11-28 18:26, Michael Thomas wrote:
On 11/28/2012 09:00 AM, Jeroen Massar wrote:
And still, if you as a proper engineer where not able to test/add IPv6 code in the last 10++ years, then you did something very very wrong in your job, the least of which is to file a ticket for IPv6 support in the ticket tracking system so that one could state "I thought of it, company did not want it".
It's very presumptuous for you to tell me what my development/test priorities ought to be, and I can tell you for absolute certain that any such badgering will be met with rolled eyes and quick dismissal.
You are missing the point that people have been told already for a decade to add IPv6 support to their products. As such, if you do not care, the only thing left when it does hit you is: the Internets told you so. See the rest of this thread which contains nice links to RFCs which also indicate that one should have been supporting IPv6 already years ago.
The only way that things will get fixed is if there's a perceived need to fix them.
I fully agree, but instead of waiting till the last moment you can also plan ahead and be ahead of the game. Do remember why there where so many of these "IPv4 address space is running out" counters and announcements. It is all to make you aware. Obviously you quickly dismissed that. That is your choice though.
Getting corpro-IT to upgrade to v6 -- as if there is even a corpro-anything with most phone apps -- just to be able to test against v6 is a fantasy.
Adding the infrastructure to be 99% there is already a good start. And that you already had a decade for to do. Phone Apps btw are only something from the last few years, thus you can't even claim there is a 'legacy' there and "IPv6 didn't exist yet" arguments don't go either. Note also that most devkits (Android/IOS) provide IP-agnostic APIs, thus if used you at least have nothing IPv6-specific in that code. Also, google(eva ipv6) for a very nice simple tutorial on moving your apps from IPv4 to IPv4/IPv6. You do not need to test on IPv6 or fully support it yet, but at least you know that when you get IPv6 connectivity it most very likely just works.
The only way things are going to change is to make v6 a part of everybody's day-to-day life. That means ISP's giving me and every other developer a /64 at home at the very least.
And that is happening, I hope you are ready to support those users because well, everybody told you it would happen, thus don't cry when you are too late at the game... (of course, some people simply do not care about the job they deliver, but in that case, it is also wise to not comment on a public list about things ;) Greets, Jeroen
On 11/28/2012 09:40 PM, Jeroen Massar wrote:
On 2012-11-28 18:26, Michael Thomas wrote:
It's very presumptuous for you to tell me what my development/test priorities ought to be, and I can tell you for absolute certain that any such badgering will be met with rolled eyes and quick dismissal.
You are missing the point that people have been told already for a decade to add IPv6 support to their products.
Programmers are routinely "told" all manner of apocalyptic things, and that they're idiots for not heeding the soothsayers. Ho Hum. At least Y2K had a finite stopping point. When v6 gets one of those, maybe you'll have more luck.
The only way that things will get fixed is if there's a perceived need to fix them. I fully agree, but instead of waiting till the last moment you can also plan ahead and be ahead of the game.
Please. When there's deployment, there will be fixes. The *vast* majority of the problem is with ISP's. This isn't even an 80-20 problem, it's a 1% problem. All you're managing to do here is tick off developers as if they are in any way, shape, or form responsible for the lack of v6 deployment.
Phone Apps btw are only something from the last few years, thus you can't even claim there is a 'legacy' there and "IPv6 didn't exist yet" arguments don't go either. Note also that most devkits (Android/IOS) provide IP-agnostic APIs, thus if used you at least have nothing IPv6-specific in that code.
Phone apps, by and large, are designed by people in homes or small companies. They do not have v6 connectivity. Full stop. They don't care about v6. Full stop. It's not their fault, even if you think they should invest a significant amount of time to fix theoretical problems.
The only way things are going to change is to make v6 a part of everybody's day-to-day life. That means ISP's giving me and every other developer a /64 at home at the very least. And that is happening, I hope you are ready to support those users because well, everybody told you it would happen, thus don't cry when you are too late at the game...
It sure isn't happening in Silly Valley or San Francisco that I've seen.
(of course, some people simply do not care about the job they deliver, but in that case, it is also wise to not comment on a public list about things ;)
All your patronizing tone does is fix you for a religious zealot. You're a dime a dozen and ignorable. Telling people they're incompetent because they won't fix your hobby-horse theoretical problem does exactly the opposite of what you want. Developers and the companies that employ them react to perceived need for bugs and features. When there is a perceived need, the bugs will be fixed. Until then, by all means rant on while the actual problem (ISP's) do nothing. Mike
Got some bad data here. Let me help. Sent from ipv6-only Android On Nov 29, 2012 8:22 AM, "Michael Thomas" <mike@mtcc.com> wrote:
Phone apps, by and large, are designed by people in homes or small companies. They do not have v6 connectivity. Full stop. They don't care about v6. Full stop. It's not their fault, even if you think they should invest a significant amount of time to fix theoretical problems.
Phone apps generally work with ipv6 since they are developed using high level and modern sdk's. My sample says over 85% of Android Market top apps work fine on ipv6. For folks to really get in trouble they need to be using NDK... that is where the ipv4-only apis live, not SDK afaik ... NDK implies greater knowledge and risk in Android. The apps that fail are not from noobies in a garage. The failures are from Microsoft/Skype , Netflix , Amazon Prime streaming , Spotify and other well heeled folks that are expected to champion technology evolution. And, Microsoft and Netflix were certainly part of world v6 launch. They just have more work to do. I have more work to do. Vzw and T-mobile USA both have ipv6. So, please note: most Android apps work on v6. Millions of mobile phone subscribers have ipv6 (all vzw LTE by default, all t-mobile samsung by phone configuration). The problem apps are from top tech companies, not garage devs. CB
On 11/29/2012 10:36 AM, Cameron Byrne wrote:
Got some bad data here. Let me help.
Sent from ipv6-only Android On Nov 29, 2012 8:22 AM, "Michael Thomas" <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
Phone apps, by and large, are designed by people in homes or small companies. They do not have v6 connectivity. Full stop. They don't care about v6. Full stop. It's not their fault, even if you think they should invest a significant amount of time to fix theoretical problems.
Phone apps generally work with ipv6 since they are developed using high level and modern sdk's.
My sample says over 85% of Android Market top apps work fine on ipv6. For folks to really get in trouble they need to be using NDK... that is where the ipv4-only apis live, not SDK afaik ... NDK implies greater knowledge and risk in Android.
The apps that fail are not from noobies in a garage. The failures are from Microsoft/Skype , Netflix , Amazon Prime streaming , Spotify and other well heeled folks that are expected to champion technology evolution. And, Microsoft and Netflix were certainly part of world v6 launch. They just have more work to do.
Ie, the referral problem. One would expect those to have problems because referrals suck generally, and are tangled up horrifically with NAT traversal. I don't really worry about those guys so much because it's just a business case rather than cluelessness. The fact that they aren't getting bit hard enough to make that business case says something. Which is why all of this gnashing of the teeth toward developers is wildly off the mark. It's the network that's the problem.
So, please note: most Android apps work on v6. Millions of mobile phone subscribers have ipv6 (all vzw LTE by default, all t-mobile samsung by phone configuration). The problem apps are from top tech companies, not garage devs.
Yeah, I just checked having switch to vzw yesterday: Galaxy S3 ipv6, iphone5 ipv4. Mike
david raistrick <drais@icantclick.org> writes:
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all.
So the software engineer should now -also- be responsible for, and capable of, recreating both the network as well as 3rd party systems that he/she has to code against?
I am not claiming that every engineer in a big project should have all knowledge necessary to complete the project, or have the responsibility for every task in the project. But defining and configuring a suitable test environment is an absolute requirement for any software project. So *someone* in a network software development project will need to know how to set up networking for the testing.
again focusing on just our last title release - 20+ 3rd party interfaces run by 6 different companies. Is the software engineer really responsible for faking things like xbox live, PSN, facebook, twitter, google, etc on a test network?
If your application interface with those services and you expect those parts of the application to work, then I'd say so, yes. There may be occasional exceptions from this rule, but most of the time you'll find that any untested parts of an application does not work. Now I'd guess that most of those services also offer a test environment. You will of course primarily use that. The claim wrt IPv6 was that it was too difficult to use existing test enviroments. The degree of real world simulation you need for testing will of course vary. It's not like a hobbyist Android app developer must set up his own cellular network. Running the app in an emulator is likely enough for most uses, including IPv6 testing. This discussion seem to go off into the wild, so I am not sure there is any point continuing it. But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software. That's simply not possible. If it fails on IPv6 then it is guaranteed to fail on IPv4 as well, only less obvious ond therefore more dangerous. The claim that missing IPv6 support in software has anything to do with the lack of native IPv6 internet access is just stupid. You may wonder how anyone could develop a new protocol, or microcode for a new CPU, or a driver for a new hardware device, or anything at all really. You just cannot count on having access to a full scale production environment during software development. You will have to find some way to simulate the missing parts. Native IPv6 internet access has never been a requirement for developing IPv6 aware applications. That was a bad excuse even 10 years ago. Today it is just ridiculous. Bjørn
On Wed, 28 Nov 2012, Bjørn Mork wrote:
Native IPv6 internet access has never been a requirement for developing IPv6 aware applications. That was a bad excuse even 10 years ago. Today it is just ridiculous.
I certainly never said that was the case. I built v6 test networks, and helped kernel devs build v6 support into firewall appliances 10 years ago. But it wasn't a feature that drove sales... My argument is that a) typical developers don't develop microcode, kernel drivers, or protocols. But they DO build a lot of applications that sit on top of them. They build them because someone is paying them to do it. The folks that sign the checks ask for A B and C. And v6 isn't one of those things yet. Some day, maybe it will be. We're just not there yet. (yes. when we get there it's going to be too late. no argument.) in the meantime there's still a ton of new and old stuff to build w/o v6 support from our internal or external vendors. ...david -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
On Wed, 28 Nov 2012, david raistrick wrote:
folks that sign the checks ask for A B and C. And v6 isn't one of those things yet.
I believe they ask for the apps to work on the "Internet". Part of that requirement is soon to be a requirement for IPv6 support. I believe the person signing the checks never asked for IPv4 support. -- Mikael Abrahamsson email: swmike@swm.pp.se
Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... Date: Wed, Nov 28, 2012 at 06:45:54PM +0100 Quoting Mikael Abrahamsson (swmike@swm.pp.se):
I believe they ask for the apps to work on the "Internet". Part of that requirement is soon to be a requirement for IPv6 support.
It is so already. IPv6 Support Required for All IP-Capable Nodes Abstract Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. RFC 6540 / BCP 177
I believe the person signing the checks never asked for IPv4 support.
Probably not. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... this must be what it's like to be a COLLEGE GRADUATE!!
I have read a little of this BS thread. 1) I have been maintaining a network for 12 years. 2) I am and have been since Feb 1965 a programmer. Anyone who bashes either group has a problem. First, at one time programmers knew bits, bytes, opcodes, machine codes etc. I have written close to thirty languages and probably could write most of them now with a couple hours to browse a manual. I have done everything from punchdowns and crimping connectors to routing and ACL's. Sure there is a lot I do not know. But most of what academia has turned out in the last twenty years is people who know the left half of the byte but not the right. Today they don't even have an idea what happens. I am not sure some of them know that a computer runs on electricity. And it is nearly as bad in Networking as it is in Programming, Data Base, etc. We are building "experts" who have learned more and more about less and less till they know everything about nothing. You need six of them to plug in a router. Somewhere we need some of them to get out of their little silo, find out that there is a world out there and learn what the other guy does. When that happens the finger pointing that was just done here will not happen. Ralph Brandt
On Nov 29, 2012, at 12:18 AM, Bjørn Mork wrote:
But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software.
Who's talking about 'networking software'? 'Networking software' is irrelevant for the vast majority of the userbase. I'm talking about ordinary applications which do stupid things like edit documents and calculate payroll runs. The main points I've taken away from this discussion is that a non-trivial proportion of ISP operational personnel have no idea what life is like within the enterprise organizations which are their customers; that they have a grossly exaggerated view of the skillsets, levels of engagement, and degrees of empowerment amongst run-of-the-mill software developers; and that they are either incapable of or are unwilling to step down from the rarified atmospheres of the technical heights they inhabit relative to the hoi polloi and even attempt to understand the constraints under which they operate. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
In message <CFB0F4DE-3E7E-4CC2-A491-3B0E9741CF38@arbor.net>, "Dobbins, Roland" writes:
On Nov 29, 2012, at 12:18 AM, Bj=F8rn Mork wrote:
But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software.
Who's talking about 'networking software'?
Read the Subject.
'Networking software' is irrelevant for the vast majority of the userbase. I'm talking about ordinary applications which do stupid things like edit documents and calculate payroll runs.
The main points I've taken away from this discussion is that a non-trivial proportion of ISP operational personnel have no idea what life is like within the enterprise organizations which are their customers; that they have a grossly exaggerated view of the skillsets, levels of engagement, and degrees of empowerment amongst run-of-the-mill software developers; and that they are either incapable of or are unwilling to step down from the rarified atmospheres of the technical heights they inhabit relative to the hoi polloi and even attempt to understand the constraints under which they operate.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 29, 2012, at 7:42 AM, Mark Andrews wrote:
Read the Subject.
Nothing about 'networking software' there . . . Unless your definition of 'networking software' is 'software which has an inherent capability to transmit/receive data over the network', which would include lots of lots of software. To me, 'networking software' means 'software which is intended to facilitate network communications', which is a more restricted subset. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
"Dobbins, Roland" <rdobbins@arbor.net> writes:
On Nov 29, 2012, at 12:18 AM, Bjørn Mork wrote:
But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software.
Who's talking about 'networking software'? 'Networking software' is irrelevant for the vast majority of the userbase. I'm talking about ordinary applications which do stupid things like edit documents and calculate payroll runs.
If it doesn't do IPv4 then I don't see the need for IPv6 support. Bjørn
On Nov 29, 2012, at 4:28 PM, Bjørn Mork wrote:
If it doesn't do IPv4 then I don't see the need for IPv6 support.
To me, 'networking software' <> software which happens to access the network. Quagga is an example of 'networking software'. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
"Dobbins, Roland" <rdobbins@arbor.net> writes:
On Nov 29, 2012, at 4:28 PM, Bjørn Mork wrote:
If it doesn't do IPv4 then I don't see the need for IPv6 support.
To me, 'networking software' <> software which happens to access the network. Quagga is an example of 'networking software'.
OK, that makes sense. What's the proper term for software which happens to access the network? Bjørn
On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote:
What's the proper term for software which happens to access the network?
Just about anything, these days. ;> 'Network-enabled' or 'network-capable' software, maybe? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 29 November 2012 12:48, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote:
What's the proper term for software which happens to access the network?
Just about anything, these days.
;>
'Network-enabled' or 'network-capable' software, maybe?
Connecting a app to a network is a fundamental change, so perhaps change the app to become a "network app". A piece of software connected to a network turns from a product into a service. "Programmers" is to a wide group of people. I am PHP programmer. How will ipv6 impact me? nothing, probably. Having to deal with ip stuff and low level networking stuff only affect a subset of programmers. It may break curl, or some sockets implementation of this and that, then I will download a replacement class that is ipv6 aware. There are two groups of programmers, a) these that have programming only as a job, and b) these that invest time beyond that. The first group is obviously not ready for ipv6 at all, maybe have not even heard about ipv6...and will not know anything about it until is something obligatory. Perhaps this also happens in other groups of people... most people reading mail-list are probably of the B group. -- -- ℱin del ℳensaje.
On 2012-11-29 13:53 , . wrote:
On 29 November 2012 12:48, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote:
What's the proper term for software which happens to access the network?
Just about anything, these days.
;>
'Network-enabled' or 'network-capable' software, maybe?
Connecting a app to a network is a fundamental change, so perhaps change the app to become a "network app". A piece of software connected to a network turns from a product into a service.
"Programmers" is to a wide group of people. I am PHP programmer. How will ipv6 impact me? nothing, probably.
*ahem* As Owen already alluded to, some programs (PHP also) actually store IP addresses in databases. Thus if you where storing those as 32bit, you are out of luck. [..]
There are two groups of programmers, a) these that have programming only as a job, and b) these that invest time beyond that.
Group a for you? :) Greets, Jeroen
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do. Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements). http://soucy.org/project/inet6/ I would point out that many developers don't even store IP addresses correctly and just treat them as a string. In regards to storing as a pair of 64-bit integers, I would caution against the temptation of treating one field as the prefix and the other as the host segment. While the 64-bit boundary is most common, it is certainly not required, so please write your IPv6 support in a way that will allow any valid prefix-length. While PHP hasn't been my language of choice in the past, it seems to be something that almost everyone knows, or can learn very quickly. I've started using it as a command line scripting language quite a bit as a result ... pretty much a cleaner Perl, the upshot is that you don't have all the pre-written libraries that you'd find with Perl. I've tried switching to Python for some things, but I got annoyed with the specification being in a constant state of drastic syntax change. But back to the topic at hand. I think the OP was expressing that until developers have native IPv6 access at home, they just won't care about IPv6 support, or won't test it as well as IPv4 support. That's pretty much expected and I'm not even sure why it's being stated as some revelation. As many have pointed out, there are tunnel brokers available to developers to test IPv6 with, but at the end of the day, most people don't want to use a slow tunnel for anything byond testing, and if they don't have a lot of users asking for IPv6 they're probably not going to give it much attention until they see a need for it. The majority of larger applications support IPv6 just fine because there are enough users asking for IPv6 support. I suspect once you see native IPv6 for residential users become more common you'll see the developers who have been dragging their feet give in and add IPv6 support. As mentioned with a shift to web applications though the browser, it's been a lot less work. Just throw your application on a server with IPv6 and it will generally work. You might need to modify a few places that interact with IP addresses, but usually they're pretty trivial (like logging) unless it's a network management oriented application. On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-11-29 13:53 , . wrote:
On 29 November 2012 12:48, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote:
What's the proper term for software which happens to access the network?
Just about anything, these days.
;>
'Network-enabled' or 'network-capable' software, maybe?
Connecting a app to a network is a fundamental change, so perhaps change the app to become a "network app". A piece of software connected to a network turns from a product into a service.
"Programmers" is to a wide group of people. I am PHP programmer. How will ipv6 impact me? nothing, probably.
*ahem*
As Owen already alluded to, some programs (PHP also) actually store IP addresses in databases. Thus if you where storing those as 32bit, you are out of luck.
[..]
There are two groups of programmers, a) these that have programming only as a job, and b) these that invest time beyond that.
Group a for you? :)
Greets, Jeroen
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
Hi Ray, I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range. Bytes are cheap and query simplicity is important. Multi-element indexes are messy and the code to manage an array of integers is messier than managing a character string in most programming languages. memcmp() that integer array for less or greater than? Not on a little endian machine!
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
If we're plugging our code, give my public domain libeasyv6 a try. It eases entry into dual stack programming for anyone used to doing gethostbyname followed by a blocking connect(). Just do a connectbyname() with the hostname or textual IP address, the port, a timeout and null options. The library takes care of finding a working IPv4 or IPv6 address for the host and connecting to it in a timely manner. http://bill.herrin.us/freebies/ Currently Linux only but if you're willing to lose timeout control on the DNS lookup you can replace getaddrinfo_a() with standard getaddrinfo() and the code should run anywhere. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Hadn't thought about it that way before. This was a useful bit of info, thanks. -Blake On Thu, Nov 29, 2012 at 8:55 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
Hi Ray,
I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range.
Bytes are cheap and query simplicity is important. Multi-element indexes are messy and the code to manage an array of integers is messier than managing a character string in most programming languages. memcmp() that integer array for less or greater than? Not on a little endian machine!
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
If we're plugging our code, give my public domain libeasyv6 a try. It eases entry into dual stack programming for anyone used to doing gethostbyname followed by a blocking connect(). Just do a connectbyname() with the hostname or textual IP address, the port, a timeout and null options. The library takes care of finding a working IPv4 or IPv6 address for the host and connecting to it in a timely manner.
http://bill.herrin.us/freebies/
Currently Linux only but if you're willing to lose timeout control on the DNS lookup you can replace getaddrinfo_a() with standard getaddrinfo() and the code should run anywhere.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... Date: Thu, Nov 29, 2012 at 09:55:19AM -0500 Quoting William Herrin (bill@herrin.us):
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
Hi Ray,
I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range.
No, you are both worng. The answer is simple and practical: Use a database that has a modern IP adress database type. Like Postgres. Its IP-adress data types understand and parse both adress strings and network strings (and, of course -- a network with the proper netmask set might be interpreted like a host.) The 32-bit integer trick might, just might make do for IPv4, but a proper data type is so much simpler to use. <non-technical ranting part> Also, stepping away from MySQL or Oracle makes Larry less powerful. </non-technical ranting part> -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I am covered with pure vegetable oil and I am writing a best seller!
I'll see your disagree and raise you another ;-) I would say you almost never want to store addresses as character data unless the only thing you're using them for is logging (even then it's questionable). I run into people who do this all the time and it's a nightmare. It's easy to store a v6 address as a string, but when you want to select a range of IPv6 addresses from a database, not having them represented as integers means you can't do efficient numerical comparisons in your SQL statements, it also makes indexing your table slower; to put it simply, it doesn't scale well. So as a general rule, if you need to do any comparison or calculation on a v6 address, please don't store it as a string.
From an efficiency standpoint, you want to store it in chunks of the largest integer your DBMS supports. If a DBMS supports 128-bit integers and has optimized operations for them, then go for it. Most only support 64-, or even 32-bit. I say 64-bit because that's what the majority of current systems actually support and I don't see anyone coming out with a 128-bit architecture ;(
For convenience I would very much love to see MySQL include inet6_aton and inet6_ntoa, along with a 128-bit data structure that would be implemented as either a pair of 64-bit or 4x 32-bit values depending on the architecture. But from a performance standpoint, I really don't want my DBMS doing that calculation; I want the application server doing it (because it's much easier to scale and distribute the application side than the storage side). Note that I'm talking about more from a database storage perspective than an internal application perspective. By all means, you should use the standard data structure for v6. As mentioned below a lot of the internal structures use 8-bit unsigned integers (or char); but that's mainly a hold-over from when we had the reality of 8-bit and 16-bit platforms (for compatibility). With unions, these structs are treated as a collection of 8, 16, 32, 64 or a single 128-bit variable which makes it something the developer doesn't need to worry about once the libraries are written. On Thu, Nov 29, 2012 at 9:55 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
Hi Ray,
I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range.
Bytes are cheap and query simplicity is important. Multi-element indexes are messy and the code to manage an array of integers is messier than managing a character string in most programming languages. memcmp() that integer array for less or greater than? Not on a little endian machine!
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
If we're plugging our code, give my public domain libeasyv6 a try. It eases entry into dual stack programming for anyone used to doing gethostbyname followed by a blocking connect(). Just do a connectbyname() with the hostname or textual IP address, the port, a timeout and null options. The library takes care of finding a working IPv4 or IPv6 address for the host and connecting to it in a timely manner.
http://bill.herrin.us/freebies/
Currently Linux only but if you're willing to lose timeout control on the DNS lookup you can replace getaddrinfo_a() with standard getaddrinfo() and the code should run anywhere.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
On 11/30/2012 09:45 AM, Ray Soucy wrote:
I'll see your disagree and raise you another ;-)
I would say you almost never want to store addresses as character data unless the only thing you're using them for is logging (even then it's questionable). I run into people who do this all the time and it's a nightmare.
It's easy to store a v6 address as a string, but when you want to select a range of IPv6 addresses from a database, not having them represented as integers means you can't do efficient numerical comparisons in your SQL statements, it also makes indexing your table slower; to put it simply, it doesn't scale well.
So as a general rule, if you need to do any comparison or calculation on a v6 address, please don't store it as a string.
From an efficiency standpoint, you want to store it in chunks of the largest integer your DBMS supports. If a DBMS supports 128-bit integers and has optimized operations for them, then go for it. Most only support 64-, or even 32-bit. I say 64-bit because that's what the majority of current systems actually support and I don't see anyone coming out with a 128-bit architecture ;(
For convenience I would very much love to see MySQL include inet6_aton and inet6_ntoa, along with a 128-bit data structure that would be implemented as either a pair of 64-bit or 4x 32-bit values depending on the architecture. But from a performance standpoint, I really don't want my DBMS doing that calculation; I want the application server doing it (because it's much easier to scale and distribute the application side than the storage side). Postgresql has an inet data type that handles both ipv4 and ipv6 addresses with a slew of functions to manipulate the data type.
http://www.postgresql.org/docs/8.4/static/functions-net.html
Note that I'm talking about more from a database storage perspective than an internal application perspective.
By all means, you should use the standard data structure for v6. As mentioned below a lot of the internal structures use 8-bit unsigned integers (or char); but that's mainly a hold-over from when we had the reality of 8-bit and 16-bit platforms (for compatibility). With unions, these structs are treated as a collection of 8, 16, 32, 64 or a single 128-bit variable which makes it something the developer doesn't need to worry about once the libraries are written.
On Thu, Nov 29, 2012 at 9:55 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do. Hi Ray,
I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range.
Bytes are cheap and query simplicity is important. Multi-element indexes are messy and the code to manage an array of integers is messier than managing a character string in most programming languages. memcmp() that integer array for less or greater than? Not on a little endian machine!
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
http://soucy.org/project/inet6/ If we're plugging our code, give my public domain libeasyv6 a try. It eases entry into dual stack programming for anyone used to doing gethostbyname followed by a blocking connect(). Just do a connectbyname() with the hostname or textual IP address, the port, a timeout and null options. The library takes care of finding a working IPv4 or IPv6 address for the host and connecting to it in a timely manner.
http://bill.herrin.us/freebies/
Currently Linux only but if you're willing to lose timeout control on the DNS lookup you can replace getaddrinfo_a() with standard getaddrinfo() and the code should run anywhere.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com
- Well I want to add my 10 cents, I am a c++ programmer, and have been waiting for my isp to offer native ipv6 for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So once I got that done, I spent only an hour updating my socket classes to support ipv6. I hadent done so before because I never had ipv6 access, * I don't release code without testing it first *. It wasn't difficult to update to ipv6, only some reading was needed, don't know what the fuss is =D
On Fri, Nov 30, 2012 at 5:18 PM, Randy <nanog@afxr.net> wrote:
- Well I want to add my 10 cents, I am a c++ programmer, and have been waiting for my isp to offer native ipv6 for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So once I got that done, I spent only an hour updating my socket classes to support ipv6. I hadent done so before because I never had ipv6 access, * I don't release code without testing it first *.
It wasn't difficult to update to ipv6, only some reading was needed, don't know what the fuss is =D
Go test it against a dual stack remote host with the Tunnel's addresses still configured on your hosts but packet filtering set to silently drop packets on the IPv6 tunnel. Then work through the implications of what you observe. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <CAP-guGWTcOAfeNKQSxsssoMXMY1SqS2ofaPrV26wW+GfVfpXyQ@mail.gmail.com>, William Herrin writes:
On Fri, Nov 30, 2012 at 5:18 PM, Randy <nanog@afxr.net> wrote:
- Well I want to add my 10 cents, I am a c++ programmer, and have been waiting for my isp to offer native ipv6 for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So once I got that done, I spent only an hour updating my socket classes to support ipv6. I hadent done so before because I never had ipv6 access, * I don't release code without testing it first *.
It wasn't difficult to update to ipv6, only some reading was needed, don't know what the fuss is =D
Go test it against a dual stack remote host with the Tunnel's addresses still configured on your hosts but packet filtering set to silently drop packets on the IPv6 tunnel. Then work through the implications of what you observe.
Go test your IPv4 code against a half broken multi-homed server. There is no difference. You either have good mutli-homed support or not in your code. With dual stack everything is multi-homed so no more ignoring the issue.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Nov 30, 2012 at 6:12 PM, Mark Andrews <marka@isc.org> wrote:
In message <CAP-guGWTcOAfeNKQSxsssoMXMY1SqS2ofaPrV26wW+GfVfpXyQ@mail.gmail.com>, William Herrin writes:
On Fri, Nov 30, 2012 at 5:18 PM, Randy <nanog@afxr.net> wrote:
It wasn't difficult to update to ipv6, only some reading was needed, don't know what the fuss is =D
Go test it against a dual stack remote host with the Tunnel's addresses still configured on your hosts but packet filtering set to silently drop packets on the IPv6 tunnel. Then work through the implications of what you observe.
Go test your IPv4 code against a half broken multi-homed server. There is no difference.
Which is why the common and successful strategy in engineering a reliable IPv4 system is to use a single IP address for each service and let BGP handle multihoming. Using a single IP address is no longer possible for dual-stacked hosts, so your dual stacked client code has to handle it instead.
With dual stack [...] no more ignoring the issue.
Exactly. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy <rps@maine.edu> wrote:
I'll see your disagree and raise you another ;-)
I would say you almost never want to store addresses as character data unless the only thing you're using them for is logging (even then it's questionable). I run into people who do this all the time and it's a nightmare.
It's easy to store a v6 address as a string, but when you want to select a range of IPv6 addresses from a database, not having them represented as integers means you can't do efficient numerical comparisons in your SQL statements, it also makes indexing your table slower; to put it simply, it doesn't scale well.
Hi Ray, If you've stored them in the string format I suggested, the string comparison *is* an efficient numerical comparison. On a CISC processor it may even be implemented with a single instruction byte string comparison. Go test. You may be surprised at the results. The one useful function you can't do directly from a string format is apply an AND mask (netmask). More often than not this is irrelevant: you don't want to load the data and then apply the mask, you want the mask to constrain the data which you load from the database. You'd need the database software to understand the address type and index it with a radix tree, something it can do with neither a string format nor your split 64-bit format. In either case you substitute query by range for query by netmask. WHERE IP>='A' AND IP<='B' WHERE (IPHigh>AHigh AND IPHigh<BHigh) OR (IPHigh=AHigh AND IPHigh!=BHigh IPLow>=ALow) OR (IPHigh!=AHigh AND IPHigh=BHigh AND IPLow<=BLow) OR (IPHigh=AHigh AND IPHigh=BHigh AND IPLow>=ALow AND IPLow<=BLow) Which version looks more efficient to you? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Nov 30, 2012, at 11:09 AM, William Herrin <bill@herrin.us> wrote:
On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy <rps@maine.edu> wrote:
I'll see your disagree and raise you another ;-)
I would say you almost never want to store addresses as character data unless the only thing you're using them for is logging (even then it's questionable). I run into people who do this all the time and it's a nightmare.
It's easy to store a v6 address as a string, but when you want to select a range of IPv6 addresses from a database, not having them represented as integers means you can't do efficient numerical comparisons in your SQL statements, it also makes indexing your table slower; to put it simply, it doesn't scale well.
Hi Ray,
If you've stored them in the string format I suggested, the string comparison *is* an efficient numerical comparison. On a CISC processor it may even be implemented with a single instruction byte string comparison. Go test. You may be surprised at the results.
The one useful function you can't do directly from a string format is apply an AND mask (netmask). More often than not this is irrelevant: you don't want to load the data and then apply the mask, you want the mask to constrain the data which you load from the database. You'd need the database software to understand the address type and index it with a radix tree, something it can do with neither a string format nor your split 64-bit format.
Since non-contiguous masking is rare, this can, actually be pretty efficient for contiguous masking because you have a ¼ chance that the mask aligns with a character (the more I think about this, the more I think storing the address as a 32-character string without colons makes the most sense). If it's not aligned on a nibble boundary, then you can either do ranged comparisons as suggested below, or, you can do a two-step process like this: Let's say we want to look for addresses within 2001:db8::/29. This would mean we need to match all strings starting with 2001:0db8 through 2001:0dbf. We could easily grab everything that begins with '20010db%' and then select the masked values matching from the 8th column where (atoi(concat("0x",substr(addr,8,1))) & 0x8). Forgive me if I don't get the SQL syntax exactly right or have a wrong function name… I do more C than SQL. Both of these comparisons could be performed in a single select like: SELECT * FROM <table> WHERE ip6addr is like '20010db%' and \ (atoi(concat('0x', substr(ip6addr,8,1))) & 0x8) This should be relatively efficient because the more expensive second test will only be performed on records that first pass the relatively cheap match of the first 7 characters. Owen
In message <CALFTrnM+a56hx3CP0qqszfNrbirQZOefS_0uHVC8VQk=+QDC2g@mail.gmail.com> , Ray Soucy writes:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
I did it as a array of 8, 16 bit integers with a old version of dhclient. The had the advantage that you could just do "%x:%x:%x:%x:%x:%x:%x:%x" and get a valid IPv6 address which you could feed to other tools. option 6rd code 212 = { unsigned integer 8, unsigned integer 8, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, array of ip-address };
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
http://soucy.org/project/inet6/
I would point out that many developers don't even store IP addresses correctly and just treat them as a string. In regards to storing as a pair of 64-bit integers, I would caution against the temptation of treating one field as the prefix and the other as the host segment. While the 64-bit boundary is most common, it is certainly not required, so please write your IPv6 support in a way that will allow any valid prefix-length.
While PHP hasn't been my language of choice in the past, it seems to be something that almost everyone knows, or can learn very quickly. I've started using it as a command line scripting language quite a bit as a result ... pretty much a cleaner Perl, the upshot is that you don't have all the pre-written libraries that you'd find with Perl. I've tried switching to Python for some things, but I got annoyed with the specification being in a constant state of drastic syntax change.
But back to the topic at hand. I think the OP was expressing that until developers have native IPv6 access at home, they just won't care about IPv6 support, or won't test it as well as IPv4 support. That's pretty much expected and I'm not even sure why it's being stated as some revelation. As many have pointed out, there are tunnel brokers available to developers to test IPv6 with, but at the end of the day, most people don't want to use a slow tunnel for anything byond testing, and if they don't have a lot of users asking for IPv6 they're probably not going to give it much attention until they see a need for it.
It is a myth that tunnels are slow. They have to add some delay but depending upon the placement of the end point that may not even be measurable. I'm using one on another continent and for most of my traffic it has no measurable impact on the time. Some detinations are significantly worse. Tunneling with 6rd will generally not be measurable for any destination especially if you put the BR in the pop.
The majority of larger applications support IPv6 just fine because there are enough users asking for IPv6 support. I suspect once you see native IPv6 for residential users become more common you'll see the developers who have been dragging their feet give in and add IPv6 support.
As mentioned with a shift to web applications though the browser, it's been a lot less work. Just throw your application on a server with IPv6 and it will generally work. You might need to modify a few places that interact with IP addresses, but usually they're pretty trivial (like logging) unless it's a network management oriented application.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Why would I want to do that instead of store it as a single 128 bit integer or bit-field? Owen Sent from my iPad On Nov 29, 2012, at 6:01 AM, Ray Soucy <rps@maine.edu> wrote:
You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do.
Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements).
http://soucy.org/project/inet6/
I would point out that many developers don't even store IP addresses correctly and just treat them as a string. In regards to storing as a pair of 64-bit integers, I would caution against the temptation of treating one field as the prefix and the other as the host segment. While the 64-bit boundary is most common, it is certainly not required, so please write your IPv6 support in a way that will allow any valid prefix-length.
While PHP hasn't been my language of choice in the past, it seems to be something that almost everyone knows, or can learn very quickly. I've started using it as a command line scripting language quite a bit as a result ... pretty much a cleaner Perl, the upshot is that you don't have all the pre-written libraries that you'd find with Perl. I've tried switching to Python for some things, but I got annoyed with the specification being in a constant state of drastic syntax change.
But back to the topic at hand. I think the OP was expressing that until developers have native IPv6 access at home, they just won't care about IPv6 support, or won't test it as well as IPv4 support. That's pretty much expected and I'm not even sure why it's being stated as some revelation. As many have pointed out, there are tunnel brokers available to developers to test IPv6 with, but at the end of the day, most people don't want to use a slow tunnel for anything byond testing, and if they don't have a lot of users asking for IPv6 they're probably not going to give it much attention until they see a need for it.
The majority of larger applications support IPv6 just fine because there are enough users asking for IPv6 support. I suspect once you see native IPv6 for residential users become more common you'll see the developers who have been dragging their feet give in and add IPv6 support.
As mentioned with a shift to web applications though the browser, it's been a lot less work. Just throw your application on a server with IPv6 and it will generally work. You might need to modify a few places that interact with IP addresses, but usually they're pretty trivial (like logging) unless it's a network management oriented application.
On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-11-29 13:53 , . wrote:
On 29 November 2012 12:48, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote:
What's the proper term for software which happens to access the network?
Just about anything, these days.
;>
'Network-enabled' or 'network-capable' software, maybe?
Connecting a app to a network is a fundamental change, so perhaps change the app to become a "network app". A piece of software connected to a network turns from a product into a service.
"Programmers" is to a wide group of people. I am PHP programmer. How will ipv6 impact me? nothing, probably.
*ahem*
As Owen already alluded to, some programs (PHP also) actually store IP addresses in databases. Thus if you where storing those as 32bit, you are out of luck.
[..]
There are two groups of programmers, a) these that have programming only as a job, and b) these that invest time beyond that.
Group a for you? :)
Greets, Jeroen
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
On 11/27/2012 01:26 PM, david raistrick wrote:
On Tue, 27 Nov 2012, Jeroen Massar wrote:
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
bull. explain using a tunnel broker to anyone who isn't a network engineer.
Old threat, I know... I am not calling myself a network "engineer" but I got the that ipv6 tunnelling working very well, from corporate offices spanning 3 continents to my own virtual servers and humble home DSL. The only thing it requires is to not be intellectually challenged and have a desire to get it working. Then you can do it in a couple of hours. Excellent read: http://madduck.net/docs/ipv6/ Greetings, Jeroen -- Earthquake Magnitude: 5.1 Date: Friday, December 14, 2012 17:46:45 UTC Location: New Ireland region, Papua New Guinea Latitude: -5.2589; Longitude: 153.4126 Depth: 36.70 km
On 11/27/2012 01:07 PM, Jeroen Massar wrote:
On 2012-11-27 20:21, mike wrote:
This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around with, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life. I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6. Especially as APIs like getaddrinfo() make it really easy to do so.
I think you vastly overestimate that developers will a) know about v6 and b) care even if they do if it's not affecting them. Asking mortals to understand tunnel brokers -- even developer mortals -- just isn't going to happen. If we want the small percentage of apps that break with v6 to be fixed, it needs to a) show up as a bug report from enough people to matter and b) need to be testable by your average developer. This chicken and egg problem can really only be solved by ISP's, IMO. Mike
On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar <jeroen@unfix.org> wrote:
I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6.
Your lack of sorrow is immaterial to the programmers in question. And in the vast majority of cases the network is incidental to their software's role. The network is the tool not the product. They'll use the available tool.
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
At home sure. If they're willing to go to a little bit of effort they can have a tunnel. At work, few programmers have any control whatsoever over the available network resources in their development environment. Heck, most count it a win if they can get corporate IT to disable realtime virus checking in the compile tree so that they can compile an application in a reasonable length of time. Control fine details of the network environment? You must kidding.
(It might not be native, so wh00p, you can test fine also on a local link in the extreme case)
You know better. You can't test worth sh*t without a real network connection with hosts on the other side that do things you weren't expecting.
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
did not care = true simply = false Deciding which of the nice-to-haves you're just not going to care about is rarely a simple question. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <CAP-guGUZU-Or-gtRP3VdaHPk-BTAM1gZYT8yTJF0PPcb8keVng@mail.gmail.com> , William Herrin writes:
On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar <jeroen@unfix.org> wrote:
I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6.
Your lack of sorrow is immaterial to the programmers in question. And in the vast majority of cases the network is incidental to their software's role. The network is the tool not the product. They'll use the available tool.
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse.
At home sure. If they're willing to go to a little bit of effort they can have a tunnel.
At work, few programmers have any control whatsoever over the available network resources in their development environment. Heck, most count it a win if they can get corporate IT to disable realtime virus checking in the compile tree so that they can compile an application in a reasonable length of time. Control fine details of the network environment? You must kidding.
(It might not be native, so wh00p, you can test fine also on a local link in the extreme case)
You know better. You can't test worth sh*t without a real network connection with hosts on the other side that do things you weren't expecting.
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
did not care = true simply = false
Deciding which of the nice-to-haves you're just not going to care about is rarely a simple question.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
And for 99% of apps using getaddrinfo() instead of gethostbyname() is all that is required to make them work with IPv6 and the documentation for getaddrinfo() has example code. getaddrinfo() works on a IPv4 only network. You read the API specfication, you write to it and it works 99.9% of the time and when it doesn't you file a bug report with the API vendor. I've reported bugs to all the major OS vendors over the years. IPv4 and IPv6 bugs. I've just reported bugs to Apple and FreeBSD over the iteraction, or lack of it, between IPV6_USE_MIN_MTU and TCP segment sizes. Havn't tested Linux's equivalent setsockopt yet. The fix to the BSD kernel to adjust the segment size is about 4 lines of additional code. One of the advantages of oss, you can go in there and fix it if you need to. I've coded for platforms that I have never worked on. It's a little more difficult but not impossible. I've debugged problems on machines that I don't have access to. Again it is more difficult but not impossible. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Nov 27, 2012 at 6:29 PM, Mark Andrews <marka@isc.org> wrote:
I've coded for platforms that I have never worked on. It's a little more difficult but not impossible. I've debugged problems on machines that I don't have access to. Again it is more difficult but not impossible.
Sure, but like me you're comfortably inside the 95th percentile. Expecting folks down under the 75th percentile to program IPv6 without a solid working IPv6 Internet link is crazy talk. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Many years ago the standard books on application network programming were based on C language. Books such as "Adventures in UNIX Network Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" detailed how to write C programs using BSD sockets where binding to a socket brought the program up in listening mode on an 2 tuple IP v4 IP address/TCP well known port. Once the program opened and bound to a socket "netstat -n" would show that program to be "listening" on the 2-tuple. Do today's programmers still use basic BSD socket programming? Is there an equivalent set of called procedures for IPv6 network application programming? On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999. David On Tue, Nov 27, 2012 at 1:07 PM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-11-27 20:21, mike wrote:
On 11/26/12 9:32 PM, Mikael Abrahamsson wrote:
The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done.
This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around with, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life.
I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6. Especially as APIs like getaddrinfo() make it really easy to do so.
The following excellent article by our beloved true IPv6 Samuarai Itojun is from 1998: http://www.kame.net/newsletter/19980604/
Thus it is not like the information is not out there either.
As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse. (It might not be native, so wh00p, you can test fine also on a local link in the extreme case)
Remember that silly thing called the 6bone and what the purpose of that was back then, indeed, for getting connectivity to the people so that they could fix their code and that ran from 1996 till 2006, 10 years where one could have fixed up those apps that was already 6 years ago again.
As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care...
Greets, Jeroen who proudly has been providing IPv6 connectivity and IPv6 patches for over more than a decade...
On Wed, 28 Nov 2012, david peahi wrote:
On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999.
The new APIs have been around since about that time ~2000. <http://www.kutukupret.com/2009/09/28/gethostbyname-vs-getaddrinfo/> <http://udrepper.livejournal.com/16116.html> ... but a few. I am sure there is a lot of new and old code using the old APIs. I wish there would be a WARN or equivalent in the APIs to tell the devs that they're using a old (should be deprecated :P) API call. -- Mikael Abrahamsson email: swmike@swm.pp.se
Am 28.11.2012 19:30, schrieb david peahi:
Many years ago the standard books on application network programming were based on C language. Books such as "Adventures in UNIX Network Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" detailed how to write C programs using BSD sockets where binding to a socket brought the program up in listening mode on an 2 tuple IP v4 IP address/TCP well known port. Once the program opened and bound to a socket "netstat -n" would show that program to be "listening" on the 2-tuple.
Do today's programmers still use basic BSD socket programming? Is there an equivalent set of called procedures for IPv6 network application programming?
On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999.
on linux/unix: if the program only opens a tcp-connection or listen on it, it's simple. socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) -> socket = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) It's more work, to build a dual-stack program - then 2 sockets needs to be opened and handled. But overall - it's trivial. y2k: the will be app's that will it never made to ipv6 - but you can do ipv6->ipv4 translation NAT-PT (RFC2766) Kind regards, Ingo Flaschberger
On Nov 28, 2012, at 10:47 AM, Ingo Flaschberger <if@xip.at> wrote:
Am 28.11.2012 19:30, schrieb david peahi:
Many years ago the standard books on application network programming were based on C language. Books such as "Adventures in UNIX Network Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" detailed how to write C programs using BSD sockets where binding to a socket brought the program up in listening mode on an 2 tuple IP v4 IP address/TCP well known port. Once the program opened and bound to a socket "netstat -n" would show that program to be "listening" on the 2-tuple.
Do today's programmers still use basic BSD socket programming? Is there an equivalent set of called procedures for IPv6 network application programming?
On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999.
on linux/unix: if the program only opens a tcp-connection or listen on it, it's simple. socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) -> socket = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP)
You left out some structure changes an the need to use getaddrinfo()/getnameinfo() in place of get*by*(). Depending on your implementation, you might also need to make some changes to your bind() call and/or the way you iterate through the returns from getaddrinfo() calling connect().
It's more work, to build a dual-stack program - then 2 sockets needs to be opened and handled. But overall - it's trivial.
Not if your system properly supports IPV6_V6ONLY=false default sock opt. If you're stuck on something based on BSD or WinSock where this is broken, then, yes, you may have to open 2 sockets or at the very least make a deliberate setsockopt() call or specify the option in the socket() call. Owen
On 11/28/2012 10:30 AM, david peahi wrote:
On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999.
Surely you mean varchar(15), right? :) Mike
On Wed, Nov 28, 2012 at 1:30 PM, david peahi <davidpeahi@gmail.com> wrote:
Do today's programmers still use basic BSD socket programming? Is there an equivalent set of called procedures for IPv6 network application programming?
The IPv6 API is BSD sockets. However, unless you were a particularly advanced sockets programmer you'll find that the way you used sockets for IPv4 (assuming that multiple IP addresses for a host was the exception rather than the rule) is wholly ineffective for writing useful IPv6-compatible code. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
From: Dobbins, Roland [mailto:rdobbins@arbor.net] On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention.
What people ought to do and what they actually do are often quite different things.
Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities.
A lot of attention was lavished on ISDN, too. More attention is lavished on IPv6. So a) attention level doesn't indicate priority, and b) even if it did, IPv6 wins. Also, CGN does not preclude IPv6; it makes most sense (if at all) as a backstop for situations when IPv6 doesn't work and IPv4 addresses are too expensive. Lee
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative.
I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs. Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Nov 26, 2012, at 15:10 , "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative.
I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs.
Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction.
Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6. If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy. Owen
On Nov 27, 2012, at 8:15 AM, Owen DeLong wrote:
Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6.
Which is pretty much everything on the Internet.
If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy.
While I would be very surprised if you didn't, heh. Also, just how widely-deployed is IPv6 now for mobile networks? It would be very edifying to get some data around this . . . ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. 'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable.
sorry if the facts did not support your conclusion. they do support mine. big initial ipv6 traffic bump but long ipv4 tail. randy
On Nov 27, 2012, at 5:26 PM, Randy Bush wrote:
sorry if the facts did not support your conclusion. they do support mine.
Pointers to these facts would be greatly appreciated, especially as no one else seems to know where to find them. ;>
big initial ipv6 traffic bump
This is what I question.
but long ipv4 tail.
I agree with this one, of course. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
sorry if the facts did not support your conclusion. they do support mine. Pointers to these facts would be greatly appreciated, especially as no one else seems to know where to find them.
to repeat, a very large broadband provider has said semi-publicly, and another has corroborated, when they enable ipv6 to an average consumer, 40% of the traffic immediately switches to ipv6. the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. content is queen. randy
On Nov 27, 2012, at 9:50 PM, Randy Bush wrote:
the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble.
Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment. Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.). ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
You can look back on Nanog56 and watch Liviu's presentation regarding implementation in the RCS-RDS network. Why, you ask? Because they/we can do it. IPv4 exhaustion is upon us. CGN will break some of the fuctionality of current day networks or rather APPs running on those networks. Because you have unlimited IPs with increased security... I could continue with the list of "why"s. The only "why not" in this entire talk is due to vendors. Core and distribution vendors have been supporting IPv6 for quite some time now while ACCESS vendors are still lagging behind. Most OS's(Windows,*nix,etc) run IPv6 this days and they have been for a few years now. PS: although this might sound silly here is a idea...have all the porn sites switch to IPv6 and you'll see a 20-30 fold increase in IPv6 traffic :)). On 11/27/2012 5:16 PM, Dobbins, Roland wrote:
On Nov 27, 2012, at 9:50 PM, Randy Bush wrote:
the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble.
Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment.
Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.).
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
Thus spake Dobbins, Roland (rdobbins@arbor.net) on Tue, Nov 27, 2012 at 03:16:27PM +0000:
On Nov 27, 2012, at 9:50 PM, Randy Bush wrote:
the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble.
Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment.
I would consider 40% offload from your expensive CGN to be incentive in and of itself. Dale
On 11/27/2012 11:19 AM, Dale W. Carder wrote:
Thus spake Dobbins, Roland (rdobbins@arbor.net) on Tue, Nov 27, 2012 at 03:16:27PM +0000:
On Nov 27, 2012, at 9:50 PM, Randy Bush wrote:
the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble.
Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment.
I would consider 40% offload from your expensive CGN to be incentive in and of itself.
Just a thought -- what percentage of flows is that 40% of traffic? Since it's mostly video I'd assume the bytes/flow would be far higher than the median. If you can get a reasonably high percentage of flows on IPv6, not only do take load off your CGN box, you can get higher users per public IPv4 address ratios and stretch your v4 allocation further. No idea if the numbers work out to make this a useful effect in the timeframe when it would be necessary, but it's a benefit I haven't heard voiced before. -Ben
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.).
IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we please just put this to rest? -- Mikael Abrahamsson email: swmike@swm.pp.se
In message <alpine.DEB.2.00.1211271746210.27834@uplift.swm.pp.se>, Mikael Abrahamsson writes:
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.).
IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we please just put this to rest?
But it will reduce the dollars that need to be spent to continue to prop up IPv4. Every IPv6 packet sent is one less packet that needs to be processed by the CGN *farm*. Split the bill so you can see the IPv4 and IPv6 traffic components and add a CGN loading on the IPv4 traffic. Mark
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 27, 2012, at 8:47 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Tue, 27 Nov 2012, Dobbins, Roland wrote:
Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.).
IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we please just put this to rest?
It's the only answer we have. Yes, it's not short enough term, so we will have to deploy some hacks along the way to try and keep things running, but, if we don't also continue (and seriously accelerate) IPv6 deployment in parallel, we're in for some serious hurt in the near future. Owen
On 27 Nov 2012, at 14:50, Randy Bush <randy@psg.com> wrote:
sorry if the facts did not support your conclusion. they do support mine. Pointers to these facts would be greatly appreciated, especially as no one else seems to know where to find them.
to repeat, a very large broadband provider has said semi-publicly, and another has corroborated, when they enable ipv6 to an average consumer, 40% of the traffic immediately switches to ipv6. the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. content is queen.
http://6lab.cisco.com/stats/ suggests the figure is even higher, over 50% in some cases. Tim
Hi, according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883. I'm wondering when we reach another significant milestone - 50% :-) Tomas -------- Original Message -------- Subject: Big day for IPv6 - 1% native penetration Date: Tue, 20 Nov 2012 10:14:18 +0100 From: Tomas Podermanski <tpoder@cis.vutbr.cz> To: nanog@nanog.org Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.
On 02/01/16 15:35, Tomas Podermanski wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883.
I'm wondering when we reach another significant milestone - 50% :-)
Tomas
Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get: Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90% with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027. Neil
On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris <neil@tonal.clara.co.uk> wrote:
On 02/01/16 15:35, Tomas Podermanski wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883.
I'm wondering when we reach another significant milestone - 50% :-)
Tomas
Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get:
Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90%
with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027.
Neil
Just a reminder, that 10% is a global number. The number in the USA is 25% today in general, is 37% for mobile devices. Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates. For example, once Apple cleanses the app store of IPv4 apps in 2016 as they have committed and pushes one of their ubiquitous iOS updates, you may see substantial jumps over night in IPv6 eyeballs, possibly meaningful moving that 37% number to over 50% in a few shorts weeks. This will squarely make it clear that IPv4 is minority legacy protocol for all of mobile, and thusly the immediate future of the internet. CB
On Mon, 4 Jan 2016, Ca By wrote:
Just a reminder, that 10% is a global number.
The number in the USA is 25% today in general, is 37% for mobile devices.
Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates.
For example, once Apple cleanses the app store of IPv4 apps in 2016 as they have committed and pushes one of their ubiquitous iOS updates, you may see substantial jumps over night in IPv6 eyeballs, possibly meaningful moving that 37% number to over 50% in a few shorts weeks.
This will squarely make it clear that IPv4 is minority legacy protocol for all of mobile, and thusly the immediate future of the internet.
True, but as noted in other recent threads, it would appear that IPv6 deployment in many areas outside the United States is nowhere near as far along. While IPv6 is the future (in some areas, the present), it's probably way too early to try to nail down a date to write the obituary on IPv4. jms
On Mon, 4 Jan 2016, Ca By wrote:
Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get:
Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90%
with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027.
Neil
Just a reminder, that 10% is a global number.
The number in the USA is 25% today in general, is 37% for mobile devices.
Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates.
Add to that the fact that as we run closer to (or further into?) run-out, at some point there's likely to be a rapid acceleration in v6 provisioning as networks finally realize that they can't reasonably get any more v4 space or their end-user customers finally begin to demand v6. If Brighthouse has people on-list...you're embarrassingly late to this party...and its time to start calling out end-user providers that still don't even offer v6. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Add to that the fact that as we run closer to (or further into?) run-out, at some point there's likely to be a rapid acceleration in v6 provisioning as networks finally realize that they can't reasonably get any more v4 space or their end-user customers finally begin to demand v6.
If Brighthouse has people on-list...you're embarrassingly late to this party...and its time to start calling out end-user providers that still don't even offer v6.
Here’s the thing, from my perspective (and I’ve been doing this for a while and I think I have a pretty good perspective from talking to a lot of people from all different levels and areas of involved)… Eyeball providers have an inherent forcing function. They _WILL_ run out of IPv4 addresses and they will have no choice but to start bringing up some new customers on IPv6. They will eventually need to recycle addresses allocated to current customers to things like CGN if they still have to maintain IPv4 connectivity for their customers. The real focus that needs to move now is content. Check out http://www.delong.com/ipv6_alexa500.html <http://www.delong.com/ipv6_alexa500.html> and/or http://www.delong.com/ipv6_fortune500.html <http://www.delong.com/ipv6_fortune500.html> for a look at how this is going… It’s _NOT_ good. 18% (90) of the top 500 web sites even have an AAAA record for the domain name. Interestingly, there are 18 more sites (108, still 18%) that have AAAA records for www.domain name. Unfortunately, only 13.8% (69) of those return a status 200 in response to a query for the domain name and only 16.2% (81) for www.domain name as of this writing. For the fortune 500, it’s even more bleak. 13 sites (2.63%) have AAAA records with only 9 (1.82%) of them returning status 200. These numbers might be slightly pessimistic because 3XX series responses are not counted as good. So long as the content situation remains this bad, there is no option to turn off IPv4 at the eyeball level. Additionally, there’s a large volume of consumer devices that are IPv4 only still being produced. This is a huge problem. IMHO, that’s the truly critical issue. Eyeball providers that haven’t started to move yet are much more capable of an accelerated deployment using a well trod path at this point and will have more than ample motivation relatively soon. On the content side, however, so far the motivations are somewhat limited and require vision and foresight which is often lacking in corporate leadership. Owen
On Mon, 04 Jan 2016 11:59:40 -0800, Owen DeLong said:
These numbers might be slightly pessimistic because 3XX series responses are not counted as good.
They may be a *lot* more than slightly pessimistic - consider the case of any site that uses 3xx replies to redirect to a geo-IP based server rather than doing it in DNS (which has the problem that you're redirecting based on the IP of the DNS server that asked, which will fail miserably for anybody using 8.8.8.8 as their DNS server)
On Mon, Jan 4, 2016 at 1:21 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Jan 2016 11:59:40 -0800, Owen DeLong said:
These numbers might be slightly pessimistic because 3XX series responses are not counted as good.
They may be a *lot* more than slightly pessimistic - consider the case of any site that uses 3xx replies to redirect to a geo-IP based server rather than doing it in DNS (which has the problem that you're redirecting based on the IP of the DNS server that asked, which will fail miserably for anybody using 8.8.8.8 as their DNS server)
While I agree with your general sentiment about 3xx responses (often used to redirect example.com to www.example.com) I think your concerns about 8.8.8.8 are over-stated. 8.8.8.8 is deployed in many locations, which gives DNS-based geolocation a decent chance of working. And it also supports the client subnet EDNS0 extension ( https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06) for more fine-grained balancing. Damian
On Mon, 04 Jan 2016 13:52:46 -0800, Damian Menscher said:
While I agree with your general sentiment about 3xx responses (often used to redirect example.com to www.example.com) I think your concerns about 8.8.8.8 are over-stated. 8.8.8.8 is deployed in many locations, which gives DNS-based geolocation a decent chance of working.
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query? How does a company know that another instance of 8.8.8.8 has been turned up or down or re-peered, causing a shift in the mapping of DNS queries to countries/ states?
https://developers.google.com/speed/public-dns/faq?hl=en there I asked jeeves for ya! On Mon, Jan 4, 2016 at 5:09 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Jan 2016 13:52:46 -0800, Damian Menscher said:
While I agree with your general sentiment about 3xx responses (often used to redirect example.com to www.example.com) I think your concerns about 8.8.8.8 are over-stated. 8.8.8.8 is deployed in many locations, which gives DNS-based geolocation a decent chance of working.
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
How does a company know that another instance of 8.8.8.8 has been turned up or down or re-peered, causing a shift in the mapping of DNS queries to countries/ states?
On Mon, 04 Jan 2016 17:23:20 -0500, Christopher Morrow said:
https://developers.google.com/speed/public-dns/faq?hl=en
there I asked jeeves for ya!
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
With 43 subnets for servers and only 13 unique airport codes, the conclusion is that without additional fun and games, locating based on the DNS for 8.8.8.8 will be incorrect for *most* countries. Probably gets the continent right. On Mon, 04 Jan 2016 14:17:56 -0800, Owen DeLong said:
Further, 8.8.8.8 actually fully supports EDNS0 Client Subnet capability, so if the geo-IP balancer in question wants, they can eliminate the failure mode you are describing in that case.
Which only helps for people using 8.8.8.8. Client Subnet does help the issue, but it doesn't actually fix it until support is near ubiquitous across intermediate nameservers that have clients in other geographic locations... (I believe that the fact that Google found a need to create EDNS0 Client Subnet *at all* is proof that using the DNS address for localization is problematic...) And again - it's still something that needs work upstream to support, and you *still* have to deal with the case where the intermediate DNS server doesn't do Client Subnet.
I say slightly pessimistic because there aren’t all that many 3XX responses being reported.
OK, that's a slightly different kettle of fish :) To the nearest 10% or so, how many are answering with a 3xx of any sort?
On Mon, Jan 4, 2016 at 2:48 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Jan 2016 17:23:20 -0500, Christopher Morrow said:
https://developers.google.com/speed/public-dns/faq?hl=en
there I asked jeeves for ya!
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
With 43 subnets for servers and only 13 unique airport codes, the conclusion is that without additional fun and games, locating based on the DNS for 8.8.8.8 will be incorrect for *most* countries. Probably gets the continent right.
If you're load-balancing by country, you've already lost. It turns out the USA has more users than Luxembourg, Samoa, Monaco, Bermuda, and Andorra *combined*. On Mon, 04 Jan 2016 14:17:56 -0800, Owen DeLong said:
Further, 8.8.8.8 actually fully supports EDNS0 Client Subnet capability, so if the geo-IP balancer in question wants, they can eliminate the failure mode you are describing in that case.
Which only helps for people using 8.8.8.8. Client Subnet does help the issue, but it doesn't actually fix it until support is near ubiquitous across intermediate nameservers that have clients in other geographic locations...
(I believe that the fact that Google found a need to create EDNS0 Client Subnet *at all* is proof that using the DNS address for localization is problematic...)
And again - it's still something that needs work upstream to support, and you *still* have to deal with the case where the intermediate DNS server doesn't do Client Subnet.
Not all auth servers need to support Client Subnet... just those that want to do DNS-based load-balancing in a more fine-grained level than already achieved by Google's multiple datacenters. And while I don't know what software most companies use for their DNS-based load-balancing, I'd guess that adding Client Subnet support is a minor feature request relative to the other required logic. Damian
We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6. Regards, Baldur
Hi,
We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6.
I already discussed that with them a long time ago, but they weren't convinced. Maybe now is the time to discuss it again :) Cheers, Sander
On Jan 4, 2016, at 16:37 , Sander Steffann <sander@steffann.nl> wrote:
Hi,
We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6.
I already discussed that with them a long time ago, but they weren't convinced. Maybe now is the time to discuss it again :)
Cheers, Sander
Another alternative discussed, but Netflix seems so far to be unconvinced: If you come via IPv6, you get all the content. If you come from IPv4, in the first week that new content is posted, instead of the new content, you get a video explaining the need to get a better internet connection and that the content you want will be available to the legacy internet on <date>. Owen
On Mon, 04 Jan 2016 19:42:45 -0500, Owen DeLong <owen@delong.com> wrote:
If you come from IPv4, in the first week that new content is posted, instead of the new content, you get a video explaining the need to get a better internet connection and that the content you want will be available to the legacy internet on <date>.
All that does is piss off Netflix's customers who have zero control ("choice") over IPv6 availability. And in most cases zero understanding as well. Netflix isn't in the business of driving away paying customers. --Ricky
On Jan 4, 2016, at 17:01 , Ricky Beam <jfbeam@gmail.com> wrote:
On Mon, 04 Jan 2016 19:42:45 -0500, Owen DeLong <owen@delong.com> wrote:
If you come from IPv4, in the first week that new content is posted, instead of the new content, you get a video explaining the need to get a better internet connection and that the content you want will be available to the legacy internet on <date>.
All that does is piss off Netflix's customers who have zero control ("choice") over IPv6 availability. And in most cases zero understanding as well. Netflix isn't in the business of driving away paying customers.
--Ricky
The same is likely true of the Google search ranking idea, no? Owen
On 5 January 2016 at 02:53, Owen DeLong <owen@delong.com> wrote:
The same is likely true of the Google search ranking idea, no?
The Netflix idea is putting pressure on eyeball networks. The google search rank idea is to put pressure on content providers. You have been arguing that the content providers are the larger problem now. Content providers in general have access to IPv6 if they want it. They are just too lazy to implement it. The exception being AWS. But I would cry dry tears if these guys got hunted by their lack of IPv6 by design. Regards, Baldur
The Netflix idea is putting pressure on eyeball networks. The google search rank idea is to put pressure on content providers.
and how does the internet benefit by putting pressure on providers? i see how the folk who produce glossy paper for a living, or those who charge for renting 128 bit integers, benefit. but how do those of us who push packets, or our customers, benefit? the more interesting question to me is: what can we, ops and ietf, do to make it operationally and financially easier for providers and enterprises to go to ipv6 instead of ipv4 nat? carrot not stick. randy
On Mon, Jan 4, 2016 at 9:37 PM, Randy Bush <randy@psg.com> wrote:
the more interesting question to me is: what can we, ops and ietf, do to make it operationally and financially easier for providers and enterprises to go to ipv6 instead of ipv4 nat? carrot not stick.
randy
The problem is, the only way to make it easier for providers and enterprises to switch is to make it less scary looking and less complicated sounding. That door closed when it was decided to go with hex and 128-bit numbering. *I* know it's not nearly as bad as it seems and why it was done, and their network folks by and large know it's not as bad as it seems, but the people making the decisions to spend large sums of money upgrading stuff that works just fine thank-you-very-much are looking at it and saying "Ye gods... I sort of understand what IP means but that looks like an alien language!" At which point the ugly duckling gets tossed out on it's ear before it has a chance to become a swan.
the more interesting question to me is: what can we, ops and ietf, do to make it operationally and financially easier for providers and enterprises to go to ipv6 instead of ipv4 nat? carrot not stick.
The problem is, the only way to make it easier for providers and enterprises to switch is to make it less scary looking and less complicated sounding. That door closed when it was decided to go with hex and 128-bit numbering. *I* know it's not nearly as bad as it seems and why it was done, and their network folks by and large know it's not as bad as it seems, but the people making the decisions to spend large sums of money upgrading stuff that works just fine thank-you-very-much are looking at it and saying "Ye gods... I sort of understand what IP means but that looks like an alien language!"
At which point the ugly duckling gets tossed out on it's ear before it has a chance to become a swan.
sorry, i am not interested in the marketing and glossy paper crap. and your dissing isps and enterprises is a part of the problem not part of an approach to a solution. this reminds me when one of the ietf ivory tower fools said (during the TLA?NLA wars), and i quote, "the HD ratio will not work because operators do not understand logarithms." and he still stands in the way of useful progress. randy
On Jan 4, 2016, at 20:27 , George Metz <george.metz@gmail.com> wrote:
On Mon, Jan 4, 2016 at 9:37 PM, Randy Bush <randy@psg.com> wrote:
the more interesting question to me is: what can we, ops and ietf, do to make it operationally and financially easier for providers and enterprises to go to ipv6 instead of ipv4 nat? carrot not stick.
randy
The problem is, the only way to make it easier for providers and enterprises to switch is to make it less scary looking and less complicated sounding. That door closed when it was decided to go with hex and 128-bit numbering. *I* know it's not nearly as bad as it seems and why it was done, and their network folks by and large know it's not as bad as it seems, but the people making the decisions to spend large sums of money upgrading stuff that works just fine thank-you-very-much are looking at it and saying "Ye gods... I sort of understand what IP means but that looks like an alien language!"
At which point the ugly duckling gets tossed out on it's ear before it has a chance to become a swan.
I haven’t been involved in a single executive briefing where hex or the length of the addresses came up as an issue. This is a total red herring. Decision makers aren’t paying attention to what the addresses look like. Most of them likely wouldn’t recognize an IPv4 address if you showed them one. Owen
On Mon, 04 Jan 2016 16:42:45 -0800, Owen DeLong said:
Another alternative discussed, but Netflix seems so far to be unconvinced:
If you come via IPv6, you get all the content.
If you come from IPv4,
And Netflix convinces Sony to ship an IPv6-capable OS update for the PS3 and PS4, how, exactly? (Replace Sony, and PS[34] with pretty much any other legacy client out there...)
Some one mentioned here a while back to make a free porn site that is IPv6 only. Watch the support lines at all the eyeballs light up! Regards, Dovid -----Original Message----- From: Owen DeLong <owen@delong.com> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Mon, 4 Jan 2016 16:42:45 To: Sander Steffann<sander@steffann.nl> Cc: nanog@nanog.org<nanog@nanog.org> Subject: Re: Another Big day for IPv6 - 10% native penetration
On Jan 4, 2016, at 16:37 , Sander Steffann <sander@steffann.nl> wrote:
Hi,
We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6.
I already discussed that with them a long time ago, but they weren't convinced. Maybe now is the time to discuss it again :)
Cheers, Sander
Another alternative discussed, but Netflix seems so far to be unconvinced: If you come via IPv6, you get all the content. If you come from IPv4, in the first week that new content is posted, instead of the new content, you get a video explaining the need to get a better internet connection and that the content you want will be available to the legacy internet on <date>. Owen
* Sander Steffann <sander@steffann.nl>
We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6.
I already discussed that with them a long time ago, but they weren't convinced. Maybe now is the time to discuss it again :)
I've mentioned this in other forums before, but I might as well repeat it here too: I can understand that Google (or Netflix for that matter) are reluctant to engage in pure IPv6 activism by providing different or improved content to users which have no IPv6 connectivity. However, maybe they'd be more open to the idea if it was limited to IPv6 clients only? That is, IFF the Google user submitting the search is doing it using IPv6, then consider the result entries' IPv6 availability when sorting the result set. My reasoning is that there would be an objective techincal reason for doing it. The client is demonstrably capable of using IPv6 and prefers to do so, and as it has been shown that IPv6 performs better than IPv4 (see e.g. https://youtu.be/_7rcAIbvzVY), giving priority to IPv6-enabled results seems a logical thing to do. Much in the same way that it makes sense to rank mobile-optimised sites high in result sets returned to mobile clients. I'd imagine that the promise of improved Google ratings for 10%/25% of global/U.S. users will still be a significant enough business reason for web site operators to seriously consider implementing IPv6. Tore
I would hope that Google would first fix the fact that "Compute Engine networks do not support IPv6 at all."[1] before doing anything with SEO. [1] https://cloud.google.com/compute/docs/networking -- James Hartig
I bet if more people moved to clouds that have IPv6 support such as: Host Virtual vr.org <http://vr.org/> Softlayer softlayer.com <http://softlayer.com/> Linode linode.com <http://linode.com/> Places like Amazon and Google and IBM would get the message faster than from people complaining on this list. Owen
On Jan 5, 2016, at 08:15 , James Hartig <fastest963@gmail.com> wrote:
I would hope that Google would first fix the fact that "Compute Engine networks do not support IPv6 at all."[1] before doing anything with SEO.
[1] https://cloud.google.com/compute/docs/networking -- James Hartig
Aren't IBM and Softlayer one and the same these days? On Tue, Jan 5, 2016 at 11:44 AM, Owen DeLong <owen@delong.com> wrote:
I bet if more people moved to clouds that have IPv6 support such as:
Host Virtual vr.org <http://vr.org/> Softlayer softlayer.com <http://softlayer.com/> Linode linode.com <http://linode.com/>
Places like Amazon and Google and IBM would get the message faster than from people complaining on this list.
Owen
On Jan 5, 2016, at 08:15 , James Hartig <fastest963@gmail.com> wrote:
I would hope that Google would first fix the fact that "Compute Engine networks do not support IPv6 at all."[1] before doing anything with SEO.
[1] https://cloud.google.com/compute/docs/networking -- James Hartig
Yes and no… Yes, IBM bot Softlayer. No, IBM datacenters that predate Softlayer still can’t spell IPv6. Softlayer datacenters all had IPv6 before IBM got to them. Owen
On Jan 5, 2016, at 14:53 , Mansoor Nathani <mnathani.lists@gmail.com> wrote:
Aren't IBM and Softlayer one and the same these days?
On Tue, Jan 5, 2016 at 11:44 AM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: I bet if more people moved to clouds that have IPv6 support such as:
Host Virtual vr.org <http://vr.org/> <http://vr.org/ <http://vr.org/>> Softlayer softlayer.com <http://softlayer.com/> <http://softlayer.com/ <http://softlayer.com/>> Linode linode.com <http://linode.com/> <http://linode.com/ <http://linode.com/>>
Places like Amazon and Google and IBM would get the message faster than from people complaining on this list.
Owen
On Jan 5, 2016, at 08:15 , James Hartig <fastest963@gmail.com <mailto:fastest963@gmail.com>> wrote:
I would hope that Google would first fix the fact that "Compute Engine networks do not support IPv6 at all."[1] before doing anything with SEO.
[1] https://cloud.google.com/compute/docs/networking <https://cloud.google.com/compute/docs/networking> -- James Hartig
On Jan 5, 2016, at 11:44 AM, Owen DeLong <owen@delong.com> wrote:
I bet if more people moved to clouds that have IPv6 support such as:
Host Virtual vr.org <http://vr.org/> Softlayer softlayer.com <http://softlayer.com/> Linode linode.com <http://linode.com/>
Places like Amazon and Google and IBM would get the message faster than from people complaining on this list.
Yes, the echo chamber of NANOG, that sometimes makes it out further :) I’ve heard rumblings that Amazon is slowly making progress in the IPv6 front and others are marching forward here. I think this will largely be driven by the mobile marketing machine. There’s a lot of things converging at once and I expect 2016 to see major shifts in “IP Classic” -> IPv6 traffic. We saw a doubling of IPv6 bitrate on our network just by the iOS change in how they handled happy eyeballs. I’m hoping that Frontier brings v6 to their service area when they close the deal on FiOS purchase from VZ. For me on the marketing side: If you expect your users to visit from a mobile device, your website and resources should be available and optimized for IPv6. - Jared
They don't need to actually implement it, just say IPv6 increases ranking. SEO is mostly BS anyways, I doubt anyone would notice. -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Baldur Norddahl Sent: Monday, January 04, 2016 4:33 PM To: nanog@nanog.org Subject: Re: Another Big day for IPv6 - 10% native penetration We just need Google to announce that IPv6 enabled sites will get a slight bonus in search rankings. And just like that, there will suddenly be a business reason to implement IPv6. Regards, Baldur
On Mon, 04 Jan 2016 14:17:56 -0800, Owen DeLong said:
Further, 8.8.8.8 actually fully supports EDNS0 Client Subnet capability, so if the geo-IP balancer in question wants, they can eliminate the failure mode you are describing in that case.
Which only helps for people using 8.8.8.8. Client Subnet does help the issue, but it doesn't actually fix it until support is near ubiquitous across intermediate nameservers that have clients in other geographic locations…
Well… that and any other DNS server that supports EDNS0 client subnet.
(I believe that the fact that Google found a need to create EDNS0 Client Subnet *at all* is proof that using the DNS address for localization is problematic…)
Sure, but anycast is even more problematic and those are basically the only two alternatives currently known for solving the problem in question.
And again - it's still something that needs work upstream to support, and you *still* have to deal with the case where the intermediate DNS server doesn't do Client Subnet.
Or accept that no solution is perfect, make this one as good as we can for now and move on.
I say slightly pessimistic because there aren’t all that many 3XX responses being reported.
OK, that's a slightly different kettle of fish :) To the nearest 10% or so, how many are answering with a 3xx of any sort?
Well… I’ll post a separate message detailing my findings. It’s more interesting than I previously realized because none were reporting 3xx results and all 3xx results were getting hidden behind 5xx results which weren’t (all) entirely valid. Owen
On Jan 4, 2016, at 14:09 , Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jan 2016 13:52:46 -0800, Damian Menscher said:
While I agree with your general sentiment about 3xx responses (often used to redirect example.com to www.example.com) I think your concerns about 8.8.8.8 are over-stated. 8.8.8.8 is deployed in many locations, which gives DNS-based geolocation a decent chance of working.
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
How does a company know that another instance of 8.8.8.8 has been turned up or down or re-peered, causing a shift in the mapping of DNS queries to countries/ states?
You do realize that the query source address is not 8.8.8.8 when it goes to the authoritative server, right? The client sees 8.8.8.8. The authoritative server does not. The query from Google to the authoritative server will come from a unique address local to the particular instance. Owen
On Mon, 04 Jan 2016 15:35:05 -0800, Owen DeLong said:
You do realize that the query source address is not 8.8.8.8 when it goes to the authoritative server, right?
As I said:
So in how many of the 196 or so extant countries does 8.8.8.8 resolve to a host which, when it sends a query up the chain, appears to be in the same country as the machine that made the original query?
User talks to 8.8.8.8, and that host goes up the tree with *its* IP. And how often does *that* IP look like it belongs in the same country as the user?
On Jan 4, 2016, at 13:21 , Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jan 2016 11:59:40 -0800, Owen DeLong said:
These numbers might be slightly pessimistic because 3XX series responses are not counted as good.
They may be a *lot* more than slightly pessimistic - consider the case of any site that uses 3xx replies to redirect to a geo-IP based server rather than doing it in DNS (which has the problem that you're redirecting based on the IP of the DNS server that asked, which will fail miserably for anybody using 8.8.8.8 as their DNS server)
I say slightly pessimistic because there aren’t all that many 3XX responses being reported. Further, 8.8.8.8 actually fully supports EDNS0 Client Subnet capability, so if the geo-IP balancer in question wants, they can eliminate the failure mode you are describing in that case. However, in either case, I’ll happily give you a copy of the code if you want to enhance it to detect 3XX responses that redirect to an IPv6 capable site vs. 3XX responses that redirect to an IPv4 only site in a sort of slight of hand designed to trick scripts like this one (yes, there are some of those out there last time I looked). Owen
It’s always fun when I open my mouth in public only to turn it into a learning experience. TL;DR version: Several enhancements to the script and to my PERL library to improve the accuracy were made. The now more accurate results aren’t very different. Details below: As a result of comments received in this thread and privately about the statistics pages, I started investigating the mysterious 5XX result codes and made several improvements to the script. First, I found the black text on blue hard to read, so I got rid of it. I converted the black text to white when the background is blue. Purely cosmetic, but still worth doing. Next, I started digging into why was LWP returning a 5xx result code. I discovered that it wasn’t getting a 5xx on the wire and was only sending one request which was getting a 3xx result and then it wasn’t sending an additional request. This led me to (erroneously) assume that it wasn’t attempting to follow the redirect. Some additional digging led me to the fact that LWP sometimes lies to you in both the documentation and the software. It was following redirects and continued to do so no matter how hard I tried to tell it not to. I did find out how to reverse the redirect back a step ($ua->previous() will return the response prior to the current response object in $ua if anyone cares). Armed with that information, I started looking at what I was getting and the text being reported by LWP with the 5xx errors. Turns out that I had neglected to install a module known as LWP::Protocol::https which meant that any redirect to HTTPS would fail with a 5xx result code from LWP without any packets over the wire being attempted. I’ve also made the script slightly more optimistic in that I do now count 3xx results as valid. This is now OVERLY optimistic in that anything that gets stuck at 3xx is actually a failed page load (the redirect went somewhere that didn’t actually work), but there are very few of these and they appear to relate to certificate verification failures which may be due to the version of root cert library on my system used by LWP more than anything else. The legitimate results post redirect are now guaranteed to come from an IPv6 destination because LWP is running with a source host name/address which does not have an A record or an IPv4 address associated. So… The revised statistics are now up and the results aren’t very startling. DNS results are unchanged. domain.name results are 82 (16.4%) up from 69 (13.8%). www.domain.name <http://www.domain.name/> results are 101 (20.2%) up from 81 (16.2%) So it only changed the results for 13-20 sites overall. speedtest.net <http://speedtest.net/> and wikimedia.org <http://wikimedia.org/> (but not www.wikimedia.org <http://www.wikimedia.org/>) failes (500) with “write failed: bad file descriptor” ??? Write? Interestingly, speedtest.net <http://speedtest.net/> has an AAAA record, but www.speedtest.net <http://www.speedtest.net/> does not. mega.nz <http://mega.nz/> still errors out 500 for timeout marca.com <http://marca.com/> still has a legitimate 500 error (timeout) A further enhancement to the script will probably replace the short status code in the table with the full status line for any result outside of the 2xx range. Owen
On Mon, Jan 4, 2016 at 3:55 PM, Owen DeLong <owen@delong.com> wrote:
domain.name results are 82 (16.4%) up from 69 (13.8%). www.domain.name <http://www.domain.name/> results are 101 (20.2%) up from 81 (16.2%)
As a professional pessimist, I can't help but note that of the 111 sites responding over IPv6 (I'm including a 400 or 500 as a "response"), more than half (58) are operated by Google. So ignoring Google sites, the Alexa Top 500 becomes the Alexa Top 441 and has 53 IPv6-enabled sites, or ~12%. Damian
On Jan 4, 2016, at 16:21 , Damian Menscher <damian@google.com> wrote:
On Mon, Jan 4, 2016 at 3:55 PM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: domain.name <http://domain.name/> results are 82 (16.4%) up from 69 (13.8%). www.domain.name <http://www.domain.name/> <http://www.domain.name/ <http://www.domain.name/>> results are 101 (20.2%) up from 81 (16.2%)
As a professional pessimist, I can't help but note that of the 111 sites responding over IPv6 (I'm including a 400 or 500 as a "response"), more than half (58) are operated by Google. So ignoring Google sites, the Alexa Top 500 becomes the Alexa Top 441 and has 53 IPv6-enabled sites, or ~12%.
Damian
I think 12% vs. 16% isn’t that much of a difference. Both numbers are horribly horribly low. Owen
On Mon, 04 Jan 2016 11:21:14 -0500, Jon Lewis <jlewis@lewis.org> wrote:
Just a reminder, that 10% is a global number.
And it's not "native". A great many (myself included) have IPv6 *by choice* through various tunnels. And AT&T (Uverse) isn't "native" either -- it's a 6rd tunnel their gateways have been programmed to setup automatically (based on the public IPv4 address.)
If Brighthouse has people on-list...you're embarrassingly late to this party...
And Earthlink ("Eye Pee Vee What?"), and TWTC (pre-L3), and TWC ("not available on that node", and "not available through that gateway"), and Sprint, etc. etc. etc. etc. Verizon _Wireless_, yes. Verizon FiOS, NO. Verizon Business (f.k.a. UUNet), "maybe". That's the issue for Fortune 500's. They ("we") care more about cost than feature. IPv6 isn't valuable enough to justify the added expense for an ISP that does have their act together. (which, in my experience, is "no one".) And Amazon doesn't do IPv6, at all; so there you are. --Ricky
On Jan 4, 2016, at 11:09 AM, Ca By <cb.list6@gmail.com> wrote:
On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris <neil@tonal.clara.co.uk> wrote:
On 02/01/16 15:35, Tomas Podermanski wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883.
I'm wondering when we reach another significant milestone - 50% :-)
Tomas Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get:
Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90%
with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027.
Neil Just a reminder, that 10% is a global number.
The number in the USA is 25% today in general, is 37% for mobile devices.
Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates.
For example, once Apple cleanses the app store of IPv4 apps in 2016 as they have committed and pushes one of their ubiquitous iOS updates, you may see substantial jumps over night in IPv6 eyeballs, possibly meaningful moving that 37% number to over 50% in a few shorts weeks.
This will squarely make it clear that IPv4 is minority legacy protocol for all of mobile, and thusly the immediate future of the internet.
I for one welcome the iOS update that brings v6 APN native access to my phone, or at least v4v6 APN setting. I keep hearing rumors it is "coming soon". This could have a similar step function in the traffic and graphs.
Great news and even more impressive is that Canada is the fastest adopter with ~8% IPv6 penetration, growing from almost 0.5% to 8% in 3 months!!!. See http://stats.labs.apnic.net/ipv6/CA Telus is making a big difference in Canada as the IPv6 adoption leader @ ~45% IPv6 adoption. http://stats.labs.apnic.net/ipv6/AS852?c=CA&g=&w=1&x=1 Hint, hint, subliminal message here for all Canadian ISPs, IPv6 works ;-) So let's shutdown IPv4 on April 4, 2024 Bonne Année!
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jared Mauch Sent: January-04-16 11:28 AM To: Ca By Cc: nanog@nanog.org Subject: Re: Another Big day for IPv6 - 10% native penetration
I'm wondering when we reach another significant milestone - 50% :-)
Tomas
Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get:
Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90%
with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027.
Neil Just a reminder, that 10% is a global number.
The number in the USA is 25% today in general, is 37% for mobile devices.
Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates.
For example, once Apple cleanses the app store of IPv4 apps in 2016 as they have committed and pushes one of their ubiquitous iOS updates, you may see substantial jumps over night in IPv6 eyeballs, possibly meaningful moving that 37% number to over 50% in a few shorts weeks.
This will squarely make it clear that IPv4 is minority legacy protocol for all of mobile, and thusly the immediate future of the internet.
On Jan 4, 2016, at 11:09 AM, Ca By <cb.list6@gmail.com> wrote:
On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris <neil@tonal.clara.co.uk> wrote:
On 02/01/16 15:35, Tomas Podermanski wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC
I for one welcome the iOS update that brings v6 APN native access to my phone, or at least v4v6 APN setting.
I keep hearing rumors it is "coming soon".
This could have a similar step function in the traffic and graphs.
On Mon, 4 Jan 2016, Jared Mauch wrote:
I for one welcome the iOS update that brings v6 APN native access to my phone, or at least v4v6 APN setting.
That's not how it's done on Apple, they (together with the operator) control the APN settings. There are several mobile networks that run IPv4v6 on iOS (all LTE enabled devices support this) for almost a year (I believe it was iOS 8.3 in March 2015 that started to support this for more general 3GPP providers). But getting IPv4v6 bearer working in a mobile network is non-trivial and it still brings the CGN mess, so a lot of mobile providers prefer to use IPv6 only with translation to reach IPv4 sites. That's where Cameron is coming from, and it's perfectly understanable mode of operation. Apple seems to be working to make IPv6 only+AFTR happen and I have good hopes that they'll succeed in 2016. To some other poster regarding IPv6 adoption by people settings up tunnels etc. In my experience, if you put "enable IPv6"-button in the self-care portal, around 1% will enable this. Very few are interested, and rightly so. IPv6 needs to be engineered and enabled by the ISP as a normal part of Internet access, not something the customer has to actively choose. If the customer buys their own CPE and it doesn't support IPv6, well, then that customer will have to fix that themselves, but the ISP needs to make sure that whatever equipment/access they deliver, they need to support IPv6 on it. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Jan 5, 2016, at 00:09 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Mon, 4 Jan 2016, Jared Mauch wrote:
I for one welcome the iOS update that brings v6 APN native access to my phone, or at least v4v6 APN setting.
That's not how it's done on Apple, they (together with the operator) control the APN settings. There are several mobile networks that run IPv4v6 on iOS (all LTE enabled devices support this) for almost a year (I believe it was iOS 8.3 in March 2015 that started to support this for more general 3GPP providers).
But getting IPv4v6 bearer working in a mobile network is non-trivial and it still brings the CGN mess, so a lot of mobile providers prefer to use IPv6 only with translation to reach IPv4 sites. That's where Cameron is coming from, and it's perfectly understanable mode of operation.
Except that the only mode of translation Cameron is willing to support is the one which isn’t available in iOS, so we have a religious war between T-Mo and Apple where T-Mo says “Support 464Xlat or suffer” and Apple says “No, you support one of the mechanisms already supported in iOS”.
Apple seems to be working to make IPv6 only+AFTR happen and I have good hopes that they'll succeed in 2016.
Good that one of them is finally backing down on the previous stupidity, but for a variety of reasons, I wish it had been T-mo. Owen
On Tue, 5 Jan 2016, Owen DeLong wrote:
Good that one of them is finally backing down on the previous stupidity, but for a variety of reasons, I wish it had been T-mo.
Why? IPv6 only with IPv4 transported over it is clearly the way to go for the future, it makes more sense to have Apple support this mode once for their devices, than it is for every mobile provider to have to support IPv4v6 with all the drawbacks, and then migrate people again to IPv6+AFTR solution in a few years. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 04/01/16 16:09, Ca By wrote:
On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris <neil@tonal.clara.co.uk> wrote:
On 02/01/16 15:35, Tomas Podermanski wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883.
I'm wondering when we reach another significant milestone - 50% :-)
Tomas
Given the recent doubling growth, and assuming this trend is following a logistic function, then, rounding the numbers a bit for neatness, I get:
Jan 2016: 10% Jan 2017: 20% Jan 2018: 33% Jan 2019: 50% Jan 2020: 67% Jan 2021: 80% Jan 2022: 90%
with IPv4 traffic then halving year by year from then on, and IPv4 switch-off (ie. traffic < 1%) around 2027.
Neil
Just a reminder, that 10% is a global number.
The number in the USA is 25% today in general, is 37% for mobile devices.
Furthermore, forecasting is a dark art that frequently simply extends the past onto the future. It does not account for purposeful engineering design like the "world IPv6 launch" or iOS updates.
For example, once Apple cleanses the app store of IPv4 apps in 2016 as they have committed and pushes one of their ubiquitous iOS updates, you may see substantial jumps over night in IPv6 eyeballs, possibly meaningful moving that 37% number to over 50% in a few shorts weeks.
This will squarely make it clear that IPv4 is minority legacy protocol for all of mobile, and thusly the immediate future of the internet.
CB
Absolutely. So these figures should be regarded as conservative. The logistic growth model is just the default model choice for predicting new-things-replacing-old transitions. Any number of things could make the transition go faster, particularly, as you say, pushes by major platform vendors like Apple, and the move to mobile first in the expansion of the Internet in the developing world. Companies like search engine providers and streaming video providers could also exert pressure to speed up the IPv6 transition, if they wished. Also, passing psychological thresholds like 50% or 90% -- or even just fashion, in the sense of decision makers wanting to be associated with success and the future, not the rapidly contracting legacy of the past -- might have an effect to accelerate the eventual collapse of IPv4 traffic volumes. I can only imagine the scale of the schadenfreude IPv6 proponents will be able to feel once they're able to start talking about IPv4 as a legacy protocol. Neil
On 1/4/16, 11:54 AM, "NANOG on behalf of Neil Harris" <nanog-bounces@nanog.org on behalf of neil@tonal.clara.co.uk> wrote:
I can only imagine the scale of the schadenfreude IPv6 proponents will be able to feel once they're able to start talking about IPv4 as a legacy protocol.
*start*? https://www.flickr.com/photos/n3pb/sets/72157634324914351/ :-) Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
This page is fun to play with. The 3rd order polynomial currently results in the most optimistic projection and 700 days in the future is enough for a good view of the results. The page is for the US. https://www.vyncke.org/ipv6status/project.php?metric=q&country=us
On Jan 2, 2016, at 9:35 AM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:
Hi,
according to Google's statistics (https://www.google.com/intl/en/ipv6/statistics.html) on 31st December 2015 the IPv6 penetration reached 10% for the very first time. Just a little reminder. On 20th Nov 2012 the number was 1%. In December we also celebrated the 20th anniversary of IPv6 standardization - RFC 1883.
I'm wondering when we reach another significant milestone - 50% :-)
Tomas
-------- Original Message -------- Subject: Big day for IPv6 - 1% native penetration Date: Tue, 20 Nov 2012 10:14:18 +0100 From: Tomas Podermanski <tpoder@cis.vutbr.cz> To: nanog@nanog.org
Hi,
It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-)
T.
--- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
participants (87)
-
. -
A.L.M.Buxey＠lboro.ac.uk -
Aaron Toponce -
Alex -
Andrew Sullivan -
Arturo Servin -
Baldur Norddahl -
Ben Jencks -
Bjørn Mork -
Blair Trosper -
Blake Dunlap -
bmanning＠vacation.karoshi.com -
Brandt, Ralph -
Bruce Curtis -
Bryan Tong -
Ca By -
Cameron Byrne
-
Carlos M. Martinez -
Carsten Bormann -
Christopher Morrow -
CJ Aronson -
Cutler James R -
Dale W. Carder -
Damian Menscher -
Damian Menscher -
Dave Edelman -
david peahi -
david raistrick -
david.binet＠orange.com -
Dobbins, Roland -
Dovid Bender -
Eugen Leitl -
Frank Bulk -
Geoff Huston -
George Metz -
George, Wes -
Harald Koch -
Ingo Flaschberger -
Jacques Latour -
James Hartig -
Jared Mauch -
Jay -
Jeroen Massar -
Jeroen van Aart -
Joe Maimon -
joel jaeggli -
Jon Lewis -
Jonathan Towne -
Joseph Holsten -
Justin M. Streiner -
Lee Howard -
Mansoor Nathani -
Marco Davids (Prive) -
Mark Andrews -
Matthew Kaufman -
Michael Kratz -
Michael Thomas -
Mikael Abrahamsson -
mike
-
Mike Jones -
Måns Nilsson -
Naslund, Steve -
Neil Harris -
Nigel Stepp -
Oliver Garraux -
Owen DeLong -
Patrick W. Gilmore -
Paul Rolland -
Phil Regnauld -
Randy -
Randy Bush -
Ray Soucy -
Richard Barnes -
Ricky Beam -
Sander Steffann -
Steve Clark -
Steve Mikulasik -
sthaug＠nethelp.no -
Tim Chown -
TJ -
Tomas Podermanski -
Tony Hain -
Tore Anderson -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
William F. Maton Sotomayor -
William Herrin