There’s been much noise about IPv4 address runout and IPv6 adoption lately, even as far as some poorly written articles in the mainstream media. The IANA address pool was depleted on February 3rd, 2011, with the final /8 blocks being assigned to the RIRs for allocation. (ARIN article on IANA runout) Now, just over 2 months later, APNIC appears to be close to exhausting their assignable address pool, the first of the RIRs to do so. (IPv4 Address Report)
So, what does all this mean for non-carrier companies who haven’t adopted IPv6 yet? Will your networks fall off the face of the internet? Will websites become unavailable to your employees, or even worse, your customers?
Well, no. In fact, you probably won’t notice anything at all. IPv4/IPv6 dual-stack hosts will be the norm for the foreseeable future in most regions. However, we are facing the possibility of IPv6 only clients starting to show up in the Asia/Pacific region. This means that even though the sky isn’t falling, steps should be taken to adopt IPv6 in a manageable fashion, particularly if you have a global presence including a customer base in Asia.
Here at Semaphore Corporation, we’ve been running down this road for some time both to migrate our own network, as well as prepare ourselves for the process of assisting our customers in their migration. I’ll present a straightforward high-level roadmap of how we recommend handling IPv6 adoption based on our own experiences.
IPv6 adoption is a 6-phase process (more or less)
Phase 1 – Internet Connectivity and External Infrastructure
Several of the other phases are optional based on your needs and the scope of your customer base. This phase, however, is not. The single most important step in IPv6 adoption is ensuring your network provider supports IPv6 natively.
At this point, any major business class carrier should offer IPv6 support to their customers. Broadband providers may or may not be an exception to this, although most have pilot programs in place. The first step in this process should be to call your carrier and ask to receive an IPv6 address allocation and have it routed to you. You can typically base your address space request size on your current network infrastructure. The following list is the most likely possibilities for address allocation:
- Single directly-connected subnet – This model is most often seen in the datacenter for small deployments. Your layer-3 gateway for your external devices is your ISP, and you either have a single server or a layer-2 infrastructure handling connectivity to your servers. Your ISP will likely assign you a /64 (single IPv6 subnet) to match your current IPv4 needs.
- Single external subnet, multiple internal – There is much confusion as to how perimeter security will function under IPv6. Many state (myself among them) that NAT is no longer necessary and security should be performed on routed subnets. Even if you currently use NAT, if you have infrastructure with multiple subnets behind your firewall, I could recommend requesting an address allocation which can be divided up into smaller subnets. The size of this allocation will vary based on your carrier, ranging from a /60 (16 /64 subnets), a /56 (256 /64 subnets) all the way to a /48 (a lot of /64 subnets)
- BGP connected and/or multihomed network – If you’re running BGP and have your routes propagating into the global table via your own AS, a /48 is required. This appears to have been decided upon as the new /24, the longest prefix length that will be allowed into the global table. Attempting to announce a netblock smaller than a /48 will likely lead to it being filtered by many networks. There isn’t a particular need for a netblock larger than a /48, so this is likely what you will get.
- Tier 1/Tier 2 Network Service Provider – If you will be delegating BGP routable space to your end-customers, you will need to go to ARIN (or your local RIR) for you address assignment. The RIRs appear to be assigning /32 length networks to NSPs. Presumably, if you fall into this category, you’re already well on your way to adoption and this post isn’t for you. =)
External Network Infrastructure
This may or may not be required, depending on your particular network model. If your external servers live outside a firewall and are directly connected to a switch (the datacenter model mentioned above), then you may not need to do anything at all here. If you have a router outside your firewall, or a layer-3 switch, you’ll need to assess its IPv6 capability. Most modern layer-3 devices offered by the large players (Cisco, Juniper, etc) have supported IPv6 for years. A code upgrade may be required on some older chassis however. If you do have an external layer-3 device that supports IPv6, now is the time to bind the IPv6 network assigned by your ISP to the internet facing interface and begin testing IPv6 connectivity to outside networks. If you’ve gotten that far, congratulations, the hardest part is done! (Getting started)
Phase 2 – External Servers
This is the second phase that I would consider “mandatory” for most companies at this point. Everything past this phase can wait, since mostly likely companies in all regions will run their externally facing servers dual-stack indefinitely. However, if IPv6 only clients begin showing up, you need to make sure they can reach you! This phase includes external webservers, mail servers (although this is less critical as mail will be relayed by dual-stack hosts), DNS servers (again, relayed, so less critical). Focus first on ensuring that your external web presence is visible by both IPv4 and IPv6 users. Your primary website should be accessible by both v4 and v6 clients at the same URL. So, for example, http://semaphore.wpengine.com has both an A and a AAAA record. Earlier is was typical to see a site such as http://ipv6.semaphore.com or http://ipv6.www.semaphore.com. However, these are becoming less common, since users don’t know to look for them and they will expect the same names they used on IPv4 to work with IPv6. Most DNS servers should support querying on IPv6 addresses at this point. Note that you do not need to query a DNS server on its IPv6 address to receive an IPv6 AAAA record back from the server. Most dual-stack clients will continue to query their DNS servers on their IPv4 addresses for the time being. However, enabling IPv6 on your DNS servers will allow other IPv6 enabled DNS servers to switch to v6 as their primary querying method. Additionally, if your nameservers exist within you own domain (E.G semaphore.net’s DNS servers at ns1.semaphore.net and ns2.semaphore.net) you will need to register an IPv6 Glue Record for your server with your DNS registrar. This allows the registrar to point IPv6 clients to the server’s address to bootstrap the resolution process. This should be done for all DNS servers once they become IPv6 enabled.
Phase 3 – Firewalls and DMZ Servers
If your website is served by a server on a DMZ for security reasons, this phase is for you! Firewalls provided by the large networks vendors (recent Cisco ASA firewalls, and Juniper Netscreen and SRX firewalls) support IPv6 in all recent code revisions. You will need to confirm support from whoever your existing vendor is, or evaluate replacing your firewall. (I’m a big fan of the Juniper SRX, personally.) Something else to consider is caveats for IPv6 deployment. If you are running active/passive stateful failover, there may be restrictions on IPv6. For example, older Cisco PIX firewalls support IPv6, but not in stateful failover mode. This is also the time to determine whether you will be doing NAT or not. Again, my recommendation is to drop NAT for IPv6. A modern flow/session based firewall can provide just as much security without requiring complex NAT/PAT rules for inbound traffic. If you are doing NAT, you will need to research the site-local scoped address space, the IPv6 equivalent of RFC1918 Private IPv4 address space.
Servers in your DMZ will need to be evaluated in the same way as your external servers in the above phase. If you aren’t doing NAT, then all that will be required is to allow inbound traffic for web, mail, etc to the server’s address and you’re done. No port-translations are required for the DMZ, which was the typical approach for a DMZ in the IPv4 world.
Phase 4 – Internal Network Infrastructure
This is the first phase that is truly optional at this point. As I mentioned above, all externally facing resources even in IPv4 constrained Asia will likely continue to respond on both IPv4 and IPv6 addresses for the foreseeable future. However, progress should be made towards eventually supporting a dual-stack architecture company-wide.
Much like the external infrastructure above, all internal layer-3 devices should be assessed for IPv6 support. Internal layer-2 only devices (access switches) need not be upgraded, although if you want the future capability to manage them via an IPv6 address, they too will need IPv6 support. If you were assigned a subnettable block from your ISP, address space planning should be done at this stage, matching your IPv4 internal subnetting scheme. Again, if NAT is in use, you will be using the site-local IPv6 address space for your internal networks.
If your network uses any site-to-site VPN via IPSec or other secured tunnels, this is also the time to evaluate if the tunnel endpoints support IPv6. Because IPSec is built in to the IPv6 protocol, most site-to-site VPN endpoints should support it fully. Configuration may be dramatically different than the equivalent IPv4 configuration.
Phase 5 – LAN Servers
Many LAN services simply do not support IPv6 at this point. However, some basic services most likely do and can be turned up immediately. Services such as internal DNS can be assigned IPv6 addresses which will allow them to query IPv6 DNS servers on the internet. Things such as internal web services, file servers and other basic LAN servers can slowly have dual-stack IPv6 addresses added over time. Corporate mail servers such as Exchange (2007 or later) support IPv6 and can have v6 addresses added, but make sure to read the vendor’s list of caveats for the particular software and OS version you are running prior to adding any IPv6 addresses to the server.
Phase 6 – LAN and VPN clients
As mentioned above, there is no reason to have IPv6 only clients at this point in time. This is a good thing, as IPv6 only clients have some major hurdles at this point. In particular, there is no widely supported way to pass DNS server configuration information to clients receiving and automatic IPv6 address. IPv6 address autoconfiguration is performed via one of three methods currently:
- Router Advertisement (Stateless autoconf) – This is the most common method for client autoconfiguration at this point in time. The router on the subnet periodically broadcasts its address and the address of the network. IPv6 clients listen for this broadcast and assign themselves an address and default gateway based on that information. There are extensions to allow for DNS configuration to be passed to the client as well, (RDNSS), but they are not widely supported at this time. For dual-stack hosts, this method works perfectly and seamlessly. When we implemented this on our network, our employees were happily surfing IPv6 websites without even realizing it was happening.
- DHCPv6 (Stateful autoconf) – This method requires a DHCPv6 server running on the network (either on the router, or elsewhere). Much like IPv4’s DHCP, DHCPv6 maintains a database of all address leases on the network. It can also pass along information such as DNS server addresses or other custom options to the clients. However, at this point, DHCPv6 CANNOT pass along a gateway IP address, making it of questionable value.
- Stateless DHCPv6 – This will mostly likely be where we end up once the dust settles. This method relies on the router advertisement/network discovery model to handle address and routing/gateway management. An “other configuration method” flag is set on the router, telling the client to broadcast for a DHCPv6 server once it has its address. The DHCPv6 server in this case hands off DNS information (and other other custom) fields to the client, but does not need to keep a database of addresses.
VPN clients will most likely be using the IPv6-specified IPSec protocol. You should check with your VPN concentrator/firewall vendor for support for IPv6. It will also be necessary to confirm that the VPN software being used by your clients supports IPv6 as well. We have not yet implemented client-based dynamic VPN for IPv6, so I can’t speak to how easy this process is to implement. If you’ve made it work, let us know!
This process can still seem daunting at first, although it is fairly straightforward if you handle it in small manageable chunks. Semaphore Received its /32 allocation from ARIN in 2003 and has been working with IPv6 even since. If you are a company in the Pacific Northwest Area and would like assistance with IPv6 adoption, please don’t hesitate to contact us! Our consulting engineers would be happy to help you with a readiness assessment and help you form a plan for full IPv6 adoption over time.
To contact us, please email email@example.com.