On 3/6/2013 9:20 AM, Cameron Byrne wrote:
On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman <matt...@matthew.at> wrote:
On 3/5/2013 8:20 PM, Owen DeLong wrote:
On Mar 5, 2013, at 7:55 PM, Matthew Kaufman <matt...@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.ta...@gmail.com>
wrote:
On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.li...@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?)
