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

Mailman List Mirror (Read Only)
1

Dear experts,

I've found myself thinking about what ground an engineer needs to cover in
order to convince the executives to approve and commit to an IPv6
Deployment project.

I think such a presentation (15 slides max in 45 minutes) should cover the
following aspects:

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.

I've detailed my thinking into each of these items at <How to ‘Sell’ IPv6
to Executive Management – Guidance for
Engineers<Techxcellence! | Thoughts on my journey of technical mastery;

My question and this is where I'd appreciate some input:

a) To all you engineers out there who have convinced managers - what else
did you have to address?

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

Regards.

As always, all opinions expressed are mine and do not necessarily represent
the views of my employers, past or present.

2

Yo Mukom!

3

Hi,

In-line

Dear experts,

I've found myself thinking about what ground an engineer needs to cover in
order to convince the executives to approve and commit to an IPv6
Deployment project.

I think such a presentation (15 slides max in 45 minutes) should cover the
following aspects:

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.

I've detailed my thinking into each of these items at <How to ‘Sell’ IPv6
to Executive Management – Guidance for
Engineers<Techxcellence! | Thoughts on my journey of technical mastery;

My question and this is where I'd appreciate some input:

a) To all you engineers out there who have convinced managers - what else
did you have to address?

One of the most important things i see not being stressed enough is
that IPv6 is frequently free or a low-cost incremental upgrade.

So, when calculating ROI / NPV, the hurdle can be very low such that
the cash in-flow / cost savings is not a huge factor since the
required investment is close to nil.

This is not always the case, some legacy stuff won't work on ipv6
without investment. But, as a plug to all you folks who work at
companies that use a CDN, please ask your CDN to turn IPv6 on for your
website. This is top-of-mind for me since i just pushed my www folks
on this issue

Here's some relevant pointers for the CDN folks, in many cases its
just a matter of clicking a button in the management portal:

Akamai http://www.akamai.com/ipv6

Edgecast Edgio - Performance & Security on the Leading Edge

Cloudflare Connect & protect with the connectivity cloud

Amazon Elastic Load Balancing Announces Support for IPv6, Zone Apex Support and Security Group Integration

Softlayer IBM Cloud

4

In-line

Isn't every reply? (Well, every reply worth reading.)

5

I did mention it under the last but one paragraph of section [a]. Even
though I only mentioned it for gov't contracts as I think those are the fat
juicy ones. But yes, I do agree about the fact that non-compliance could
mean you lose some business today.

Regards

6

The low hurdle advantage remains only if the organisation starts soon and
progresses incrementally. I suspect the longer v6 deployment is put off,
the more this advantage is eroded.

7

The low hurdle advantage remains only if the organisation starts soon and
progresses incrementally. I suspect the longer v6 deployment is put off,
the more this advantage is eroded.

Agreed; IMHO planning and starting sooner "costs less" than pushing it off
until it is a firedrill.
*Less in terms of money, service impact, PR complications, etc.*

And it is "here" now - my home has native IPv6 from Comcast, my phones have
native IPv6 from TMobile (and previously, from Verizon Wireless) ... the
only missing link in my daily life is my client site, which is:
a) why I am here
and
b) being held up by DISA :(.

/TJ

8

I've found myself thinking about what ground an engineer needs to cover in
order to convince the executives to approve and commit to an IPv6
Deployment project.

You forgot step 0 - figuring out why in 2013, you're talking to an executive
about this in the first place. You're going to have to deal with the root
cause reasons why the discussion was delayed before you have a snowball's
chance of succeeding. The presentation you need to give if the execs don't
understand what IPv4 exhaustion is will be different from the one they need
if they understand that issue full well but don't see an ROI win from doing
it this year and they want to push it off.

a) To all you engineers out there who have convinced managers - what else
did you have to address?

Finding working code in 1998 was... interesting.

9

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:

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!).

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

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

You get maybe 2 slides of summary on the technology and what it's for.
If they want to know more, they'll ask. Everything else should focus
on answering the above three questions.

Regards,
Bill Herrin

10

Dear experts,

I've found myself thinking about what ground an engineer needs to

cover in

order to convince the executives to approve and commit to an IPv6
Deployment project.

