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

Cameron Byrne cb.list6 at gmail.com
Sun Dec 2 20:36:05 UTC 2012


> "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-7000007058/

http://www.gossamer-threads.com/lists/nsp/ipv6/33334

http://www.change.org/petitions/skype-add-ipv6-support-to-skype


http://www.gossamer-threads.com/lists/nsp/ipv6/41499

But, this is just the same old carping.  Skype / Microsoft should add
IPv6 support because it is the right thing to do for the Internet.
Microsoft, like Google and Facebook, was part of world v6 launch and
knows ipv6 is about making the internet better and bigger.

The Skype issue is so serious, that it is specifically blocking
IPv6-only architectures since it is THE most major app that breaks in
IPv6-only.  Skype is the killer app for 464XLAT ... which means that
since Skype refuses to evolve their product, the OS now has to have
hacks to fix it.

CB

> other things would be way above it in the stack-ranked backlog(s) anyway.
> One could argue that until we add IPv6 support throughout our systems,
> consumers will continue to demand IPv4 connectivity from operators in order
> to run software like ours, rather than us being cut off from any meaningful
> proportion of customers.
>
> pps. And until we were last acquired, we *didn't* have IPv6 at our
> developer's desktops. Now we do, but it doesn't connect to the global IPv6
> Internet (yet).
>




More information about the NANOG mailing list