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.
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 there – D-Link has shipped more than 10 million IPv6-enabled devices.
I’m positive there are missing bits and pieces but the situation is not much better in the high-end enterprise market.
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).
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.