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:

• Can the ISP support IPv6 routing protocols you want to use? Some protocols support IPv6 by default, some protocols require IPv6 services to be enabled, and some IPv4 routing protocols (such as RIP and OSPF) must be upgraded or replaced by IPv6-capable versions. (To be compatible with the ISP's devices, your own devices may also need software upgrades or even new hardware.) See https://en.wikibooks.org/wiki/Routing_protocols_and_architectures/IPv6_routing#IS-IS.
• Does your ISP translate IPv4-only resources into IPv6 for you? If not, you may have to support that translation yourself or risk not seeing IPv4-only Internet services. If your ISP can provide DNS64 and NAT64 services, that is the easiest path (because you are purchasing legacy IPv4 support as a service). See https://community.infoblox.com/t5/IPv6-CoE-Blog/On-The-Road-to-IPv6-Only-From-Dual-Stack-to-DNS64-NAT64-and/ba-p/13192.
• Can you use your ISP for IPv6 DNS resolution? Does the ISP support static IPv6 (AAAA, MX, SPF, PTR and other) records for your Internet-facing Internet services? See https://labs.ripe.net/Members/gih/ipv6-and-the-dns and https://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6.
• How many IP addresses will you need to support your organization? (Remember, IPv6 does not generally support NAT solutions.) Small environments may use DHCP-PD (with prefix delegation) to use dynamically-assigned IPv6 addresses, which are appropriate for home users and small-to-medium businesses. See https://en.wikipedia.org/wiki/Prefix_delegation.
  
  Larger environments will be assigned a block of global unicast addresses, but due to the design of IPv6, this isn't as simple as it sounds. IPv6 addresses are organized globally, so a global unicast address will have an identified region of the Earth, as well as the providing top-tier ISP, indicated by the address. This can complicate multi-site and/or multinational IPv6 addressing because the actual location of a connection may be routed to some remote region before coming back to the client computer. You can expect additional complexity if you have multiple Internet connections in different countries or regions, because decisions may need to be made on whether to use one address space globally or to assigned address spaces based on the regional Internet connections and the related routing. The solution may be a provider-independent address space, which requires autonomous system number (ASN) assignment (among other steps). See https://community.infoblox.com/t5/IPv6-CoE-Blog/The-headache-of-IPv6-readdressing-and-the-potential-for-ULA/ba-p/6279.
• What changes have to be made to BGP routing to support IPv6? If your organization has multiple ISPs and/or multiple Internet connections, you must ensure that your ISPs can properly configure BGP to use the shortest or best paths to the different networks on which you have points of presence (POPs). This may also impact decisions of provider-assigned versus provider-independent address allocations. Some security measures will also require the proper setup of reverse path forwarding (RPF).
  
  Finally, since IPv6 addresses are four times longer than IPv4 addresses, some routers may experience capacity issues due to the larger routing tables caused by the longer addresses and, potentially, a larger number of address entries. The issue concerns ternery content addressable memory (TCAM) starvation, which wasn't evident when using IPv4 addresses. See https://etherealmind.com/tcam-detail-review/.
  
  
• Does your ISP support redundant router failover (HSRP, VRRP, FHRP, BGP4, etc.) in IPv6? Most large organizations see single ISP-facing routers as a single point of failure and, therefore, employ various redundancy protocols and multiple edge routers for failover in the event of hardware or service failures at the edge. Check to ensure the failover protocol in use supports and is configured for failover when running IPv6. See https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2s/ipv6-15-2s-book/ip6-fhrp.html and https://www.juniper.net/documentation/en_US/junos/topics/example/vrrp-for-ipv6-example-config.html.
• If my organization uses MPLS will I have to do anything different when converting to IPv6?
  Organizations using multiprotocol label switching (MPLS) have a special challenge in converting to IPv6, because MPLS was closely integrated with IPv4. New standards have been developed to support IPv6 management of MPLS, but these new standards are not widely adopted, and support for MPLS using IPv6 will be variable, depending on the providers available to the organization. See https://tools.ietf.org/html/rfc7439.

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.