9.7. NAT64 Address Translation

Home Prev	cOS Stream 4.00.02 Administration Guide	Next

To address the need for communication between IPv4 and IPv6 networks, cOS Stream provides an Address Family Translation (AFT) feature using NAT64.

Usually, NAT64 assumes that a flow will be initiated by an IPv6 host towards an IPv4 host. However, translation is also possible in the reverse direction with IPv4 initiated flows. On the IPv6 side, IPv4 addresses are embedded in IPv6 addresses and creating such IPv4 embedded address objects in a firewall configuration is described in Section 5.5, IPv6 With Embedded IPv4.

NAT64 is configured by creating an appropriate IPRule object. On the IPv4 side of the IPRule object, an interface could have a single IPv4 address or, when appropriate, make use of multiple IPv4 addresses by associating a NATPool object with the interface (however, deterministic NAT cannot be used).

Types of NAT64

NAT64 can be configured in one of the following two ways:

Stateful NAT64

Stateful NAT64 is the most frequently used type of NAT64 and the typical use case is when multiple IPv6 hosts behind a firewall require access to remote IPv4 servers. The address translation is automatic and the mapping is many-to-one (multiple IPv6 addresses to one IPv4 address which is usually a public address). However, the mapping could be made many-to-one by configuring a NAT pool for the IPv4 addresses (this would often be done in a CGNAT scenario). Configuring this is described in Section 9.7.1, Stateful NAT64.

With stateful NAT64, only IPv6 hosts can initiate the communication.

Where IPv6 HTTP clients initiate access to IPv4 HTTP servers on the Internet, access to a DNS64 server is required to resolve FQDNs and this is discussed in the stateful NAT64 section.
Stateless NAT64 (SIIT)

Stateless NAT64 is also referred to as SIIT and is a static one-to-one translation between IPv6 and IPv4 addresses, similar to normal IPv4 to IPv4 SAT. In the typical but infrequent use case, an IPv4 only server will be behind the firewall (possibly in a DMZ network) and stateless NAT64 will allow remote IPv6 hosts to access this server. Configuring this is described in Section 9.7.4, Stateless NAT64 (SIIT).

Stateless NAT64 allows translation in either direction so that either the IPv4 or IPv6 host can initiate communication.

Protocol Restrictions

It should be noted that NAT64 feature supports only the following protocols:

ICMPv6 traffic.
UDP and/or TCP traffic.

In addition, protocols that embed IPv4 addresses in packets, for example SIP and FTP, cannot be used with NAT64 in cOS Stream.

	Note: NAT64 configuration with BGP
	When BGP is configured with NAT64, BGP export needs to be configured accordingly. This is discussed further in section 3.2 of RFC 6052.

Configuring the different types of NAT64 translation is described further in the sections that follow.

9.7.1. Stateful NAT64

The stateful version of NAT64 is similar to normal NAT where an IPv4 (usually public) address on an interface connected to an IPv4 network is reused for multiple connections. cOS Stream implements stateful NAT64 by changing the address of the packet to its own overloaded IPv4 address and tracks these changes so it can reverse the change in returning packets. The diagram below illustrates stateful NAT64 usage.

Figure 9.4. Stateful NAT64

Use Cases

The principal use cases for stateful NAT64 are the following:

IPv6-only clients accessing IPv4-only servers on the Internet.
IPv4-only servers delivering data over IPv6.

Stateful NAT64 Supports Only IPv6 to IPv4 Mapping

It should be noted that unlike stateless NAT64 (SIIT), IPRule objects can only be configured that support IPv6 to IPv4 address mapping, where the IPv6 hosts initiate the communication.

Stateful NAT64 Setup

Setting up stateful NAT64 is achieved by creating an IPRule object with the following property values:

Set the ProtocolTranslation property to have the value ToIP4.
Set the SourceTranslation property to be NAT.
Set the DestinationTranslation property to be SAT.

Note that a route is also needed for the IPv6 address of the server.

