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

Wed Mar 6 20:57:15 UTC 2013

On 3/6/2013 9:20 AM, Cameron Byrne wrote:
> On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>> 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.
>>
> So, your position, which is substantiated my Microsoft's / Windows
> Phone's / Skype's lack of IPv6 support , is that "nobody cares" until
> we "run out of IPv4".

No. While you've cleverly quoted something I did say, Skype is an 
example of an application where, as I mentioned in the paragraph above, 
until both ends of a call are always guaranteed to be on IPv6, there is 
*more* complexity involved in supporting both IPv4 and IPv6 than in 
supporting IPv4 alone.

This entire discussion started with "how should I sell IPv6 to 
executives" and Owen claimed that switching to IPv6 represents less 
engineering effort. I simply claim that isn't true. In fact the amount 
of engineering effort required to make an application like Skype work 
(both development effort and testing required) where the users who might 
want to call each other are on an unknown mixture of IPv4, IPv4/IPv6 
dual-stack, IPv6 w/NAT64 for IPv4, and IPv6 single-stack is *tremendous* 
compared to the effort required to make it work with IPv4 and end-user 
NAT devices.

> But, Matthew, your division of Microsoft is really a bunch of "Free
> Riders" that is honestly holding back the rest of us.

My division of Microsoft is currently engaged in a massive amount of 
engineering... work to add features that customers are demanding, work 
to make Skype work better on mobile devices, work to make Skype 
interoperate with Lync, and yes, work to make Skype work in the huge 
explosion of new network connectivity situations it will find itself in 
as IPv6 is deployed and especially as those IPv6 users stop getting 
native IPv4 alongside it.

And we're using Agile and Scrum as our engineering methodology, and I 
can tell you that it is very very hard to get IPv6 work to rise to the 
top in any organization, including ours, given that the short-term 
return on that investment is nil and the engineering and testing effort 
is huge.

But again, the only reason I even brought this up here is that there are 
people like Owen running around trying to tell engineers that when the 
whole world is IPv6 everything will be so much easier... and while that 
might be true, there are at least 5 more years and probably more where 
the necessary engineering effort required to support *both*, especially 
for applications like Skype, is crazy hard compared to IPv4-only, and so 
trying to sell the execs on the idea that we'll deploy some IPv6 
internally and write some IPv6 code and our QE and Dev budget can go 
*down* is frankly ridiculous.

Matthew Kaufman

p.s. As I pointed out privately last night, if doing IPv4+IPv6 was 
really easier than doing IPv4-only, we wouldn't see other smart 
collections of engineers with bugs like this one: 
https://code.google.com/p/webrtc/issues/detail?id=1406 (because 
*clearly* there's no reason to have taken the "extra effort" to make it 
IPv4-only, right?)