I think such a presentation (15 slides max in 45 minutes) should cover

the

following aspects:

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.

11

ours doesn't..... at least not the may '12 AR

12

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
  after the upcoming changes. The IT department will need substantial training,
  covering a wide variety of topics (application changes (development, configuration,
  testing, management), systems administration changes, networking changes, etc.)

3. We've actually been through this before. In some cases more than once.
  e.g.:
    Novell -> TCP/IP
    Windows Networking -> TCP/IP
    Appletalk -> TCP/IP
    NCP -> TCP/IP

  In some ways, this change is less profound than many of those.

It's also worth pointing out the ways you can save by starting sooner rather than later.

Owen

13

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.

14

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.

That is really the meat of it, more addresses is the killer IPv6 app.
If you have plenty of ipv4, your situation is not very urgent, but one
day it will be urgent.... There are folks who don't have much IPv4,
and sometimes people on your network may want to communicate with
them.. Like the folks in Europe or Asia. Remember, APNIC and RIPE are
both out of IPv4 right now. So all meaningful growth (mobile, cloud,
internet of things...) must happen on IPv6 ... or relatively expensive
IPv4 addresses from the black market and / or NATs

CB

15

Lest we forget one of the more profound ones whose memory could be the
source of much resistance. Assuming this industry had any memory...
                  TCP/IP -> MAP/TOP/GOSIP -> TCP/IP
Complete with government mandates, dual stacking, and RFP inclusion.
Been there, done that, been burnt...

Vincent Jones

16

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:
      Because we will be able to get rid of all that NAT traversal code,
      we get the following benefits:

      I. Improved security
        A. Fewer code paths to test
        B. Lower complexity = less opportunity to introduce flaws
      II. Lower cost
        A. Less developer man hours maintaining (or developing) NAT traversal code
        B. Less QA time spent testing NAT traversal code
        C. No longer need to keep the lab stocked with every NAT implementation ever invented
        D. Fewer calls to support for failures in product's NAT traversal code
  2. Increased transparency:
      Because addressing is now end-to-end transparent, we gain a
      number of benefits:

      I. Improved Security
        A. Harder for attackers to hide in anonymous address space.
        B. Easier to track down spoofing
        C. Simplified log correlation
        D. Easier to identify source/target of attacks
      II. Simplified troubleshooting
        A. No more need to include state table dumps in troubleshooting
        B. tcpdump inside and tcpdump outside contain the same packets.

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.

It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years.

Today, the IPv6 internet is this big: . Today, the IPv4 internet is this big: o
In a few years, the IPv4 internet will still be this big: o and the IPv6 internet will be more like this: OOOOO

(Size comparison should be relatively accurate at any font size as long as you use the same font and font size for the whole thing.)

Owen

17

Hello Owen,

Would I be accurate in re-phrasing each of these as....

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.

"The scope of the IPv6 endeavour is organisation-wide" so as to mitigate
any internal disconnects that will result from other units perceiving this
as an 'IT department's project?. I would specifically like to at some point
later bring in the marketing and sales folks. They can't pitch it correctly
if they don't understand it can they?

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
        after the upcoming changes. The IT department will need
substantial training,
        covering a wide variety of topics (application changes
(development, configuration,
        testing, management), systems administration changes, networking
changes, etc.)

+1

3. We've actually been through this before. In some cases more than
once.
        e.g.:
                Novell -> TCP/IP
                Windows Networking -> TCP/IP
                Appletalk -> TCP/IP
                NCP -> TCP/IP

I totally didn't think of this perspective ... this is really assuring.

18

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

      Because we will be able to get rid of all that NAT traversal code,
      we get the following benefits:

No, we keep the NAT traversal code.

      I. Improved security
        A. Fewer code paths to test

And now we have to test end-to-end IPv4-IPv4 (with and without NAT), IPv4-IPv6 through relays, IPv4-IPv6 in the presence of NAT64, IPv6-IPv6, at the very least.

        B. Lower complexity = less opportunity to introduce flaws

See above.

      II. Lower cost
        A. Less developer man hours maintaining (or developing) NAT traversal code

