Migration from IPv4 to IPv6 strategies

Question

As everyone is aware we are out of IPv4 addresses and soon (if not already) we shall be moving on to IPv6. What are some good strategies and practices to migrate a complete IPv4 network onto IPv6?

Answer 1

I don't have a full strategy, but here's the rough way I did it at $JOB[-1]:

1. Get an IPv6 block, either from your existing carrier, or an RIR
2. You might also want to mark a fc00::/7 (Unique local) block for fully internal subnets if you have an ISP block and may ever need to renumber
3. Decide on your v6 IGP, IS-IS is still a safer option than OSPFv3, but much kit won't do IS-IS
4. Bring up v6 on your core kit, from internet edge through to DC core switches
5. Bring up v6 transit, if you have to a BGP tunnel from he.net can work while waiting for ISP's stuck in the last decade (remember to enable v6 on your iBGP mesh if you have one)
6. Create v6 infrastructure services, mostly DNS, v4 accessible is fine here
7. Enable v6 on a single server net (you'd probably have a default deny firewall here)
8. Test the v6 connectivity to the world, will it break things?
9. Turn up v6 on a second server net for redundency
10. Bring up a DHCPv6 server if you want to use it
11. Bring up v6 on a single access network (IT staff is a good choice here)
12. Test. Ensure nothing breaks
13. Bring up v6 on remaining server networks
14. Add a v6 namesever for your domains, and a v6 DNS entry for an MX (one, or all but one are good choices for what to dual-stack)

Now, when bringing up new services or upgrading them you can test if they work on v6, and add the appropriate DNS records (almost all web services will "just work"), eventually you might start looking for services remaining on v4 and fix them, but there's no hurry for that.

Answer 2

I think it's important to separate two different goals here:

• Dealing with IPv6 enablement. The main issues with this goal usually has to do with equipment in your network not supporting IPv6, and you have to use some kind of tunneling/transport solution to bypass those elements. 6rd and 6PE are very popular.
• On the other side there are strategies to face IPv4 address depletion. The only way to solve this issue is implementing some kind of NAT (carrier grade NAT, DSLite, NAT64...)

Some technologies solve the first issue, some solve the second one, and some solve both of them.

Everything is evolving very quickly and you have to watch out for new solutions arising. For example. One solution that is taking a lot of attention lately is MAP-E and MAP-T, which are currently in draft status (MAP-E is close to becoming RFC) and allow you to implement IPv6 and solve IPv4 address exhaustion in a very smart way. You can get more information at https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-06

To get more detailed information, I'd need to know the context and the requirements. I mean, solutions depend on the kind of network (a Service Provider is very different to a content provider or a small business network) and the goal you're trying to achieve.

Kind regards,

Diego Nuevo

Answer 3

IPv6 migration at a high level?

1. Enable IPv6 throughout the network, until IPv6 capabilities and connectivity are on par with IPv4.
2. Wait for the day to come when IPv4 is no longer relevant.

Now for the low-level:

Get a prefix (ideally from an RIR) and get it announced, I'd recommend OSPFv3 for your IGP unless you happen to be running a large flat network that you feel IS-IS is better suited to. If you have legacy equipment that is IPv4 only, consider getting around that by doing 6in4 or GRE tunnels across the equipment.

Have a plan for address management, IPv6 space is not precious, if you have a /32 and you think customers will be wanting something larger than a /64, route sufficient space up to your equipment; if a single router or router pair serves 100 customers and each one gets a /56, your IGP should not contain each /56 - allocate a /48 for that router (pair) and you're done. The IPv6 space is so huge that subnet fragmentation should never be necessary if you're doing it right.

Make sure that all of the services you run are dual-stacked, be that DNS, e-mail, whatever - in the majority of cases it's as simple as ensuring the service is configured to listen on v6 and your DNS has an AAAA record. If you provide hosting services, servers etc, be proactive about informing people they can dual-stack their offerings.

Start getting familiar with technologies that will prevent disaster when you have no IPv4 space and cannot get any more of it either - keep a finger on the pulse of things like NAT64 and 464XLAT so that when the time comes, you can determine the viability of having IPv6 only hosts vs. using RFC6598 space and NAT44(4). Setup a lab, experiment.

Then? Wait for Encourage the IPv4 wind-down.

Answer 4

While IPv4 addresses are no longer being given out like candy that doesn't mean it's nessacery or practical to get rid of IPv4 completely in the near future.

Turning up ipv6 is a good first step https://networkengineering.stackexchange.com/a/261/20201 does a good job of covering that. This lets you interact with v6 only devices on the internet, it reduces the load on your NATs and therefore reduces the number of external IPs/Ports needed to serve those NATs. With big services like google and facebook supporting IPv6 it is likely a significant proportion of internet traffic will move over (i've seen figures as high as 70% ).

The next question you need to ask yourself is whether your organisation is big enough to be at risk of running out of private IPv4. For the vast majority of organsiations the answer will be no.

Assuming the answer is no I see little reason to remove private IPv4 from existing deployments in the near future. Getting rid of private IPv4 may simplify administration a bit in the long term but in the short term it's going to bring a lot of extra breakage for little gain.

If you are running out of public v4 the next step would be to audit your public v4 usage. Look for wasted public v4 addresses that could be freed up by changing subnetting. Look for systems that could migrate from public ipv4 to ipv6 or private ipv4. Consider schemes like load balancers and DNAT which can apply a small pool of public V4 addresses to precisely where they are needed and in some cases share a public v4 address among multiple services.

Consider deploying a NAT64/DNS64 gateway so that new systems can be made v6 only and still have access to resources on the ipv4 internet.