IPv6 Legends and Myths: More Opinions than Data Points

Trevor Pott wrote an interesting article in The Register (linking to my IPv6 multihoming post – thank you!) explaining how, in his opinion, IPv6 sucks for small and medium businesses. I wholeheartedly agree with some of his conclusions (actually, agreed with them for the last three years), but unfortunately the article contains several factual errors that simply have to be corrected (I doubt many of Trevor’s readers will actually find their way to this article, but one can always hope).

I forgot how often I told engineers writing technical articles “get it watertight, or someone will attack your mistakes and use them to diminish your credibility instead of discussing your message”, but the advice tends to get ignored.

Big Picture Summary

While I disagree with quite a few of Trevor’s opinions, the major one is spot-on: we don’t have a good solution for small networks that have two IPv6-enabled uplinks. BGP-based multihoming is not an option, renumbering is way too slow, and although Ole Troan, Mark Townsley, Andrew Yourtchenko, and other members of the IPv6 IETF working groups work on proposals to solve the problem, it’s an evident case of too little too late.

However, whenever I bring up this problem, I get a lot of responses along the lines of “nobody is using that” (see also: mid-market innovator’s dilemma). There is only one thing you can do: make yourself heard. Follow Trevor’s example (but please do your fact-checking first). Raise the red flags. Don’t accept another round of never-ending kludges. And remember: NPT66 is still a kludge. We can do better. We must do better. But you have to shout.

Factual errors

As I said, Trevor’s article contains a few unfortunate factual errors. Here they are (in random order):

Lack of consumer gear. Maybe Trevor wanted to write lack of Best Buy gear. Numerous smaller vendors offer pretty good IPv6 gear (my friend Jan Žorž claims Mikrotik has a bad-ass IPv6 implementation). Just because you think Linksys and Netgear don’t have IPv6 doesn’t mean that there is nothing out thereD-Link has shipped more than 10 million IPv6-enabled devices.

The elephant in the room is renumbering. Not true (the elephant is lack of multihoming ;). A network that contains servers (that need fixed IPv6 addresses) and does not have its own provider independent IPv6 address space should use two sets of IPv6 addresses: a prefix allocated by the current ISP and an internal Unique Local Addresses (ULA) prefix. Any IPv6 host can have numerous IPv6 addresses (one for every on-link prefix), and the default source address selection rules ensure ULA source address (if one exists) will be used to reach ULA destinations.

RIPE started giving out PI address space to organizations that don’t have their own AS number. Cost: approximately 50 euro/year.

It’s thus perfectly possible (and quite simple) to continue using internal IPv6 addresses like we were using internal IPv4 addresses. The only difference is that in a well-designed IPv6 network each host has an internal and an external IPv6 address (and there is no NAT).

Trevor is right, however, that changing ISP requires changes in every layer-3 networking device. Even that could be solved with DHCP prefix delegation and is easily done with general IPv6 prefixes (if you use Cisco IOS). People have been writing about the ease of networking renumbering with general IPv6 prefixes more than three years ago.

Yet again, if your vendor doesn’t support an equivalent of the general IPv6 prefixes, start shouting. They are not hard to implement and require no hardware or protocol changes (they’re just a syntactic sugar).

No more static addresses. Totally wrong. Any IPv6 protocol stack (well, maybe not the one on an iPhone or a Symbian phone) allows you to configure static IPv6 addresses on any interface.

The domain name assignation will just work. Actually, it will. Even simple solutions like Windows servers running as DHCP/DNS servers just work. There’s no difference between IPv4 and IPv6.

NAT is the solution. I will try to stay focused on the technical arguments and not argue with the Trevor’s religious beliefs. NAT has been a short-term technical solution the last time we ran out of IPv4 addresses, and as everyone using something else but HTTP(S) knows, it introduced more evil than goodness (you don’t believe me? Ask any developer of peer-to-peer software or anyone who had to troubleshoot a SIP gateway).

Unfortunately we need NAT64, SLB64 and NPT66 in some environments, but like any sane person involved with networking, I would love to keep my life simple and get rid of all of them (for simplicity, not for priestly, elitist or religious reasons).

Final Thoughts

More than anything else, Trevor’s article makes me sad. We had the opportunity to do it right (including getting rid of NAT with IPv6), and we’re extremely close to bust it because of collective ignorance. Worst case, sysadmins like Trevor will go back to the tool they know too well: NAT.

The article also illustrates a distressing lack of IPv6 awareness. If we have to argue whether you can use static IPv6 addresses or not in 2012, it means we didn’t do our job right – we didn’t help everyone involved with networking understand the true implications of IPv6.

