"Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....

Sat Dec 1 16:43:52 UTC 2012

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).