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

[Cameron Byrne <cb.list6 () gmail com>]

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

#1.  We have run out of IPv4, check APNIC and RIPE, they are done.
ARIN and LACNIC both have ~2.5 /8s left.  Are you waiting on AfriNic?
When are we run out, in your opinion?  How are people in Indonesia,
India, and the Philippines (and so ...) expected to get online without
IPv4 addresses at APNIC?  How do a launch a new disruptive wireless
service across Europe when RIPE's currently implemented run-out-policy
only allows for a /22 max allocation, ever....

#2.  Your employer seems to have money to buy IPv4 addresses, what
about everyone else?  http://www.bbc.co.uk/news/technology-12859585

#3  I believe this position of your's / Microsoft's is also known as
the "free rider problem".
http://en.wikipedia.org/wiki/Free_rider_problem

I personally would expect that Microsoft would not be a "free rider",
i am sure they would like to cultivate an imagine of technology
leadership.  I expect a leadership role from Microsoft given their
stature and resources.  And, all told, they did step up for world IPv6
launch on www.bing.com, which is a big deal and many of their products
work admirably well with IPv6 (notwithstanding this Exchange issue
http://labs.apnic.net/blabs/?p=309)

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

I even had to write an IETF draft, more or less, just to work-around
Skype's issues http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-10

Granted, there are other apps that don't work with IPv6, for example
Netflix's Android app.  But Skype is the big dog.  And so is
Microsoft.  I think we expect technology leadership there, not a "free
rider" making the rest of the system work around you at a cost to
everyone else.

CB


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