This last paragraph will probably get me one more “master spammer” award from my friend Marko, but the IPv6 webinars I created do help some people understand what’s needed to get IPv6 rolling … and if you want a free advice, you can always read 100+ blog posts I wrote on IPv6, there are dozens more on PacketPushers and PacketLife blogs, and tons of other wikis, blogs and vendor design/deployment documents. Lack of information is no longer an excuse for ignorance.

17 comments:

  1. Ivan, I couldn't agree more.

    You know, the more I think about it and the more conversations with customers I have, I think the biggest problem is fear. When you get right down to it, a large number of "sysadmins" (particularly those in my customer base who are part of a small team and thus have to be multi-skilled) actually don't understand how IPv4, NAT, DHCP or other technologies really work. They've been used to putting certain numbers in certain boxes because that's how they've always been taught to do it and that's what makes it work(ish). Indeed, many of these people have been taught badly.

    So, when you try and add a new varient on a technology they don't have a fundamental knowledge that they can fall back on - rather it's a paralysing fear of a thing that they just don't understand. Not letting go of what they know is not letting go of the security blanket of a set of habits that they call "the way it's done".
  2. Hey! First off, thanks for taking the time to read my article. Secondly, if I may, I'd like to take the time to offer a few counter points and clarifications. (No, I am not out to start a flame war.)

    Regarding the lack of consumer/SME gear, I never intended to indicate that none existed at all. Certainly some does; even Dlink is starting to ship some gear that is (for the most part) IPv6 capable. The issue is one of quality and usability. "Will pass IPv6 packets" is a heck of a lot different than "gives you a single point of management for your whole network." (As current IPv4 cheap-o CPE stuff does.)

    IPv6 consumer gear largely expects everything will autoconfigure, won't need to worry about things like renumbering, and generally are just dumb consumer devices that do nothing but consume content. It expects individual devices to manage their own firewalls and thus offer really terrible ACL/firewall support. (Thus Johnny Cyberphreak can crawl down your tubes and pwn your toaster with relative ease.)

    Again; the statement in my article was never intended to say that no gear existed at all, but simply that it is both exceptionally rare and most of what exists borders on unfit for the described purpose.

    The "no more static addresses thing" was NOT a reference to an inability to statically address a given system in IPv6. It was instead a reference to the inability to reasonably and reliably static address these systems in an environment where renumbering was going to take place.

    Autorenumbering tech? Not until you have a completely bulletproof implementation of all relevant technologies in a single widget for a sub-$100 price with a dead-simple interface

    As to DHCP/DNS/etc "just working," we're going to have to agree to disagree. I have seen all sorts of things that can break these setups. It's more common than we'd like to think.

    “NAT is the solution.” Hell no. NAT is a terrible, kludge. I personally do not believe NAT (or NPT66) is the right solution to the problems I listed. I do however think that it is the solution that works right now, today. Unfortunately for us all, that is all that will *ever* matter to SMEs.

    Potential solutions, solutions that are more expensive than current ones, solutions that don't deliver immediate and obvious value, or solutions that require things like "trusting your ISPs to play ball and not be douchenozzles" will simply never fly.

    Part 2 to follow…
  3. In the end, the purpose of my article was to highlight the fact that the purity of the technical solution *doesn't matter* to the average Joe. You know how to properly implement an IPv6 network. I know how to properly implement an IPv6 network. We both know enough to build this stuff out of duct tape and glue if we have to.

    But that's irrelevant. What matters is *simple* and *cheap*. NAT solves the problems (real or imagined) that SMEs and consumers see when they look at IPv6. If we want to prevent NAT from gaining any sort of hold, then we have to put our hubris aside, accept that IPv6's marketing, message and CPE implementations were an [expletive deleted] hatchet job, and focus on the money, not the technical purity considerations.

    You aren't dealing with a base of "sysadmins" who know what an IPv4 header looks like and can tell you what the community string of an SNMP packet is by slapping wireshark on a line. Instead, you have “sysadmin-as-a-second-jobbers” who know only that they need to run a mailserver and a webserver and a what-have-you, on the cheap. They need to do it from the consumer-grade DSL connection they can afford and they need to do it with the shoestring equipment they can find at the local Best Buy.

    The disconnect between this world and the world inhabited by IPv6ers needs highlighting, the gap needs bridging. And the current culture of “scorn and belittle people into complying” will achieve the opposite results from those desired.

    I felt it was worth clarifying that, and sorry for the longwindedness of my post.

    I am planning a follow-up article probably towards the end of next month. If you would like to work with me to present a "IPv6-with-no-compromises for environments where the word "Cisco" means "too much money"" style article I will entirely welcome the collaboration.

    I have written the article to get the IPv6ers riled up and thinking about the problem. At some point I hope that enough of the right people get angry enough about it that I can write about real world solutions to these problems that fit in the real-world price points and usability requirements of the target audience I was discussing in my article.

    The ability to say “here is how you do IPv6 right, for dirt cheap, never have to worry about renumbering, its a completely bulletproof solution, can do multihoming and it is as easy as using a pfsense firewall with NPT66” would be a wonderful followup.

    In the meantime, I hope my article has caused some people to think about the problems faced by those living on the frugal edge. Maybe they will even look to addressing them.
  4. Totally agree with you regarding the lack of proper IPv6 support in low-end devices. Please start hammering the low-end vendors and start requesting support for at least "Basic Requirements for IPv6 CPE":

    http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09

    And I'm glad we're agreeing on the kludginess of NAT :-P
    Replies
    1. NAT by itself is a decent concept. However, it was even a more stupid idea to implement NAT back then as a way to deal with IPv4 exhaustion. Because it would have been much easier to implement a protocol with a bigger address space when the Internet was small and simple.
      And the big elephant in the room is that they didn't NEED NAT back then. With CIDR we had enough IP addresses for every Internet host until the early 2000s. We actually don't need NAT now. There are only about 1.5 billion hosts on the Internet. If the addresses were not hoarded by corporation like HP or IBM, every home user could have a public IP address on their PC.
      Instead of using NAT, they (back in the 90s) could have migrated to IPv6 as early as possible, because waiting is a truly stupid strategy. The more you delay doing your homework, they harder it would be when you actually have to do it.
  5. Yet again, in perfect agreement on the "the knowledge gap needs bridging", but I honestly don't know what else to do than to put the information out there (and there are tons of people doing that).

    As for non-BGP multihoming with IPv6, we won't see a proper solution for a while, and it will probably require changes to host IPv6 stacks as well (great news, isn't it).
  6. As I said in my own missive about this, NAT is coming to IPv6 whether we like it or not:

    http://phoneboy.com/4289/nat-is-coming-to-ipv6-whether-we-like-it-or-not

    Not only SMEs have issues with multihoming, but large businesses want to use NAT to ensure symmetric traffic flows on their multihomed link.

    If the industry/standards bodies can come up with a less kludgy, NAT-free solution to both issues, we're all ears. Meanwhile, people will continue to clamor for NAT because everyone knows "it works."
  7. So... NAT is good! :-P
  8. Ivan, have you read Templin's IRON proposal? It offers an interesting approach to multihoming (as a service, you might say). I realize it would cost money, but I suspect it would still be cheaper than BGP and cause less breakage than NAT.
  9. After a very cursory glance at the introduction section of the draft, I can't see how it would be significantly different from what LISP is offering. If you wish, you could easily deploy LISP-as-a-service with proxy ITR.
  10. Sure is - keeps your job secure :-E
  11. I consider NAT as a money-saver when connectivity provider charges for the service per device. For example, imagine how it affects mobile tethering - if no NAT is present, then mobile operator gets to control the end number of devices via 3G, thus including the charge on tethering (which is being done in France even now, I guess though analysis of the traffic..)

    Another situation - when CPE can provide only one IP address per port (because it is designed to do so), and then you are stuck with laptop with 3 VMs inside..)

    Vilius
    Replies
    1. It they really wanted they could nail you down from even behind the NAT. NAT isn't really effective to "secretly" add more devices without the ISP knowing.
      Not to mention that the ISP can simply break your connectivity so that NATing wouldn't work.
  12. Why not a solution that is actually somewhat human readable? The biggest problem I see with ipv6 is simple. Get on the phone and tell someone to go to, say, 192.168.0.104. Pretty easy, right? Now get on the phone and tell someone to go to 2001:0:9d38:953c:3c5e:367c:3f57:fffd. Not so easy, now, is it? IPV6 addresses are simply garbage. Would have been much simpler and easier for everyone to just add another .xxx to ipv4 if we needed the address space (which we don't but that's another conversation). IPv6 is a thinly veiled attempt to extort yearly fees paid to the standards bodies. That, coupled with the basic unreadability and unusability of ipv6 have ensured it will never take off. Period.
    Replies
    1. Ever heard of DNS?
    2. Well, he is talking about troubleshooting scenarios. Honestly, these things are set up once and then it just works. The real solution is universal use of mDNS. No normal person is going to set up a DNS server in their house.
  13. I absolutely agree with Iueras regarding IPv6 addresses. They are monstrous, ugly and impossible to remember, communicate or use in any sensible way. Why can't we get a new protocol? IPv6 failed. It's been around since 1998! We've had it forever and its usage rate is still pathetically low.

    The second problem is that not everyone wants all their devices publicly addressable. I think a lot of people feel more comfortable being behind a home router, not just for the firewall but because someone can't go after their individual devices by address when NAT is employed.

    We need something else. IPv6 is a failure. Period. Next idea, please?
Add comment
Sidebar