1000 IPv4 addresses sounds like a lot and it is, until you have to start breaking it up. The company was a hosting (dedicated server and colocation) and every customer had at least their own /30 subnet with many having /29 (8 addresses), /28 (16 addresses) or even larger routed to them. It's amazing what you can achieve on a single server using virtualization. The customers would have their own firewall running a router VM, usually PFsense with multiple other VMs sitting behind it, sometimes 10 or more on a single 1u rack server! A /30 uses 4 addresses so at a minimum, one customer would use 4 addresses. Some reading this will say that it could have been done more efficiently and i guess it could but it wouldn't have been so clean.
So back to the IPv4 story in today's timeframe. Luckily Xtracta's main hosting provider here in NZ, called Orcon have had enough IPv4 addresses to provide really any amount of space their customers want. That's coming to an end however with it becoming tougher and tougher for us to get space from them. The obvious answer is IPv6. I have made it a personal policy that any device we have acquired for the last 2 years must be IPv6 capable and most are. These include our:
- Desk Phones
Xtracta's Network StrategyOur network design strategy at Xtracta revolves around dual stack IPv4/IPv6. We run different network segments, at least one for our publicly facing servers and at least one those that don't need public access. The reason for this extends beyond security; it allows us to put the small amount (/28) of public space we have only on those servers which really need them. This is for things like our web server, file transfer server, DNS nameserver etc.
The other subnet has private IPv4 space (also known as RFC1918) for things such as our processing servers, Smart OCR artificial intelligence (yes quite a mouthful) servers, testing servers, development servers, storage servers. So many servers! This usually runs a /24 like 192.168.1.1 - 192.168.1.254
Both segments have a /64 IPv6 subnet. Now this is important, try and make EVERY ONE of your IPv6 subnets /64. It's the semi agreed upon standard size so we don't need to worry about variable length subnetting anymore. The biggest advantage is we can now run this great technology called stateless autoconfig. Stateless autoconfig is the replacement for DHCP where complexity isn't required. It works based on the the subnet itself, a device can use it's MAC address to come up with its own unique address on that subnet which is guaranteed unique - you no longer need a server to handle that important requirement. It also brings static addressing naturally without needing to keep track of what devices are using what addresses simply by the fact its IPv6 address is built on the MAC address; something that doesn't change.
Route ProperlyI talk with lots of people who think port forwarding is the be all and end all. And I've seen for myself some of the problems it creates. Often people will have a number of addresses with their ISP which are provided on their linking interface - ie the WAN side of their router. They then proceed to port forward these to servers they have internally which sit on a private IPv4 address space e.g. 192.168.xxx.xxx 172.1x.xxx.xxx or 10.xxx.xxx.xxx. This is really messy and can cause real issues with things like DNS. Do things properly, for IPv4 get your ISP to route you a subnet via the WAN IP on your router, then set the public IP directly up on your server. Most routers should support firewall rules to protect your servers and you should only allow connection on ports relevant to each server from the general internet. E.g. perhaps port 25 is open to your mail server or 80 to your web server.
This native, non-hacked approach to routing/firewalling is the approach the internet was originally designed for and its structure is just so much better than port forwarding.It is the approach you will need to take with IPv6 also so its best to follow it as a standard within your network.
Make IPv6 support a PolicyOne of the key things to rolling out IPv6 is that your equipment actually supports it. A lot of equipment already does but a lot doesn't and you should be avoiding equipment which doesn't have support. A quick run down:
- Operating Systems: Windows From Vista and Server 2008 has excellent, near native support for all services. Only thing I have found lacking is the ability to pass DNS server information in SLAAC which still isn't possible even with Server 2012. It's really annoying as you have to run DHCP just to provide a DNS server which is really all that is needed besides IP address and gateway information. Linux support really depends on your distro but we have used Ubuntu from 10.04 onwards and support is top notch. One thing to watch our for is that Ubuntu creates multiple "fake" addresses by default - probably to hide the MAC address. The proper SLAAC address is there. Try the following command and look for a "global dynamic" address:
ip -6 addr
- Routers: Routers are where the big issues around IPv6 rollout happen. Besides the OSes, in most networks routers are the only critical layer 3 device required to make IPv6 a reality. Most small office home office brands have a very poor track record here such as Dlink, Netgear etc. I am a STRONG proponent of the PFsense project, I manage around 15 PFsense routers and they are amazing. What's even more amazing is the fact they can run on any hardware or as we do, as virtualized machines on our ESXi infrastructure. Another good option could be Mikrotik.
One you start entering into the mid tier market e.g. Juniper, Cisco etc. support starts to come in but often while it will say its IPv6 ready, the implementation is very poor and in many cases unworkable. Basic services won't be supported and you can become highly frustrated! Read the reviews and talk to other users with the devices and running IPv6 before you take the plunge (online discussion boards are a great place to ask about this).
- ISP: This is an obvious one, if you want to use IPv6 your ISP must support it. Yes you can use tunnels like SIXXS or HE.net but its much better to go native as otherwise you are tunneling all your traffic through an unknown node which may increase your latency and decrease your bandwidth (and increase risk if that tunnel provider is down for eample). Choose an ISP who have native IPv6 support and will actually provision it rather than just tell you they do then when it comes to crunch time say they can't do it.
- Network Devices: Besides your computers you probably run a number of other layer 3 network devices like printers, VOIP phones, managed network switches, CCTV cameras etc.. support in these devices is a bit hit and miss. I have been pleasantly surprised on how many do support IPv6 however. Our Konica MFDs and Cisco SMB switches (SG300 series) have full support and it works. Our phones, Yealink T22P claim to have IPv 6 support but in fact have none at all or if they do, require immense firmware hacking which doesn't count as IPv6 capable in my book. Our wireless access points and CCTV cameras, both from Ubiquiti have no IPv6 support (but nor do they claim to). Check this out before you buy the device, while there always is a possibility of a firmware upgrade bringing IPv6, don't rely on it.
Rollout - Gradual or Rapid, either way make it happenRolling out IPv6 in your network can be approached in two ways:
- One big "hit"
- Gradually service by service, device by device over a period of time
Test your DNS and ServicesOnce you are up and running with IPv6 make sure you test! Remember that even if your server supports IPv6, the services that run on it may not, or if they do, require extra configuration. A lot of people use IP addresses directly when mapping services, printers etc. and this is not a good practice in my book. This is even more true with IPv6, remember that if you ever change ISP your entire IP addressing will change, even for your internal network. Partly for this reason and partly to make the transition to IPv6 smoother, I suggest setting all of your devices up with a DNS entry e.g. for us it may look like printer1.ororke.akl.xtracta.local. This would then have both the A record (for IPv4) and the AAAA record (for IPV6) setup for the device. If the service on that device, in this case a print server supports IPv6 then great, otherwise it should automatically fall back to IPv4.
This approach does have the downside that you won't know what services are running IPv6 and which are running IPv4 since they both work. But you can go through each one by one to ensure that IPv6 is running and they are responding to it. A tell tale sign that IPv6 isn't working are delays caused by IPv6 timeout. Typically if one device is trying to connect to another on IPv6 it will try and wait for a preset amount of time before falling back to IPv4. This is a good indication the particular service being connected to is not configured for IPv6.
One of the other benefits of this approach is that, especially for remotely connected sites/services (e.g. connecting from an office in one city to another over a VPN tunnel for example), if you are having connectivity issues with one protocol - it could well be the other is still working. We have experienced this a few times now where IPv4 connectivity between our sites has been down while IPv6 has remained up - leading to greater reliability for us.
I hope this provides some good tips for those wanting to roll out IPv6 which should be... everyone... Good luck with your rollout!
Originally published @ http://xtracta.com/blog/item/28-basics-of-ipv6
Other related posts:
Uber & Driverless Cars - Changing Your World
Comment by resurrect, on 17-Jan-2014 12:05
unless i'm new to binary based math a /22 should give 1024 addresses as a /24 gives 256. and then you have NAT/PAT which almost stopped IPv4 from running out (as well as classless addressing).
Zeon: Yup you are right! A /22 indeed is 1000 addresses! And we all use NAT/PAT now but its still not enough to stop IPv4 crunch!