Configuring an IPRule for Stateful NAT64

The following table summarizes the properties and the combinations of their possible values for IPRule objects used to define stateful NAT64 translation. Note that values in brackets are specified in the rule as either actual IP addresses or references to other configuration objects such as IP address objects or NAT pool objects.

ProtocolTranslation	ToIP4	ToIP4	ToIP4	ToIP4	ToIP4
SourceAddress	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)
SourceTranslation	NAT	NAT	NAT	NAT	NAT
SetSourceAddress	InterfaceAddress	AllToOne	AllToOne	NATPool	NATPool
NATPool				(NATPool object)	(NATPool object)
Destination Address	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)
DestinationTranslation	SAT	SAT	SAT	SAT	SAT
SetDestinationAddress	Prefix	Offset	Prefix	Offset	Prefix
NewDestinationIP4		(IPv4 address)		(IPv4 address)
Prefix	(IPv6 prefix)		(IPv6 prefix)		(IPv6 prefix)

Example 9.14. Setting Up Stateful NAT64

In this example, clients on an IPv6 network 2001:db1::/120 will be allowed UDP access to a single server with the IP address with the known IPv4 address 192.168.20.220 on the IPv4 network 192.168.20.0/24. This is done by setting up an IP rule with stateful NAT64 source address translation.

It is assumed that the Clavister NetShield Firewall is connected to the IPv6 network via the if1 interface and to the IPv4 network via the if2 interface. The IPv4 server is accessible by the IPv6 clients using the IPv6 address 2001:db21::5.

Command-Line Interface

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			SourceNetwork=2001:db1::/120
			DestinationInterface=if2
			DestinationNetwork=2001:db21::5 
			Service=all_udp
			ProtocolTranslation=ToIP4
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress 
			DestinationTranslation=SAT
			SetDestinationAddress=Offset
			NewDestinationIP4=192.168.20.220
			Name=NAT64_udp_6to4

Note that if a route does not already exist for the server it must be added manually so that the address 2001:db21::5 is routed on the if2 interface.

Using NAT Pools with NAT64

To spread the IPv4 connection load across multiple IPv4 addresses, NAT64 can take advantage of the NAT pool feature in cOS Stream. Setting up a NATPool object is described in Section 9.3, NAT Pools. To utilize a NAT pool object with NAT64, the IPRule object for NAT64 is modified as follows:

The SetSourceAddress property is set to the value NATPool.
The NATPool property of the rule is set to a NATPool object that has been previously created.

	Note: Deterministic NAT pools are not supported with NAT64

9.7.2. Stateful NAT64 with DNS64

When IPv6 HTTP clients need to access a remote IPv4-only server over the Internet, they will first need to resolve the web server's FQDN into an IP address that they can use to make the connection via NAT64. This is usually done by resolving the FQDN with a DNS64 server. The DNS64 server will look up the FQDN and if no AAAA record (for IPv6) is available it uses the available A record (for IPv4) to synthesize an acceptable response by embedding the IPv4 address into an IPv6 address that has a fixed prefix. The DNS64 server could be private and internal or public and external.

DNS64 Server Prefixes

When a DNS64 server sends back a synthesized IPv6 address it will use an IPv6 prefix in the address that will depend on the configuration of the server. There are a number of public DNS64 servers and the prefix used by them is usually the Well Known Prefix which is 64::ff9b::/96. For example, this is the prefix used by Google's public DNS64 server. However, some DNS64 servers may be set to use another Network Specific Prefix (NSP).

Knowing the prefix used by the DNS64 server is important since this will be the prefix of the destination address for flows that an IPv6 client will open. The prefix will therefore need to be specified in the IPRule object that performs NAT64 translation.

Configuring Stateful NAT64 with a DNS64 server

The diagram below illustrates how NAT64 is used with a private NAT64 server located in a DMZ network.

Figure 9.5. Stateful NAT64 with Private DNS64

In the case of an internal IPv6 network of clients accessing IPv4 servers on the Internet via the firewall, the following needs to be configured:

