IPv6, the new IPv4

I've been using IPv6 since I was asked to work on a project relating to it in 2002. At the time it was a cool "new" protocol to play with and had some really neat auto-configuration features. I deployed it in only small limited sites where I could view the old animated IPv6 turtle. More recently I have been using IPv6 in production and have seen a lot of attempts at making political grabs on IPv6. The one that amuses me the most is the technical grab at, "hey we can change things now that were problems with IPv4 before."

I have found that the majority of the time if the problem was easy to just fix, there is a solution for it already in IPv4... with the exception of global address space of course. People like to use it as a crux and have a different network layout and rules for IPv6 than they do for IPv4. The problem is that having two distinct paths to all of your hosts and a different set of rules for each path does not create a stronger whole. At best it only stays as strong as it was and the rest of the time you are making your network weaker. By weaker I am not talking just security but usability as well.

Security is paramount so I'll discuss this for a moment. Let's assume that we have a dual-stack network with 100 nodes. We have done our due diligence in IPv4 and have a firewall in place to make sure certain traffic does not flow, however historically the network has been open so we can't just close off all ports except the ones we know we have published. Now comes IPv6, the new historically un-used protocol... at least for this network. We have the opportunity to do things the way we want from scratch, right? Let's just close off all ports except the ones we know we publish in IPv6 and we will have a more secure network going forward! Hoorah! Wait a second, that doesn't help security because everything is still available in IPv4 and now you are managing two different rule sets for all of your services. Two different rule sets in itself is added complexity which means more room for human error.


Now, let's imagine we have a split administration for network management and host management. The network IT staff are now happy with their more secure IPv6 network and meanwhile the host IT staff are saying, "ah ... finally we don't need to worry about random traffic to these hosts." From this they leave their vendor defaults of no IPv6 host based firewall while having restrictive IPv4 host based firewalls. This is essentially the opposite scheme as the network folks have taken. IPv6 is wide open while IPv4 is restricted down.


I'm sure some of you white hats are starting to raise an eyebrow as you realize that any one compromised host can now access all services available via IPv6 on the local lan. What you thought you had locked down in IPv4 host based firewalls is completely open under IPv6 (but only locally). You black hats are probably thinking to yourselves, "hmm, but how common is IPv6 and is it worth my while?" Given that there are a lot of rogue IPv6 deployments from 6to4 routers and the fact that you could easily configure an entire network by sending out the right SLAAC packets ... as common as you want. Also, finding local IPv6 hosts is usually as easy as "ping6 ff02::1"


Now that I have put most of the key ingredients out there for a really nasty worm that exploits this not-so-uncommon topology, let's talk briefly about usability. A local developer decides to deploy a service on port 8080. When he is local, his client-server connections just work because IPv6 host based or site-level firewalls are not in the way. He is also developing in a high level language so he doesn't even need to know that IPv6 is being used for this to work. Later, he goes home and tries again ... except he only has IPv4. The flow might look something like this: Ok, fair enough ... the firewall is getting in the way as usual. Time to flip on the VPN. Hmm, it's still not working? I know it was working locally when I was there and I haven't changed anything so it must be the VPN. Let's send an email to our IT staff and let them debug this wretched VPN again. Maybe I will just ask for port 8080 to be opened instead. Harrumph, another night of no progress. ~insert beer here~

The next morning the IT staff says, "Oh, he needs port 8080 opened for access from home" and makes the appropriate request to the network folks. IT responds and says, "OK, we opened port 8080, give it another try." The developer, waking up a little groggy decides to go to a local coffee shop to check email and get the day started. He sees the email and decides, "alright, I'm in a coffee shop ... I'm still remote so let's test this really quickly. Hey, it works! Perfect! I can work from home tonight." Little did he know the coffee shop had an Apple Airport which sets up 6to4 for the local clients. It worked and bypassed the host based firewall again.

At this point I can keep iterating back and forth in this scenario and see that at least one more day goes by before anyone sits down and gets all of the glitches out of the connection process. All of this could have been avoided had all rules been held consistent between IPv4 and IPv6.

Now, given this one example I will say that usability is impaired and then leave it as an exercise to the reader to discover other scenarios that arise in a complicated asymmetric configuration. Solving this one problem does not solve the others. I know that sufficiently creative users manage to find all kinds of great ways in which to break the perfect models we make ... especially when we make them more complicated ... and then even more so when they don't even have to realize that more is going on below the hood than they care to know.

The bottom line is, making IPv6 significantly different in your organization from IPv4 will invariably cause problems down the road. From a users perspective, the network should just work and not get in the way.