I wouldn’t consider myself an anti-IPv6 luddite. I have IPv6 deployed in my home network (with maybe 15 different subnets, 30 or so VM’s, multiple sites, etc.a decent approximation of an SMB network) with HE.net tunnels. I’m frustrated about all the real world issues associated with IPv6 though.

IPv4 is obviously running out of addresses, and IPv6 is the only reasonable solution today for that. But beyond the issue of address space exhaustion, I’m not sure that IPv6 is going to solve many more problems than it causes.

I don’t think we can really blame these issues on the good folks at the IETF who developed IPv6. IPv6 was designed quite a long time ago, and the IPv4 landscape has changed a lot in the last 15 years. It’s frustrating though that we’re trading one set of problems (associated with IPv4) to another set of problems that IPv6 will bring.

I’d like to see more universal support for IPv6.from network vendors, software vendors, and ISP’s. Unfortunately, the organization I work at has a /8, and don’t appear to be eager to adopt IPv6. What are your thoughts?

Small Sites

Connecting a small site to multiple ISP’s via IPv6 is going to be more difficult than with IPv4 / NAT. I think this is a fairly well documented (see Ivan Pepelnjak’s post).

But in my view, the even more significant issue is that the internal addresses small sites use will be tied to an ISP.

Currently with IPv4, most smaller orgs will use RFC 1918 space internally and NAT those addresses to their public IP range. With v6, organizations that aren’t large enough to obtain their own provider independent IPv6 allocation will use their IPv6 address ranges given to them by their ISP’s - both internally and externally.

This makes changing ISP’s an extremely painful experience. With IPv4, changing your public address space would involve some relatively simple NAT changes, and probably some DNS / firewall changes on the outside. With IPv6, all of the internal devices will have to be re-IP’ed. For end-user devices using DHCPv6 or stateless autoconfiguration, that’s really not a huge deal. But for all of the routers, servers, and other infrastructure devices with static addresses.that’s not going to be a fun undertaking.

Fundamentally, I think it makes sense to decouple internal and external addresses. Overloaded NAT as is typically deployed with IPv4 is not necessarily the best way to handle this. One-to-one NAT would be a bit better. IPv6 prefix translation as RFC 6296 describes makes more sense. I’m not sure that any existing IPv6 hardware actually supports what RFC 6296 describes however. The fanatical religious opposition to any implementation of address translation in IPv6 is disheartening. I think the lack of common support for address translation in IPv6 will cause a lot more harm than good.

Maybe this is just a personal thing. But I find link local addresses to be fairly annoying. I get that there are scenarios where multiple devices are in the same broadcast domain that need to communicate with eachother without a router sending RA’s or a DHCPv6 server. But I’m not sure I see a purpose of using link local addresses when a routable address is already assigned on an interface.

Take for instance this output from a “show ipv6 route” in Vyatta:

O>* 2001:470:c147:50::/64 [110/2] via fe80::80ab:92ff:fe6e:82ee, br1, 21:52:50 O>* 2001:470:c147:60::/64 [110/2] via fe80::80ab:92ff:fe6e:82ee, br1, 21:53:00 O>* 2001:470:c147:70::/64 [110/2] via fe80::80ab:92ff:fe6e:82ee, br1, 21:53:00 O>* 2001:470:c147:80::/64 [110/10] via fe80::80ab:92ff:fe6e:82ee, br1, 21:53:00

To me, that link local address is fairly useless information. Here’s another example, from Wireshark:

clip_image002

Now these two issues are really more related to the applications themselves than the protocol. But I see link local addresses as causing more confusion and headaches than they will solve.

Colons

I’ll admit, this is somewhat petty. But honestly, colons were probably one of the worst possible characters to use as a delimiter in IPv6. It conflicts with the delimiter for port numbers that often follow IP addresses. This often requires square brackets around the IPv6 address. As if IPv6 addresses weren’t frightening looking enough, a URL that previously looked like http://10.20.30.40:8080 will now look like http://[2001:470:c147:50::10]:84. (Granted, DNS should be used in most of these situations.)

It also requires multiple key presses on most keyboards and is more difficult to type on mobile devices.

Maybe forward “/” slash would have been worse as far as confusion and conflicts go. Other than that though, I can’t think of too many symbols that would be more of a pain.

Handling of Dual Stack Environments

Five years from now, I think it’s fairly clear that a great deal of environments will be dual stack. Sure, there will be a few places that have managed to become IPv6 only or greenfield deployments that are IPv6 only by necessity. And I’m sure there will be some lethargic organizations that will hold on to IPv4 until the end of time. But, the way it looks now, most places will be dual stack. With hosts using an IPv4 address and an IPv6 address. With routers using separate protocols and forwarding tables for IPv4 and IPv6. And with firewalls using separate access lists for IPv4 and IPv6.

In my mind, it would make sense if this were a little more unified.

Why shouldn’t I be able to apply an access list to an interface that includes both IPv4 and IPv6 elements? I think this would really come in handy with firewalls that support address groups. I apply policy Webservers_Policy to an interface that allows traffic to port 80 on everything in the Webservers_Group address group. And when I happen to add an IPv6 web server, I just add an IPv6 address to that group.  Obviously, the v4 / v6 ACL’s would just appear to be unified from a management perspective.  But surely it couldn’t be too difficult a vendor to do this.

For routing, IS-IS might make this feasible with single-topology support. See this example.

I don’t think this would make sense in every environment. But I think in a lot of cases it would make it a lot easier to add IPv6 on to an existing IPv4 environment. And that’s going to be the most common scenario in the near future.

Vendor Support

This is really more a vendor problem than a problem with the protocol itself. But it feels like a number of vendors view anything beyond basic IPv6 support as an addon or advanced feature, even if the IPv4 equivalent is included standard.

I think this situation is changing as IPv6 support becomes more of a necessity. Still though, some devices support just enough IPv6 to be able to check the “I support IPv6” checkbox, but not enough to use in real world networks.

For instance, the image I have on a Cisco 1720 supports IPv6, and OSPFv2, but not OSPFv3. As another example, Vyatta supports things like VRRP and firewall address groups for IPv4, but not IPv6.

If I’m using OSPF for dynamic routing with IPv4, chances are I’m going to want to use OSPFv3 for IPv6.