How do NAT64 and DNS64 work?

As part of improving IPv6 content on this blog, I have chosen to write about how we can integrate these slightly distinct technologies DNS64 and NAT64. On this post, I will try to show how a native IPv6 client can access an IPv4 resource. In my opinion it isn’t really difficult but needs some focus as what is done with these two techniques is slightly different than what we have done with DNS and NAT so far and you must read every paragraph here not to miss anything. First I will explain the concepts and show the configuration. If you are familiar with the concepts, you can skip to the configuration step. For DNS64 BIND software is used and vSRX for NAT64.

We have the following topology and the question we ask here is that we have a client PC which has only an IPv6 address 2015:1000::2/64 and this client device doesn’t know anything about IPv4 world. How can it reach a web server e.g www.cnn.com having an IPv4-only address of 185.31.17.73? By the way, at the time of this writing www.cnn.com doesn’t have any IPv6 address. Let’s see how we will let our client PC access this resource.

PC1 is a Linux host, first check its network configuration.

PC1>ip -6 addr
23: vlan1167@if9:  mtu 1500 
    inet6 2015:1000::2/64 scope global               ip -6 route
2015:1000::/64 dev vlan1167  proto kernel  metric 256 
fe80::/64 dev vlan1167  proto kernel  metric 256 
default via 2015:1000::1 dev vlan1167  metric 1024

Let’s first try to ping www.cnn.com IPv4 address.

PC1>ping 185.31.17.73
connect: Network is unreachable

Yes we can’t connect. This is expected but I have just run it to show that address family (v4) that we are trying to reach isn’t recognized by PC1 linux device. Hence forget about reaching any IPv4 address directly like this 🙂 if we can’t reach an IPv4 address then we must have an IPv6 destination which somehow represents this IPv4 address but how?
An IPv6 address size is large enough to embed an IPv4 address as well right?. With the help of this big space we will use 32bits of an 128bits IPv6 address for IPv4 address and the second question is which IPv6 address/range we can use to embed this IPv4. Can we just use any IPv6 that is assigned to our network or any special range?

You can use part of your range but IANA has already assigned a well-known prefix for this purpose which is : 64:ff9b::/96 you can check RFC6052 for more details. One of the textual representation of this converted IP address is below.

 
64:ff9b::185.31.17.73

This isn’t an IP address but only a representation, first 96 bits of which belongs to this well-known prefix and last 32 bits is the IPv4 address. So far it may still seem vague but it will be clear. Carry on!

Now another question is how do we convert this IPv4 address 185.31.17.73 to a real IPv6 address so that we can send our packets to this converted IPv6 address. The answer is DNS64 technique which is working like as follows or I think it works like this. It really took time to draw this process steps.

• 1) Client PC tries to reach www.cnn.com on the browser. As it is an IPv6 client, AAAA type query is sent to the configured DNS server on the client
• 2) DNS64 server can’t serve this request from its cache hence needs to ask authoritative DNS server.
• 3) DNS64 server sends AAAA query for www.cnn.com address
• 4) However authoritative isn’t configured with any IPv6 address and returns no AAAA response
• 5) DNS64 in response to this negative feedback, sends an A query for IPv4 address (which isn’t done normally on DNS)
• 6) This time authoritative DNS server returns the IPv4 address
• 7) Our BIND DNS64 server is configured in such a way that for this type of request it should embed the IPv4 on 64:fb9::/96 network or as per RFC6144, it will synthesize AAAA from A record
• 8) And finally IPv6 response 64:ff9b::b91f:1249 returned to the client

Now client has received an IPv6 address to which it can really send an IPv6 packet. Every thing is completed? i.e can we really connect to the remote web server www.cnn.com? Not actually. Why? This time remote device has only IPv4 and our source and destination packet address is IPv6 because of which we have to translate our IPv6 source and destination address to IPv4. This translation will be done as I have drawn in the following sequence diagram.

I hope this sequence diagram is self explanatory. The only thing I would like to add is that you notice that this isn’t a normal NAT i.e NAT-PT or swapping one IP address by another. This is an address family translation (AFT) i.e we swap IPv6 address on both fields by IPv4.

So far it was all about how the translation works. Now we dive into configuration of BIND DNS server and vSRX.

DNS64 Configuration

dns64 64:ff9b::/96 {
              clients { any; };
};

That is it :-), yes if you add these lines in your named.conf and want to serve any client, for the situation I have explained above, DNS server will synthesize AAAA from A records that it obtains. You just instruct DNS server which prefix you want to return to your IPv6-only clients.

vSRX Configuration

On SRX side, one static nat + source nat is sufficient to perform the address family translation.

STATIC NAT

set security nat static rule-set nat64-LAB1014 from zone LAB1014-LAN
set security nat static rule-set nat64-LAB1014 rule ipv6-clients1 match destination-address 64:ff9b::/96
set security nat static rule-set nat64-LAB1014 rule ipv6-clients1 then static-nat inet                  

By using static nat and “static-nat inet” statement, SRX takes last 32 bits of the IPv6 destination address and puts onto the new IPv4 header. LAB1014-LAN is the internal zone facing the clients as you can guess.

SOURCE NAT

set security nat source rule-set LAB1014-Internet rule nat64-src-nat1 match source-address 2015:1000::/64
set security nat source rule-set LAB1014-Internet rule nat64-src-nat1 match destination-address 0.0.0.0/0
set security nat source rule-set LAB1014-Internet rule nat64-src-nat1 then source-nat interface

Here we replace IPv6 clients’ IP addresses by IPv4 interface address.

PS1: destination-address statement is very important here. Don’t miss it.
PS2: Security policy configuration is omitted here

Let’s connect to the TCP port 80 of www.cnn.com

root@LAB1014-srx2:~# telnet www.cnn.com 80
Trying 64:ff9b::b91f:1249...

Yes we did it!

and check the session table of vSRX

admin@vSRX> show security flow session destination-port 80 
Session ID: 3452, Policy name: lab1014-default-permit/10, Timeout: 286, Valid
  In: 2015:1000::2/45776 --> 64:ff9b::b91f:1249/80;tcp, If: ge-0/0/0.1167, Pkts: 2, Bytes: 152    10.10.100.90/1950;tcp, If: ge-0/0/0.1168, Pkts: 1, Bytes: 60

And finally, one side is IPv6 and the other side is IPv4…

What can go wrong in this setup? While I was configuring, I forgot to add “destination-address 0.0.0.0/0” as I don’t add this usually in IPv4-IPv4 NAT but if you don’t set it here, NAT module doesn’t understand that you want translation for IPv4 traffic and drops the following error in flow trace

CID-0:RT:no source nat found.
CID-0:RT:The packet destination ip is xlated to v4, with source ip is not xlated, drop it

and the packet is dropped afterwards.

Wavvv, finally I have finished this post. I have also listed several RFCs which are worth reading such as;

• Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
• DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
• Framework for IPv4/IPv6 Translation
• IPv6 Addressing of IPv4/IPv6 Translators

Please drop your comment/feedback or experience if you have done any deployment like this.

and finally the IPv4 counter. Let’s wee when this will reach all zero!