IPv6 Deployment Series Part 2: Routing Design

RYAN HARRIS | Sr. Network Engineer 

This blog post is part of a series detailing the various parts of planning and deploying IPv6 for enterprise networks. It is meant as a primer for the network engineer or architect to understand the various concepts they may be unaware of when developing their IPv6 production design. 

If you have not read the previous posts, I highly recommend starting with Part 1 – Hierarchical Subnetting Design. 

Determining which Routing Protocol 

It is tempting to use the same routing protocol that your organization is using in your IPv4 deployment in IPv6. After all, that decision was made for a reason. Your team has experience configuring and troubleshooting that protocol, and it is supported by the platforms that you currently run. 

This thinking might be slightly flawed, though. Implementing IPv6 in a dual-stack environment while en route to an IPv6-only environment presents challenges, but also opportunities to simplify and improve your network architecture. 

Our goal with choosing an IPv6 routing protocol should be to simplify the network architecture, provide compatibility across the network and across vendors, and provide flexibility for future changes in network architecture. In most cases, I believe that OSPFv3 provides the best scenario for organizations as an interior gateway protocol, but your specific scenario should be evaluated to determine what is best for you. 

There are two schools of thought when determining how to migrate from IPv4 routing protocols to IPv6; the first is to migrate both protocols to a single compatible routing instance to reduce troubleshooting surface area and resource utilization. The other school of thought is that by retaining your existing routing protocol for IPv4 only and implementing a second IPv6 only routing protocol, it removes the need to migrate your IPv4 environment and makes the decommissioning of the IPv4 environment easier in the future. 

I do believe that both are valid; however, since the goal should be IPv6 only, the argument for spending a lot of time and effort to migrate IPv4 routing protocols does not hold a lot of water.  

Static Routing 

As great as dynamic routing protocols are, static routing is such a powerful tool it needs to be discussed here. From the ability to override dynamic routing decisions, to providing a way to redistribute routes into another protocol, this is where we need to start our journey. 

The IPv6 static routing syntax is largely the same as IPv4, we specify a prefix and mask and either an outgoing interface or next hop IP address. This is one of the cases where I think the IPv6 syntax is improved over the IPv4 syntax. The default route has changed from us typing “0.0.0.0 0.0.0.0” to simply, “::/0”. It is cleaner and quicker to type than before because we can shorten IPv6 prefixes and CIDR notation is more straightforward to type and understand. 

The next-hop address for a static route does not necessarily need to be a globally unique address. Because every interface is automatically configured with a link-local address (FE80::/10), we can use this in our routing syntax if we specify an outgoing interface. 

RIPv6 

RIP is being dragged into the IPv6 world kicking and screaming. No one is really advocating for RIPv2 in IPv4 networks, and the same is true for RIPv6. It is slow to converge, still uses hop count as its metric, does not offer backwards compatibility for IPv4, and support for it is worse than RIPv2. 

Needless to say, RIPv6 is not a recommended routing protocol. 

EIGRPv6 

EIGRP has been a popular routing protocol for a long time for good reason, it is simple and easy to implement and troubleshoot, and is very quick. Unfortunately, the proprietary nature of the protocol for most of its life limited its capabilities in multi-vendor environments. Even today, EIGRP support within some of Cisco’s own product lines is limited or missing entirely. While some third-party vendors have implemented EIGRP support, it is not typical and would require static routing or redistribution into either OSPF or BGP for compatibility. 

These support issues are expanded when we start to explore EIGRPv6 device compatibility, and this is another nail in its coffin. 

IS-IS 

If you are reading this, you likely know about Intermediate System to Intermediate System, but have more than likely never worked with it directly. IS-IS has been relegated to just carrier networks and it barely even gets mentioned in most certification materials for enterprise focused domains. IS-IS is starting to make some inroads into the enterprise market space though through deployments such as Cisco’s SD-Access and ACI, however many organizations choose to redistribute into other protocols at the fabric edge. 

IS-IS surprisingly very well suited for IPv6 deployments for two reasons, it offers many of the same benefits of OSPF and natively supports IPv6 in the same process as IPv4, making it quite useful for dual-stack deployments. Unfortunately, the biggest drawback to IS-IS is its support, or lack thereof, in many network operating systems, specifically firewalls and SD-WAN routers. 

In another world where IS-IS support was more widespread, I would happily endorse it for deployment in enterprise networks because it offers many of the same benefits of OSPF while avoiding some of the scaling architecture gotchas. But unfortunately, in 2023, the state of support is not where it needs to be in firewalls and load-balancing appliances. 

OSPFv3 

OSPF of course has been widely deployed for decades now in both enterprise networks and carrier networks because it is an open standard and has widespread support, is quick to converge, can scale to meet the needs of large networks, and supports network overlay technologies such as MPLS traffic engineering. The one downside is that because of the flexibility and optimization options in OSPF, it can be complicated to design and troubleshoot. 

With the transition to IPv6, a new version of OSPF was needed and OSPFv3 was developed. For most organizations, OSPFv3 should be the path forward for their IPv6 deployments because of the reasons listed above but also because it represents an opportunity to eliminate a routing process in our network. OSPFv3 provides support for both IPv4 and IPv6 by enabling address families. 

As for the actual design of your OSPFv3 network design, it is hard to be exhaustive in recommendations but here’s a couple of good ideas to get you started: 

• Consider in your hierarchical subnet design where area border routers will be configured to allow for clean summarization. 
• Consider assigning the router ID to have a meaningful purpose in the IPv6 subnets (OSPFv3 router IDs retain the IPv4-style dotted decimal format) 
• Make a transition plan to move away from legacy IGPs before you start your IPv6 migration, this will reduce the time needed to support multiple routing protocols. 
• Implement authentication from the beginning. OSPFv3 offers support for authentication and encryption via the native IPv6 IPsec features. Security should not be an afterthought. 
• Adjust your reference bandwidths. Most modern enterprise networks have interfaces that exceed the default reference bandwidth. This results in any link faster than the reference bandwidth having the same cost regardless of the actual speed.  

MP-BGP 

BGP has long supported address families and is used extensively for routing overlays technologies such as MPLS L3 VPNs and EVPN. Of course, to a lot of network engineers, they are most familiar with BGP being the routing protocol of the Internet, and they may or may not have experience with peering with an ISP to advertise their public IP space. 

If your organization is already advertising provider independent IPv4 address space, the good news is that adding IPv6 to that peering is incredibly simple. Just activate the IPv6 unicast address family on your edge routers and notify your ISP of your assigned prefix so that they can adjust any filters they have configured for you. You should be able to receive a default IPv6 route from them very simply. If you are running a design that requires a full route table, make sure that your edge router is equipped with enough TCAM space to support both the IPv4 and IPv6 tables. 

If your organization is not currently advertising IPv4 provider independent space, no problem. You can either build out an edge design that accommodates BGP routing with your ISP or have your ISP advertise your PI space for you.