[161253] in North American Network Operators' Group
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Mar 6 05:21:09 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5136E23F.3060400@matthew.at>
Date: Wed, 6 Mar 2013 02:16:03 -0800
To: Matthew Kaufman <matthew@matthew.at>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>> Doubt it all you want. Once it's gone, it stops generating support =
calls, or they become very short:
>>=20
>> C: "Hi, my application isn't working through my NAT."
>> TSR: "Hi=85 Get IPv6, we don't support NAT any more."
>> TSR: "Is there anything else I can help you with today?"
>=20
> C: "Hi, my application isn't working between me and my grandmother"
> TSR: "Hi... Get IPv6, we don't suppotr NAT any more."
> C: "Screw you guys... my grandmother isn't served by an ISP that is =
offering IPv6 and her old operating system barely supports it anyway. =
Please refund my money."
>=20
Point is that Grandma's ISP will support IPv6 by the time this comes to =
pass, or, Grandma will be 1/10,000 and the ISV will either cheerfully =
refund the price of the application in those limited circumstances, or, =
say "I'm sorry, we don't offer refunds. You're welcome to continue using =
the old version which includes NAT traversal."
In either case, there are some customers that it's just too expensive to =
maintain vs. what you get from them. Once IPv4 ceases to be the internet =
lingua franca, the ones clinging to it will rapidly fall into that =
category.
> The point being that for some applications, *both ends* need to be on =
IPv6 before any of this complexity can go away.
Point being that once a sufficient set of end points is on IPv6 that the =
market share lost by not supporting IPv4 and/or IPv4 NAT traversal will =
stop getting supported. Just like many developers don't support the 10+% =
of us that use Macs, the 5% or less that don't have IPv6 in a few years =
will fall off the supportability list.
> For the rest, they're just talking to web services... and until the =
places those are hosted run out of IPv4 addresses, nobody cares.
I don't think this is anywhere near as large a userbase as you think =
these days.
>> NAT will most likely become a thing of the past. I know you prefer to =
remain in denial about this, but more and more of the ISVs I have talked =
to are saying that they have no intention of adding NAT traversal to =
their IPv6 code.
>=20
> I'm not in denial about this. I just don't think IPv4 is going away in =
the next 30-60 days... and so my next one to two releases, which is what =
I'm engineering for this week, need to support it, and NAT traversal, =
and all that.
> It'd be nice if they supported IPv6 as well, but really when you rank =
on a big list all the things customers are demanding, IPv6 is *way* down =
that list.
If you're not looking past 60 days, then we're not having the same =
conversation. What will exist in the next 30-60 days is already =
determined, so any discussion of positive change to that situation is =
pretty much irrelevant as it can't possibly come to fruition.
>> The firewall shouldn't be adjusting the packet. I'm not sure why you =
think it would or what adjustments you think it would be making.
>=20
> Option stripping, Diffserv scrubbing, all sorts of things that make =
the packets no longer identical.
Perhaps I should have said "identical enough to be readily recognizable =
using the same tcpdump filter string." As long as they don't change the =
IP addresses or the port numbers, that's pretty much the case. Mucking =
with the other things is undesirable, but not fatal.
>>>> Finally=85 There are 7 billion people on the planet. There are 2 =
billion currently on the internet.
>>>>=20
>>>> The other 5 billion won't fit in IPv4. If you want to talk to them, =
you'll need IPv6.
>>> Or a very big CGN.
>> If you think this will actually scale and provide a user experience =
that will be considered at all acceptable, then you are delusional.
>=20
> For most web and web-service based applications, it'll work just fine.
Which is about 60% of modern internet traffic. The remaining 40%...
> In the "long run", sure, it runs out of steam... but I'm already =
talking about times way sooner than your 5-8 years.
I think you will be surprised how fast it runs out of steam even for web =
services.
On any sort of a large customer-base scale, it very quickly becomes a =
maintenance and support nightmare.
>> I don't think that's actually true. I think that the economic =
incentives to drop IPv4 support from the inter domain world as soon as =
possible will apply strong pressure to expedite this process once IPv6 =
achieves a certain level of critical mass.
>=20
> Yes... and will that "certain level of critical mass" happen before =
the end of this June? If not, all it means is extra work, not less.
Granted, it's much more work at first and a little work as long as IPv4 =
maintenance is required. If your application was stupidly designed such =
that it's unnecessarily difficult to add dual-stack support, then it's =
even worse. However, you're having a 60 day conversation while I'm =
talking about considerations applicable to something on an =
enterprise-roll-out time table (most likely closer to 24 months than 2 =
and probably 12-18 months of preparation before the roll-out starts in =
earnest).
>=20
>>=20
>>> Trying to sell this to smart engineers writing code or testing it as =
"less work" is just going to get you laughed out of the room as the =
crazy IPv6 zealot.
>> Actually, smart engineers realize that in the long run it's a lot =
less work.
>=20
> Yes. In "the long run"... which is way farther out than the backlog =
for the current sprint or even release, I'm afraid.
1. You're talking development, I'm talking enterprise.
2. You're talking immediate action, I'm talking enterprise rollout =
timescales.
>> That there's a brief period where it's way more work followed by a =
much better long-term.
>=20
> That "brief period" lasts longer than most software startups are in =
existence. Your shortest prediction was 5 years... an eternity, still. =
So right now, today, when you take the powerpoint deck to the engineers, =
you are asking them to do >2x the work, starting now, for some unknown =
future benefit... likely after they are either 1) working somewhere else =
or 2) the entire operation has been acquired by someone else.
5 years from now. Given the speed with which the average enterprise =
moves on an undertaking like this, that's probably not much more than 12 =
months after they deliver IPv6 to the desktop.
>=20
>> I'll leave off the obvious question about how smart can engineers be =
if they built an application in the 90s that was as strongly tied to =
unistack as Skype is when it was obvious that unistack IPv4 was a very =
temporary phenomenon.
>=20
> Well maybe it wasn't that obvious in Estonia in the early 1990s. When =
I wrote my P2P stack in the same era, it supported both IPv4 and IPv6, =
and a version of that is what is in every copy of Flash Player. Working =
*and tested* to support IPv6.
If you were on the internet, it's hard to imagine how you missed the =
fact that we knew we were going to run out of IPv4 addresses fairly =
quickly back then. If you learned enough about NAT to know about doing =
NAT traversal, odds are pretty good that you knew that address =
exhaustion was driving NAT and that IPv6 was the longer term solution =
while NAT was a hack to get us by until then,
>=20
> Matthew Kaufman
