On Tue, Mar 5, 2013 at 10:35 PM, Gary E. Miller <gem@rellim.com> wrote:

You missed the most important one. Many people now include IPv6 as a mandatory RFQ item. If you don't support it your customers will be fewer and fewer.

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 -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

On Mar 05, 2013, at 13:41 , Cameron Byrne <cb.list6@gmail.com> wrote:

In-line

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

On Tue, Mar 5, 2013 at 9:55 AM, Mukom Akong T. <mukom.tamon@gmail.com> wrote:

...

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.

Why not just have them read their own SEC filings. Nearly every company has something to the effect of this in their 10K: The potential exhaustion of the supply of unallocated IPv4 addresses and the inability of $COMPANY and other Internet users to successfully transition to IPv6 could harm our operations and the functioning of the Internet as a whole. No company would lie to the SEC, would it? -- TTFN, patrick

...

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<http://techxcellence.net/2013/03/05/v6-business-case-for-engineers/>

...

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 http://www.edgecast.com/ipv6/

Cloudflare https://www.cloudflare.com/ipv6

Amazon http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-secur...

Softlayer http://www.softlayer.com/about/network/ipv6

...

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.

--

Mukom Akong T.

http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- --

Mukom Akong T.

http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

On Tue, Mar 5, 2013 at 10:41 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

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.

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. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

Hello William, Thank you for your inputs, see my comments inline. On Wed, Mar 6, 2013 at 12:09 AM, William Herrin <bill@herrin.us> wrote:

...

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<http://techxcellence.net/2013/03/05/v6-business-case-for-engineers/>) 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.

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

-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

-- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

On Wed, 6 Mar 2013, Mukom Akong T. wrote:

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.

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

On Wed, 6 Mar 2013, Mukom Akong T. wrote:

On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin <tony@lavanauts.org> wrote:

...

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.

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

If they're convinced that it's not worth doing ever - then you're wasting your own time. They may think it's not worth a lot of effort over the immediate future but if the effort is spread thinly and integrated into regular infrastructure upgrades over a longer period of time then that's an easier pill to swallow. Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com

On Tue, Mar 5, 2013 at 11:49 PM, Mukom Akong T. <mukom.tamon@gmail.com> wrote:

On Wed, Mar 6, 2013 at 12:09 AM, William Herrin <bill@herrin.us> wrote:

...

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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Tue, 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.

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

--

Mukom Akong T.

http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

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

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

...

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,

Matthew Kaufman

On Wed, Mar 6, 2013 at 9:20 AM, Cameron Byrne <cb.list6@gmail.com> wrote:

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

That is clearly reducto ad absurdum and does not resemble Matthew's detailed and nuanced argument. Please try again. -- -george william herbert george.herbert@gmail.com

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

On Tue, Mar 5, 2013 at 8:20 PM, Owen DeLong <owen@delong.com> wrote:

Matthew wrote:

...

[...]

...

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:

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. -- -george william herbert george.herbert@gmail.com

On Wed, Mar 6, 2013 at 12:30 PM, david raistrick <drais@icantclick.org> wrote:

On Wed, 6 Mar 2013, George Herbert wrote:

...

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

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.

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 ... -- -george william herbert george.herbert@gmail.com

Hello Owen, Would I be accurate in re-phrasing each of these as.... On Wed, Mar 6, 2013 at 5:41 AM, Owen DeLong <owen@delong.com> wrote:

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. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

On Mar 6, 2013, at 10:50 AM, Jeroen van Aart <jeroen@mompl.net> wrote:

On 03/05/2013 05:41 PM, Owen DeLong wrote:

...

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