An IP rule to translate the IPv6 client traffic to IPv4.
An IP rule that allows the clients to query the DNS64 server.
If the DNS64 server is internal, an IP rule to allow access to the Internet by the server.
IPv6 clients will need to be configured with the address of the DNS64 server.

Note that the IP rule that performs the translation must have its DestinationNetwork and Prefix properties set to the prefix used by the DNS64 server. In the example below with a private DNS64 server, this is the address object if1_64_prefix.

It is also possible to narrow the DestinationNetwork value further by increasing the prefix size from the standard 96 bits. For example, if the DNS64 prefix is 64:ff9b::/96 then setting the DestinationNetwork to 64:ff9b::203.0.113.0/120 will specify the permitted destination IPv4 range as being 203.0.113.0-203.0.113.255 (matching will be done against everything except the last 8 bits of the IPv6 address).

Example 9.15. Setting Up Stateful NAT64 with a Private DNS64 Server

This example for NAT64 will be set up using a private DNS64 server to resolve client FQDNs into IPv4 embedded addresses so they can perform HTTP/HTTPS web browsing.

It is assumed that the DNS64 server is located on the local DMZ network if3_net which is connected to the if3 interface. The DNS64 server is set up to use the prefix if1_64_prefix. Note that the server has the following IPv4 and IPv6 address objects in the address book:

dns64_ip4 - 192.168.10.10
dns64_ip6 - 2001:db9::10

It is also assumed the if1 interface is connected to the IPv6 client network and the if2 network is connected to the IPv4 Internet. Below is a summary of the other IP addresses used in this example:

if1_64_prefix - 2001:64::/96 (prefix used by the DNS64 server)
if1_ip6 - 2001:db8::1
if1_ip6_net - 2001:db8::/96
if2_ip - 203.0.113.1 (the public IP address of the firewall)
if2_net - 203.0.113.0/24 (the network for ISP connection)

Command-Line Interface

Give IPv6 clients access to IPv4 HTTP/HTTPS Internet servers:

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			DestinationInterface=if2
			SourceNetwork=if1_ip6_net
			DestinationNetwork=if1_64_prefix
			Service=http-all
			ProtocolTranslation=ToIP4
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			DestinationTranslation=SAT
			SetDestinationAddress=Prefix
			Prefix=if1_64_prefix
			Name=NAT64_6to4

Allow IPv6 client access to the private DNS64 server:

System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			DestinationInterface=if3
			Service=dns-all
			SourceNetwork=if1_ip6_net
			DestinationNetwork=dns64_ip6
			Name=client_to_private_DNS64

Allow the private DNS64 server access to the Internet:

System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if3
			DestinationInterface=if2
			SourceNetwork=dns64_ip4
			DestinationNetwork=all-nets-ip4
			Service=dns-all
			ProtocolTranslation=Disabled
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			Name=DNS64_to_internet

Using a Public DNS64 Server

The rules used with a public DNS64 server are simpler. However, it is important to know the prefix that the server will use when it sends back IPv4 embedded addresses to a querying client. As with a private DNS64 server, this prefix must be specified for the DestinationNetwork and Prefix properties of the translating IP rule.

Example 9.16. Setting Up Stateful NAT64 with a Public DNS64 Server

This example for NAT64 repeats the previous scenario from Example 9.15, “Setting Up Stateful NAT64 with a Private DNS64 Server” but instead uses an external public DNS64 server to resolve client FQDNs into IPv4 embedded addresses. The two rules in the previous example that allow access for the private DNS64 server are replaced with a single rule that allows direct IPv6 access to the Internet for DNS queries.

It is assumed that the IPv6 clients have already been allocated the IPv6 address of a public DNS64 server. It is also assumed that the prefix used by the DNS64 server in the addresses it sends back is defined by the address object dns64_prefix. In many cases, this will be the well-known prefix 64:ff9b::/96.

Command-Line Interface

