Since the release of IPv6 back in 2012 we have seen countless organizations and ISPs begin implementation of this new protocol. Unfortunately, in recent years we have seen a reduction in the rate of adoption amongst these ISPs, organizations, and other carriers. Google has a useful webpage available showing IPv6 statistics since before 2012 until present day. While adoption rates continue to grow, organizations tend to hold-off or not fully deploy IPv6 as it doesn’t affect the ability to browse the internet or access services. This is because our current methodology for deployment uses ‘Dual Stack’ which leverages IPv4 and IPv6 together. While it’s certainly possible to have something accessible only over V4/V6, IPv4 is still the preference as it is what everyone has access to.
Table Of Content
There are some key considerations before you go all-out and deploy IPv6 across your network. If you’re looking to implement IPv6 across your entire network, the key devices which would require IPv6 connectivity to facilitate this type of connectivity include your routers, firewalls, switches, and access points. This is of course in-addition to also receiving an IPv6 allotment from your ISP. These could be some of the many factors which would prevent an organization from adopting IPv6. Nothing stops you from internally implementing IPv6, though you likely are not running out of IPv4 space internally.
Understandably, IPv6 is considered a learning curve even for those familiar with IPv4 networks and subnetting. This is because it does not follow suit with IPv4. IPv4 has a much smaller address size with only 32-bits providing a global address range of 0.0.0.0 to 255.255.255.255. With IPv6 this address size is 128-bits and includes numbers 0-9 and letters A-F. This essentially gives you a global address range of 0000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
When you are assigned an IPv6 range from your ISP, your typical assignment is between a /48 and /64. You will want to confirm with your ISP to see what size they permit you to utilize on their network. In the event of a corporate network, this would typically be a static assignment whilst on residential or lower-end business networks it may be dynamic (DHCPv6). There are smaller subnets than a /64, though these are not typical under the IETF definition. IPv6 subnets range from a /0 to a /128.
Benefits of Deploying IPv6
IPv6 has a number of benefits, though the deployment can take time which can often times cause it to be very low on a ‘to-do’ list. With IPv6, you no longer have to use NAT (Network Address Translation) which in-turn means less that your router/gateway has to handle through policies. Modern routers likely don’t have this problem, and if you have something older – you may not even have IPv6 support. Your routing can also be improved over IPv6, depending on a multitude of factors. You’ll often find side-by-side that IPv6 is using fewer hops, and while marginal this can reduce overall RTT (round trip time). Some services utilize separate servers for IPv6 as well, meaning that you could in-theory be getting a less congested route/server to connect to at the destination. While all of these are not guaranteed, what is guaranteed is that IPv6 isn’t going away. We likely won’t see V6 only services anytime soon, but there shouldn’t be a reason to wait until it’s forced upon us to start adapting to that change.
At my workplace, I was assigned a ::/48 from our ISP. This far exceeds what we need internally, but allows us while we are deploying ‘Dual Stack’ to align networks accordingly. Let’s say we have 10.20.0.0/16 as our IPv4 subnet, and we were given fc00:1234:5678::/48 (private address range for this demonstration) as our IPv6 subnet, we’d be able to use the next octet to match our internal IPv4 subnet to keep things orderly. This means for that same 10.20.0.0/16 network, we’d be able to use fc00:1234:5678:20::/64.
In some instances, people will go a step further and utilize NAT64 and/or NAT48. Some cellular providers such as T-Mobile use 464XLAT which allows them to run IPv6 only on their cellular networks, and translate all requests bound for IPv4 only hosts over this protocol. This greatly reduces the number of IPv4 addresses needed for any given site, and allows them to ‘combine’ them using NAT pools by site, location, or some other factor. Many ISPs have started enabling IPv6 on their equipment by default (with an IPv4 allocation) for dual-stack connectivity as well. Not all providers do this, but some of the major players (AT&T, Comcast, and Cox Communications) will do this.
Local IPv6 Addresses
With IPv6, the concept of ‘NAT’ using a local address in the RFC 1918 ranges (192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8) as is typical with IPv4 is not used. Because of the extensive number of addresses offered with a ::/64 or larger allocation such as the ::/48 I have, there’s no need to use NAT. This means the IP Address given to your client would typically be a ::/64 from the allocation. If you only have a single ::/64 allocation, you may have to share addresses between networks or deviate from a ::/64 to something smaller. IPv6 has block sizes up to ::/128 available.
As long as your firewall is properly configured, which is discussed in further detail later in this article, these IPs will not be able to host services publicly without an additional firewall rule permitting it. Without a firewall, you would potentially be placing your clients directly on your WAN connection relying instead on device firewalls to block connections, which is typically not recommended in a business or enterprise environment. You may consider using NAT in these circumstances, though you will want to use this as a last resort. Please note, when referring to ‘NAT’ this is different to NAT46, NAT64, and 464XLAT.
When mapping out networks, especially for those with smaller ::/64 allocations, having an understanding of the IPv6 addressing will significantly help. As previously mentioned, IPv6 allows 0-9 and a-f in the addresses, unlike IPv4. Using publicly available calculators, you should be able to split your ::/64 into multiple smaller networks if necessary. You won’t have the ability to have nice short addresses, but you will have plenty of addresses to work with.
What’s the difference between Dual Stack, NAT46, and NAT64?
Dual Stack is when you provide both native IPv4 and IPv6 to a client on a given network. This means having both an V4 and V6 IP Address, and in some instances, can also mean using different gateways to provide these addresses, which can add some level of redundancy while you initially deploy IPv6 and are making changes without affecting the rest of the network. Dual Stack is currently the most common deployment of IPv6 for home environments, though for business use it tends to vary.
NAT46 is a way to provide IPv6 access using IPv4 only addresses and translating them, typically at the router or gateway. This is particularly useful when you have clients unable to obtain IPv6 addresses, and are running out of IPv4 addresses. This is not a concern for the foreseeable future, especially with the private address range of 10.0.0.0/8 available, but as IoT and other internet connected devices continue to be developed and added to networks, could create this need in very select use-cases.
NAT64 is the opposite of NAT46 where it provides translation from IPv6 to IPv4. This is typical during the transitional process from an IPv4-only network over to an IPv6-only network. Unlike dual-stack, clients are not assigned an IPv4 address and instead use a translation address (on IPv4) to talk to IPv6 hosts. Both NAT46 and NAT64 are fairly commonly used in businesses environments. Another variant, 464XLAT is commonly used by carriers such as T-Mobile to build an IPv6 only network which has IPv4 support.
Enabling IPv6
IPv6 requires that network components ‘support’ this capability, in some way or another. Typically this would require that your firewall, router, switches, and access points all support IPv6. With any recent hardware, this should be relatively easy though configuration values will vary from vendor to vendor. Possibly the most important step is ensuring that your ISP supports IPv6. If you use a business or enterprise grade connection, you may need to reach out to inquire about your assigned IPv6 address. In some instances, this may be handled dynamically through DHCPv6.
During my deployment, I opted to first enable IPv6 on my WAN interface and then on my Management and Server VLANs. With IPv6 enabled on the firewall/router and the other two VLANs, I could now assign an IPv6 address on my DNS servers to locally serve DNS requests versus having to use public DNS resolvers for IPv6. This subsequently also allowed me to test the connection and ensure it was working. With my ::/48 allocation, I split each subsequent network into a ::/64. Since our network topology lined up with VLAN 20 being 10.20.0.0, we decided to use 20::/64 to line things up since we were going for dual stack.
My next step was to enable IPv6 on a test network where I could ensure that IPv6 connectivity worked across VLANs and over both protocols. Once I validated that, I pushed it out to our Staff networks to see if any problems would be encountered. At this point, things were working out fairly well and I opted to enable it across almost every network internally, except a few networks which only had a few devices on them. Most clients received an IP within a minute or two at most, though some devices did require a restart to properly obtain an IP address.
Getting around providers which do not offer IPv6
There are still a fair number of providers globally which do not support IPv6. In these circumstances, your choices are to either switch to a provider which offers IPv6 or revert to using an IPv6 Tunnel Broker. With an IPv6 Tunnel Broker such as Hurricane Electric (HE), you are essentially creating a VPN tunnel to the provider which you can then use to bring up an IPv6 tunnel. This tunnel is assigned an IPv6 range which you can then assign to clients, servers, etc. While this does technically still use IPv4 to send your data to HE, you are getting IPv6 in a way. This is primarily meant for lab environments, I’m not sure if I would use it in a business/corporate setting. Configurations may vary by tunnel broker as my experience is limited to HE.
Firewall Policies
One of the biggest mistakes made by those implementing IPv6 for their organization is lack of firewall policies. Whether it’s a simple oversight or something intended for ‘down the road’ you will want to ensure these rules are setup and regularly test them. Many firewall vendors support policies with IPv4 and IPv6 hosts in the same rule which can prevent you from having to manage separate V4/V6 policies. Either way, ensuring you have these policies in-place will significantly increase your network security.
For my setup, I have a Fortigate 201F firewall setup with a /28 IPv4 allocation and a ::/48 IPv6 allocation. Depending on the specific firewall policy, I am able to define an interface or both IPv4 and IPv6 networks as long as the source/destinations include both as well (or all). This allows me to essentially have rules that process the traffic identically, which is useful on dual stack networks where you may still want restrictions between networks.
Considerations
Often times when people configure IPv6, they will treat firewall policies in a completely different manner, which can cause problems. Ideally, you want to try and merge your IPv4/IPv6 policies together if your firewall supports it. Without this, you will have to update two policies potentially whenever you wish to make a change to a policy affecting IPv4 and IPv6. This could potentially create a security vulnerability and reportedly has been the cause of prior ransomware/cyber attacks.
You will occasionally find devices which do not support IPv6 at all. This is typically limited to older devices, though some IoT/Smart devices still lack this functionality. For these types of networks, I advise using dual stack and/or IPv4 only for the best possible experience. If all of your IoT/Smart devices support IPv6 including the devices which need access, you may consider using IPv6-only for access to these types of devices.
VPNs and other remote access gateways will also need a functional IPv6 address to work over IPv6. It is common for a firewall to also have built-in VPN option(s) available, which may not natively use the WAN IP Address for a VPN. Like with IPv4, you can assign (through NAT) a single address or range to use for VPN connectivity if you wish to not use the WAN IP Address. This functionality is available provided your firewall/router supports NAT for both protocols. Not every device has these capabilities.
No Comment! Be the first one.