Understanding 464XLAT ALG Traffic Support
When you deploy IPv6 applications on mobile networks, be aware that some mobile operators cannot provide IPv6 support for their users, because some phone applications do not support an IPv6-only environment.
The solution is to use the NAT64 mechanism to access the IPv4-only content in the operator’s network and to use 464XLAT traffic to enable IPv4-only applications to work on IPv6-only networks.
The 464XLAT architecture is a combination of stateless translation on the customer-side translator (CLAT) and stateful translation on the provider-side translator (PLAT). The 464XLAT architecture is used to translate the packet information of a device using the combination of stateless (translates private IPv4 address to global IPv6 addresses, and vice versa) and stateful (translates IPv6 addresses to global IPv4 addresses, and vice versa) translation.
Starting in Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the 464XLAT traffic is not supported in a none PAT pool with a persistent NAT pool.
Figure 1 illustrates the 464XLAT architecture, which provides IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation on PLAT in the core and stateless protocol on CLAT at the edge. The private IPv4 host can reach global IPv4 hosts through both CLAT and PLAT translation. Conversely, the IPv6 host can directly reach other IPv6 hosts on the Internet without translation. This means that the customer premises equipment (CPE) can support CLAT and also operate as an IPv6 native router for native IPv6 traffic.
Understanding 464XLAT ALG Functionality
Figure 2 describes the address translation architecture and shows how packet information for a device is translated using a combination of stateful translation at the provider-side translator (PLAT) and stateless translation at the customer-side translator (CLAT). In this diagram, the client is delegated an IPv6 prefix from a prefix delegation mechanism such as DHCPv6 Prefix Delegation (DHCPv6-PD). Therefore, the client has a dedicated IPv6 prefix for translation.
The PPTP, RTSP, and FTP ALGs also support XLAT functionality.
This following sections explain how the PPTP, RTSP, and FTP ALGs work when the device acts as PLAT:
How the PPTP ALG Supports the Device Acting As PLAT
Figure 3 describes the PPTP ALG XLAT functionality.
The PPTP ALG uses the call_ID for destination port functionality.
The client sends the outgoing call request (with PPTP Access Concentrator (PAC) call_ID) to the server:
CLAT: The source address/port is translated from Ipv4_1/port1 to Ipv6_1/port1. However, the payload call_ID is not changed.
PLAT: The source address/port Ipv6_1/port1 is translated to Ipv4_1’/port1’ and matches the NAT64 rule. However, the call_ID in the payload is not changed. The PPTP ALG creates a gate such as server_ip/0->Ipv4_1’/call_ID(Ipv6_1/call_ID).
The first generic routing encapsulation (GRE) packet reaches the gate from the server side: When the first GRE traffic reaches the gate, the GRE packet from the server side with destination Ipv4_1’/call_ID is translated to Ipv6_1/call_ID. Finally, the GRE packet reaches the client Ipv4_1/call_ID after CLAT.
Another special case for call_ID 0:
CLAT: The source address/port is translated from Ipv4_1/port1 to Ipv6_1/port1. However, the payload call_ID is not changed.
PLAT: The source address/port Ipv6_1/port1 is translated to Ipv4_1’/port1’ and matches the NAT64 rule. However, the call_ID 0 in the payload is manually translated to 65002. The PPTP ALG creates a gate such as server_ip/0->Ipv4_1’/65002(Ipv6_1/0).
The first GRE packet reaches the gate from the server side: When the first GRE traffic reaches the gate, the GRE packet from the server side with destination Ipv4_1’/65002 is translated to Ipv6_1/0. Finally, the GRE packet reaches the client Ipv4_1/0 after CLAT.
The server sends the outgoing call reply (with PPTP Network Server (PNS) and PAC call_ID) to the client:
PLAT: The source address/port Ipv4_2/port2 is translated to Ipv6_2/port2’ and matches the NAT64 rule. However, the call_ID in the payload is not changed, and the PPTP ALG creates a gate such as client_v6/0->Ipv6_2/call_ID(Ipv4_2/call_ID).
CLAT: The source address/port is translated from Ipv6_2/port2 to Ipv4_2/port2. However, the payload call_ID is not changed.
The first GRE packet reaches the gate from the client side: When the first GRE traffic reaches the gate, the GRE packet from the client side with destination Ipv4_2’/call_ID is translated to Ipv6_2/call_ID after CLAT and then it is translated to Ipv4_2/call_ID. Finally, the GRE packet reaches the server Ipv4_2/call_ID after PLAT.
Another special case for call_ID 0:
PLAT: The source address/port Ipv4_2/port2 is translated to Ipv6_2/port2’ and matches the NAT64 rule. However, the call_ID in the payload is translated to 65002 and the PPTP ALG creates a gate such as client_v6/0->Ipv6_2/65002(Ipv4_2/0).
CLAT: The source address/port is translated from Ipv6_2/port2 to Ipv4_2/port2. However, the payload call_ID is not changed.
The first GRE packet reaches the gate from the client side: When the first GRE traffic reaches the gate, the GRE packet from the client side with destination Ipv4_2’/65002 is translated to Ipv6_2/65002 after CLAT and then it is translated to Ipv4_2/0. Finally, the GRE packet reaches the server Ipv4_2/0 after PLAT.
How the RTSP ALG Supports the Device Acting As PLAT
Figure 4 describes the RTSP ALG XLAT functionality.
The Windows Media Player on the Windows PC sends a SETUP message:
CLAT: The source address/port is translated from Ipv4_1/port1 to Ipv6_1/port1. However, the payload Ipv4_2/port3 is not changed.
PLAT: The source address/port Ipv6_1/port1 is translated to Ipv4_1’/port1’ and matches the NAT64 rule, and the payload port3 is translated to port3’. However, the IP address in the payload ULR remains unchanged.
The Windows Media Server on the Windows server sends a 200 OK message:
PLAT: The source address/port Ipv4_1’/port1’ is translated to Ipv6_1/port1 and matches the NAT64 rule. However, the port4 in the payload is not changed. The port3’ is translated to port3. The RTSP ALG create gates such as c->s Ipv6_1/port1->Ipv6_2/port3 and s->c Ipv4_2/port4->Ipv4_1’/port3’ over UDP media data sent from the server side with destination Ipv4_1’/port1’, then the IP header is translated to Ipv6_1/port1 and reaches the gate.
CLAT: The source address/port is translated from Ipv6_1/port1 to Ipv4_1/port1. However, the payload port3/port4 is not changed.
The server sends the Real-Time Transport Protocol (RTP) over UDP media data:
PLAT: When the RTP over UDP media data is sent from the server side with destination Ipv4_1’/port3, the IP header is translated to Ipv6_1/port3 and reaches the gate.
CLAT: The IP header is translated from Ipv6_1/port3 to Ipv4_1/port3.
The client sends the RTP over UDP media data:
CLAT: The source address/port is translated from Ipv4_1/port3 to Ipv6_1/port3 and the destination address is translated from Ipv4_2/port4 to Ipv6_2/port4.
PLAT: The source address/port is translated from Ipv6_1/port3 to Ipv4_1’/port3 and the destination address is translated from Ipv6_2/port4 to Ipv4_2/port4.
How the FTP ALG Supports the Device Acting As PLAT
Figure 5 and Figure 6 describe the FTP ALG XLAT functionality in passive mode and port mode.
A 227 message enters passive mode:
CLAT: The source address/port is translated from Ipv4_1/port1 to Ipv6_1/port1. However, the payload does not contain IP or port information.
PLAT: The source address/port Ipv4_1’/port1’ is translated to Ipv6_1/port1 and matches the NAT64 rule. However, the Ipv4_2/port3 in the payload is not changed, and the FTP ALG creates a gate such as Ipv4_1/0(Ipv6_1/0)->Ipv4_2/port3.
The first packet reaches the gate from the client side: When the traffic reaches the gate, the date packet from the client side with destination Ipv4_2/port3 is translated to Ipv6_2/port2. The IP header is translated to Ipv4_2/port3 by NAT64 rule based on PLAT.
FTP port mode sends a PORT message:
CLAT: The source address/port is translated from Ipv4/port1 to Ipv6/port1.
PLAT: The source address/port is Ipv6_1/port1 is translated to Ipv4_1’/port1’ and matches the NAT64 rule. The Ipv4_1/port2 in the payload is translated to Ipv4_1’/port2’ and the FTP ALG creates a gate such as Ipv4_1’/port2’(Ipv4_1/port2->server_ip/server_port.
The first packet reaches the gate from the server side: When the traffic reaches the gate, the first packet from the server side with destination Ipv4_1’/port2’ is translated to Ipv6_1/port2. Finally, the packet reaches the client Ipv4_1/port2 before CLAT.
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.