Give IPv6 clients access to IPv4 HTTP/HTTPS Internet servers:

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			DestinationInterface=if2
			SourceNetwork=if1_ip6_net
			DestinationNetwork=dns64_prefix
			Service=http-all
			ProtocolTranslation=ToIP4
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			DestinationTranslation=SAT
			SetDestinationAddress=Prefix
			Prefix=dns64_prefix
			Name=NAT64_6to4

Give IPv6 clients direct access to the IPv6 Internet (including the public DNS64 server) with no translation:

System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			DestinationInterface=if2
			Service=all_services
			SourceNetwork=if1_ip6_net
			DestinationNetwork=all_nets_ip6
			Name=client_to_public DNS64

9.7.3. Stateful NAT64 Hairpinning

The term hairpinning refers to the ability for an IPv6 host behind the firewall to communicate with another IPv6 host behind the firewall using the second host's external NATed IPv4 address. cOS Stream's stateful NAT64 feature supports hairpinning and it is set up by configuring an additional IPRule object.

An example of when hairpinning is needed might be when an IPv6 client queries a DNS64 server for a host located on its own network and receives back, embedded in an IPv6 address, the external, public IPv4 address used for stateful NAT64. The diagram below illustrates a typical hairpinning scenario.

Figure 9.6. Stateful NAT64 Hairpinning

Example 9.17. Setting Up Hairpinning in Stateful NAT64

This example assumes the same scenario as Example 9.16, “Setting Up Stateful NAT64 with a Public DNS64 Server” but this time an extra rule is needed to allow the internal IP clients to communicate with another server on the internal IPv6 network. The following address book objects are used:

server_ip6 - 2001:db8::5
server_embedded_ip6 - 2001:64::203.0.113.5

Command-Line Interface

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			DestinationInterface=core
			SourceNetwork=if1_ipv6_net
			DestinationNetwork=server_embedded_ip6
			SourceTranslation=NAT
			SetSourceAddress=AllToOne 
			NewSourceIP6=server_embedded_ip6
			DestinationTranslation=SAT
			SetDestinationAddress=AllToOne
			NewDestinationIP6=server_ip6
			Service=all_http
			Name=NAT64_hairpin_6to4

Note that a route is also needed so that the address server_embedded_ip6 is routed on the core interface.

9.7.4. Stateless NAT64 (SIIT)

Stateless NAT 64 (also known as Stateless IP/ICMP Translation which can be abbreviated to SIIT) is a type of address translation that allows IPv6 networks to communicate with IPv4 networks in either direction. The term SIIT will be used throughout this section.

The principal use case for SIIT is IPv4-only clients accessing IPv6-only servers.

SIIT works by replacing the headers in IP packets and cOS Stream supports both kinds of SIIT:

SIIT with Prefix - A single IPv6 prefix is removed or appended to packets.
SIIT with EAM - Explicit Address Mapping (EAM) means that the address mapping to be performed can be explicitly defined.

With cOS Stream, either type of SIIT can be defined in a configuration by creating the appropriate IPRule object. There is no port mapping so the address translation must be a 1:1 mapping.

SIIT Supports Address Mapping in Both Directions

It should be noted that unlike stateful NAT64, IPRule objects can be configured for SIIT that support both IPv6 to IPv4 address translation or IPv4 to IPv6 address translation.

Configuring an IPRule for Stateless NAT64 (SIIT)

The following tables summarize the properties and the combinations of their possible values for IPRule objects used to define stateless NAT64 (SIIT) translation. The first table applies to IPv6 to IPv4 translation. The second table applies to IPv4 to IPv6 translation.

A. Properties for IPv6 to IPv4 Translation

ProtocolTranslation	ToIP4	ToIP4	ToIP4	ToIP4
SourceAddress	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)
SourceTranslation	SAT	SAT	SAT	SAT
SetSourceAddress	Offset	Offset	Prefix	Prefix
NewSourceIP4	(IPv4 address)	(IPv4 address)
DestinationAddress	(IPv6 address)	(IPv6 address)	(IPv6 address)	(IPv6 address)
DestinationTranslation	SAT	SAT	SAT	SAT
SetDestinationAddress	Offset	Prefix	Offset	Prefix
NewDestinationIP4	(IPv4 address)		(IPv4 address)
Prefix		(IPv6 prefix)	(IPv6 prefix)

