Software Engineering Institute | Carnegie Mellon University

SEI Insights

SEI Blog

The Latest Research in Software Engineering and Cybersecurity

IPV6 Adoption: Is your ISP ready to support IPv6?

Posted on by in

By Joe Mayes
Network Security Engineer
CERT Division

If you're considering migrating to IPv6, you may be asking, Am I ready? That's a good question to ask, but you also have to ask, Is my ISP ready? If your Internet service provider (ISP) isn't ready for an IPv6 migration, you may have external web sites that won't load, problems receiving email, and many other issues. This post is the latest in a series examining issues, challenges, and best practices when transitioning from IPv4 to IPv6, whether at the enterprise level, the organizational level, or the home-user level. In this post, I present some points to help you know if your ISP can support your IPv6 ambitions.

As I outlined in my first blog post in this series, IPv6 deployment is on the rise. Google reported that as of July 14, 2018, 23.94 percent of users accessed its site via IPv6, up more than 6 percent from that same date in 2017. Drafted in 1998 and adopted as an Internet standard in July 2017, Internet Protocol 6 (IPv6) is intended to replace IPv4 in assigning devices on the Internet a unique identity, because IPv4's 4.3 billion addresses, aren't sufficient to cover the growing number of devices accessing the Internet.

Moving Forward with an IPv6 Transition Strategy

Once an organization commits to adopting IPv6, the next decision is determining where to start the conversion. I believe that starting at the ISP makes the most sense because ultimately the rest of your network is dependent on what the ISP supports, and the services you want from the ISP may have the longest lead times (simply because the ISP isn't under your control).

You must also decide how you want to perform your internal transition, and most people at least consider using a dual stack approach to make the transition.

Checklist Item #1: What is Dual Stack, and Should I Adopt It?

"Dual-stack" refers to supporting two different protocols on the same network. In this context, it refers to running IPv4 and IPv6 concurrently. Dual-stack solutions are often championed as a transition technology to move from IPv4 to IPv6, but I'm personally not in favor of dual-stack networking. I confess that one reason I prefer not to dual stack is because I tend to be a rip-the-bandage-off type of person: I think it's better to make a clean transition from old to new to shorten the transition period. The other reason I'm against dual-stack networking is that each protocol has its own configuration peculiarities and its own security issues, so running dual-stack networks creates new headaches, from failure troubleshooting to increased security risks.

If you're wondering whether an IPv6-only network can connect to the entire Internet without IPv4 addresses, remember that your smartphone is a great example of an IPv6 station on an IPv6 network that accesses IPv4 resources successfully with end users not seeing any difference. Consequently, my recommendations are based on the cutover transition model, including a proof-of-concept test, followed by a pilot, and finally a full cutover to IPv6, either all at once or by dividing your network up into a number of smaller migrations. In this transition, it's the ISP that would have two separate networks: your existing IPv4 connections that would support subnets still operating on IPv4, with new subnets operating on IPv6 being routed through the new IPv6 connectivity.

In this migration, servers would temporarily operate in a dual stack network environment, but the transition should be able to move quickly to an all-IPv6 environment. For a discussion of cutover options, see https://www.networkworld.com/article/3214388/lan-wan/how-to-plan-your-migration-to-ipv6.html and https://www.theregister.co.uk/2018/06/28/lw4o6_dump_parallel_ipv6/. The recommendations I've listed below are applicable to both cutover and dual-stack IPv6 migrations. However, some issues I've identified may be unique to a total cutover IPv6 migration. The ultimate goal of these recommendations is to limit the pain resulting from overlooked transition issues, and the questions and answers listed below should help you discover and resolve most of these migration issues.

Checklist Item #2: ISP support for IPv6
The most obvious ISP question is, Does my ISP support IPv6 traffic? But a successful migration to IPv6 requires much more than the ability to pass IPv6 traffic to the Internet, especially if you are migrating a larger enterprise environment. And it doesn't end there. Other relevant questions include:

Checklist Item #3: IPv6 Edge Security

What should you expect from your ISP regarding IPv6 edge security? If your ISP supports all IPv6 functionality, it also needs to support the same security measures provided to IPv4 customers. This should include, at a minimum, malicious source address filtering (which for IPv6 would mean blocking of the following:

  • most multicasts (permitting only what's necessary for functioning of the connection between the ISP edge and your organization)
  • unique local and link-local source addresses (which aren't globally routable and should never be a valid source IPv6 address)
  • your assigned organizational global unicast addresses (which should also never valid as an external source address)
  • other malicious addresses as mutually identified

Malicious traffic monitoring, likewise, should be looking for and blocking

  • DoS and DDoS traffic
  • malformed packets (half-open TCP sessions, echo replies without matching existing echo requests, etc.)
  • ping sweeps, port scans, and other reconnaissance traffic
  • other malicious traffic as mutually identified

What's your organizational responsibility regarding IPv6 edge security?

The short answer is that you should provide IPv6 security measures similar to the IPv4 measures that should already be functioning in your Ipv4 network, including, Do you have the appropriate devices to act as firewalls, IDS/IPS units, proxies, filters and/or other security systems? If not, you run the risk of lowering your security posture in the transition, which should not be allowed to occur.

Are you filtering outbound traffic to ensure that only authorized internal IP addresses are leaving your network? Doing this keeps your network from unintentionally generating spoofed IP traffic to the Internet.

  • Do you have all appropriate safeguards and alerting mechanisms configured to provide security at, or above, the levels provided in your IPv4 environment?
  • Do you have proper support for roaming laptops and VPN connections? Even if your infrastructure is all IPv6, can you support IPv4 tunnel connections from remote locations? Can you pass appropriate IPv6 addresses into your VPN tunnels for client addressing? Have you updated security to inspect all IPv6 traffic coming through your VPNs?

Wrapping Up and Looking Ahead

The points I've outlined above should cover most issues regarding ISP support for your migration to IPv6. In my next blog post in this series, I will emphasize what it means to make the change to IPv6 within your network boundaries. In a fourth installment, I will address IPv6 and security issues.

Additional Resources
Read other posts in our ongoing series on IPv6 adoption.

About the Author

Comments

Policy

We welcome comments with a wide range of opinions and views. To keep the conversation focused on topic, we reserve the right to moderate comments.

Add a Comment

Comments*


Type the characters you see in the picture above.