[161275] in North American Network Operators' Group
RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (George, Wes)
Wed Mar 6 16:36:24 2013
From: "George, Wes" <wesley.george@twcable.com>
To: Matthew Kaufman <matthew@matthew.at>, Owen DeLong <owen@delong.com>
Date: Wed, 6 Mar 2013 16:36:05 -0500
In-Reply-To: <5136E23F.3060400@matthew.at>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> 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, the=
re is a real risk to you that the kinky middlebox (CGN, etc) that an SP put=
s between you and your customers in order to extend the life of IPv4 in the=
ir network will break or otherwise degrade your service in ways that you ca=
n'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 ba=
sically held hostage by the business drivers of an organization that has li=
ttle vested interest in ensuring your specific application works, other tha=
n to ensure that the majority of their customers stay happy. How much do yo=
u 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 n=
ot help if the performance is just bad on account of scale. This is increme=
ntally worse than the status quo today, because while CGN/NAT44 is fairly c=
ommon, 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 star=
t supporting IPv6 in the next feasible release, but given the IPv6 deployme=
nts underway in many ISPs, it seems a worthwhile thing to pursue in order t=
o possibly bypass some permutations of NAT that you're not solving for toda=
y and attempt to remove another barrier to moving to IPv6-only and the atte=
ndant reductions in complexity single-stacking provides.
Wes George
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se 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 dissem=
ination, distribution, copying, or action taken in relation to the contents=
of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.
