SD-WAN and IPv6

While SD-WAN (Software Defined Wide Area Network) and SASE (Secure Access Service Edge) become popular architectures, what happens to IPv6 planning? It's not necessarily a mature operational model for many companies yet, but here are some considerations to keep in mind.

Why is SD-WAN popular?

An easy way to think of a WAN, or Wide Area Network, is that it is the part of the network that connects our main building or HQ and our branch offices. So, we have LANs, or Local Area Networks, within our HQ and branch offices, and then the WAN connects the two (or more) LANs.

While there are a few ways to achieve this WAN connection, MPLS (Multiprotocol Label Switching) has been a very common approach over the last decade or so. Without getting too bogged down in the technical details of MPLS, it's just good to understand that there are benefits to it such as traffic engineering and uptime, but there are also cons such as cost and flexibility. MPLS services are purchased from MPLS providers, usually the same companies you use as your ISP (Internet Service Provider).

Because of the cost and inflexibility of MPLS, SD-WAN architectures have become more popular in recent years. SD-WAN basically uses software (and sometimes hardware firewalls, wireless access points, and other appliances) to define the tunnels (or in some cases sessions) between your HQ and branch offices over the public network, or internet, if you will. SD-WAN solutions can be purchased from vendors such as Cisco, Juniper, Fortinet, and other networking companies you're likely familiar with and they all have their own ways of achieving these connections. Often they'll provide not only connectivity, but quality of service, load balancing, high availability, and security as well.

Of course, you still need to work with your ISP(s) to have Internet connectivity as well. At this point in time, ISPs are not keen to giving out static IPv4 addresses due to the scarcity issue of IPv4, especially in certain geographies. Therefore, you are likely receiving IPv6 address spaces for external use. Which brings us to our first of many considerations. When identifying a vendor for SD-WAN, what do they support from an IPv6 perspective, and are all the features available for IPv6 as they are for IPv4?

It always comes back to NAT

Would this even be an IPv6 blog if I didn't mention NAT (Network Address Translation). NAT is something we used heavily with IPv4, especially to solve the scarcity issue. NAT is a technology that allowed us to translate an internal IP to an external IP, since we're likely using Private IP address ranges internally and in order to serve out services externally we need to use external IP addresses. PAT (Port Address Translation) then allowed us to put multiple services with multiple IP addresses out for public consumption, using only 1 (or fewer) external addresses, which is what helped us solve the scarcity issue for a while.

While NAT/PAT helped us in a few ways, there are problems with it as well. In the context of this blog, I'll simply mention that there are certainly some performance issues that may occur, especially as a packet has flowed through two or three NAT devices between the HQ and branch offices. This brings in another consideration of whether to use NAT with IPv6. There are a few flavors of NAT possible here, especially if, like many, you've implemented a dual stack situation with IPv4 and IPv6. In which case you would consider NAT64 and/or NAT46. Even in the case of an IPv6 only implementation, there's still a possibility of using NAT66 perhaps because that's the operational model your teams are used to.

• NAT44 - Translate from IPv4 to IPv4
• NAT 46 - Translate from IPv4 to IPv6
• NAT 64 - Translate from IPv6 to IPv4
• NAT 66 - Translate from IPv6 to IPv6

There's another option similar to NAT66 called NPTv6. This is likely the best bet if you have performance concerns but require some translation from IPv6 to IPv6. The difference between NAT66 and NPTv6 is that NPTv6 only modifies the prefix for a 1:1 translation between the internal and external networks. Therefore you're not likely seeing any performance degradation from NPTv6 like you would from NAT66 possibly.

So, while IPv6 may offer better performance due to less hops over possibly the same physical infrastructure, the kind of address translation, if any,  that you need to do will also come into play for performance considerations.

Is it standards based?

The biggest consideration of all here, though, is whether any of these technologies and protocols are supported by your network vendors and how they're implemented. Because these technologies are not all standards based currently, having a multi-vendor topology may be problematic. Also, when considering sustainability, will the current implementation be maintained when it's time for a network refresh?

ULA Addressing?

The question may arise on whether to use ULA (Unique Local Addressing) on the LAN side (internal side) of your SD-WAN implementation as well. ULA is unique to IPv6, but is similar to Private IP addressing in IPv4. However, one of the benefits of using IPv6 is that we don't actually need Private IP addressing because there are so many addresses available that every device can have it's own unique address, the same address internally and externally. So, does it really make sense to design this kind of implementation and do we, as engineers somewhat beholden to network vendor capabilities, have the ability to manage this new operational model?

Moral of the Story

While I've probably left you with more questions than answers in this blog, hopefully it's helped give a few insights into the considerations necessary to implement SD-WAN with IPv6. The moral of the story is really to check with your network vendors and your ISPs to ensure that they offer the capabilities you need for both IPv4 and IPv6 implementations. And, as always, Men&Mice are here to help. If you have a question about IPv6 implementations, just reach out to our world class customer support team any time!