Barriers to internal IPv6 deployment: human factors

While the push for IPv6 at the Internet edge is definitely there, the push for internal adoption is not nearly as strong. In the absence of a screaming crisis or upper-management commands to push things along, it is human-factors that will prevent such a push. I'm going to go into a few.

RFC1918 means we never have to change.

10.0.0.0/8 has so many addresses, we'll never run out. There is no need to change.

This is a hard one to fight against, I put it as the top barrier for a reason. I saw something similar play out with the IPX to IPv4 migration, and I talked about that last month. This is a human factor that can't be easilly fixed through habit changes, it will be technical issues that push past it. Technical issues like IPv6 being required for some new bit of technology, that kind of thing.

Some organizations will end up feeling the pain sooner rather than later through address-space collisions. This can be from company mergers or through services that require private direct-connections between separate 10/8 spaces.

Memorized IP addresses

How in blazes am I going to remember 2001:98ba:08f2::1:16 is our primary DNS server?

Back when I worked on networks that didn't have DHCP, or on servers that weren't allowed to be DHCP assigned, this was a big one. IPv4 addresses are easy to memorize, IPv6 is less so. That said, there are patterns here. In the above example, every address on your network will have at least the 2001:98ba:: bit on it, since that's the network prefix. If you've memorized something like 186.238 as your own prefix, this isn't much harder. The next bit is the internal subnet, and the last bit the hand-assigned IP address. All of these are memorizable.

In my office we're forever telling each other how to get to specific servers by using their IP addresses. If we move to IPv6, there is no way we're going to still be able to do that. We're not moving.

There are two big reasons for why you would resort to using IP addresses to talk about servers and not their DNS hostnames:

  1. They're not in DNS.
  2. They're in DNS, but the naming-convention is not easy to memorize (or isn't sufficiently descriptive) so memorizing IP addresses is actually easier.

To work around the no-DNS issue, examine why DNS is not in use and perhaps address that.

The hard-naming-convention problem is trickier to manage. IPv6 addresses are harder to memorize than IPv4 and possibly harder than the naming convention would be so once you're on v6 use of the naming convention will increase. However, staff will resent having to do it. If you're an internal advocate of v6, you can start pushing coworkers to tell you how to get to things by their naming-convention IDs and not things like "the 242.16 server on the 14 network" or can push for a more human-accessible naming convention.

Memorized subnets.

We all know what the 242 subnet is. How in blazes are we going to remember something like the 4a9c subnet?

If you run into this remind people of a few little factoids about subnet allocation in v6-land

  1. You don't actually have to use hex. For subnets people will have to memorize or keep track of, you can assign them purely base-10 subnet numbers to ease strain on the human brain-meats.
  2. Because you can use more than one Unique Local Address, you can have more subnets than the IPv4 /8 you were using before. A ULA has as many subnets as an IPv4 /16 has addresses. However, you can have as many ULAs as you want.

It's the kind of thing you may have to draw diagrams of before people get it, but they will get it. And once they do, a bit of the visceral fear over IPv6 will abate.

Remember that DNS subnet? 08f2? If you put some intentionality into your subnet allocation and aim to put the memorizable addresses on subnets that humans won't grumble at, that 'hard to memorize' address could be as easy as 2001:98ba:30::1:16. That's not far off of what you're already memorizing.