More IPv6 FUD being thrown @ CFOs

The CFO magazine has recently published a FUDful article “Trouble Looms for Company Websites” (read it to see what CFOs have to deal with). Obviously, some people think it’s a good idea to throw FUD at CFOs to get the budget to implement IPv6. Long term, it’s a losing strategy; your CFO will become immune to anything coming from the IT department and ignore the real warnings.

Yes, it's time to make your content reachable over IPv4 and IPv6, more so if you’re in the eyeballs business. Google knows that. So does Facebook. Twitter doesn’t seem to care. Maybe because they’re not selling ads?

Yes, you should go and implement IPv6 in your DMZ. Yes, you should start planning and budgeting today. But today the problems are as real as the Y2K ones were on Cisco IOS.

Eventually (in a decade) you’ll be dead if you won’t have IPv6, as every Service Provider will stop caring about your obsolete protocol and discontinue the translation services. In the meantime, the problems will appear gradually ... faster for people that have fancy two-way applications or broken web sites (for example, tracking users by their IP addresses or doing sloppy load balancing), slower for those that have more traditional applications using HTTP the way it was designed to be used (including, interestingly, Netflix).

The article is also full of NATty FUD. Without ever calling NAT64 by its name, it implies that a “connection through a gateway probably won't perform nearly as well as users have come to expect”. Come on, almost every enterprise user accessing the Internet is using some form of NAT. Why would NAT work well today and so badly in the future when it has to convert IPv6 addresses into IPv4 addresses? Admittedly it’s true that my (or their) claims are not verifiable since there’s no publicly-available large-scale production-grade NAT64 device (but there are some in field trials).

On a more positive note, you’ll find a universal truth in the article (courtesy of Martin Levy): “You can either do a planned, careful migration, or you can do it in a panic. And you should know full well that panicking is more expensive.” I’ll definitely use it in my presentations.

Last but not least, offering early IPv6 access to your content is not a big deal: Facebook did it pretty quickly and so can you ... assuming you have an IPv6-capable load balancer (some companies are still pretending you don’t need them). If you don’t, why don’t you go over to F5 web site and download their 90-day trial virtual machine? Or use NAT-PT in a standalone Cisco IOS box (I’m positive you have a few lying around) for a trial deployment? Just make sure you understand the caveats.

Would you like to hear more about my (potentially biased) perspective on enterprise IPv6 deployments? Get in touch with me and let’s organize an Enterprise IPv6 Deployment workshop for your team.


  1. "but a connection through a gateway probably won't perform nearly as well as users have come to expect, says John Curran, CEO of the American Registry for Internet Numbers (ARIN)"

    This is full quote and I fail to see NAT64 in here :) I suspect John was referring on CGN (presumably worst nightmare) and not on NAT64 (CGN came down from IETF to RIR's discussions, NAT64 not yet so much.)
  2. The sentence before the one you quote says "Unfortunately, a computer with an IPv6 connection will not be able to communicate directly with an IPv4 Website." How is that related to CGN (assuming CGN == NAT444)?

    And if he were actually refering to large-scale NAT444, how would making your content available over IPv6 improve the situation? The article is predicting imminent doom when users move to IPv6.

    It could be, though, that his quote was used "slightly" out-of-context.
  3. Yes, I suspect John was quoted in slightly misleading way... but anyway, we still don't know, how this translation beasts will behave in larger scale, no matter if we talk about CGN or NAT64. I must say, that Viagenie implementation of NAT64 works quite well, but curently for one or two users, that's what it can take :)
  4. Forgot to answer your real question: If you enable content on IPv6 and ISP implements IPv6 all the way down to end user, then you avoid all translation mechanisms, even if ISP decides to do CGN or even completely remove IPv4 from access network and do NAT64 in the core.

    Straight, clean and simple way to go :)
  5. We got NAT64 up and running at T-Mobile USA, works well.
  6. Hey, Cameron...

    How's the trial going? Any observations, what's good and what's broken in NAT64? BTW, nice to see you on Ivan's blog :)

  7. Thanks for chiming in! How is the trial going? Can you share with us what you use as the NAT64 platform?
Add comment