Documentación > Introducción > Mecanismos de Transición
Introducción a la Traducción IPv4/IPv6
Índice
Introducción
Este documento proporciona una introducción general a SIIT y NAT64.
Traducción IPv4/IPv6
SIIT (Stateless IP/ICMP Translation) y NAT64 (“NAT seis cuatro”, no “NAT sesenta y cuatro”) son tecnologías orientadas a comunicar nodos de red que únicamente hablan IPv4 con nodos que solo hablan IPv6.
Ambos son básicamente una “actualización” de NAT. Un “Traductor IPv4/IPv6” no solamente remplaza direcciones y/o puertos dentro de los paquetes, sino también los encabezados de las 3 capas.
- SIIT es la forma más simple, y permite mapeos preconfigurados 1-a-1 entre direcciones IPv4 e IPv6.
- Stateful NAT64, NAT64 para abreviar, pemite que varios nodos IPv6 dinámicamente compartan unas pocas direcciones IPv4. Esto le será muy útil si es víctima del agotamiento de las direcciones de IPv4.
Por razones históricas, algunas veces etiquetamos erróneamente a SIIT como “Stateless NAT64”. Ya que esta expresión no está incluida en ningún estándar relevante, la consideramos imprecisa, a pesar de que tiene cierto grado de sentido. Si es posible, por favor trate de evitarla.
Una implementación SIIT segmenta los encabezados de red y en ocasiones los checksums de transporte. En un Stateful NAT64 también manipula los identificadores de transporte.
Esto es realmente todo. Continue leyendo para más detalles y ejemplos.
SIIT con EAM
Esta es la modalidad más sencilla de explicar. Considere la siguiente configuración:
(T representa “traductor”.)
Asumiendo que la puerta de enlace por default de todos es T, comó se podría comunicar A (IPv6) con V (IPv4)?
- Se le indica a T, “La dirección IPv4 de A debe de ser 198.51.100.8,
y la dirección IPv6 de V debe de ser 2001:db8:4::16”. - Se le indica a A, “la dirección de V es 2001:db8:4::16”.
- Se le indica a V, “la dirección de A es 198.51.100.8 “.
La primera es traducida por SIIT, las otras pueden ser hechas vía DNS.
Esto es lo que va a suceder:
El traductor esta “engañando” a ambos nodos, haciéndoles pensar que el otro puede hablar su mismo protocolo.
“EAM” es abreviación de “Explicit Address Mapping” (Mapeo Explícito de Direcciones), y es más versátil que simples asociaciones entre diferentes direcciones arbitrarias.
Más detalles sobre EAM pueden encontrarse en este resumen o en el documento de la IETF.
SIIT (tradicional)
El modo básico es más constrictivo. Por lo tanto, es necesario modificar la red:
Para lograr la comunicación entre A y V bastaría con establecer lo siguiente:
- Se le indica a T, “Tu prefijo de traducción es 2001:db8::/96”.
- Se le indica a A, “la dirección de V es 2001:db8::192.0.2.16”.
- Se le indica a V, “la dirección de A es 198.51.100.8”.
La idea es simplemente remover el prefijo de traducción en la dirección IPv6 a IPv4, y adjuntarlo en el otro sentido. Este sería el flujo:
Por supuesto, esto significa que la dirección IPv4 de cada nodo en IPv6 tiene que ser codificada dentro de su dirección IPv6, lo cual es un poco engorroso.
Podría parecer que “SIIT con EAM” y “SIIT tradicional” son cosas diferentes, pero en realidad son suscriptores de la misma idea básica (mapeo de direcciones 1 a 1). Es posible tener un prefijo de traducción y una EAMT al mismo tiempo; en despliegues de este tipo, el traductor intenta primeramente convertir direcciones consultando la tabla EAM, y si no lo logra, retrocede y usa el prefijo en su lugar.
Puedes encontrar un ejemplo concreto de cómo SIIT “tradicional” y SIIT “EAM” pueden ser combinados para cumplir un caso de uso en draft-v6ops-siit-dc.
Dependiendo de la longitud del prefijo, la dirección IPv4 se incorporará en diferentes posiciones dentro de la dirección de IPv6. Puede encontrarse más información en el RFC 6052.
Siempre que el RFC 6052 esté involucrado, es conveniente dar de alta también un DNS64 para que los usuarios no necesiten estar al tanto del prefijo, y resuelva por nombre.
Stateful NAT64
Este modo es más parecido a lo que la gente entiende como NAT (Network Address Translator). Por lo tanto, es conveniente recordar cómo opera un NAT:
Note que la red de la izquierda es llamada “Privada” porque usa direcciones no disponibles en la Internet Global. NAT modifica las direcciones de los paquetes para que los nodos externos piensen que el tráfico proveniente de los nodos internos fue en realidad iniciado por él mismo:
Desde el punto de vista del operador, los nodos A, B, C, D, E y NAT están “compartiendo” la(s) dirección(es) global(es) de NAT.
NAT ayuda a reducir el empleo de direcciones globales en Internet de IPv4, pero tiene un precio: NAT es stateful; tiene que recordar por cierto tiempo qué nodo privado emitió el paquete a V, porque la dirección de A fue completamente borrada durante el enmascarado. Si NAT se olvida de A, no tiene cómo saber a quién va dirigida la respuesta de V.
Dos cosas que hay que tomar en cuenta es:
- Cada mapeo require memoria.
- V no puede iniciar la comunicación con A, porque primeramente el NAT debe aprender el mapeo en el sentido de la Red_Privada-a-Red_Externa (de izquierda a derecha).
Si quieres saber más sobre NAT, consulta los RFCs 2663 y 3022.
Stateful NAT64 es muy similar a NAT. Conceptualmente, la única diferencia es que la “Red Privada” es de hecho una red (pública) de IPv6:
Para lograr la comunicación entre A y V bastaría con establecer lo siguiente:
- Se le indica a A, “la dirección de V es 2001:db8::203.0.113.16”.
- A V no se le indica nada; él cree que está hablando con T.
- Se le indica a T, “Usa tu dirección para enmascarar a A”.
La idea es reemplazar la dirección de A y remover el prefijo a V durante la traducción de IPv6 a IPv4, y adjuntar el prefijo en V y quitar la máscara en el sentido contrario.
El punto de NAT64 es que los nodos de IPv6 no se ocultan detrás de un único gateway hacia IPv4; por el contrario, T solamente desemboca hacia la “subred” que es el Internet de IPv4. El Internet de IPv6 es alcanzable desde otro gateway:
De esta manera, los nodos A hasta E son solo de IPv6, pero tienen acceso a ambas Internets. A la IPv6 mediante un ruteador R, y a la IPv4 mediante T.
Si gustas conocer el resto de los escenarios posibles en Stateful NAT64 y SIIT consulta el RFC 6144, cap. 2.
Para soportar direccionamiento por nombre se requiere habilitar el DNS64.
Nota Histórica
Sobre el orígen y desarrollo de estas metodologías:
-
El algoritmo para SIIT fue definido formalmente a inicios del 2000 por Erik Nordmark de SUN Microsystems en el RFC 2765. Este ha sido actualizado en varias ocasiones: (RFC 6145, 2011), (RFC6791, 2012) e inclusive hasta nuestros días. De éstos, ya están incluidos en Jool el (draft-ietf-v6ops-siit-dc, 2015), el (draft-ietf-v6ops-siit-dc-2xlat, 2015) y el (draft-anderson-v6ops-siit-eam, 2015). Estas tres adiciones a SIIT han sido propuestas y promovidas por Tore Anderson de la compañía Redpill Linpro en Noruega.
-
El algoritmo de Stateful NAT64 fue uno de los resultados del Proyecto Trilogy, organizado por la Unión Europea, con una inversión aprox. de 9 millones de Euros, por un período de 3 años (2008 al 2010) donde participaron 5 Universidades, 4 compañías de telecomunicación y 2 centros de investigación. El estándar para el NAT64 que es el RFC 6146 fue publicado en el 2011 por el mismo coordinador del projecto, el Dr. Marcelo Bagnulo Braun de la Universidad Carlos III y otros dos colaboradores del proyecto.
-
Conoce más trabajos elaborados por la IETF acerca de NAT64 en TOOLS IETF y en Datatracker.