Descripción de la compatibilidad con el tráfico 464XLAT ALG
Cuando implemente aplicaciones IPv6 en redes móviles, tenga en cuenta que algunos operadores móviles no pueden proporcionar compatibilidad con IPv6 a sus usuarios, ya que algunas aplicaciones telefónicas no admiten un entorno de solo IPv6.
La solución es usar el mecanismo NAT64 para acceder al contenido solo IPv4 en la red del operador y usar el tráfico 464XLAT para permitir que las aplicaciones solo IPv4 funcionen en redes solo IPv6.
La arquitectura del 464XLAT es una combinación de traducción sin estado en el traductor del lado del cliente (CLAT) y traducción con estado en el traductor del lado del proveedor (PLAT). La arquitectura 464XLAT se utiliza para traducir la información del paquete de un dispositivo mediante la combinación de traducción sin estado (traduce la dirección IPv4 privada a direcciones IPv6 globales, y viceversa) y con estado (traduce las direcciones IPv6 a direcciones IPv4 globales, y viceversa).
A partir de Junos OS versión 12.3X48-D15 y Junos OS versión 17.3R1, el tráfico 464XLAT no se admite en un grupo sin PAT con un grupo NAT persistente.
La Figura 1 ilustra la arquitectura 464XLAT, que proporciona conectividad IPv4 a través de una red solo IPv6 al combinar la traducción de protocolos de estado existentes y conocidos en PLAT en el núcleo y el protocolo sin estado en CLAT en el borde. El host IPv4 privado puede llegar a hosts IPv4 globales mediante la traducción CLAT y LAT. Por el contrario, el host IPv6 puede llegar directamente a otros hosts IPv6 en Internet sin traducción. Esto significa que el equipo en las instalaciones del cliente (CPE) puede admitir CLAT y también funcionar como un enrutador nativo IPv6 para el tráfico IPv6 nativo.
de 464XLAT
Descripción de la funcionalidad 464XLAT ALG
La figura 2 describe la arquitectura de traducción de direcciones y muestra cómo se traduce la información de paquetes para un dispositivo mediante una combinación de traducción con estado en el traductor del lado del proveedor (PLAT) y traducción sin estado en el traductor del lado del cliente (CLAT). En este diagrama, se delega al cliente un prefijo IPv6 desde un mecanismo de delegación de prefijos como la delegación de prefijos DHCPv6 (DHCPv6-PD). Por lo tanto, el cliente tiene un prefijo IPv6 dedicado para la traducción.
464XLAT ALG
Las ALG PPTP, RTSP y FTP también admiten la funcionalidad XLAT.
En las secciones siguientes se explica cómo funcionan las ALG PPTP, RTSP y FTP cuando el dispositivo actúa como PLAT:
Cómo el ALG PPTP admite que el dispositivo actúe como PLAT
La figura 3 describe la funcionalidad PPTP ALG XLAT.
PPTP ALG XLAT
El ALG PPTP utiliza la call_ID para la funcionalidad del puerto de destino.
The client sends the outgoing call request (with PPTP Access Concentrator (PAC) call_ID) to the server:
CLAT: La dirección o puerto de origen se traduce de Ipv4_1/puerto1 a Ipv6_1/puerto1. Sin embargo, la call_ID de carga no cambia.
PLAT: La dirección de origen/puerto Ipv6_1/puerto1 se traduce a Ipv4_1'/puerto1' y coincide con la regla NAT64. Sin embargo, el call_ID en la carga útil no cambia. El ALG PPTP crea una puerta como 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: Cuando el primer tráfico GRE llega a la puerta, el paquete GRE del lado del servidor con destino Ipv4_1'/call_ID se traduce a Ipv6_1/call_ID. Finalmente, el paquete GRE llega al cliente Ipv4_1/call_ID después de CLAT.
Another special case for call_ID 0:
CLAT: La dirección o puerto de origen se traduce de Ipv4_1/puerto1 a Ipv6_1/puerto1. Sin embargo, la call_ID de carga no cambia.
PLAT: La dirección de origen/puerto Ipv6_1/puerto1 se traduce a Ipv4_1'/puerto1' y coincide con la regla NAT64. Sin embargo, el call_ID 0 en la carga se traduce manualmente a 65002. El ALG PPTP crea una puerta como server_ip/0->Ipv4_1'/65002(Ipv6_1/0).
The first GRE packet reaches the gate from the server side: Cuando el primer tráfico GRE llega a la puerta, el paquete GRE del lado del servidor con destino Ipv4_1'/65002 se traduce a Ipv6_1/0. Finalmente, el paquete GRE llega al cliente Ipv4_1/0 después de CLAT.
The server sends the outgoing call reply (with PPTP Network Server (PNS) and PAC call_ID) to the client:
PLAT: La dirección de origen/puerto Ipv4_2/puerto2 se traduce a Ipv6_2/puerto2' y coincide con la regla NAT64. Sin embargo, el call_ID de la carga útil no cambia y el ALG PPTP crea una puerta como client_v6/0->Ipv6_2/call_ID(Ipv4_2/call_ID).
CLAT: La dirección o puerto de origen se traduce de Ipv6_2/puerto2 a Ipv4_2/puerto2. Sin embargo, la call_ID de carga no cambia.
The first GRE packet reaches the gate from the client side: Cuando el primer tráfico GRE llega a la puerta, el paquete GRE del lado del cliente con destino Ipv4_2'/call_ID se traduce a Ipv6_2/call_ID después de CLAT y luego se traduce a Ipv4_2/call_ID. Finalmente, el paquete GRE llega al servidor Ipv4_2/call_ID después de PLAT.
Another special case for call_ID 0:
PLAT: La dirección de origen/puerto Ipv4_2/puerto2 se traduce a Ipv6_2/puerto2' y coincide con la regla NAT64. Sin embargo, el call_ID en la carga útil se traduce a 65002 y el ALG PPTP crea una puerta como client_v6/0->Ipv6_2/65002(Ipv4_2/0).
CLAT: La dirección o puerto de origen se traduce de Ipv6_2/puerto2 a Ipv4_2/puerto2. Sin embargo, la call_ID de carga no cambia.
The first GRE packet reaches the gate from the client side: Cuando el primer tráfico GRE llega a la puerta, el paquete GRE del lado del cliente con destino Ipv4_2'/65002 se traduce a Ipv6_2/65002 después de CLAT y, a continuación, se traduce a Ipv4_2/0. Finalmente, el paquete GRE llega al servidor Ipv4_2/0 después de PLAT.
Cómo el ALG RTSP admite el dispositivo que actúa como PLAT
La figura 4 describe la funcionalidad RTSP ALG XLAT.
RTSP ALG XLAT
The Windows Media Player on the Windows PC sends a SETUP message:
CLAT: La dirección o puerto de origen se traduce de Ipv4_1/puerto1 a Ipv6_1/puerto1. Sin embargo, la carga útil Ipv4_2/puerto3 no cambia.
PLAT: La dirección de origen/puerto Ipv6_1/puerto1 se traduce a Ipv4_1'/puerto1' y coincide con la regla NAT64, y el puerto de carga 3 se traduce a puerto 3'. Sin embargo, la dirección IP en el ULR de la carga útil permanece sin cambios.
The Windows Media Server on the Windows server sends a 200 OK message:
PLAT: La dirección de origen/puerto Ipv4_1'/puerto1' se traduce a Ipv6_1/puerto1 y coincide con la regla NAT64. Sin embargo, el port4 de la carga no cambia. El port3' se traduce a port3. El ALG RTSP crea puertas como c->s Ipv6_1/port1->Ipv6_2/port3 y s->c Ipv4_2/port4->Ipv4_1'/port3' sobre datos multimedia UDP enviados desde el lado del servidor con destino Ipv4_1'/port1', luego el encabezado IP se traduce a Ipv6_1/port1 y llega a la puerta.
CLAT: La dirección o puerto de origen se traduce de Ipv6_1/puerto1 a Ipv4_1/puerto1. Sin embargo, el puerto de carga 3/puerto4 no cambia.
The server sends the Real-Time Transport Protocol (RTP) over UDP media data:
PLAT: Cuando los datos multimedia RTP sobre UDP se envían desde el lado del servidor con destino Ipv4_1'/port3, el encabezado IP se traduce a Ipv6_1/port3 y llega a la puerta.
CLAT: El encabezado IP se traduce de Ipv6_1/port3 a Ipv4_1/port3.
The client sends the RTP over UDP media data:
CLAT: La dirección o puerto de origen se traduce de Ipv4_1/puerto3 a Ipv6_1/puerto3 y la dirección de destino se traduce de Ipv4_2/puerto4 a Ipv6_2/puerto4.
PLAT: La dirección o puerto de origen se traduce de Ipv6_1/port3 a Ipv4_1'/port3 y la dirección de destino se traduce de Ipv6_2/port4 a Ipv4_2/port4.
Cómo el ALG de FTP admite que el dispositivo actúe como PLAT
La Figura 5 y la Figura 6 describen la funcionalidad FTP ALG XLAT en modo pasivo y modo puerto.
A 227 message enters passive mode:
CLAT: La dirección o puerto de origen se traduce de Ipv4_1/puerto1 a Ipv6_1/puerto1. Sin embargo, la carga no contiene información de IP o puerto.
PLAT: La dirección de origen/puerto Ipv4_1'/puerto1' se traduce a Ipv6_1/puerto1 y coincide con la regla NAT64. Sin embargo, el Ipv4_2/port3 de la carga no cambia y el ALG de FTP crea una puerta como Ipv4_1/0(Ipv6_1/0)->Ipv4_2/port3.
The first packet reaches the gate from the client side: Cuando el tráfico llega a la puerta, el paquete de fecha del lado del cliente con destino Ipv4_2/puerto3 se traduce a Ipv6_2/puerto2. El encabezado IP se traduce a Ipv4_2/port3 mediante la regla NAT64 basada en PLAT.
puerto FTP
FTP port mode sends a PORT message:
CLAT: La dirección/puerto de origen se traduce de Ipv4/port1 a Ipv6/port1.
PLAT: La dirección/puerto de origen es Ipv6_1/port1 se traduce a Ipv4_1'/port1' y coincide con la regla NAT64. El Ipv4_1/port2 de la carga se traduce a Ipv4_1'/port2' y el ALG FTP crea una puerta como Ipv4_1'/port2'(Ipv4_1/port2->server_ip/server_port.
The first packet reaches the gate from the server side: Cuando el tráfico llega a la puerta, el primer paquete del lado del servidor con destino Ipv4_1'/port2' se traduce a Ipv6_1/port2. Finalmente, el paquete llega al cliente Ipv4_1/puerto2 antes de CLAT.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.