In the NAT64 policy rule, configure the original source to be
an IPv6 host address or Any. Configure the destination IPv6 address
as either the Well-Known Prefix or the NSP that the DNS64 server
uses. (You do not configure the full IPv6 destination address in
If you need to use a DNS, you need to use a DNS64
Server to convert an IPv4 DNS “A” result into an “AAAA” result
merged with the NAT64 prefix. If you don’t use a DNS, you need to
create the address using the IPv4 destination address and the NAT64
prefix configured on the firewall, following RFC 6052 rules.
For environments that use a DNS, the example topology below illustrates
communication with the DNS64 server. The DNS64 server must be set
up to use the Well-Known Prefix 64:FF9B::/96 or your Network-Specific
Prefix, which must comply with RFC 6052 (/32, /40,/48,/56,/64, or
On the translated side of the firewall, the translation type
must be Dynamic IP and Port in order to implement stateful NAT64.
You configure the source translated address to be the IPv4 address
of the egress interface on the firewall. You do not configure the
destination translation field; the firewall translates the address
by first finding the prefix length in the original destination address
of the rule and then based on the prefix, extracting the encoded
IPv4 address from the original destination IPv6 address in the incoming
Before the firewall looks at the NAT64 rule, the firewall must
do a route lookup to find the destination security zone for an incoming
packet. You must ensure that the NAT64 prefix can be reached through
the destination zone assignment because the NAT64 prefix should
not be routable by the firewall. The firewall would likely assign
the NAT64 prefix to the default route or drop the NAT64 prefix because
there is no route for it. The firewall will not find a destination
zone because the NAT64 prefix is not in its routing table, associated
with an egress interface and zone.
You must also configure a tunnel interface (with no termination
point). You apply the NAT64 prefix to the tunnel and apply the appropriate
zone to ensure that IPv6 traffic with the NAT64 prefix is assigned
to the proper destination zone. The tunnel also has the advantage
of dropping IPv6 traffic with the NAT64 prefix if the traffic does
not match the NAT64 rule. Your configured routing protocol on the
firewall looks up the IPv6 prefix in its routing table to find the
destination zone and then looks at the NAT64 rule.
The following figure illustrates the role of the DNS64 server
in the name resolution process. In this example, the DNS64 server
is configured to use Well-Known Prefix 64:FF9B::/96.
1. A user at the IPv6 host enters the URL www.abc.com, which
generates a name server lookup (nslookup) to the DNS64 server.
2. The DNS64 Server sends an nslookup to the public DNS server
for www.abc.com, requesting its IPv4 address.
3. The DNS server returns an A record that provides the IPv4
address to the DNS64 server.
4. The DNS64 server sends an AAAA record to the IPv6 user, converting
the IPv4 dotted decimal address 198.51.100.1 into C633:6401 hexadecimal and
embedding it into its own IPv6 prefix, 64:FF9B::/96. [198 = C6 hex;
51 = 33 hex; 100 = 64 hex; 1 = 01 hex.] The result is IPv4-Embedded
IPv6 Address 64:FF9B::C633:6401.
Keep in mind that in a /96 prefix, the IPv4 address is the last
four octets encoded in the IPv6 address. If the DNS64 server uses
a /32, /40, /48, /56 or /64 prefix, the IPv4 address is encoded
as shown in RFC 6052.
Upon the transparent name resolution, the IPv6 host sends a packet
to the firewall containing its IPv6 source address and destination
IPv6 address 64:FF9B::C633:6401 as determined by the DNS64 server.
The firewall performs the NAT64 translation based on your NAT64