From IPv4-Only to Dual-stack to IPv6-Only: What Tech Will You Need For Each Stage of Your IPv6 Migration?
IPv6 adoption will progress in stages, from the IPv4-only network to a dual-stack one and finally to an IPv6-only network. There are unique operational challenges when running an IPv6-only network as compared to say a dual-stack or IPv4-only network. Knowing where you are at on the curve of IPv6 adoption is important as it determines what technologies you need to have in place for each stage. Over the next few blog articles we will cover what technologies you will need to be familiar with at each stage of your adoption process. Each of the decisions you make may impact your design in a different way and, where appropriate, we’ll take a moment to discuss these decision points in more detail.
The IPv6 adoption and planning process is not an easy journey and can be complicated by many things such as:
- A lack of management buy in (no senior leadership to drive the adoption across the many teams impacted)
- Poor understanding of the impact of the technology change (who or what is being impacted)
- Missing fundamental skills around IPv6 (education, training and career development)
- No planning, or the mistake of assuming it is a network team problem
- Other political, technical, and financial reasons [layer 8 of the OSI model! –ed.]
Once the decision to adopt IPv6 has been made however, one of the early questions a team will get is what additional technologies and changes will need to happen in order to support IPv6. Often this also comes with a request for budgetary numbers and other associated costs.
Let’s examine each phase and see if we can give you a head start on being able to answer some of these questions. (You might be able, with help from some of the information that follows, to put a tentative budget together too.)
This is where everyone begins. However, when considering IPv6 there may be a decision made that says IPv6 will never be adopted (or it will be put off indefinitely). While I consider this a huge mistake (and could be a financial burden due to having to continually purchase IPv4 addresses on the open market), I understand that it does happen for a variety of reasons. But there are still things a company MUST do and specific technologies they SHOULD adopt around IPv6 even in an IPv4-only deployment. This might seem odd. Why in the world would you need to adopt anything IPv6-related if you are running an IPv4-only network? First, let’s establish some well-known facts about IPv6 so we all start with the same basic knowledge and assumptions.
- Every major OS that is in use today is set up by default for dual-stack (in other words, IPv6 is on by default)
- Every major OS will prefer IPv6 if it is available
- All that is required to get IPv6 operational for all hosts on a given Ethernet layer 2 segment is a router advertisement (RA)
- Your existing IPv4-only network devices will not know anything about this happening
- It is possible to tunnel IPv6 traffic over IPv4
Now that we have this basic understanding there are many things you will want to put in place for an IPv4-only network to protect it and optimize it in regards to IPv6.
- Put in place First Hop Security (FHS) measures for IPv6 to ensure a misconfiguration or bad actor cannot put their own RA on the Ethernet Layer 2 segment
- Have inspection systems in place looking for IPv6 traffic and monitoring that traffic
- Proactively set up link-local network addresses on major network equipment to help identify equipment in your monitoring system
- Specifically put in blocking ACLs and firewall rules in place for IPv6
- Block ICMPv6 traffic in addition to IPv6 traffic
- Inspect IPv4 traffic for IPv6 tunneled traffic (IPv4 protocol 41, 6to4, ISATAP, Teredo)
- Modify your DDI platform to respond with IPv4-only values for DNS and DHCP
- For active directory joined Windows hosts use GPOs to turn off IPv6 on all appropriate hosts (client or servers)
- Remove IPv6 from all Linux system kernels
- For guest wireless/wired networks put in specific segmentation to prevent peer to peer IPv6 traffic
As you can see, the list is not short. These are the minimum protective measures you should take to ensure you are running a proper IPv4-only network. You’ll need to run a lot of IPv6 enabled functions to make sure you do not have any IPv6 running on your network that is able to “get out” to external networks or the Internet. But realize that these measures still do not prevent IPv6 from appearing on your network. No matter how much you do, IPv6 will always be running because you will have some guest OS, printer or other IoT device that will attempt to use IPv6. At a minimum you will see link-local IPv6 traffic on some Layer 2 Ethernet segments. Your concern should be if you see global unicast or unique local addresses being used. If so, your IPv4-only network is no longer an IPv4-only network and you are operating some sort of dual-stack network. Congratulations, you made an unplanned move to IPv6!
The specific technologies you will leverage in an IPv4-only network will mainly be around IDS/IPS, firewalling and security. You want to be able to identify when IPv6 is present and block it proactively. In addition, you want to prevent someone from running IPv6 on the network to “take over” your hosts and get them to route through an unsanctioned device. This would be the case where someone sets up a rogue IPv6 router and starts sending out RAs on a given network segment. It is very similar to a rogue DHCP server providing IPv4 addresses on a network segment so that it can send traffic to a new default gateway or proxy. You can utilize FHS measures from some manufacturers. For others you will have to create your own ACLs to protect your network Ethernet segments. You will want logging and alerting enabled for these situations so you know when a device is attempting to send an RA.
For those running Windows Server in routing mode (RRAS) realize that the server will automatically send out RAs. The only way to disable that behavior is to turn of the RRAS function. This may not be possible in some situations and therefore the RA will need to be blocked on the switch or router to prevent other hosts on that Ethernet segment from seeing those RAs. In virtual environments you need to check if your virtual switch supports RA blocking.
Identifying all critical network traffic leaving your environment is typically done by a proxy, content filter, or firewall platform. This product should have robust IPv6 support with the ability to inspect multiple tunnel layers to determine if IPv6 is being used. In addition, they should be configured to deny any native IPv6 traffic. It’s important for alerts to be generated when IPv6 traffic that contains global unicast, unique local or other non-link-local address types is detected. There may be times that specific filters will have to be put in place to prevent or suppress the alerting depending on what network segments you are watching. For instance, the guest wireless may have hosts attempting to use tunneling or VPN and have IPv6 encapsulated in IPv4. This would be normal for Windows hosts using DirectAccess.
That covers the IPv4-only stage of the eventual migration to IPv6-only as well as the technologies and measures you will have to put in place to account for IPv6. In the next article we will be covering dual-stack and what IPv6 technologies you will have to adopt to ensure your network is running at its best.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!