Wednesday (6 June 2018) is the sixth anniversary of ‘World IPv6 Launch’, and during this week APNIC is marking the occasion with a series of IPv6-themed posts on the APNIC Blog, including research, success stories, opinions, and more.
Migrating to IPv6 will make you ready for the next stage of the Internet. I was the principal network design engineer and member of the project team for deploying native IPv6 for all residential home users at Vodafone New Zealand two years ago. As an outcome of that project, IPv6 has been deployed for about 80% of residential home Internet users now.
I believe adopting IPv6 is inevitable, and as an international technology company, we were committed to providing our users with the latest technologies.
The graph below from APNIC Labs shows Vodafone’s IPv6 deployment rate and compares that with the rate of IPv6 adoption at the country level.
Figure 1: Vodafone’s IPv6 deployment rate compared to IPv6 adoption at country level. Source: APNIC Labs
Adopting IPv6 is just like learning a new language. It’s not a matter of removing a word and replacing it with another. There are new structures to be learned and different ways of doing things to be tried.
There are also changes to be made on mindsets of people who are directly using IPv6 or are engaged in delivering it. There are some concepts that are ingrained in IPv4 networks and are completely out of context in the IPv6 realm.
NATing, for example, is not a best practice in IPv6 networks. Every device will have a publicly routable IPv6 address. Fragmentation and reassembly and also Address Resolution Protocol (ARP) are other examples that do not apply to IPv6.
Once these differences are understood, replacing one protocol with the other is going to be much easier.
Migration Strategy
First, and maybe the most important step in deploying IPv6, is deciding on a migration strategy. There are multiple options that an ISP can choose based on their specific setup, number of users, IPv4 address space usage, and so forth. We decided to implement IPv6 in parallel to IPv4 in a dual-stack topology.
The next step for us was to decide how to allocate IPv6 addresses to end users. We needed to determine how big of a block would be allocated to each subscriber and how to break that down into individual /64 addresses to be used by internal devices.
Next, and another one of the most important steps, was a thorough testing of IPv6 with all the access technologies that we had for our subscribers. Here we faced multiple challenges that were specific to certain kinds of access setups.
And finally, the last step was deploying IPv6 in different network building blocks like international gateways, DNS, access and core platforms.
IPv6 and transparent caching
One specific lesson we learned during our IPv6 project is related to transparent caching.
Caching is being used by many service providers and even enterprises to provide a better experience for end users by caching the content closer to the user. Transparent caching is where this process is transparent from the users’ perspective. The user requests a piece content from the Internet and the content is served by caching platforms, but the source and destination addresses are spoofed, so the user receives the content with the source IP address of the content on the public Internet but doesn’t see cache involvement in delivering it.
Figure 2: Transparent caches can pose a problem for IPv6’s path MTU discovery.
This can cause issues when using IPv6 because, in an IPv6 world, source and destination of a packet stream should be reachable using ICMP, so that when a device cannot forward the IPv6 packet it notifies the sender to send smaller packets. But with packets now using spoofed addresses, the ICMP messages won’t be able to reach the right device; and as a result, it may break connections.
One workaround to the problem could be reducing the MTU of the minimum allowed by the IPv6 standard, which is 1280 bytes. But in our case, we decided to keep the dynamic path MTU discovery and instead, bypass the caching platforms for all IPv6.
My advice for you
When you first get started, try setting strategies on how to start allocating IPs. Without that, IPv6 allocations can soon lead to a messy situation, which would be very hard to manage.
Also, use IP address management platforms as far as you can. Managing IPv6 manually or using spreadsheets is not practical.
You will want to pay special attention to the DNS. With IPv6 in place, everything should have a DNS record. You can’t expect people to remember the IPv6 string.
Lastly, having ICMP allowed anywhere is very important. Otherwise, the path MTU discovery will not work, which leads to poor performance or even breaking the communication.
The best advice I can give you is to start deploying IPv6 right now. There’s no better time to start the process.
Do not buy equipment that doesn’t support IPv6. In 2018, every piece of equipment must have IPv6 support.
I recommend that you grow the IPv6 culture inside your organization by challenging everyone to know at least as much about IPv6 as they know about IPv4. Teach people fun ways to experiment with IPv6, and this will encourage them to keep using it.
Original post appeared on Team ARIN Blog.
Mansour Ganji is a Senior Network Engineer at Next Dimension Inc. Prior to that, he was a Senior Engineer, Principal Designer and Network Design Team Leader at Vodafone New Zealand.
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.
I’m confused by two things.
1st one is the use of migration. I guess you mean transition and coexistence, because you also mention dual-stack. Migration is wrong terminology for deploying IPv6, unless you totally disable IPv4 in the network. The IETF didn’t designed any migration protocols, only transition (and coexistence) ones.
Migration is when you move from Windows XP to Windows Vista. You completely remove the previous OS. Which is something you don’t want to do (at least not at this stage) for IPv6, because many end users devices still are only able to use IPv4.
The 2nd issue is that if you are deploying IPv6 in a residential network, then you must not talk about /64 addresses (by the way, /64 is not an address but a prefix). In fact, you should not talk about allocating addresses to end users, but about assigning prefixes, which always must be a big number of /64s (my recommendation is /48).
I suggest reading https://blog.apnic.net/2017/07/07/isps-simplifying-customer-ipv6-addressing-part-1/ and https://blog.apnic.net/2017/07/10/isps-simplifying-customer-ipv6-addressing-part-2/.
In a cellular network of course, it is a different issue, because you provide a /64 for each PDP context.
That’s hairsplitting. Transition/coexistence is part of the migration and yes we remove IPv4, first partially and then complete.
Your second issue is similar, sometimes it’s a question of the perspective.
Well, you do transition or you do migration, not both at the same time … And the article clearly mention dual-stack, so that’s not migration, it is transition.
Phase 1: old world, IPv4 only
Phase 2: dual-stack
Phase 3: new world, IPv6 only
You may call phase 2 transition.
But the result of the comparison of phase 1 and 3 is migration.
When you are training about IPv6 tens of thousands of people, you soon realize that not using the right wording means that you are confusing people, and in this specific case, you get questions as “so IPv6 is compatible with IPv4, so we just disable IPv4 …”, which is not the case.
The complete process is a transition. A migration will be going straight from IPv4-only to IPv6-only end-to-end. This is not the case, and if we teach people and write articles, it is much better to be precise so to avoid confusing other people.
That’s a good question. Who confuses the people?
You should teach them to disable IPv4 – at least the circumstances – were it is possible. (e.g. access with DNS64/NAT64, private networks, compute centers…)
I am still wondering about well informed people believing ipv4 would stay forever.
The goal is to disable ipv4 – at the end of the migration!
That must be clearly said. Otherwise the people think they should do their work all times twice(ipv4 and ipv6). Nobody likes double work.
Then you say it, is not a migration is a transition, at the end you have done a migration.
Transition is not the same as migration, they are two different words.
There is no IETF mechanism for migration.
Of course I tell the people that the goal is to get rid of IPv4, but this is only possible once you have no apps that use literals neither old APIs, etc. NAT64/DNS64 alone is not the right way. It breaks many things.
Suggested reading: https://datatracker.ietf.org/doc/draft-palet-v6ops-nat64-deployment/