Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Looking at http://mydeviceinfo.comcast.net you get a choice of wireless or IPv6 in Arris. I Wish they would ask which you want before install: I already have better wireless, and the Arris ones don't let you disable theirs :/ Thank you for the pointer - perhaps a swap is in order. David Barak Sent from a mobile device, please forgive autocorrection.
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 1/30/2013 9:10 PM, David Barak wrote: IPv6 has been launched on all Arris DOCSIS 3.0 C4 CMTSes, covering over 50% our network. The update you sent is lovely, except I can tell you that the one (also an Arris, running DOCSIS 3.0) which was installed in late October in my house in Washington simply does not run v6 with the pre-installed load. In this particular case C4 CMTSes is the important bit of that update. The CMTS is what your modem connects to on the other end. You might be connected to a different type of CMTS which doesn't support or isn't configured for IPv6. You wouldn't be able to know that without contacting someone with a good knowledge of the network at Comcast though. It could be as you say, that the modem only supports it when wireless is disabled and that is the only thing stopping it from working for you. If that was the case I would ask for a different modem, or go buy a modem that you think will work.
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Jan 30, 2013, at 12:43 PM, joel jaeggli joe...@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.
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 01/30/2013 01:51 PM, Cutler James R wrote: On Jan 30, 2013, at 12:43 PM, joel jaeggli joe...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 51099c0f.5040...@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 joe...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Comcast removed the no IPv6 excuse? That removal somehow skipped my house in Washington DC where they installed (last October) a router which does not even support it (an Arrus voice gateway- the one where you can#39;t turn of the crummy 2.4g wireless radio) and none of the folks I#39;ve spoken to on the phone can tell me when or if it will be coming. I look forward to Comcast giving me native v6 at home. David Barak
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 1359591223.5270.yahoomailmob...@web31809.mail.mud.yahoo.com, David Barak writes: Comcast removed the no IPv6 excuse? That removal somehow skipped my house in Washington DC where they installed (last October) a router which does not even support it (an Arrus voice gateway- the one where you can#39;t turn of the crummy 2.4g wireless radio) and none of the folks I#39;ve spoken to on t he phone can tell me when or if it will be coming. I look forward to Comcast giving me native v6 at home. David Barak Firstly fix your mail client. What's this #39; garbage in text/plain? Deployment Update Published on Tuesday, October 23, 2012 IPv6 has been launched on all Arris DOCSIS 3.0 C4 CMTSes, covering over 50% our network. We are targeting completion of the rest of the network by mid-2013. Our progress has led to nearly 2.5% of our Xfinity Internet customers actively using native dual stack. Additionally, IPv6 traffic has increased 375% since World IPv6 Day in June 2011. Following World IPv6 Launch in June 2012 Comcast also observed that approximately 6% of the 2012 Olympics served over YouTube to Comcast customers was over IPv6. http://www.comcast6.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Jan 30, 2013, at 7:52 PM, Mark Andrews ma...@isc.org wrote: Firstly fix your mail client. What's this #39; garbage in text/plain? That's yahoo web mail on an iPhone, sorry. Deployment Update Published on Tuesday, October 23, 2012 IPv6 has been launched on all Arris DOCSIS 3.0 C4 CMTSes, covering over 50% our network. We are targeting completion of the rest of the network by mid-2013. Our progress has led to nearly 2.5% of our Xfinity Internet customers actively using native dual stack. Additionally, IPv6 traffic has increased 375% since World IPv6 Day in June 2011. Following World IPv6 Launch in June 2012 Comcast also observed that approximately 6% of the 2012 Olympics served over YouTube to Comcast customers was over IPv6. http://www.comcast6.net The update you sent is lovely, except I can tell you that the one (also an Arris, running DOCSIS 3.0) which was installed in late October in my house in Washington simply does not run v6 with the pre-installed load. Now, is there some firmware upgrade which could fix this? Maybe, but it sure would be nice if the folks who answer the phone in support could direct me to someone who has heard of this technology. So no, as I said before, Comcast has *not* removed the v6 barrier here. I'd like it to just work, please. David Barak Sent from a mobile device, please forgive autocorrection.
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Wed, 30 Jan 2013, David Barak wrote: Comcast removed the no IPv6 excuse? That removal somehow skipped my house in Washington DC where they installed (last October) a router which does not even support it (an Arrus voice gateway- the one where you can#39;t turn of the crummy 2.4g wireless radio) and none of the folks I#39;ve spoken to on the phone can tell me when or if it will be coming. I know Verizon is rolling out v6 in some areas of their FiOS footprint. The router they provided supports it, but what I got from their customer service people was that they ran into some sort of issue with their TV set-top boxes working properly with IPv6 or at least in a dual-stack environment. At least that's where things stand in Pittsburgh. I don't think they've provided training to their customer service people on IPv6 yet. The rep I spoke with a few weeks ago told me I was the first customer that has asked her about it. Looking forward to native v6 / dual-stack here... jms
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
- Original Message - From: Justin M. Streiner strei...@cluebyfour.org I know Verizon is rolling out v6 in some areas of their FiOS footprint. The router they provided supports it, but what I got from their customer service people was that they ran into some sort of issue with their TV set-top boxes working properly with IPv6 or at least in a dual-stack environment. At least that's where things stand in Pittsburgh. VZF's ONTs can't even do *ARP* right, or at least they couldn't as of last March. We expect them to do v6? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Wed, 30 Jan 2013, David Barak wrote: On Jan 30, 2013, at 7:52 PM, Mark Andrews ma...@isc.org wrote: The update you sent is lovely, except I can tell you that the one (also an Arris, running DOCSIS 3.0) which was installed in late October in my house in Washington simply does not run v6 with the pre-installed load. Now, is there some firmware upgrade which could fix this? Maybe, but it sure would be nice if the folks who answer the phone in support could direct me to someone who has heard of this technology. So no, as I said before, Comcast has *not* removed the v6 barrier here. I'd like it to just work, please. That was the case with the router that was provided with my FiOS service over the summer. It looks like it wasn't even a firmware issue, or a Verizon-specific formware load, unless Verizon turned on the 'enable IPv6' bit at some point. When I first got it, there was no IPv6 configuration on the router at all, nor was there an option to turn it on. When I checked a few weeks later, there was an IPv6 configuration section, but the router had not been rebooted during that time, and it is still running the same firmware as before - when no v6 config section showed up. jms
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 8c10ded0-0980-4c76-8307-4f4f139d6...@yahoo.com, David Barak writes : On Jan 30, 2013, at 7:52 PM, Mark Andrews ma...@isc.org wrote: Firstly fix your mail client. What's this #39; garbage in text/plain? That's yahoo web mail on an iPhone, sorry. Deployment Update Published on Tuesday, October 23, 2012 IPv6 has been launched on all Arris DOCSIS 3.0 C4 CMTSes, covering over 50% our network. We are targeting completion of the rest of the network by mid-2013. Our progress has led to nearly 2.5% of our Xfinity Internet customers actively using native dual stack. Additionally, IPv6 traffic has increased 375% since World IPv6 Day in June 2011. Following World IPv6 Launch in June 2012 Comcast also observed that approximately 6% of the 2012 Olympics served over YouTube to Comcast customers was over IPv6. http://www.comcast6.net The update you sent is lovely, except I can tell you that the one (also an Arris, running DOCSIS 3.0) which was installed in late October in my house in Washington simply does not run v6 with the pre-installed load. Now, is there some firmware upgrade which could fix this? Maybe, but it sure would be nice if the folks who answer the phone in support could direct me to someone who has heard of this technology. So no, as I said before, Comcast has *not* removed the v6 barrier here. I'd like it to just work, please. Looking at http://mydeviceinfo.comcast.net you get a choice of wireless or IPv6 in Arris. David Barak Sent from a mobile device, please forgive autocorrection. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Wed, Jan 30, 2013 at 10:22:43PM -0500, Jay Ashworth wrote: VZF's ONTs can't even do *ARP* right, or at least they couldn't as of last March. We expect them to do v6? Perfect! We don't *need* ARP for v6!
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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-with-UMTS-unlocked-Galaxy/td-p/380685 http://www.zdnet.com/voip-and-instant-messaging-problem-looming-skype-doesnt-support-ipv6-707058/ http://www.gossamer-threads.com/lists/nsp/ipv6/4 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).
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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. http://owend.corp.he.net/ipv6 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).
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 b...@herrin.us wrote: On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy r...@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 her...@dirtside.com b...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 b...@herrin.us wrote: On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy r...@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 her...@dirtside.com b...@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.cl...@netwolves.com http://www.netwolves.com
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy r...@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 (IPHighAHigh AND IPHighBHigh) 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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 30, 2012, at 11:09 AM, William Herrin b...@herrin.us wrote:
On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy r...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
- 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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Fri, Nov 30, 2012 at 5:18 PM, Randy na...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message cap-gugwtcoafenkqsxsssomxmy1sqs2ofaprv26ww+gfvfp...@mail.gmail.com, William Herrin writes: On Fri, Nov 30, 2012 at 5:18 PM, Randy na...@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 her...@dirtside.com b...@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: ma...@isc.org
RE: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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:rdobb...@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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Fri, Nov 30, 2012 at 6:12 PM, Mark Andrews ma...@isc.org wrote: In message cap-gugwtcoafenkqsxsssomxmy1sqs2ofaprv26ww+gfvfp...@mail.gmail.com, William Herrin writes: On Fri, Nov 30, 2012 at 5:18 PM, Randy na...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 29 November 2012 12:48, Dobbins, Roland rdobb...@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.
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 2012-11-29 13:53 , . wrote: On 29 November 2012 12:48, Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 jer...@unfix.org wrote: On 2012-11-29 13:53 , . wrote: On 29 November 2012 12:48, Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Wed, Nov 28, 2012 at 1:30 PM, david peahi davidpe...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy r...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 b...@herrin.us wrote: On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy r...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 (b...@herrin.us): On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy r...@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! signature.asc Description: Digital signature
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Got some bad data here. Let me help. Sent from ipv6-only Android On Nov 29, 2012 8:22 AM, Michael Thomas m...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 m...@mtcc.com mailto:m...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message CALFTrnM+a56hx3CP0qqszfNrbirQZOefS_0uHVC8VQk=+qd...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 r...@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 jer...@unfix.org wrote: On 2012-11-29 13:53 , . wrote: On 29 November 2012 12:48, Dobbins, Roland rdobb...@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
RE: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
david raistrick dr...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Wed, Nov 28, 2012 at 2:52 AM, Bjørn Mork bj...@mork.no wrote: david raistrick dr...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
david raistrick dr...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 Abrahamssonemail: swm...@swm.pp.se
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 (swm...@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!! signature.asc Description: Digital signature
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 jer...@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...
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 Abrahamssonemail: swm...@swm.pp.se
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 28, 2012, at 10:47 AM, Ingo Flaschberger i...@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
RE: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
RE: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
-Original Message- From: Owen DeLong [mailto:o...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message cfb0f4de-3e7e-4cc2-a491-3b0e9741c...@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 rdobb...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 28, 2012, at 4:17 PM, Dobbins, Roland rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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...
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 jos...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 84f8debc-c754-4d06-99b0-405cc8a35...@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 =46rom 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. =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 = 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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message alpine.bsf.2.00.1211271621190.85...@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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 27, 2012, at 4:30 PM, Bryan Tong cont...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar jer...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message cap-guguzu-or-gtrp3vdahpk-btam1gzyt8ytjf0ppcb8ke...@mail.gmail.com , William Herrin writes: On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar jer...@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 her...@dirtside.com b...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 27, 2012, at 1:26 PM, david raistrick dr...@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
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. 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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 27 Nov 2012, at 23:44, Owen DeLong o...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Tue, Nov 27, 2012 at 6:29 PM, Mark Andrews ma...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 -Original Message- From: Owen DeLong [mailto:o...@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. 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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Nov 27, 2012, at 19:18 , Dave Edelman dedel...@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:o...@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. 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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 asulli...@dyn.com
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 20121128041816.gf1...@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: ma...@isc.org
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 11/27/2012 09:00 PM, Mark Andrews wrote: In message 20121128041816.gf1...@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. Let's be clear: nobody sets up a VPN because they want to. Mike
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 asulli...@dyn.com
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@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
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
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 rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
In message 69adb141-d40b-4dfb-8fbc-d0863897b...@delong.com, Owen DeLong write s: On Nov 27, 2012, at 19:18 , Dave Edelman dedel...@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: ma...@isc.org
