Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Understanding 464XLAT ALG Functionality

Figure 13 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.

Figure 13: 464XLAT ALG Functionality

464XLAT ALG Functionality

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 14 describes the PPTP ALG XLAT functionality.

Figure 14: PPTP ALG XLAT Functionality

PPTP ALG XLAT Functionality

The PPTP ALG uses the call_ID for destination port functionality.

  1. 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.

  2. 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 15 describes the RTSP ALG XLAT functionality.

Figure 15: RTSP ALG XLAT Functionality

RTSP ALG XLAT Functionality
  1. 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.

  2. 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.

  3. 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.

  4. 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 16 and Figure 17 describe the FTP ALG XLAT functionality in passive mode and port mode.

Figure 16: FTP Passive mode:

FTP Passive mode:
  1. 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.

  2. 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.

Figure 17: FTP Port Mode

FTP Port Mode
  1. 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.

  2. 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.

Related Documentation

Modified: 2016-05-01