RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?

["George, Wes" <wesley.george () twcable com>]

> From: Matthew Kaufman [mailto:matthew () matthew at]

> They suggest that IPv4 support is needed *in conjunction with* IPv6
> support for 5-8 years.
>
> That's a long time if you're developing software... so, basically, no...
> no cost or effort saving if you were to do this work today. In fact, >2x
> the effort if you were to start today.
>
> So again, why try to sell it to the engineers that way? Either sell it
> as 1) If you don't start doing a lot more work now you'll be screwed at
> the transition or 2) You should just wait until you can single-stack on
> IPv6.
[WEG] snip
> The point being that for some applications, *both ends* need to be on
> IPv6 before any of this complexity can go away.
>
> For the rest, they're just talking to web services... and until the
> places those are hosted run out of IPv4 addresses, nobody cares.
[WEG] One point to consider is that as an application/content provider, there is a real risk to you that the kinky 
middlebox (CGN, etc) that an SP puts between you and your customers in order to extend the life of IPv4 in their 
network will break or otherwise degrade your service in ways that you can't control, may not be able to test for, and 
may not be able to fix easily. The success of your business becomes dependent on that ALG, or the scale and performance 
of that box and its effect on latency and jitter. You're basically held hostage by the business drivers of an 
organization that has little vested interest in ensuring your specific application works, other than to ensure that the 
majority of their customers stay happy. How much do you trust $ISP not to negatively affect your user experience?

Fixing it requires good assumptions about all possible variations of how it might work in each SP and vendor 
implementation so that your NAT traversal code works across multiple layers of NAT in each direction, and that may not 
help if the performance is just bad on account of scale. This is incrementally worse than the status quo today, because 
while CGN/NAT44 is fairly common, especially in the mobile space, it isn't as common in networks where there is already 
a layer of NAT (eg a home ISP) thus giving you NAT444, so it's maybe not quite as simple as you're making it.
I'm not going to argue that this problem will magically go away if you start supporting IPv6 in the next feasible 
release, but given the IPv6 deployments underway in many ISPs, it seems a worthwhile thing to pursue in order to 
possibly bypass some permutations of NAT that you're not solving for today and attempt to remove another barrier to 
moving to IPv6-only and the attendant reductions in complexity single-stacking provides.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, 
confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the 
individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby 
notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments 
to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the 
sender immediately and permanently delete the original and any copy of this E-mail and any printout.