Last month, LinkedIn announced that it had reached a major milestone in its transition from IPv4 to IPv6, with more than 50% of LinkedIn pages accessed over IPv6 via mobile devices in the US.
Read it and weep, IPv4: https://t.co/tig4lRFU0p #IPv6
— LinkedIn Engineering (@LinkedInEng) July 26, 2017
As we have previously reported, LinkedIn has been taking a gradual approach towards its IPv6-only end goal in 2018.
“We wanted to go v6-only but we wanted to be realistic with our developers to make sure they were comfortable with the protocol. So, we said we’d dual-stack our data centres over 2015–17. By 2018 we’ll turn off v4 in our data centres because we don’t want to be supporting two stacks.”
– Zaid Ali Kahn, Senior Director of Infrastructure Engineering at LinkedIn.
At APNIC, we have been taking a similarly cautious approach towards becoming an IPv6-only organization. We have been implementing the traditional NAT-PT on LAN using dual-stack alongside an IPv6-only office Wi-Fi network so that we can test the experience.
This post will discuss the successes and the challenges we, the APNIC technical team, have experienced in these two set-ups and hopefully provide some practical strategies to consider during your transition to IPv6.
Dual-stack NAT-PT
APNIC has been running a dual-stack network using public IPv4 and IPv6 addresses for many years. So, this part of the project was to change these public addresses to private address space, and still maintain all dual-stack functionality.
The diagram shows the logical view of the network layout.
The complications of this set-up were two-fold:
- NAT needed to be done at Site 1, where the clients reside, but the Site 1 routers are not the gateways to the upstreams (which is where NAT is usually implemented).
- No NAT was to be done within the organization, thus no translation was to be done between the three sites.
To resolve these problems, we used an access list, a route map and a prefix list configuration. The access list was used to filter out all the internal addresses used between the sites so that they are not affected by NAT. The route map was used to match the access list to the NAT address pool. Finally, the prefix list was used along with OSPF to route the NAT pool to the gateway routers.
This means if an internal service is requested from Site 2 or 3 now, then no translation is performed, but if a service from a server outside the organization is requested, then Site 1 handles the request and routes it to the gateway.
Yeah, success!
As with any transitioning, there were a few teething problems, including some users reporting reconnections at approximately two-minute intervals towards external sites when SSH was used. This issue was only to some and not all external servers. It turned out this was due to asymmetric routing, since Site 1 has redundant routers. Further investigation is needed to find the root cause.
Apart from these minor challenges, the transition has been smooth using NAT-PT.
IPv6-only Wi-Fi
We launched our IPv6-only office Wi-Fi on World IPv6 Day this year. The architecture is the same as shown in the diagram above but also uses DNS64/NAT64. We kept it simple and the DNS64 server was set up to use Bind9; with clients getting their addressing via SLAAC and stateless DHCPv6.
The IPv6-only Wi-Fi has been tested using a variety of devices. Laptops, ranging from MacOS Yosemite Sierra machines, Windows 7 and 10 machines, to a mix of Linux distributions and kernel versions, have all worked well for us using this set-up.
In the mobile space, the set-up is dependent on the type of mobile devices. As we cannot test every single type of mobile device ever created, when it came down to the actual users, we found that some mobiles had no problems and could connect and browse, while others did not connect to the network (these devices would display the error ‘Obtaining IP Address’ and then time out). We initially thought that the mobile devices with this error were incapable of working on an IPv6-only network, but a quick Google search dismissed this theory.
So, the next logical train of thought was to check the device’s versions. To do this, we picked two Android devices with the same version but different manufacturers and tested them again. Strangely, device 1 picked up the IP address and could browse, but device 2 continued to display the same error message.
As it was unlikely to check with all mobile manufacturers, the next step was to change the configuration of the router. So, after some research, we enabled RDNSS defined in RFC6106 on the router. In this set-up, both devices could obtain an IP address and connect to the Internet.
Yeah, success!
Apart from the mobile drama, the IPv6-only network has been working well, and we are able to connect to IPv4-only networks with hardly any noticeable differences in performance between the dual-stack and IPv6-only set-ups.
Things to watch out for when connecting to different types of servers
- Even though a server may have an IPv6 address, ensure that its services are listening on IPv6.
- We currently have not got Spotify, Skype and Zoom working yet. There are some articles that have pointed to some problems with these applications and IPv6. For example:
– Spotify over NAT64
– Desktop client IPv6 support
– Oh IPv6, Where Art Thou
– Add IPv6 support to Skype
- As detailed in Happy Eyeballs Version 2, browser clients need to fall back to looking up the A record and using that on AAAA/ipv6 connection failure. Happy Eyeballs is designed to help IPv6 networks become more reachable by attempting to connect using both IPv4 and IPv6 at the same time. This happens when a service has an AAAA DNS record but is not listening on this address and the clients do not fall back to IPv4. This is not happening with some of our services and we are in the process of auditing our IPv6 servers to see how many servers are affected by this issue.
So, what does it all mean
Although it appears we have had more challenges than successes with setting up IPv6-only compared with NAT, it doesn’t mean IPv6-only should be put in the ‘too hard’ basket.
The set-up of IPv6-only is much simpler, requires no special fixes with route maps or prefix lists, and the more that people use IPv6-only, the more vendors will be forced to produce more IPv6-only compatible devices and services.
We are keen to have it working just as well as our dual-stack network, and will keep you updated on the findings. In the meantime, leave a comment if you have some insights on our process or would like to share your own successes and challenges with deploying IPv6.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Please I need your paper to demonstrate some issues during IPv6 Transitions