"Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
matthew at matthew.at
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.
> 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
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.
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).
More information about the NANOG