6WIND CG-NAT vRouter with NAT64

ISPs migrating towards an IPv6 core network still need to reach the IPv4 world. Maintaining a dual-stack environment internally is often not a valid option as it would increase the costs and complexity. Meanwhile, IPv4 address depletion remains. A CG-NAT router performing NAT64 proposes an appropriate solution for both of these requirements. In today’s blog post, we will show how to configure 6WIND vRouter as a CG-NAT router that enables NAT64 at the edge of the core network.  

Overview

In this post, we will focus on the following use case scenario:

This ISP must allow end-users connected behind their uCPEs to connect to IPv4-only hosts through the IPv6 core network. It owns a restricted pool of IPv4 public addresses. When IPv6 clients want to connect to a given domain name they must first perform a DNS resolution to retrieve the associated IPv6 address by querying a DNS name server for an AAAA DNS resource record (DNS RR). However IPv4-only hosts are recorded in a type A DNS RR. That’s why NAT64 works in conjunction with a DNS64 name server that can provide custom-built AAAA DNS RRs for IPv4-only hosts:

The DNS64 name server relies on a regular DNS name server and acts as a proxy for end-user DNS resolution requests: it first forwards the query for AAAA records. If no record is returned, it searches for A records of the same domain name. When A records are returned, it converts them into AAAA records using the scheme described in RFC 6052 to finally send them back to the end-user. This scheme embeds IPv4 addresses in IPv6 addresses by using a “well-known IPv6 prefix”. The prefix 64:ff9b::/96 is reserved for this usage, even though any prefix can be used, provided that the NAT64 and DNS64 servers agree on the same value. The client is now able to access the IPv4 host using this IPv6 address. The packet is routed through the NAT64 router, which translates the IPv6 packet into an IPv4 packet by extracting the embedded IPv4 address. 6WIND vRouter can fulfill both NAT64 and DNS64 functions: the uCPEs then declare the vRouter as a DNS name server and as a gateway.  

Configuration

In previous blog posts we showed how to deploy 6WIND vRouters in a wide variety of environments and provided guidelines on how to manage the configuration of the different instances. 6WIND vRouter management is NETCONF/YANG-based and you can find more information in this blog.  

System and Network

Let’s first focus on the fast path configuration under “system”:

system
    fast-path
        port pci-b0s4
        port pci-b0s5
        ..

We enable the fast path, which will be in charge of the physical interfaces. LAN and WAN interfaces handled by the fast path are configured with static addresses inside the main vrf:

vrf main
    interface
        physical lan
            port pci-b0s4
            ipv6
                address 2001:db8:100::1/96
                ..
            ..
        physical wan
            port pci-b0s5
            ipv4
                address 9.0.0.1/24
                ..
            ..
    routing
        static
            ipv4-route 0.0.0.0/0
                next-hop 9.0.0.2
                ..
            ipv4-route 32.96.119.0/24
                next-hop blackhole
                ..
            ipv6-route 64:ff9b::/96
                next-hop wan
                ..
            ipv6-route 2001:db8:200::/96
                next-hop 2001:db8:100::2
                ..
            ..
        ..

We also define a default IPv4 route via the WAN interface, an IPv6 route back to the uCPEs and 2 additional routes that we’ll explain below.  

DNS64 and NAT64

In the main VRF, we can now enable both the DNS64 and NAT64 features: We first configure the vRouter to proxy DNS queries to the DNS name server at 2001:db8:100::3. In addition to that, we enable the DNS64 mechanism for the requests coming from the uCPE subnet 2001:db8:200::/96 using the “well-known prefix” 64:ff9b::/96.

vrf main
    dns
        proxy
            forward
                server 2001:db8:100::3
                ..
            dns64 64:ff9b::/96
                client 2001:db8:200::/96
                ..
            ..
        ..

Then we enable CG-NAT performing NAT64:

vrf main
    cg-nat
        pool mypool
            address 32.96.119.0/24
            block-size 256
            port-range 1024 65535
            ..
        rule 1
            match
                source
                    ipv6-address 2001:db8:200::/96
                    ..
                outbound-interface wan
                ..
            translate-to
                pool-name mypool
                max-blocks-per-user 2
                destination-prefix 64:ff9b::/96
                algo stateful-nat64
                ..
            ..
        ..

We first declare the pool of public IPv4 addresses to be used as a source for outgoing packets and the port allocation policy within this pool. Then we can define the rules that govern CG-NAT: we want to apply NAT64 to packets coming from the uCPEs’ IPv6 addresses and going out through the WAN interface. The vRouter translates these packets into IPv4 packets by picking public IPv4 addresses and ports within the defined “mypool” pool for the source. It enforces stateful NAT64 for incoming packets targeting the same “well-known” prefix as the one used in AAAA records returned by the DNS64. This way it knows how to extract the IPv4 destination address. We can now understand the 2 additional routes defined in the previous paragraph: we need to make sure that the specially crafted packets using the well-known IPv6 prefix 64:ff9b::/96 are routed towards the WAN interface so that the NAT64 rule applies. Additionally, we don’t want to route packets coming back to the IPv4 addresses of our public pool anywhere else. Legitimate packets will be handled by CG-NAT and forwarded back to the uCPEs but out-of-context packets are discarded.  

Conclusion of 6WIND CG-NAT vRouter with NAT64

Using 6WIND vRouter, an ISP can easily implement both CG-NAT64 and DNS64 functions to connect its IPv6 core network to the IPv4 world. Feel free to request an evaluation as well. We will be happy to hear from you. This article was written by Aurélien DEGEORGES, L2 support engineer at 6WIND.