Nope. All the same man-hours plus all the NAT64/DNS64 cases need to be covered, plus any other transition technologies that get popular (DS-Lite, 6RD, etc.) and screw with NAT traversal *plus* all the extra work required to operate in certain CGN environments which may become even more common than IPv6 in some place.

        B. Less QA time spent testing NAT traversal code

See above about all the interworking cases.

        C. No longer need to keep the lab stocked with every NAT implementation ever invented

Nope, now you also need to buy all the much more expensive gear to test CGN, NAT64, DS-Lite, 6RD, and any number of other transition/customer deployment models.

        D. Fewer calls to support for failures in product's NAT traversal code

Doubt it.

  2. Increased transparency:
      Because addressing is now end-to-end transparent, we gain a
      number of benefits:

Assuming NAT66 isn't mandated in some environments for "security"... but even so, none of these benefits apply in the customer NAT, CGN, or NAT64 cases.

      I. Improved Security
        A. Harder for attackers to hide in anonymous address space.

What?!? It is much easier for attackers to rotate addresses when IPv6 is widely available.

        B. Easier to track down spoofing

Don't see how. (See below). (Never mind that BCP38 should have prevented this long ago)

        C. Simplified log correlation

Yes, if only you didn't also have to do it for all the CGN and NAT64 cases.

        D. Easier to identify source/target of attacks

Again, I doubt it. Identifying the single IP address assigned to a customer who has an on-premise NAT appears to be just as easy/hard as identifying the block of IP addresses assigned to a customer running IPv6. And for privacy reasons, end-user hosts won't have stable addresses within that block any more than port numbers are stable on the outside of a NAT in the IPv4 case.

      II. Simplified troubleshooting
        A. No more need to include state table dumps in troubleshooting

Not true. Lots of failure cases will still involve firewall configuration... tracking down the "my SIP phone registers but RTP doesn't work but only when I receive calls, not when I send calls" is identical in the IPv4 and IPv6 stateful firewall cases.

        B. tcpdump inside and tcpdump outside contain the same packets.

Unless you have almost any firewall, which will be adjusting all sorts of things for you.

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.

It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years.

This is the actual argument. IPv6 must be supported because as the Internet grows, it will get to the point where some of it MUST be IPv6-only. Unfortunately there will be a long time in the interim where you need to do more than 2x the work you are doing now in the IPv4+end-user-NAT Internet we currently have.

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.

Matthew Kaufman

19

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:

  1. IPv6 deployment continues to accelerate and achieves relative ubiquity before IPv4 becomes
    completely unsustainable. In this case, IPv4 will be gracefully, but rapidly decommissioned
    because of the extreme costs involved in keeping it running vs. the limited benefit of doing so.

    Sure, there will be isolated pockets of IPv4 for a very long time, but application developers will
    stop supporting IPv4 NAT traversal in new products or new product updates fairly soon after
    this point. In this case, we're probably looking at around 5 years.

or

  2. IPv6 deployment doesn't reach relative ubiquity before IPv4 becomes utterly unsustainable.
    We scramble to simultaneously shore up IPv4 as best we can will deploying IPv6 in a
    complete panic. There is widespread disruption, costs are high, reliability is low for several
    years, pretty much the worst case scenario. In this case, it's probably about 8 years before
    we completely splatter against the wall with IPv4 and another 2 years of scrambling to
    deploy the rest of IPv6.

      Because we will be able to get rid of all that NAT traversal code,
      we get the following benefits:

No, we keep the NAT traversal code.

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.

      I. Improved security
        A. Fewer code paths to test

And now we have to test end-to-end IPv4-IPv4 (with and without NAT), IPv4-IPv6 through relays, IPv4-IPv6 in the presence of NAT64, IPv6-IPv6, at the very least.

Only for a couple of years. Once IPv4 disappears from the inter domain world, which will happen fairly quickly, I think you'll see little or no focus on these areas and support for most of them will be mothballed.

        B. Lower complexity = less opportunity to introduce flaws

See above.

See above debunking of the flawed assumptions.

      II. Lower cost
        A. Less developer man hours maintaining (or developing) NAT traversal code

