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

Mailman List Mirror (Read Only)
21

Hello William,

Thank you for your inputs, see my comments inline.

>
> a) Set the strategic context: how your organisation derives value from IP
> networks and the Internet.
>
> b) Overview of the problem: IPv4 exhaustion
>
> c) Implications of IPv4 Exhaustion to your organization’s business model.
>
> d) Introduction of IPv6 as a solution to IPv4 exhaustion.
>
> e) Understanding the risks involved.
>
> f) How much will deploying IPv6 will cost.
>
> g) Call to action.

My experience has been that this model fail to _sell_ IPv6 to
non-technical executives. Non-technical executives have 3 questions
you must effectively answer:

And the model does explicitly address all three concerns (note I only
posted an outline ... the post (How to ‘Sell’ IPv6 to Executive Management
– Guidance for Engineers<Techxcellence! | Thoughts on my journey of technical mastery)
gives more detail)

1. What is the real dollar cost of doing the project (including both
up-front and currently indefinite ongoing costs of dual stack. And
don't forget to price out risk!).

Now in the post, I mention cost elements. At a point when you are still
trying to convince execs about v6, is it possible to have an accurate value
for this cost. Wouldn't cost elements and ball-park amounts be sufficient?

Please could you shed some more light on 'Pricing out Risk'? any tools and
techniques to do that would be highly appreciated.

2. What is the real dollar cost of not doing the project. (i.e.
customers you expect to lose because you didn't do it. Don't suggest
that IPv6 will allow you to avoid acquiring more IPv4. That's not yet
true and if you say, "It will be in 5 years" the exec will respond,
"great, come see me in 5 years.")

IPv6 has elements of a disruptive technology (right now it really only
addresses the needs of a fringe segment of the market and also is perceived
as worse with respect to feature set). The inherent problem with such
technologies is that no one knows the real dollar cost of NOT taking action
(when concrete data becomes available to support that, it would mean it has
already seen market success and so if you still don't have it, you'd be too
late.)

However, in terms of cost (and risk) of inaction - it really will depend on
how your organisation derrives value from the Internet and could run from
stalled growth in client and revenue base, inability to retain clients and
possible unknown adjacent opportunities that will be enabled by IPv6.

3. What is the opportunity cost of doing/not doing the project.

Implicitly they'll also be looking for the answer to a fourth
question: Do you know WTF you're talking about? If you assure them
it's all peaches and cream with tiny costs and no opportunity cost,
the answer is, "no."

I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6
Solution" in very specific terms of the business model of the company will
implicitly inspire confidence in execs that they know what they are talking
about.

22

Hello all,

I forgot to include a link to the post that details the framework I
initially suggested. It's at

http://techxcellence.net/2013/03/05/v6-business-case-for-engineers/

Regards

23

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

24

Cameron -

  I agree with the intent, but just for clarity, I'd like to ask what you mean
  by "the black market"? I see two possibilities, one being that the current
  IPv4 address transfer regime is viewed as "illegitimate' (which would be the
  typical use of the term 'black market'); or secondly, that the current IPv4
  transfer system is fine but likely won't meet one's requirements for growth
  and hence may require turning to transfers "outside the system", i.e. truly
  to an underground black market...

  I can see reasons to assert either view, but figured other folks might also
  be wondering which of these two potential points you are making... :slight_smile:

Thanks!
/John

25

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

Point is that Grandma's ISP will support IPv6 by the time this comes to pass, or, Grandma will be 1/10,000 and the ISV will either cheerfully refund the price of the application in those limited circumstances, or, say "I'm sorry, we don't offer refunds. You're welcome to continue using the old version which includes NAT traversal."

In either case, there are some customers that it's just too expensive to maintain vs. what you get from them. Once IPv4 ceases to be the internet lingua franca, the ones clinging to it will rapidly fall into that category.

The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away.

Point being that once a sufficient set of end points is on IPv6 that the market share lost by not supporting IPv4 and/or IPv4 NAT traversal will stop getting supported. Just like many developers don't support the 10+% of us that use Macs, the 5% or less that don't have IPv6 in a few years will fall off the supportability list.

For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares.

I don't think this is anywhere near as large a userbase as you think these days.

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.

