Why People Still Haven’t Adopted IPv6 (And Why You Should Learn It Anyway)

It’s 2017, and if you haven’t learned IPv6 yet, well, you’re not the only one. In December 2016, IPv6 turned 18 years old. Children who were in the womb when RFC 2460 was being drafted are now old enough to vote, get married, and purchase firearms in some states.

In honor of IPv6’s 18th birthday, allow me to share my theories on why people have been so slow to adopt IPv6. And why you still should consider learning it.

The “Lame name” theory

IPv6 terminology makes it sound like a new version of IPv4 and it’s not. It’s a totally different protocol with a similar name. If you’re familiar with the confusion between Java and JavaScript, you know what I’m talking about. People who set out to learn IPv6 are disappointed when they find out it’s almost nothing like IPv4.

The “Let’s split DHCP in half and spread its most popular functions across two protocols” theory

DHCP for IPv4 can provide clients with IP addresses, DNS servers, default gateways, TFTP servers, and pretty much anything else. DHCPv6 doesn’t have an option for providing a default gateway. If you want to push a default gateway to IPv6 clients, you have to use SLAAC.

The “all things to all people, places, animals, plants” theory

IPv4 has only a few address types that anyone actually uses. Colloquially, they’re public, private (RFC 1918 addresses like 192.168.1.1), and multicast (which includes broadcast). IPv6 has approximately one zillion different address types, including unique-local, link-local, unspecified, and global unicast. Although there are technical justifications for some of these, the plethora of address types makes no sense to anyone who doesn’t deeply understand why “layer 2” is even in the IT lexicon.

The “IPv4 apocalypse” theory

We’ve all heard the constant chicken-little talk about how we have to move to IPv6 yesterday or the internet will die. Driving this is the myth that all IPv4 addresses are gone. They’re not, and the U.S. government is sitting on tens of thousands it’s never going to use. What really happened was that in 2011, the Internet Assigned Numbers Authority (IANA) assigned the last of its available IP address space to regional internet registries (RIRs) which are responsible for doling out addresses. But the IPv4 addresses didn’t just go away. They still exist, and many of them are unused and can be reassigned.

The “NAT is a tool of the devil” theory

If you ever want to have fun, go on any IT forum and ask, “Why do we need IPv6 when we have NAT?” Actually, don’t. That would be trolling. But if you were to ask that question, you’d probably get a few responses hating on IPv4 NAT as a tool of the devil, which IPv6 will save us from… except it does NAT, too.

The “Why do I need both again?” theory

Implementing IPv6 almost always requires a multihomed (dual-stack) implementation, which people figured out about 30 years ago was a bad idea with IPv4 because it confuses everybody. IT admins translate this as, “More work for me.”

The “Because we can” theory

There are enough IPv6 addresses for every cell in your body to have its own internet. Seriously? This, like NAT, is another non-reason to adopt it. Yes, it’s cool that I can give my Uncle Milton’s ant farm its own Internet. But as far as business justification goes, nope.

Why you might want to learn IPv6 (hint: money)

Although IPv6 has been poorly marketed, it’s still worth learning. In fact, I believe in IPv6 so strongly that I’ve created several Pluralsight courses on configuring and troubleshooting it.

Here are three big reasons to consider adding IPv6 to your set of skills:

  • It’s is like a sports team. The big boys are rooting for it. I’m talking about Cisco, Juniper, ISPs, Google, et alia. They want to see it win, and they’ll pay to make it happen. If you know IPv6, you can be on the receiving end of some of those payments.
  • The confusion and complexity around IPv6 has made experts that much more valuable to companies who have already invested in IPv6 infrastructure.
  • If you know IPv4, IPv6 isn’t that hard to learn once you realize that it’s a distinct protocol and not a new version of IPv4.

For further IPv6 learning, check out my Pluralsight courses:

Troubleshooting IPv6 at the desktop:

Practical Networking

Configuring and troubleshooting IPv6 on Cisco routers:

Basic Networking for CCNP Routing and Switching 300-101 ROUTE
Troubleshooting Cisco Networks: IPv6 Routing Protocols for CCNP R&S 300-135 TSHOOT

Building Windows Server with Puppet and Chocolatey

Forget using scripts and group policies to configure a new Windows Server machine. Using Chocolatey and Puppet, you can do it faster & easier than ever (and it’s more fun too). This is especially true if you’re using a Server Core installation and don’t have a GUI to help you along. Oh, and if you don’t know Puppet, you really should watch my course Puppet Fundamentals for System Administrators on Pluralsight 🙂

Assign IP address using PowerShell:

$ New-NetIPAddress –InterfaceAlias "Ethernet" –IPAddress "192.168.51.29" –PrefixLength 24 -DefaultGateway 192.168.51.8

$ Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses 192.168.50.20, 192.168.50.21

Install Chocolatey:

$ set-executionpolicy unrestricted
$ iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Restart PowerShell

Install VMware tools

$ choco install vmware-tools

The server will automatically restart.

Rename server

$ rename-computer -newname newservername

Reboot

restart-computer

Join to domain
add-computer -domain benpiper.com

Reboot again
restart-computer

Install Puppet
choco install puppet

Configure Puppet
Configure c:\programdata\puppetlabs\puppet\etc\puppet.conf

Generate puppet certificate
puppet_interactive

Sign puppet certificate on puppet master
puppet cert sign newservername

Apply appropriate profiles to server. Remember to restart the Puppet master if you change your Hiera configuration.

Run Puppet agent
puppet_interactive

Verify
puppet resource dism
puppet resource package

Citrix Web Interface 5.4: Error occurred while making the requested connection

I recently ran into a bizarre issue with users not being able to launch applications from a very old Citrix Presentation Server 4.0 farm when trying to launch from Citrix Web Interface 5.4. They were getting the eminently unhelpful, “An error occurred while making the requested connection.”

In the web interface application logs, I noticed this:

An error of type IMA with an error ID of 0x80000003 was reported from the Citrix XML Service at address (servername)

And this:

The farm MyFarm has been configured to use launch references, but a launch reference was not received from the Citrix XML Service. Check that the farm supports launch references or disable launch reference requests.

To resolve this, I modified C:\inetpub\wwwroot\Citrix\XenApp\conf\WebInterface.conf on the Web Interface servers and changed the RequireLaunchReference directive as follows:
RequireLaunchReference=Off
(It was set to On)

And it worked. Supposedly, that directive must be set to Off when using Web Interface 5.4 with PS 4.0. But, I’ve been running for years with it set to On and it worked fine until recently. Another Citrix mystery.

Want more Citrix tips and tricks? Watch my course Citrix NetScaler 10: Design and Deployment!