Matthew, I am sorry to offend, but I don't think the Skype development "agile" when u say IPv6 is not needed or important in 2013. Microsoft hs strong thought leaders like VJ Gill and Najam Ahmad who bring v6 to Bing and GFS. You should follow their example. Regards Vinod
Date: Wed, 6 Mar 2013 12:57:15 -0800 From: matthew@matthew.at To: cb.list6@gmail.com Subject: Re: What Should an Engineer Address when 'Selling' IPv6 to Executives? CC: nanog@nanog.org
On 3/6/2013 9:20 AM, Cameron Byrne wrote:
On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 3/5/2013 8:20 PM, Owen DeLong wrote:
On Mar 5, 2013, at 7:55 PM, Matthew Kaufman <matthew@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@gmail.com> wrote:
> On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.lists@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?)