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:
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.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
sequential option is introduced to enable
you to configure sequential allocation of ports.