-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, November 27, 2012 6:48 PM To: Jared Mauch Cc: nanog@nanog.org Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly.
Sure, using gethostbyname() is certainly easier to find code examples,
but not impossible to find other examples.
Pretty much everything you need to know about taking your applications from mono-stack to dual-stack.
Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python.
In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do.
There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and- over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be.
It's actually pretty easy to change the datatype in an SQL database, so
I think that we are missing a significant part of this conversation. Even if programmers never write a line of code that invokes IPv6, they need to accommodate the effects of all the other programmers who aren't writing a line of IPv6 code. CGN renders most application logs useless unless they record source port as well as address. For many industries, logging of transactions in a manner that allows you to track back to the originator of the transaction is not optional. And yes that does translate to track back to the ISP who (when presented with the appropriate piece of paper) can convert the timestamp /IP address/ port combination to the customer who is responsible for the account. Even if programmers never write a line of code that invokes IPv6, they had better be testing their Internet facing applications against users in pure IPv4 environments; users in pure IPv6 environment using each of the transition mechanism, and users in dual-stack environments. I've spent more than a small amount of time explaining to vendors that AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded that the change would require retesting everything. I'm afraid that he wasn't happy when I pointed out that they obviously hadn't tested the first time and that as the customer, I was entitled to at least one full set of (successful) pre-delivery testing. --Dave that
shouldn't be that much of an impediment.
Owen