[arin-ppml] The non-deployment of IPv6

[Chris Engel]

Lee Howard wrote:

"Why is it less expensive to buy a big NAT box to translate nearly all of your traffic than to migrate to IPv6?"


Lee, simply having Legal IDENTIFY (let alone find a way to mitigate) all the contractual and compliance issues that might be involved with such a switch would likely exceed the cost of a NAT box significantly....and that's only one small factor involved in making such a switch.


"Vendors may not come to your rescue."

This is entirely possible. However, there will be a large cash incentive for them to do so. Furthermore, it may not be MY rescue that they need to come to. Who is likely to be more negatively impacted by such a situation... the 1-5% of internet users who MAY initially be on IPv6 only....or the 95+% of the existing IPv4 internet that can communicate with itself just fine???

Believe it or not....I'm alot more aware of the IPv6 situation then the average Enterprise Admin..... and I expect my attitude is not at all atypical.  If there aren't some fairly robust solutions available by the time IPv6 hits.... then the problem is going to be alot more wide-reaching then you may think.


"In most cases, IPv6 is simpler and cheaper than the alternatives."

This statement is impossible even as a generalization as the costs and impacts of IPv6 and it's ramifications vary wildly from Enterprise to Enterprise. Without understanding the specifics of each individual situation and the possible alternatives it is simply not possible to make such statements accurately.



"IETF does whatever the people who participate want done.  Many of the people who would implement AFT (Address Family Translation) at your favorite network equipment vendor are working on it at IETF They're already working on it, and don't think they'll have it in time;
are you betting your company that somebody else will just make a
drop-in product you can buy on your budget?"

IETF like many institutions (including ARIN) is subject to institutional biases....just mention NAT66 on an IETF mailing list and you'll see what I mean. Heck, I've gotten enough grief for mentioning NAT here on this list....despite the fact that many Administrators find it a valuable tool.

Obviously when the time comes when it is necessary to start researching a solution (I'm assuming for the 2011, 2012 or 2013 budget cycles depending on how depletion goes)....if adequate solutions do not exist....then it's time to start considering other options and costs. Right now switching to IPv6 native is pretty far down on the list of options (possibly even below not having connectivity to the IPv6 only portion of the internet initially).



"Depends on how important the problem is.  But now you've just
bought a big NAT64 box, and a new VPN solution.  Of course, you still need monitoring and management systems to support those new things.  This is all still cheaper than just learning and using IPv6??"

Off the top of my head...by many orders of magnitude, yes. I find that taking a gradual approach and layering services on top of existing infrastructure to address specific needs is generally more cost effective then wholesale replacement of entire infrastructure. Of course, this is just a guess on my part....but it's the initial approach I'm going to try to take with the issue. If, through further research, it proves to be impractical, I'll start looking at other options.



" But everyone needs to spend several dedicated hours writing a project plan for how they will respond to an unavailability of IPv4 from ARIN.  Compare
different possible strategies, make a good business decision, and
implement the plan.  Do it this month, because IPv4 runout projections are variable, and the plan you choose may require budget and labor in 2010."


Several hours??? Try a week at least. But the question of WHEN you do it is not that simple. The Leading Edge is also nick-named the "Bleeding Edge" for good reason. If providing IP transport was my core business I would say you were correct....If I was an ISP, I'd certainly be doing it already....however for the Enterprise it's just a means to an end.

Problem is that if I start putting together a detailed plan now, I'm working with very limited intel. The options that are available to me now are likely far more limited then those which might exist a year or two from now. There are likely quite a few plans in the works at vendors which have not been made public yet. What I don't want to do is spend weeks on a plan now.... then go back and have to redo all that work over again next year at this time.


"to an O/S issued in 2007 or later, which by end of 2011 is pretty minimal; would you even allow something older on your network? "


LOL.... you really aren't that familiar with Enterprises are you??  I'm writing this from my Win2K Pro box right now. It's really not THAT uncommon for an Enterprise to have some hw/sw that is 10 years old or more. Right now XP is the standard on the Enterprise....it remains to be seen whether Windows 7 will pickup that mantle or not....and certainly there will be plenty of XP around in the Enterprise by the end of 2011. MS's life-cycle support for it extends out to 2014 or so I understand.


Not trying to pick on you Lee.... but try to see things from my side. IPv6 is a huge cost for near ZERO gain from my perspective (other then addressing IPv4 runout). It's undoubted that we'll need connectivity to IPv6 address space at some-point. Obviously the natural inclination to achieve that is with as little disruption/change/cost to the existing infrastructure as possible. From my perspective that would be some sort of IPv4/IPv6 gateway services or proxy or something similar.... ideally deployed at the network perimeter. Obviously if an acceptable solution of that sort doesn't exist... we'll have to start looking for PLAN B.
Given the magnitude of what PLAN B might entail.... we're certainly going to try hard to avoid it if possible. If going to IPv6 native was that simple/easy for us....we wouldn't be considering a different alternative first.





Christopher Engel