ON THIS PAGE
Stateful NAT64
Configuring Stateful NAT64
To configure stateful NAT64, you must configure a rule at the [edit services nat] hierarchy level for translating the source address dynamically and the destination address statically.
When you configure the service set that includes your NAT rule, include the set stateful-nat64 clear-dont-fragment-bit at the [edit services service-set service-set-name] hierarchy level.This clears the DF (don't fragment) bit in order to prevent unnecessary creation of an IPv6 fragmentation header when translating IPv4 packets that are less than 1280 bytes. RFC 6145, IP/ICMP Translation Algorithm, provides a full discussion of the use of the DF flag to control generation of fragmentation headers. For more information on service sets for NAT, see Configuring Service Sets for Network Address Translation.
To configure stateful NAT64:
- In configuration mode, go to the [edit services nat] hierarchy level.[edit]user@host# edit services nat
- Define the pool of source addresses to be used for dynamic
translation.[edit services nat]user@host# set pool pool name address source addressesuser@host# set pool pool name port source ports
For example:
[edit services nat]user@host# set pool src-pool-nat64 address 203.0.113.0/24user@host# set pool src-pool-nat64 port automaticNote Starting in Junos OS release 14.2, the sequential option is introduced to enable you to configure sequential allocation of ports. The sequential and random-allocation options available with the port automatic statement at the [edit services nat pool nat-pool-name] hierarchy level are mutually exclusive. You can include the sequential option for sequential allocation and the random-allocation option for random delegation of ports. By default, sequential allocation of ports takes place if you include only the port automatic statement at the [edit services nat pool nat-pool- name] hierarchy level. The auto option is hidden and is deprecated in Junos OS Release 14.2 and later, and is only maintained for backward compatibility. It might be removed completely in a future software release.
- Define a NAT rule for translating the source addresses.
Set the match-direction statement of the rule as input. Then define a term that uses stateful-nat64 as the translation
type for translating the addresses of the pool defined in the previous
step.[edit services nat]user@host# set rule rule name match-direction inputuser@host# set rule rule name term term name from source-address source addressuser@host# set rule rule name term term name from destination-address destination addressuser@host# set rule rule name term term name then translated source-pool pool nameuser@host# set rule rule name term term name then translated destination-prefix destination prefixuser@host# set rule rule name term term name then translated translation-type stateful-nat64
For example:
[edit services nat]user@host# set rule stateful-nat64 match-direction inputuser@host# set rule stateful-nat64 term t1 from source-address 2001:DB8::0/96user@host# set rule stateful-nat64 term t1 from destination-address 64:FF9B::/96user@host# set rule stateful-nat64 term t1 then translated source-pool src-pool-nat64user@host# set rule stateful-nat64 term t1 then translated destination-prefix 64:FF9B::/96user@host# set rule stateful-nat64 term t1 then translated translation-type stateful-nat64
The following example configures dynamic source address (IPv6-to-IPv4) and static destination address (IPv6-to-IPv4) translation.
[edit services]
user@host# show
nat {
pool src-pool-nat64 {
address 203.0.113.0/24;
port {
automatic;
}
}
rule stateful-nat64 {
match-direction input;
term t1 {
from {
source-address {
2001:db8::0/96;
}
destination-address {
64:ff9b::/96;
}
}
then {
translated {
source-pool src-pool-nat64;
destination-prefix 64:ff9b::/96;
translation-type {
stateful-nat64;
}
}
}
}
}
}
service-set sset-nat64 {
nat-options {
stateful-nat64 {
clear-dont-fragment-bit;
}
}
service-set-options;
nat-rules stateful-nat64;
interface-service {
service-interface ms-0/1/0;
}
}If you configure two NAT64 rules and associate them with the same service set, along with stateful firewall rules, and apply the service set on two VLAN-tagged interfaces, for traffic that is transmitted matching both the NAT rules, the traffic that is destined to the second NAT rule is dropped. In such a scenario, traffic flows are not dropped on the Routing Engine. This behavior of traffic drop by the second NAT rule is expected. With Junos OS Extension-Provider packages installed on a device, because endpoint-independent mapping (EIM) is not supported, EIM per VLAN or per NAT rule term. The second session, which is dropped by the second NAT rule in the configuration scenario described here, is not created owing to the following sequence of events:
The first packet matching either rule creates an EIM and a session.
The second packet matches the EIM entry because the second packet is sent with the same source IP address and port as the first packet (but with a different destination address).
This condition causes allocation (reuse) of the same public IP address and port to the second packet as the first packet. The reverse flow for this session has the same 5-tuple data as the reverse flow of the first session. This behavior causes flow addition failure because a duplicate flow in the same service set is not permitted.
To work around this problem, disable EIM in both the NAT rules, which causes both the sessions to be established and processed correctly. Alternatively, to avoid this problem, specify the NAT rules on different service-sets configured on different units of the media interface with EIM enabled to successfully establish both the sessions.