If you're not looking past 60 days, then we're not having the same conversation. What will exist in the next 30-60 days is already determined, so any discussion of positive change to that situation is pretty much irrelevant as it can't possibly come to fruition.

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.

Perhaps I should have said "identical enough to be readily recognizable using the same tcpdump filter string." As long as they don't change the IP addresses or the port numbers, that's pretty much the case. Mucking with the other things is undesirable, but not fatal.

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.

Which is about 60% of modern internet traffic. The remaining 40%...

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 think you will be surprised how fast it runs out of steam even for web services.

On any sort of a large customer-base scale, it very quickly becomes a maintenance and support nightmare.

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.

Granted, it's much more work at first and a little work as long as IPv4 maintenance is required. If your application was stupidly designed such that it's unnecessarily difficult to add dual-stack support, then it's even worse. However, you're having a 60 day conversation while I'm talking about considerations applicable to something on an enterprise-roll-out time table (most likely closer to 24 months than 2 and probably 12-18 months of preparation before the roll-out starts in earnest).

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.

1. You're talking development, I'm talking enterprise.
2. You're talking immediate action, I'm talking enterprise rollout timescales.

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.

5 years from now. Given the speed with which the average enterprise moves on an undertaking like this, that's probably not much more than 12 months after they deliver IPv6 to the desktop.

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.

If you were on the internet, it's hard to imagine how you missed the fact that we knew we were going to run out of IPv4 addresses fairly quickly back then. If you learned enough about NAT to know about doing NAT traversal, odds are pretty good that you knew that address exhaustion was driving NAT and that IPv6 was the longer term solution while NAT was a hack to get us by until then,

26

I don't think the business case is the issue. It is the timeline over which the sense of urgency becomes important enough for most execs to take seriously. That's still a large unknown.

Antonio Querubin
e-mail: tony@lavanauts.org
xmpp: antonioquerubin@gmail.com

27

Why should they care about the timeline if they aren't convinced it is even
worth doing?

28

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? BBC News - Microsoft spends $7.5m on net addresses

#3 I believe this position of your's / Microsoft's is also known as
the "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
Literally IPv6 | blabs)

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

29

I've migrated (or enabled) offices (and homes) to IPv6 without them even realising it. If it's just enabling IPv6 connectivity there may be very little to be done with regards to training and informing end users. The beauty of IPv6 in my experience is that it is quite transparent, you don't even notice it is there (or shouldn't, if done properly).

Adapting your current software to IPv6, that could be more tricky. Although if you use the right IPv6 aware libraries and functions it could be relatively easy in code. In my own apps it's just a matter of changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done so yet. Although interestingly that may have complications (sudden loss of connectivity or more subtle issues). So I can relate to the fact it can be tricky.

Greetings,
Jeroen

30

[…]

b) To you who are managers, what else do you need your engineers to address
in order for you to be convinced?

How long will it take to complete the project?

31

That is clearly reducto ad absurdum and does not resemble Matthew's
detailed and nuanced argument. Please try again.

32

I'm probably biased because I'm a fulltime consultant off in
EndUserLand, but I don't believe this argument for a moment.

I'm sorry, but a lot of organizations' response to IPv6 has been "Ok,
desktops will need an overlay of it for some websites in AP next year,
so we'll do that. And we need an IPv6 front end visibility for our
website. But we don't REALLY need to change to using it primarily."
And a fair number are still "What six?".

A very small sliver of end-user networks are truly fully functionally
dual-stacking internally now.

A fair number of IT admins still don't know anything useful about how
to implement it, and are going to pray for translating gateways, and
are having pain and suffering getting their heads around what's needed
for the minimal IPv6 front end for their corporate web presence.

Adoption in big network providers, and in big network services, and in
big telco (both broadband and mobile users) are much further along
than the average "enterprise".

The mindshare shift is happening, but the change won't snowball until
IT admins - in bulk - really get it.

33

