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

Wed Mar 6 06:29:19 UTC 2013

On 3/5/2013 8:20 PM, Owen DeLong wrote:
> On Mar 5, 2013, at 7:55 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>
>> On 3/5/2013 7:15 PM, Owen DeLong wrote:
>>> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. <mukom.tamon at gmail.com> wrote:
>>>
>>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.lists at mgm51.com> wrote:
>>>>
>>>>> I would lean towards
>>>>>
>>>>>   f) Cost/benefit of deploying IPv6.
>>>>>
>>>> I certainly agree, which is why I propose understanding you organisation's
>>>> business model and how specifically v4 exhaustion will threaten that. IPv6
>>>> is the cast as a solution to that, plus future unknown benefits that may
>>>> result from e-2-e and NAT elimination.
>>>>
>>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even
>>>> for engineers, there's not much of a benefit except more address space.
>>> I'm not so sure about that…
>>>
>>> Admittedly, most of these are too technical to be suitable for management consumption, but:
>>>
>>> 	1.	Decreased application complexity:
>> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then…
>>
> I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result:

Two unsubstantiated suppositions deleted.

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.

> Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice.

Sure. In 5 to 8 years, as you claimed.

>
> Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short:
>
> C: "Hi, my application isn't working through my NAT."
> TSR: "Hi… Get IPv6, we don't support NAT any more."
> TSR: "Is there anything else I can help you with today?"

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."

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.

>
> 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.

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.

> 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.

Option stripping, Diffserv scrubbing, all sorts of things that make the 
packets no longer identical.

>
>>> Finally… There are 7 billion people on the planet. There are 2 billion currently on the internet.
>>>
>>> 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.

For most web and web-service based applications, it'll work just fine.

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 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.

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.

>
>> 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.

Yes. In "the long run"... which is way farther out than the backlog for 
the current sprint or even release, I'm afraid.

>   That there's a brief period where it's way more work followed by a much better long-term.

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.

> 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.

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.

Matthew Kaufman