Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Thu, Mar 7, 2013 at 12:25 AM, William Herrin b...@herrin.us wrote: 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. Point taken. Thank you. 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. I don't think NAT solves the problem in a sustainable way. Sure for managers that are already driven by short-term goals, that's fine however in Africa, we are seeing situations where NAT just doesn't scale. Specifically with the influx of submarine cables, the bottleneck has shifted from 'available bandwidth' to 'NAT' (or strictly speaking NAPT) capacity. 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. Good point. 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. Thank you once again. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 7 Mar 2013, at 02:50, Dobbins, Roland wrote: On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote: I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. That's a great point, but my guess is that the suits will say that since none of their customers are using IPv6, there's no urgency (yes, I know, it's better to be prepared ahead of time; but foresight doesn't generally carry much weight in quarterly-driven enterprises). Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. /as
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 7, 2013, at 5:42 AM, Arturo Servin aser...@lacnic.net wrote: Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. Presuming a medium/small service provider, the most typical sequence that I've been hearing runs something like this: 1. Engineers internally experiment with IPv6 on an individual basis (lab, tunnels, virtual servers, etc.) Doesn't always happen, but the ones that don't are making their own gamble regarding their skills and career trajectory. 2. Some formal recognition by the network team of need to gain IPv6 experience; this can be equipment for a real lab, formal training, minor investment in external firewalls to bring up to spec, etc. 3. The network folks start arranging for real IPv6 connectivity from the outside, this could be transit or peering, and begin working on plans for the network backbone to be fully dual-stack. 4. The talk with IT regarding IPv6, and acceptance of the concept that it would be nice if the web site had some minimal support (yes, maybe not the customer ticketing/feedback system, or every page, but at least the major content sections.) This leads to the idea that IT will test new web rollouts with IPv6, and the need therefore to get IPv6 to some of the integration/QA folks. 5. IT/internal network team realization that they have to get IPv6 internally to some of the Internet network team, some of the developers, and that means that the corporate network really does need to support IPv6, and that means those firewalls, and management and training for the internal corporate network team. 6. Several meetings with marketing and sales trying to explain that other organizations (i.e. customers are doing the same thing, and a general mismatch in expectations since the vast majority of customers have never uttered IPv6 to anyone in sales/marketing. 7. Slow but steady internal progress on IPv6 deployment in the company, all while waiting for sales/marketing to recognize the need for IPv6 services for customers. 8. One key event (often a customer RFP requirement, or a sale lost due to lack of IPv6 support) occurs, which then brings the lack of IPv6 into focus as a competitive issue, and subsequent discussions about budget/investment for adding IPv6 support to the service catalog. YMMV, and every organization is a little different, but the common theme is that the more awareness that we can generate in CIO/IT industry about the IPv4 constraints facing the Internet network industry, the faster that IPv6 will happen... /John
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Pretty much the same process that I have seen in many ISPs and enterprises. Regards. as On 07/03/2013 11:32, John Curran wrote: On Mar 7, 2013, at 5:42 AM, Arturo Servin aser...@lacnic.net wrote: Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. Presuming a medium/small service provider, the most typical sequence that I've been hearing runs something like this: 1. Engineers internally experiment with IPv6 on an individual basis (lab, tunnels, virtual servers, etc.) Doesn't always happen, but the ones that don't are making their own gamble regarding their skills and career trajectory. 2. Some formal recognition by the network team of need to gain IPv6 experience; this can be equipment for a real lab, formal training, minor investment in external firewalls to bring up to spec, etc. 3. The network folks start arranging for real IPv6 connectivity from the outside, this could be transit or peering, and begin working on plans for the network backbone to be fully dual-stack. 4. The talk with IT regarding IPv6, and acceptance of the concept that it would be nice if the web site had some minimal support (yes, maybe not the customer ticketing/feedback system, or every page, but at least the major content sections.) This leads to the idea that IT will test new web rollouts with IPv6, and the need therefore to get IPv6 to some of the integration/QA folks. 5. IT/internal network team realization that they have to get IPv6 internally to some of the Internet network team, some of the developers, and that means that the corporate network really does need to support IPv6, and that means those firewalls, and management and training for the internal corporate network team. 6. Several meetings with marketing and sales trying to explain that other organizations (i.e. customers are doing the same thing, and a general mismatch in expectations since the vast majority of customers have never uttered IPv6 to anyone in sales/marketing. 7. Slow but steady internal progress on IPv6 deployment in the company, all while waiting for sales/marketing to recognize the need for IPv6 services for customers. 8. One key event (often a customer RFP requirement, or a sale lost due to lack of IPv6 support) occurs, which then brings the lack of IPv6 into focus as a competitive issue, and subsequent discussions about budget/investment for adding IPv6 support to the service catalog. YMMV, and every organization is a little different, but the common theme is that the more awareness that we can generate in CIO/IT industry about the IPv4 constraints facing the Internet network industry, the faster that IPv6 will happen... /John
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Wed, 6 Mar 2013, Mukom Akong T. wrote: On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin t...@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: t...@lavanauts.org xmpp: antonioqueru...@gmail.com
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Thursday, March 7, 2013, Antonio Querubin wrote: On Wed, 6 Mar 2013, Mukom Akong T. wrote: On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin t...@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. You are talking about people who have already decided its worth doing and so they need convincing as to how early to start. I am thinking of people who need convincing in the first place. For such people, business case is their language, timeline comes after they are convinced Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com -- 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 ---
RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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: matt...@matthew.at To: cb.li...@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 matt...@matthew.at wrote: On 3/5/2013 8:20 PM, Owen DeLong wrote: On Mar 5, 2013, at 7:55 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then… I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: Two unsubstantiated suppositions deleted. They suggest that IPv4 support is needed *in conjunction with* IPv6 support for 5-8 years. That's a long time if you're developing software... so, basically, no... no cost or effort saving if you were to do this work today. In fact, 2x the effort if you were to start today. So again, why try to sell it to the engineers that way? Either sell it as 1) If you don't start doing a lot more work now you'll be screwed at the transition or 2) You should just wait until you can single-stack on IPv6. Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. Sure. In 5 to 8 years, as you claimed. Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: C: Hi, my application isn't working through my NAT. TSR: Hi… Get IPv6, we don't support NAT any more. TSR: Is there anything else I can help you with today? C: Hi, my application isn't working between me and my grandmother TSR: Hi... Get IPv6, we don't suppotr NAT any more. C: Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money. The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. So, your position, which is substantiated my Microsoft's / Windows Phone's / Skype's lack of IPv6 support , is that nobody cares until we run out of IPv4. No. While you've cleverly quoted something I did say, Skype is an example of an application where, as I mentioned in the paragraph above, until both ends of a call are always guaranteed to be on IPv6, there is *more* complexity involved in supporting both IPv4 and IPv6 than in supporting IPv4 alone. This entire discussion started with how should I sell IPv6 to executives and Owen claimed that switching to IPv6 represents less engineering effort. I simply claim that isn't true. In fact the amount of engineering effort required to make an application like Skype work (both development effort and testing required) where the users who might want to call each other are on an unknown mixture of IPv4, IPv4/IPv6 dual-stack, IPv6 w/NAT64 for IPv4, and IPv6 single-stack is *tremendous* compared to the effort required to make it work with IPv4 and end-user NAT devices. But, Matthew, your division of Microsoft is really a bunch of Free Riders that is honestly holding back the rest of us. My division of Microsoft is currently engaged in a massive amount of engineering... work to add features that customers are demanding, work to make Skype work better on mobile devices, work to make Skype interoperate with Lync, and yes, work to make
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 5, 2013, at 9:55 PM, Cameron Byrne cb.li...@gmail.com wrote: 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 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... :-) Thanks! /John
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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: t...@lavanauts.org xmpp: antonioqueru...@gmail.com
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin t...@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? -- 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 8:20 PM, Owen DeLong wrote: On Mar 5, 2013, at 7:55 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then… I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: Two unsubstantiated suppositions deleted. They suggest that IPv4 support is needed *in conjunction with* IPv6 support for 5-8 years. That's a long time if you're developing software... so, basically, no... no cost or effort saving if you were to do this work today. In fact, 2x the effort if you were to start today. So again, why try to sell it to the engineers that way? Either sell it as 1) If you don't start doing a lot more work now you'll be screwed at the transition or 2) You should just wait until you can single-stack on IPv6. Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. Sure. In 5 to 8 years, as you claimed. Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: C: Hi, my application isn't working through my NAT. TSR: Hi… Get IPv6, we don't support NAT any more. TSR: Is there anything else I can help you with today? C: Hi, my application isn't working between me and my grandmother TSR: Hi... Get IPv6, we don't suppotr NAT any more. C: Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money. The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. So, your position, which is substantiated my Microsoft's / Windows Phone's / Skype's lack of IPv6 support , is that nobody cares until we run out of IPv4. #1. We have run out of IPv4, check APNIC and RIPE, they are done. ARIN and LACNIC both have ~2.5 /8s left. Are you waiting on AfriNic? When are we run out, in your opinion? How are people in Indonesia, India, and the Philippines (and so ...) expected to get online without IPv4 addresses at APNIC? How do a launch a new disruptive wireless service across Europe when RIPE's currently implemented run-out-policy only allows for a /22 max allocation, ever #2. Your employer seems to have money to buy IPv4 addresses, what about everyone else? http://www.bbc.co.uk/news/technology-12859585 #3 I believe this position of your's / Microsoft's is also known as the free rider problem. http://en.wikipedia.org/wiki/Free_rider_problem I personally would expect that Microsoft would not be a free rider, i am sure they would like to cultivate an imagine of technology leadership. I expect a leadership role from Microsoft given their stature and resources. And, all told, they did step up for world IPv6 launch on www.bing.com, which is a big deal and many of their products work admirably well with IPv6 (notwithstanding this Exchange issue http://labs.apnic.net/blabs/?p=309) But, Matthew, your division of Microsoft is really a bunch of Free Riders that is honestly holding back the rest of us. I even had to write an IETF draft, more or less, just to work-around Skype's issues http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-10 Granted, there are other apps that don't work with IPv6, for example Netflix's Android app. But Skype is the big dog. And so is Microsoft. I think we expect technology leadership there, not a free rider making the rest of the system work around you at a cost to everyone else. CB NAT will most likely become a thing of the past. I know you prefer to remain in denial about this, but more and more of the ISVs I have talked to are saying
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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). 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 -- Earthquake Magnitude: 5.0 Date: Wednesday, March 6, 2013 16:49:46 UTC Location: Nepal Latitude: 28.7312; Longitude: 82.2176 Depth: 10.00 km
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 5, 2013, at 9:55 AM, Mukom Akong T. mukom.ta...@gmail.com wrote: […] 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?
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Wed, Mar 6, 2013 at 9:20 AM, Cameron Byrne cb.li...@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.herb...@gmail.com
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 8:20 PM, Owen DeLong o...@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.herb...@gmail.com
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 11:49 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:09 AM, William Herrin b...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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 addresssigh), the snowball really won't happen until it Just Works(tm). impe and all that. -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Wed, Mar 6, 2013 at 12:30 PM, david raistrick dr...@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 addresssigh), 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.herb...@gmail.com
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 3/6/2013 9:20 AM, Cameron Byrne wrote: On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 8:20 PM, Owen DeLong wrote: On Mar 5, 2013, at 7:55 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then… I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: Two unsubstantiated suppositions deleted. They suggest that IPv4 support is needed *in conjunction with* IPv6 support for 5-8 years. That's a long time if you're developing software... so, basically, no... no cost or effort saving if you were to do this work today. In fact, 2x the effort if you were to start today. So again, why try to sell it to the engineers that way? Either sell it as 1) If you don't start doing a lot more work now you'll be screwed at the transition or 2) You should just wait until you can single-stack on IPv6. Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. Sure. In 5 to 8 years, as you claimed. Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: C: Hi, my application isn't working through my NAT. TSR: Hi… Get IPv6, we don't support NAT any more. TSR: Is there anything else I can help you with today? C: Hi, my application isn't working between me and my grandmother TSR: Hi... Get IPv6, we don't suppotr NAT any more. C: Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money. The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. So, your position, which is substantiated my Microsoft's / Windows Phone's / Skype's lack of IPv6 support , is that nobody cares until we run out of IPv4. No. While you've cleverly quoted something I did say, Skype is an example of an application where, as I mentioned in the paragraph above, until both ends of a call are always guaranteed to be on IPv6, there is *more* complexity involved in supporting both IPv4 and IPv6 than in supporting IPv4 alone. This entire discussion started with how should I sell IPv6 to executives and Owen claimed that switching to IPv6 represents less engineering effort. I simply claim that isn't true. In fact the amount of engineering effort required to make an application like Skype work (both development effort and testing required) where the users who might want to call each other are on an unknown mixture of IPv4, IPv4/IPv6 dual-stack, IPv6 w/NAT64 for IPv4, and IPv6 single-stack is *tremendous* compared to the effort required to make it work with IPv4 and end-user NAT devices. But, Matthew, your division of Microsoft is really a bunch of Free Riders that is honestly holding back the rest of us. My division of Microsoft is currently engaged in a massive amount of engineering... work to add features that customers are demanding, work to make Skype work better on mobile devices, work to make Skype interoperate with Lync, and yes, work to make Skype work in the huge explosion of new network connectivity situations it will find itself in as IPv6 is deployed and especially as those IPv6 users stop getting native IPv4 alongside it. And we're using Agile and Scrum as our engineering methodology, and I can tell you that it is very very hard to get IPv6 work to rise to the top in any organization, including ours, given that the short-term return on that investment is nil and the engineering and testing effort is huge. But again, the only reason I even brought this up here is that there are people like Owen running around trying to tell engineers that when
RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
From: Matthew Kaufman [mailto:matt...@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.
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 6, 2013, at 10:50 AM, Jeroen van Aart jer...@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
Migrating IPv6 (was Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?)
On Wed, 2013-03-06 at 18:48 -0800, Owen DeLong wrote: On Mar 6, 2013, at 10:50 AM, Jeroen van Aart jer...@mompl.net wrote: 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.[...] 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. 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 :-) 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 :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Not sure how to avoid the legal entanglements my employer has placed in the IT teams path but I'll try to provide a real-world example without breaking confidentially agreements we all were required to sign for continued employment at a very large US-based bank. Our senior IT team had proposed a multi-year upgrade to v6 for our existing internal network, external services and connectivity to partner companies in 2009. It was fully funded in 2010, with staffing, vendor reqs and milestones set. At the end of 2012 our companies senior finance team reviewed the benefits and progress. They came away with a very simple view but alas one which could not be overcome. They held that our bank did not gain any strategic advantage by rolling out v6 but instead now had two entire security and software profiles to maintain. Hence our company has mothballed the project and has reassigned the entire team to other business needs. So, our globally known brand will only keep a nominal amount of ongoing public statements of being in support of v6 when in reality we are no longer going to deploy it until the market demands it. I have been employed here through two mergers and thought very hard about leaving, as did several of us that put a lot of effort into the project. But in the end, the job is secure, it is not my company to tell them they are wrong and I can't fault the logic no matter how much I wish. Upon reading this thread I'm dumbstruck at each of the arguments. None really matter. I had to agree, there was zero gain to be found for my company, today or in the immediate future, to proceed but there is plenty of downside. I read the zealots comments and know that they will claim we are fools. We, as a team, thought so too. But now several months removed, we all actually agree with the business/finance group. So there it is. I cannot give specifics, but a well-known global bank has turned out the lights for now on the v6 deployment. It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. Jerry
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote: It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. Is the deployment in such a state that rollout can be resumed if/when it's deemed a priority? Another possible approach might be to utilize IPv6 for BYOD wireless - it's sort of the ultimate in device segregation. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 6, 2013, at 11:31 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote: It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. Is the deployment in such a state that rollout can be resumed if/when it's deemed a priority? Another possible approach might be to utilize IPv6 for BYOD wireless - it's sort of the ultimate in device segregation. The big problem I have (and with our own IT group) is that their network doesn't provide IPv6 yet we have offered it as a commercial service for a decade or more. This limits the ability to troubleshoot and dog-food the IPv6 network when using their resources. This means we stand up our own resources because they are unable to meet our needs. This is natural in many businesses, you work around what is broken or missing to get things done. I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. I found banks that would return NXDOMAIN instead of NOERROR when you asked for their domain name. This caused many problems until they corrected it. I actually got in contact with someone there by calling their whois contact. Was amazed that worked, but was a happy surprise. - Jared
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote: I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. That's a great point, but my guess is that the suits will say that since none of their customers are using IPv6, there's no urgency (yes, I know, it's better to be prepared ahead of time; but foresight doesn't generally carry much weight in quarterly-driven enterprises). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 6, 2013, at 3:13 PM, George Herbert george.herb...@gmail.com wrote: ... 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. 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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Yo Mukom! On Tue, 5 Mar 2013 21:55:14 +0400 Mukom Akong T. mukom.ta...@gmail.com wrote: I think such a presentation (15 slides max in 45 minutes) should cover the following aspects: 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. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 signature.asc Description: PGP signature
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Hi, In-line On Tue, Mar 5, 2013 at 9:55 AM, Mukom Akong T. mukom.ta...@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. 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 Engineershttp://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-securitygroups/ 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 05, 2013, at 13:41 , Cameron Byrne cb.li...@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.ta...@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 Engineershttp://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-securitygroups/ 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 10:35 PM, Gary E. Miller g...@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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 10:41 PM, Cameron Byrne cb.li...@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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, 05 Mar 2013 21:55:14 +0400, Mukom Akong T. said: 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. pgpE6aJfyv91_.pgp Description: PGP signature
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 12:55 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: 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. 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 -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 3/5/2013 at 9:55 PM Mukom Akong T. 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. | |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. | |[snip] = Instead of f) How much will deploying IPv6 will cost. I would lean towards f) Cost/benefit of deploying IPv6. If you only talk about how much it will cost, then you've created a major uphill battle for yourself. Also talk of how IPv6 will benefit the business.
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, 5 Mar 2013, Patrick W. Gilmore wrote: 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. ours doesn't. at least not the may '12 AR -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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 On Mar 5, 2013, at 9:55 AM, Mukom Akong T. mukom.ta...@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. 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 Engineershttp://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? 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. -- 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, Mar 5, 2013 at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. 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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Tue, 2013-03-05 at 17:41 -0800, Owen DeLong wrote: 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. 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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: 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: O (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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Hello Owen, Would I be accurate in re-phrasing each of these as On Wed, Mar 6, 2013 at 5:41 AM, Owen DeLong o...@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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then... 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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On Mar 5, 2013, at 7:55 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then… I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: 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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
Hello William, Thank you for your inputs, see my comments inline. On Wed, Mar 6, 2013 at 12:09 AM, William Herrin b...@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 Engineershttp://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 her...@dirtside.com b...@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 ---
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 3/5/2013 8:20 PM, Owen DeLong wrote: On Mar 5, 2013, at 7:55 PM, Matthew Kaufman matt...@matthew.at wrote: On 3/5/2013 7:15 PM, Owen DeLong wrote: On Mar 5, 2013, at 6:46 PM, Mukom Akong T. mukom.ta...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:34 AM, Mike. the.li...@mgm51.com wrote: I would lean towards f) Cost/benefit of deploying IPv6. I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. I'm not so sure about that… Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then… I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: Two unsubstantiated suppositions deleted. They suggest that IPv4 support is needed *in conjunction with* IPv6 support for 5-8 years. That's a long time if you're developing software... so, basically, no... no cost or effort saving if you were to do this work today. In fact, 2x the effort if you were to start today. So again, why try to sell it to the engineers that way? Either sell it as 1) If you don't start doing a lot more work now you'll be screwed at the transition or 2) You should just wait until you can single-stack on IPv6. Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. Sure. In 5 to 8 years, as you claimed. Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: C: Hi, my application isn't working through my NAT. TSR: Hi… Get IPv6, we don't support NAT any more. TSR: Is there anything else I can help you with today? C: Hi, my application isn't working between me and my grandmother TSR: Hi... Get IPv6, we don't suppotr NAT any more. C: Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money. The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. 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