B. Properties for IPv4 to IPv6 Translation

ProtocolTranslation	ToIP6	ToIP6	ToIP6	ToIP6
SourceAddress	(IPv4 address)	(IPv4 address)	(IPv4 address)	(IPv4 address)
SourceTranslation	SAT	SAT	SAT	SAT
SetSourceAddress	Offset	Offset	Offset	Offset
NewSourceIP6	(IPv6 address)	(IPv6 address)
DestinationAddress	(IPv4 address)	(IPv4 address)	(IPv4 address)	(IPv4 address)
DestinationTranslation	SAT	SAT	SAT	SAT
SetDestinationAddress	Offset	Prefix	Offset	Prefix
NewDestinationIP6	(IPv6 address)		(IPv6 address)
Prefix		(IPv6 address)	(IPv6 address)	(IPv6 address)

SIIT with Prefix Setup

Setting up SIIT with prefix is achieved by creating an IPRule object with the following property values:

Set the ProtocolTranslation property to have the value ToIP6 or ToIP4 depending on the type of translation required.
Set the SetSourceAddress and SetDestinationAddress properties to the value Prefix.
Set the Prefix property to be the value of the prefix.

Note that a route is also needed for the destination address for flows and may have to be added manually if it does not already exist. The following example illustrates the setup of SIIT with prefix.

Example 9.18. Setting Up Stateless NAT64 (SIIT) with Prefix

In this example, multiple clients on the IPv4 network 192.168.10.0/24 will be allowed TCP access to a single server with the IPv6 address 2001:db2::192.168.11.15 located on the network 2001:db2::192.168.11.0/120.

It is assumed that the Clavister NetShield Firewall is connected to the IPv4 network via the if1 interface and to the IPv6 network via the if2 interface. The server is accessible to the IPv4 clients using the IPv4 address 192.168.11.15.

Command-Line Interface

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			SourceNetwork=192.168.10.0/24
			DestinationInterface=if2
			DestinationNetwork=192.168.11.15 
			Service=all_tcp
			ProtocolTranslation=ToIP6
			SourceTranslation=SAT
			SetSourceAddress=Prefix
			DestinationTranslation=SAT
			SetDestinationAddress=Prefix
			Prefix=2001:db2::/96
			Name=SIIT_TCP_4to6

Note that if a route does not already exist for the server it must be added manually so that the address 192.168.11.15 is routed on the if2 interface.

SIIT with EAM Setup

Setting up SIIT with EAM is achieved by creating an IPRule object with the following property values:

Set the ProtocolTranslation property to have the value ToIP6 or ToIP4 depending on the type of translation required.

Set the SetSourceAddress and SetDestinationAddress properties to the offset value.

Example 9.19. Setting Up Stateless NAT64 (SIIT) with EAM

This example will implement the following 1:1 address mapping between IPv6 addresses and IPv4 addresses:

IPv6	IPv4
2001:ab::/120	1.2.3.0/24
2002:ab::10	10.10.10.10

Command-Line Interface

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=if1
			SourceNetwork=2001:ab::/120
			DestinationInterface=if2
			DestinationNetwork=2002:ab::10 
			Service=all_udp
			ProtocolTranslation=ToIP4
			SourceTranslation=SAT
			SetSourceAddress=Offset
			NewSourceIP4=1.2.3.0
			DestinationTranslation=SAT
			SetDestinationAddress=Offset
			NewDestinationIP4=10.10.10.10
			Name=SIIT_EAM_6to4

	Note: Configuration with BGP
	When BGP is configured with SIIT, BGP export needs to be configured accordingly. This is discussed further in section 3.2 of RFC 6052.