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 would highly recommend that you start at the beginning:   

• Part 1 – Hierarchical Subnetting Design  
• Part 2 – Routing Design  
• Part 3 – OSPFv3 
• Part 4 – Security 
• Part 5 – Transitional Client Addressing 
• Part 6 – SLAAC vs DHCPv6 

Building out your IPv6 deployment starts with acquiring an IPv6 prefix from your provider or through a Regional Internet Registry (ARIN, RIPE, AFRINIC, LACNIC, APNIC). The next step is advertising that space via BGP into the global routing table.  

In a previous post, we discussed Provider Assigned (PA) vs Provider Independent (PI) space, but as a quick review, your organization owns PI space. It can be advertised to any ISP you partner with, while PA space is owned and advertised by the ISP you contract with. The provider assigned space has the annoying problem of requiring an organization to re-address every subnet when they change ISPs or implement tools such as prefix translation to mask the subnet prefix as it heads out to the internet. 

SD-WAN 

Historically, a common WAN design for organizations with geographically dispersed sites has been to contract for private WAN connections between branch sites and one or multiple centralized data centers. Traffic destined from branch sites to the Internet flows through a data center and a centralized security stack. This hub-and-spoke design has served most organizations well, and the drawbacks, a less-than-ideal traffic flow, and cost, are outweighed by the added administrative overhead of the alternatives until the proliferation of SD-WAN tech. 

SD-WAN has turned the WAN design of many organizations on its head; instead of concentrating security services in centralized data centers, SD-WAN devices allow for distributed network security services and, therefore, allow direct internet access from branch sites. We’ll ignore the viability and effectiveness of those network security services for the purposes of this article as well as the support (or depressing lack of) IPv6 support by specific vendors. 

IPv4 in SDWAN designs is unsurprisingly no different than what’s traditionally deployed, SD-WAN devices act as NAT gateways to the internet while there’s generally no need for NAT over the IPSec tunnels to the hub location.  

IPv6 adds some slight complications due to the elimination of NAT, namely if a device at a branch-location egresses through the branch’s internet connection using a prefix that is being advertised via a central DC, asynchronous routing occurs and stateful firewalls are going to block return traffic. We can engineer around this issue in a couple of ways: 

1. Configure BGP at every branch location and advertise a /48 from the organization PI prefix – the issue here is that it’s incredibly time-consuming to stand up branch locations, and it breaks situations where we want some traffic to egress directly from the branch while other traffic egresses from a central DC. 
2. Use PA prefixes configured at every branch location – This solution gives us the issues inherent to PA space – non-portability – while introducing the need for us to maintain discontiguous prefixes for each site and still doesn’t solve the issues present if we want to send certain traffic out of a central DC while maintaining the ability to egress some traffic directly from the branch location. 

So, it sounds like we need a solution similar to NAT, a mechanism that masks the true address of a device so that we don’t introduce asynchronous routing issues. Fortunately, NAT66 never made it out of the draft RFC stage, but a tool called NPTv6 did and it’s the solution to our SD-WAN problem. 

Network Prefix Translation 

NPTv6 or IPv6-to-IPv6 Network Prefix Translation allows for multihoming network designs. It creates a stateless 1:1 relationship mapping from one prefix to another. This solution’s benefits over proposed NAT66 solutions are that it allows for true end-to-end reachability while providing the ability to load share to multiple ISPs, migrate away from one prefix to another without re-addressing clients, and take advantage of network designs that would otherwise be impossible to implement. 

NPT is useful not just for load-sharing or overcoming asynchronous routing architectures, it’s also a potent tool for migration away from PI space or networks going through a merger or acquisition. Since it can be costly and time-consuming to re-IP networks, it may be better, at least for the short term, to mask an existing prefix to a new prefix when exiting a network to the internet. 

Because NPTv6 is NOT stateful, it provides no security benefit, and it should NOT be relied on as a security mechanism. Further, many routers that support NPTv6 do not support firewall features during its use. Be sure to check your device’s configuration guide for full support. 

NAT64 and DNS64 

In the future, when IPv4 will finally be relegated to stories told by networking veterans to prove that they were there when the internet changed and IPv6 transition mechanisms will finally be retired, we won’t need NAT64. However, until then, native v6 networks need to have some way to access websites that are lagging behind. 

There are, of course, other IPv6 transition mechanisms, but NAT64 is by far the widest deployed because it solves one of the biggest issues. IPv6-only users need to have access to the legacy internet. NAT64 operates effectively the same as NAT44 with one slight quirk. The source IPv6 address and port of a packet is mapped to a public IPv4 address and port. This mapping information is stored in a state table so that the response packet can be appropriately mapped back to the original source address. 

The quirk of NAT64 is that it relies on DNS64 to work correctly. In its simplest explanation, DNS64 looks up an IPv4 A record, embeds the IPv4 address into an IPv6 address, and sends this along to the endpoint as an AAAA record. When the endpoint initiates the connection to this address, the NAT64 gateway performs a stateful translation from IPv6 to IPv4. 

The prefix 64:ff9b::/96 has been reserved for use in DNS64/NAT64. However, it should be noted that you can choose to assign and use your own prefix. We’ll leave the discussion on whether this is a good idea or not for another time. This custom prefix is called a Network-Specific Prefix (NSP) and needs to match between the DNS64 server and the NAT64 gateway. 

I recommend reading through the DNS64 RFC to understand its use in further detail.