Nope. All the same man-hours plus all the NAT64/DNS64 cases need to be covered, plus any other transition technologies that get popular (DS-Lite, 6RD, etc.) and screw with NAT traversal *plus* all the extra work required to operate in certain CGN environments which may become even more common than IPv6 in some place.

Nope… Maybe for a very short period of time, but precisely because IPv4 no longer provides benefit, only cost at this point, it will be rapidly decommissioned at least from the inter-domain world. In the intra-domain world, NAT traversal is mostly not relevant. Almost certainly not relevant enough to garner continuing support from ISVs.

        B. Less QA time spent testing NAT traversal code

See above about all the interworking cases.

See above about why nobody is actually going to be that dumb.

        C. No longer need to keep the lab stocked with every NAT implementation ever invented

Nope, now you also need to buy all the much more expensive gear to test CGN, NAT64, DS-Lite, 6RD, and any number of other transition/customer deployment models.

Nope… See above.

        D. Fewer calls to support for failures in product's NAT traversal code

Doubt it.

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

  2. Increased transparency:
      Because addressing is now end-to-end transparent, we gain a
      number of benefits:

Assuming NAT66 isn't mandated in some environments for "security"... but even so, none of these benefits apply in the customer NAT, CGN, or NAT64 cases.

Even if it is, at this point, I doubt it will be a sufficient critical mass of environments to drive ISVs to provide special support for it. As such, those few institutions will probably change fairly quickly.

The customer NAT, CGN, and NAT64 cases are not likely to exist by then. See above.

      I. Improved Security
        A. Harder for attackers to hide in anonymous address space.

What?!? It is much easier for attackers to rotate addresses when IPv6 is widely available.

Yes, but their prefix isn't anonymous and they have a hard time getting outside of the prefix.

        B. Easier to track down spoofing

Don't see how. (See below). (Never mind that BCP38 should have prevented this long ago)

1. You don't have to compare 701 against 9,000,000 prefixes in the routing table looking for
  the one that's getting spoofed.

2. RIR records will be more accurate because there is no legacy space.

        C. Simplified log correlation

Yes, if only you didn't also have to do it for all the CGN and NAT64 cases.

Which won't last long.

        D. Easier to identify source/target of attacks

Again, I doubt it. Identifying the single IP address assigned to a customer who has an on-premise NAT appears to be just as easy/hard as identifying the block of IP addresses assigned to a customer running IPv6. And for privacy reasons, end-user hosts won't have stable addresses within that block any more than port numbers are stable on the outside of a NAT in the IPv4 case.

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.

      II. Simplified troubleshooting
        A. No more need to include state table dumps in troubleshooting

Not true. Lots of failure cases will still involve firewall configuration... tracking down the "my SIP phone registers but RTP doesn't work but only when I receive calls, not when I send calls" is identical in the IPv4 and IPv6 stateful firewall cases.

Sure… I meant that you don't need to dump the state table to identify that the packet from 192.0.2.123:1234 to 204.81.221.6:80 is the same packet as the one on the inside from 192.168.5.6:9321 to 204.81.221.6:80.

        B. tcpdump inside and tcpdump outside contain the same packets.

Unless you have almost any firewall, which will be adjusting all sorts of things for you.

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.

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.

It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years.

This is the actual argument. IPv6 must be supported because as the Internet grows, it will get to the point where some of it MUST be IPv6-only. Unfortunately there will be a long time in the interim where you need to do more than 2x the work you are doing now in the IPv4+end-user-NAT Internet we currently have.

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.

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. That there's a brief period where it's way more work followed by a much better long-term. 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.

Owen

20

The benefits, if any, of supporting IPv6 now really depend on what
kind of use your organization makes of the Internet. Despite all of
the huffing and puffing, it will be a very long time before there are
interesting bits of the net not visible over IPv4 for common
applications like http and smtp. No matter how much NAT sucks in
theory, for most non-technical users it's invisible and they have no
reason to care.

At this point, I'd say the mail selling point is that there are an
increasing number of home users and particularly mobile users with
native connections only in v6. If you're running services of interest
to those users, you'll get better visibility about who they are over
v6.

Failing that, from a business point of view it's mostly handwaving and
I wouldn't spend a lot of time trying to persuade them that there are
practical advantages of adding v6 to an existing working v4 network.

R's,
John