IPv6 has and continues to cause a lot of confusion for network administrators. I suspect that a lot of it is down to misunderstanding about the new system and therefore people blame it for problems because it is new.
In forums, I see a lot of people who simply post that the problem is "IPv6" and it should be disabled because it is "known to cause problems". I have been asked to clean up Exchange deployments where IPV6 has been disabled, simply because the installer believed it would cause issues if it wasn't.
In many cases this is simply not true - IPv6 is not the cause of many problems and in the default configuration on Windows 2008/2008 R2 will not get in the way of day to day operations.
However IPv6 is not going to go away and very soon most network administrators are going to need to do something with it, whether they like it or not. Therefore getting experience with it now, before being forced to do so can only benefit the network administrator.
Back in the summer, just after the World IPv6 day, I decided to look at using IPv6 myself and have been running an IPv6 network at home ever since. The web sites that I operate are also IPv6 enabled and if you are already using IPv6 you may well be reading this blog posting having accessed the site using Ipv6.
Initial Experiences with IPv6
Having now lived with IPv6 for a few months, I thought I would write up my experiences with using it. In brief, I have found it to be largely trouble-free. I was caught out by a few small issues at the beginning, but after being setup correctly, it has been largely set and forget.
IPv6 Addresses and Getting Started
The first thing you have to do is get hold of an IPv6 subnet. Most ISPs are currently not issuing IPv6 addresses, so you have to source them from elsewhere. Having researched on the easiest way to do this, I settled on using a tunnel broker, specifically Hurricane Electric (HE).
It was easy enough to sign up with them, and before long I had the single address required. HE are giving out the addresses free, and allow you to choose where to create tunnel to. I chose London, being in the UK.
I built a Windows 7 machine in a virtual machine, and followed their instructions to enable it - which was simply a matter of entering some commands in to a Command Prompt to configure the tunnel, which Windows 7 supports natively.
For the tunnel to create, HE need to be able to ping your EXTERNAL IPv4 address, so a firewall change might be required.
Once entered, I tried to ping ipv6.google.com, only for it to fail.
Therefore I hit the first problem, which is probably the most common issue with IPv6 - hardware support.
I am fortunate that I have dual internet connections, regular ADSL and a cable internet. My ADSL had a Cisco router on it, and I quickly discovered that Cisco only support IPv6, even pass through, on specific OS types and I had the wrong one. I wasn't paying for the upgrade for a test (And was planning to drop the Cisco router a few months later when I got fibre internet), so I decided to use the second connection.
Switching over to my cable internet connection, which used DDWRT, the tunnel passed through immediately and I was on the internet using IPv6.
I have to say, it was a rather underwhelming experience - it just worked.
Putting the Network on to IPv6
With the single machine on IPv6, I thought I would see if I could put my entire home network on as well. This meant the router needed to support it. I played around with DDWRT for a while, but found it wasn't easy to configure with IPv6 information. Therefore I changed my attention to my public web server.
The web site that you are reading this posting on is actually a virtual server. The firewall that protects it is a VM, and generally I can do what I like with the system. A look around at other software firewalls it quickly became clear that the best one for IPv6 was monowall. It didn't take long to install a fresh VM with monowall and used a spare external IPv4 address.
After requesting a second subnet from HE I entered them in to the firewall and I was online. Took minutes to configure monowall. I then set the firewall rules so I could ping out etc and all was good. I modified the firewall rules to allow inbound traffic and after a few minutes configuring the DNS records, I was able to browse my web server with IPv6 from my test system at home.
Using IPv6 also gives the strange sensation of the same IP address internally as well as externally. No NAT involved. I haven't been in that situation since a job back in 1999, where the employer had enough public addresses that we could use them internally as well.
IPv6 Addresses
One of the things that did start to cause me a headache was dealing with the IP addresses themselves. You have so many and they are so long. However I quickly learned about the "::" shortcut, which allows you to shorten the addresses. What this means is that instead of using:
2001:470:1f09:1ab5:0000:0000:0000:0090
I can use this instead:
2001:470:1f09:1ab5::90
From an understanding point of view, I found that using the same number at the end of the IP address for both IPv4 and IPv6 made managing the addresses much easier. For example this blog is on 85.234.131.90, so I used ::90 at the end of the IPv6 Address.
With the addresses configured on the web server, it means I can just look at the last number to ensure that I am putting in the correct bindings to the web server.
Boyed by the success of getting the public web site to work, I looked again at my home network. Switching the DDWRT router for a monowall virtual machine meant that I was able to configure the home network for IPv6 quickly, and also meant that I now had a static IPv6 address running over my dynamic IP address cable internet connection.
With the addresses the length they are, you have a lot of addresses available to you.
I subnetted my allocation down further, which has allowed my labs to have their own IPv6 subnet. This means my labs "could" be seen from the internet, if I set the rules to allow that to happen in the firewall. Once IPv6 is widely used, I can see that as a major advantage, particularly if you are testing email servers.
DHCP or Not
One of the features of IPv6 is that removes the need to have traditional DHCP. Instead you enter information on your router and it is able to "announce" that information which IPv6 clients are able to find.
Microsoft do provide an IPv6 DHCP server, which I had some success configuring, but as the information from the router was correct, it wasn't something I pursued.
Most of the systems on my network I entered static IP address information for, but I did find they were getting an automatic address as well, which must be a feature of IPv6. However when reviewing WSUS for example, the static address I assigned is being entered in to WSUS as the server's IP address.
The impression I am getting though is that the IP address of the system is going to be less important, at least internally. I have set static addresses in the public DNS and on the servers, and those work correctly, but internally the network is also using the automatic addresses.
With the length of the IP address, remembering them for doing testing isn't going to be easy. Therefore I can see in the future that DNS will become more important, so that you can simply ping or nslookup the host name, to get its IPv6 address, then work from there.
DNS
I mentioned DNS above.
Backwards compatibility for DNS on IPv6 works really well - you have two entries for most things - an IPv4 A record and an IPv6 AAAA record. The AAAA record takes priority.
This can of course give unexpected results, particularly when troubleshooting. Therefore what I have done is create three records for hosts where I am likely to want to do troubleshooting (mail servers mainly).
- The regular host name - so host.example.com - both A and AAAA records.
- A IPv6 specific host name - so ipv6.host.example.com - this is an AAAA record only.
- An IPv4 specific host name - so ipv4.host.example.com - no AAA record.
A good example of this in action can be seen on a basic IP address display site I built.
If you browse to the site normally then you will have the IPv6 address displayed if you are using IPv6 and the IPv4 if you are using IPv4.
http://ip.sembee.info/
However further down the page are links to other versions of the page - one for displaying just the IPv4 address and then one that displays both IPv4 and IPv6. Moving through the pages you will notice that the host name in the browser bar changes, so that the correct DNS entry is used.
Email
As an Exchange MVP, I was of course interested in how this would work for email.
For email it is just a matter of adding the additional AAAA record for the host name.
MX records point at host names, and then the client resolves the host name to an IP address.
Therefore my MX record hosts have both IPv4 and IPv6 addresses.
Although monitoring the email I have found that I have received just three emails (all marketing) from IPv6 hosts.
Drawbacks with IPv6
The major issues with IPv6 is support of the address type.
I quickly discovered that the antispam solution I am using cannot cope with IPv6 addresses, but as spammers aren't using it, it hasn't been a problem so far.
I also discovered that my web stats application doesn't support IPv6, so I have no real ideal how many people are accessing my web sites with IPv6. Certain applications also have issues with IPv6, but in a lot of cases this is only if it is pure IPv6, not a mixed network.
The length of the IP address I think will be something that many network admins will find difficult and will miss being able to type in the four sets of numbers from IPv4. I fully expect IPv4 to be used internally for some time to come, perhaps with IPv6 being used just for internet traffic.
Conclusion
As you can test Ipv6 with almost no disruption to the production network, it is something that network admins should take a look at, so that they simply get their heads around it. Then as it becomes more widely used, they have already been through the learning curve.