1. What is the real dollar cost of doing the project (including both
up-front and currently indefinite ongoing costs of dual stack. And
don't forget to price out risk!).

Now in the post, I mention cost elements. At a point when you are still
trying to convince execs about v6, is it possible to have an accurate value
for this cost. Wouldn't cost elements and ball-park amounts be sufficient?

Please could you shed some more light on 'Pricing out Risk'? any tools and
techniques to do that would be highly appreciated.

Howdy,

For that, you need the help of a real cost analyst. That's what
they're for; they help organizations figure out a solid idea what
something will really cost before they start spending money. If your
organization is large, you may even have one on staff somewhere.

You can also consider pitching an IPv6 pilot project where you get
your IP addresses and bring IPv6 in from your ISPs but then stop just
on your side of the border rather than thoroughly deploying it. That
strongly bounds the cost, including the cost from risk. One of the
elements of such a pilot project would be contracting a cost analyst
to help you collect figure out what data to collect during the pilot
and then produce a cost model from the data to figure out what it'll
really cost for a full deployment.

2. What is the real dollar cost of not doing the project. (i.e.
customers you expect to lose because you didn't do it. Don't suggest
that IPv6 will allow you to avoid acquiring more IPv4. That's not yet
true and if you say, "It will be in 5 years" the exec will respond,
"great, come see me in 5 years.")

IPv6 has elements of a disruptive technology (right now it really only
addresses the needs of a fringe segment of the market and also is perceived
as worse with respect to feature set). The inherent problem with such
technologies is that no one knows the real dollar cost of NOT taking action
(when concrete data becomes available to support that, it would mean it has
already seen market success and so if you still don't have it, you'd be too
late.)

Practically speaking, there's no point in projecting the cost of never
taking action. You only have to project the cost of not intiating
action *this year*, or within two years or whatever the budgeting
cycle is that allows you to get started on the proposed project.

Implicitly they'll also be looking for the answer to a fourth
question: Do you know WTF you're talking about? If you assure them
it's all peaches and cream with tiny costs and no opportunity cost,
the answer is, "no."

I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6
Solution" in very specific terms of the business model of the company will
implicitly inspire confidence in execs that they know what they are talking
about.

Your first paragraph loses the argument: the day has past when IPv6
could become a credible solution to the IPv4 exhaustion problem. Like
it or lump it, NAT was the solution to the IPv4 exhaustion problem.
Which the exec will learn when he chats up his computer literate buddy
before making his decision.

If IPv6 approaches ubiquity, it'll get another crack at solving that
problem. Until then, the business case for IPv6 deployment is about
making your products compatible with emerging standards and to what
(if any) degree your customers will penalize you if you do not do so
during your projection window.

If you're an ISP or you make network software, this is a
straightforward case to make. There are public sources of IPv6
deployment rate data. You can presume that a similar rate holds among
your customers and that the customers who deploy IPv6 will disqualify
your product if the product doesn't work with IPv6.

If your business isn't networks, you have a much harder case to make.
As another poster noted, the end of IPv4 is not on the radar yet. A
statistically insignificant number of people will change banks this
year over their bank's web site IPv6 reachability.

Regards,
Bill Herrin

34

and keeping in mind that the bulk still don't "get" ipv4, either, (how many times a day do I explain to someone what a /xx is, and how you'd fill that out for just a single ip address....sigh), the snowball really won't happen until it Just Works(tm). impe and all that.

35

I had to check something now, but the current client site is first
time my laptop's come up on the client's internal net finding IPv6
addresses in use.

10 clients in the last 4 years, mostly SF Bay Area tech firms of some sort.

This client is a subsidiary of a network hardware vendor.

Your mileage may vary, but ...

36

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: 1406 - webrtc - Web-based real-time communication - Monorail (because *clearly* there's no reason to have taken the "extra effort" to make it IPv4-only, right?)

37

From: Matthew Kaufman [mailto:matthew@matthew.at]

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.

[WEG] snip

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.

[WEG] One point to consider is that as an application/content provider, there is a real risk to you that the kinky middlebox (CGN, etc) that an SP puts between you and your customers in order to extend the life of IPv4 in their network will break or otherwise degrade your service in ways that you can't control, may not be able to test for, and may not be able to fix easily. The success of your business becomes dependent on that ALG, or the scale and performance of that box and its effect on latency and jitter. You're basically held hostage by the business drivers of an organization that has little vested interest in ensuring your specific application works, other than to ensure that the majority of their customers stay happy. How much do you trust $ISP not to negatively affect your user experience?

Fixing it requires good assumptions about all possible variations of how it might work in each SP and vendor implementation so that your NAT traversal code works across multiple layers of NAT in each direction, and that may not help if the performance is just bad on account of scale. This is incrementally worse than the status quo today, because while CGN/NAT44 is fairly common, especially in the mobile space, it isn't as common in networks where there is already a layer of NAT (eg a home ISP) thus giving you NAT444, so it's maybe not quite as simple as you're making it.
I'm not going to argue that this problem will magically go away if you start supporting IPv6 in the next feasible release, but given the IPv6 deployments underway in many ISPs, it seems a worthwhile thing to pursue in order to possibly bypass some permutations of NAT that you're not solving for today and attempt to remove another barrier to moving to IPv6-only and the attendant reductions in complexity single-stacking provides.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

38

I think it's also important to cover the following topics somewhere in the process:

1. This will affect the entire organization, not just the IT department and
  will definitely impact all of apps, sysadmin, devops, operations, and
  networking teams within the IT department.

2. Training will be required for virtually all levels of the organization. End users
  won't need more than a ~2 hour introduction to what to look for during and

I've migrated (or enabled) offices (and homes) to IPv6 without them even realising it. If it's just enabling IPv6 connectivity there may be very little to be done with regards to training and informing end users. The beauty of IPv6 in my experience is that it is quite transparent, you don't even notice it is there (or shouldn't, if done properly).

You can usually get away with this for the home.

In the enterprise, I wouldn't recommend it.

If the users get surprised, it's a lot worse than if they know what's coming. Rumors rapidly get way out of hand before corrective action can quell a problem. OTOH, if the user base knows what to expect and that the problems are anticipated and/or being properly worked, you tend to get a greater level of patience and understanding.

Further, a little training up front can go a long way to getting better user reports into the help desk to reduce the time consumed in troubleshooting.

As I said, a 2 hour introduction is about all that's required, but it really is helpful.

As to other things, consider that once you enable stuff on IPv6, you need to be able to monitor it. If you're looking at IPv6 transition from an enterprise perspective, it's not just delivering IPv6 to every desktop, but making sure that all of your internal applications and services are also available on IPv6. That can be a significant development undertaking.

I agree just enabling the network to use it is a useful and positive step forward that can be taken fairly easily.

However, it's certainly not an end in and of itself and should not be where your efforts stop in any real plan.

Adapting your current software to IPv6, that could be more tricky. Although if you use the right IPv6 aware libraries and functions it could be relatively easy in code. In my own apps it's just a matter of changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done so yet. Although interestingly that may have complications (sudden loss of connectivity or more subtle issues). So I can relate to the fact it can be tricky.

Yep. The important thing is for the enterprise to be aware of what is required and realize that it spans development, systems administration, networking, logistics, and will have end-user impacts worthy of some consideration.

Owen

39

People adapting stuff to IPv6 may find this blog entry of mine useful:

   http://biplane.com.au/blog/?p=179

It says "Java" in the title, but the principles are pretty much the same
for anything... Java has a class that encapsulates "IP address",
regardless of address family, so if your stuff was written with that
it's a lot easier to migrate some stuff. The same will be true of any
language with a similar abstraction. But you can't get away from print
and display changes, for example, where the physical space required,
that is, the real estate on screen or paper, is about three times larger
for IPv6 than IPv4.

And you can't get away from the end-user impact of the new and unknown;
IPv6 is transparent only up to the first support call...

In technical forums I find myself saying things like "bee thousand" for
"b000", "ay thousand dee zero" for "a0d0" and on one occasion even "ay
thousand and deety". It seems very natural and right to me and most
people seem to understand it without much effort, but boy, does it get
me strange looks sometimes :slight_smile: No-one looks askance when you say "one
ninety two dot one sixty eight dot one dot one", but that's pretty weird
too, really. I guess we (the wider IPv6 using community) will have to
develop a human vocabulary for IPv6 as well as a technical one :slight_smile:

Regards, K.

40

If nothing else, it's worthing giving that last point some priority
(i.e. "And we need an IPv6 front end visibility for our website.")
While the Internet is greater than the web, the more public facing
servers reachable by IPv6, the more functional IPv6 is as an IPv4
substitute for connecting customers to the Internet.

/John