Introducción A La Traducción de IPv4 - IPv6

12/10/21, 11:26 AM Introducción a la traducción de IPv4 / IPv6
Traducido al: español Mostrar texto original Opciones ▼
Documentación > Introducción > ¿Qué es SIIT / NAT64?
Introducción a la traducción de IPv4 / IPv6

Índice
1. Introducción
2. Traducción de IPv4 / IPv6
1. AQUÍ (EAMT)
2. AQUÍ (tradicional)
3. AQUÍ-DC
4. Traducción dual SIIT-DC
5. NAPT
6. NAT64 con estado
7. 464XLAT
8. MAP-T
Introducción
El objetivo de este documento es proporcionar una introducción sencilla a las técnicas de traducción de IP conocidas
actualmente por este desarrollador de software en particular.
Se supone que el lector tiene conocimientos básicos de IPv4 , IPv6 y TCP y / o UDP . Se recomienda estar
familiarizado con DNS y enrutamiento estático. No es necesario estar familiarizado con otros protocolos circundantes
(como ARP, ND y Ethernet).
Recuerde que 2001: db8 :: / 32, 192.0.2 / 24, 198.51.100 / 24 y 203.0.113 / 24 son prefijos de
documentación (definidos en las RFC 3849 y 5737 ) con los que puede experimentar, pero debe
reemplazarlos una vez que cree implementaciones públicas reales.
Por favor, avíseme si tiene comentarios sobre esta documentación.
Traducción de IPv4 / IPv6

Aquí hay un problema: IPv4 e IPv6 no son compatibles entre sí. Un nodo que solo habla IPv4 no puede interactuar
directamente con un nodo que solo habla IPv6.
Similar a contratar un traductor humano para que personas de diferentes culturas se entiendan entre sí, un "traductor
de IP" es un dispositivo (o en ocasiones un servicio) que se coloca entre nodos de red que hablan diferentes protocolos
de IP con la intención de intercambiar datos.
Un paquete IPv4 típico consta de un encabezado IPv4, un encabezado TCP (o UDP) y un bloque de carga útil:
https://www.jool.mx/en/intro-xlat.html 1/27
Version IHL TOS Total Length

Identification Flags Fragment Offset
TTL Protocol
Source IP Address
Header Checksum IPv4 Header
Destination IP Address
Source Port Destination Port
Sequence Number
D. Offset Flags
Acknowledgment Number
Window Size
TCP Header
Checksum Urgent Pointer
Payload
Por el contrario, un paquete IPv6 típico consta de un encabezado IPv6, un encabezado TCP (o UDP) y un bloque de
carga útil:
Version IHL Flow Label

Payload Length Next Header Hop Limit
Source IP Address
IPv6 Header
Destination IP Address
Source Port Destination Port

Sequence Number
D. Offset Flags
Acknowledgment Number
Window Size
TCP Header
Checksum Urgent Pointer
Payload
La tarea de un traductor de IP, entonces, es reemplazar los encabezados de IP entrantes, dejando los datos reales sin
modificar:
T
Hello! Hello!
A veces, el encabezado TCP / UDP también debe ajustarse ligeramente, pero llegaremos a eso más
adelante
adelante.
La mayor parte de la traducción del encabezado es sencilla. Por ejemplo, el campo "Protocolo" de IPv4 es
básicamente el mismo que el campo "Encabezado siguiente" de IPv6. IPv4 “TTL” es lo mismo que IPv6 “Límite de
saltos”, etc. La única parte en la que se vuelve táctico son las direcciones IP. En gran medida, las estrategias de
traducción de direcciones son las que separan a los diferentes tipos de traductores de los demás.
La mayoría de los mecanismos de traducción de IP fueron diseñados por el Grupo de Trabajo de Ingeniería de
Internet (IETF) y formalmente definidos en varios RFC diferentes (que se enumeran en las secciones dedicadas de sus
traductores correspondientes a continuación).
En general, existen tres tipos básicos diferentes de traductores de IP:
1. SIIT (también conocido como "NAT64 sin estado". Quizás se podría decir que también se lo conoce como
"NAT46". YMMV).
2. NAT64 con estado (deletreado “NAT-six-four”, no “NAT-sixty-four”).
3. MAP-T
Estos, junto con las diferentes estrategias de traducción de direcciones disponibles, se explicarán en las siguientes
secciones.
AQUÍ (EAMT)
Este es el más fácil de explicar. Considere la siguiente configuración:
2001:db8:6::/96 192.0.2.0/24
::8 .16
A V
B ::9 .17 W
::a ::1 .1 .18

C T X
::b .19
D Y
E ::c .20 Z
( T significa "traductor").
Suponiendo que la puerta de enlace predeterminada de todos es T , ¿cómo se comunica A (IPv6) con V (IPv4)?
Le dice a T (por configuración SIIT-EAM): "Cambie 2001: db8: 6 :: 8 a 203.0.113.8 y 192.0.2.16 a 2001: db8: 4
:: 16 ".
Le dice a A (generalmente por DNS): " La dirección de V es 2001: db8: 4 :: 16 ".
Usted le dice a V (por lo general por el DNS): “ Una dirección‘s es 203.0.113.8 .”
Esto es lo que va a ocurrir:
A T V
2001:db8:6::8 192.0.2.16
2+2=?
src: 2001:db8:6::8
dst: 2001:db8:4::16 2+2=?
src: 203.0.113.8
dst: 192.0.2.16
src: 192.0.2.16
4 dst: 203.0.113.8
src: 2001:db8:4::16
dst: 2001:db8:6::8
El traductor está "engañando" a cada nodo haciéndole creer que el otro puede hablar su idioma. Es una estrategia de
traducción de direcciones en la que asigna direcciones específicas a nodos específicos sin que ellos se den cuenta.
¡USO!
En otras palabras, usaría un traductor SIIT (EAM) cuando tenga un número limitado de nodos IPv6 que
deseen interactuar con un número limitado de nodos IPv4 . Ya sea asignado explícita o implícitamente,
cada nodo participante necesitará tanto una dirección IPv4 dedicada como una dirección IPv6 dedicada
para funcionar.
Por un lado, "SIIT" significa "Traducción de IP / ICMP sin estado" o, en nuestro caso, "Traductor de IP / ICMP sin
estado".
De hecho, eso no es estrictamente cierto. De acuerdo con la especificación oficial , "SIIT" significa "
Algoritmo de traducción IP / ICMP sin estado ", lo cual es algo incómodo. Hasta donde yo sé, lo más
cercano que tienen los traductores SIIT a un nombre oficial es “traductor apátrida”, pero en realidad no
está definido por ningún glosario. Y no parece tener en cuenta que los MAP-Ts también sean "apátridas"
y "traductores". Por otra parte, con ese argumento también se podría decir que los MAP-Ts también son
“traductores de IP / ICMP sin estado”, pero ya he arrastrado demasiado este hilo de pensamiento.
Desde mi experiencia personal, el IETF tiende a tener dificultades para mantener una terminología
precisa, por lo que le recomiendo que tampoco pierda el sueño. Los llamamos "SIIT". Es posible que vea
que se refieren a ellos como de otro modo en otros lugares.
Un SIIT es un dispositivo (o servicio) de capa de red que simplemente intercambia direcciones IPv4 e IPv6 de
acuerdo con un mecanismo de traducción de direcciones estáticas preconfigurado.
Por otro lado, la "Tabla de asignación de direcciones explícita" (EAMT) es el mecanismo de traducción de direcciones
específico en juego aquí. Es una tabla en la que cada fila asigna una dirección IPv4 arbitraria a sus direcciones IPv6
correspondientes y viceversa.
Aquí hay un ejemplo de un EAMT que permitiría la comunicación entre todos los nodos de la red que se muestra
arriba:
IPv6 IPv4
2001: db8: 6 :: 8 203.0.113.8
2001: db8: 6 :: 9 203.0.113.9
2001:db8:6::a 203.0.113.10
2001: db8: 6 :: b 203.0.113.11
2001: db8: 6 :: c 203.0.113.12
2001: db8: 4 :: 16 192.0.2.16
2001: db8: 4 :: 17 192.0.2.17
2001: db8: 4 :: 18 192.0.2.18
2001: db8: 4 :: 19 192.0.2.19
2001: db8: 4 :: 20 192.0.2.20
Dada la configuración anterior, los nodos IPv6 perciben la red así:
2001:db8:6::/96 2001:db8:4::/96
::8 ::16
A V
B ::9 ::17 W
::a ::1 ::1 ::18

C X
T
::b ::19
D Y
E ::c ::20 Z
Y a la inversa, se ve así desde el lado de IPv4:
203.0.113.0/24 192.0.2.0/24
.8 .16
A V
B .9 .17 W
.10 .1 .1 .18
C X
T
.11 .19
D Y
E .12 .20 Z
He simplificado el EAMT aquí con fines ilustrativos. En realidad, es más versátil que simplemente permitirle vincular
direcciones individuales arbitrarias a otras direcciones únicas arbitrarias Puede encontrar más información en su
direcciones individuales arbitrarias a otras direcciones únicas arbitrarias. Puede encontrar más información en su
especificación formal, RFCal:7757
Traducido . La documentación
español deoriginal
Mostrar texto Jool también tiene un pequeño resumen . Opciones ▼
AQUÍ (tradicional)
En realidad, esta es la forma de SIIT diseñada originalmente y, como tal, es más constrictiva. Necesitamos cambiar la
red IPv6 de muestra para que funcione:
2001:db8::cb00:7100/120 192.0.2.0/24
(2001:db8::203.0.113.0/120)
::8 .16
A V
B ::9 .17 W
::a ::1 .1 .18

C T X
::b .19
D Y
E ::c .20 Z
La idea es simplemente eliminar un prefijo mientras se traduce de IPv6 a IPv4, y anteponerlo en la otra dirección:
A T V
2001:db8::203.0.113.8 192.0.2.16
2+2=?
src: 2001:db8::203.0.113.8
dst: 2001:db8::192.0.2.16 2+2=?
src: 203.0.113.8
dst: 192.0.2.16
src: 192.0.2.16
4 dst: 203.0.113.8
src: 2001:db8::192.0.2.16
dst: 2001:db8::203.0.113.8
Como puede ver, este mecanismo de traducción permite convertir cualquier dirección IPv4 en una dirección IPv6
mediante un simple prefijo IPv6 configurable. Sin embargo, lo contrario no es cierto. Una dirección IPv6 necesita una
dirección IPv4 válida, pública e integrada (además del prefijo) para ser traducible. Su kilometraje puede variar en
cuanto a la viabilidad de cumplir con esto.
¡USO!
Utilizaría un SIIT tradicional cuando tenga un número limitado de nodos IPv6 que deseen interactuar con
Utilizaría un SIIT tradicional cuando tenga un número limitado de nodos IPv6 que deseen interactuar con
cualquier número deal:
Traducido nodos IPv4 . AlMostrar
español igual que con
texto EAM SIIT, cada participante necesitará direcciones
original Opciones ▼
IPv4 e IPv6 (explícitas o implícitas).
(Puede notar que las direcciones IPv4 tienen una longitud de 32 bits, que es exactamente la longitud del
sufijo de nuestro prefijo de traducción (128 - 96). En otras palabras, la totalidad literal de Internet IPv4
encaja cómodamente en la cola de 2001: db8: : .)
Sin embargo, tenga en cuenta que el SIIT tradicional impone restricciones a sus direcciones IPv6, lo que
puede resultar poco práctico.
Cuando SIIT se concibió originalmente, lo que llamamos modo "tradicional" era el único algoritmo de
traducción de direcciones sin estado que se esperaba que existiera. Por esta razón, se podría suponer, no
se le dio un nombre oficial. Después de una búsqueda rápida, las especificaciones de IETF tienden a
aludir a él con descriptores como el "algoritmo de asignación de direcciones sin estado definido en
[RFC6052]", el "formato de dirección IPv6 integrado en IPv4" o el "algoritmo [RFC6052]". Nuevamente,
este nombre es desagradable para mí, por lo que para los propósitos de esta documentación (no solo esta
introducción, sino toda la documentación de Jool), usaremos el apodo " tradicional " no oficial para
referirnos al algoritmo, y " pool6 " para referirnos al prefijo.
¿Por qué “pool6”? Porque así es como se llama en el código y la configuración de Jool.
(Para ser perfectamente honesto, "tradicional" es un nombre poco apropiado, porque solía existir una
versión aún más antigua y más simple del algoritmo, pero fue obsoleto por RFC 6145 en 2011.)
La vista de IPv6 es seguida por la vista de IPv4:
2001:db8::cb00:7100/120 2001:db8::c000:0200/120
(2001:db8::203.0.113.0/120) (2001:db8::192.0.2.0/120)
::8 ::10 (.16)

A V
B ::9 ::11 W
::a ::1 ::1 ::12

C X
T
::b ::13
D Y
E ::c ::14 Z
203.0.113.0/24 192.0.2.0/24
.8 .16
A V
B .9 .17 W
.10 .1 .1 .18
C X
T
.11 .19
D Y
E .12 .20 Z
C i ó d
https://www.jool.mx/en/intro-xlat.html
t l d fi i ió f ld l l it d t d ió d di i t di i l 7/27
Como ya se mencionó, puede encontrar la definición formal del algoritmo de traducción de direcciones tradicional en
Traducido al: español
RFC 6052 . La documentación Mostrar
de Jool también texto
tiene un original
resumen . Opciones ▼
AQUÍ-DC
SIIT-DC ( SIIT para entornos de centros de datos IPv6 ) es más una arquitectura que un mecanismo de traducción de
direcciones dedicado, pero lo incluyo aquí porque (a) es un escenario sin estado útil y mucho más realista que debe
mantener en mente, y (b) es una oportunidad perfecta para mostrar al EAMT y al pool6 trabajando en concierto.
Así que aquí está la cosa:
Podría haberle dado la impresión de que “EAMT” SIIT y “tradicional” SIIT se refieren a diferentes tipos de
traductores. Este no es el caso; esto es todo SIIT. Se espera que una implementación moderna siempre intente traducir
una dirección basada en el EAMT primero, y si no se encuentra un mapeo, recurra para agregar o eliminar pool6. La
separación se realizó anteriormente solo con fines ilustrativos.
Suponga que tiene un centro de datos solo para IPv6. Para ahorrar espacio, lo mostraremos para tener solo dos
servidores. s6a solo debe ser accedido por clientes IPv6 remotos, pero resulta que s6b one también debe ser accedido
desde IPv4:
Data Center
c6
IPv6
s6a 2001:db8::ab:cd
2001:db8:12:34::6a
s6b
2001:db8:12:34::6b c4
BR IPv4
192.0.2.4
Un Border Relay (BR) es solo una puerta de enlace, que en el contexto SIIT-DC es simplemente un
traductor SIIT. (O varios idénticos, si desea redundancia).
Basically, the pool6 prefix is only used to mask IPv4 Internet nodes (which is a pattern you will see often from now
on, because it works well), whereas the EAMT is used to mask your IPv6 servers.
Suppose BR has the following configuration:
pool6:
64:ff9b:1::/96
EAMT:
IPv6 IPv4
2001:db8:12:34::6b 203.0.113.6
(Add one EAM entry for every other server you want available from IPv4.)
Here’s the expected packet flow between your EAM’d server and a random IPv4 Internet client:
c4 s6b
BR
192.0.2.4 2001:db8::12:34::6b
2+2=?
src: 192.0.2.4
dst: 203.0.113.6 2+2=?
src: 64:ff9b:1::192.0.2.4
dst: 2001:db8::12:34::6b
src: 2001:db8::12:34::6b
4 dst: 64:ff9b:1::192.0.2.4
src: 203.0.113.6
dst: 192.0.2.4
USAGE!
In this way, any IPv4 Internet node can access your EAM’d servers, and only your EAM’d servers can
respond. You are also not forced to assign constrained IPv6 addresses to your servers, effectively gaining
the advantages of both traditional and EAM, and the drawbacks of neither. It is also worth
mentioning that most of your Data Center enjoys the simplicity of IPv6-only, since IPv4 has been
relegated into a “service.”
Much like the documentation prefixes, “64:ff9b:1::/48” is officially reserved, and it’s publicly known
as the “Local-Use IPv4/IPv6 Translation Prefix.” You can use it freely for translation purposes in your
network, as long as you don’t route it globally. If you’re curious, it’s defined in RFC 8215.
Tenga en cuenta que el traductor no afecta de ninguna manera el tráfico IPv6 puro:
c6 s6b
2001:db8::ab:cd 2001:db8::12:34::6b
2+2=?
src: 2001:db8::ab:cd
dst: 2001:db8::12:34::6b 2+2=?
src: 2001:db8::ab:cd
dst: 2001:db8::12:34::6b
src: 2001:db8::12:34::6b
4 dst: 2001:db8::ab:cd
src: 2001:db8::12:34::6b
dst: 2001:db8::ab:cd
Naturalmente, en cuanto a DNS, el registro A de s6b debería ser 203.0.113.6 , y su registro AAAA debería ser 2001:
db8: 12: 34: 1 . Como de costumbre, efectivamente le ha dado a s6b una pila dual (es decir, capacidades tanto de IPv4
como de IPv6) sin que él lo sepa.
Así es como s6b ve la red:
Data Center
c6
IPv6
s6a 2001:db8::ab:cd
2001:db8:12:34::6a
s6b
2001:db8:12:34::6b 64:ff9b:1::/96 c4
network
BR
64:ff9b:1::192.0.2.4
Así es como s6a y c6 ven la red:
Data Center
c6
IPv6
s6a 2001:db8::ab:cd
2001:db8:12:34::6a
s6b
2001:db8:12:34::6b BR
Y esta es la vista c4 :
Data Center
s6b c4
IPv4
BR
203.0.113.6 192.0.2.4
SIIT-DC se define formalmente en RFC 7755 .
SIIT-DC: modo de traducción dual

A pesar de que su objetivo final puede ser un centro de datos solo para IPv6, los servicios que aún son completamente
incompatibles con IPv6 no son desconocidos.
No puede proporcionar estas pilas de IPv6, pero si aún desea tener un centro de datos mayoritariamente IPv6, puede
aislarlos en pequeñas islas IPv4 y conservar la mayor parte de su infraestructura IPv6. Esta técnica se conoce como
“SIIT-DC: Modo de traducción dual” (SIIT-DC-2xlat).
¡USO!
Bueno, esto es solo un resumen de los dos párrafos anteriores. Utilizaría un SIIT-DC-2xlat cuando desee
un SIIT-DC, pero también necesita islas IPv4 como solución para el software heredado.
Data Center
c6
IPv6
s6a 2001:db8::ab:cd
2001:db8:12:34::6a
s6b
2001:db8:12:34::6b c4
BR IPv4
192.0.2.4
s4
ER
pool6:
203.0.113.4 64:ff9b:1::/96
EAMT:
IPv6 IPv4
pool6: 2001:db8:12:34::6b 203.0.113.6
64:ff9b:1::/96
2001:db8:12:34::4 203.0.113.4
EAMT:
IPv6 IPv4
2001:db8:12:34::4 203.0.113.4
En el contexto de SIIT-DC-2xlat, un traductor que sirve a una isla específica se llama Edge Relay
(ER). Nuevamente, es solo un SIIT normal.
Este es el flujo de paquetes esperado para estos pequeños infieles:
c4 s4
BR ER
192.0.2.4 203.0.113.4
2+2=?
src: 192.0.2.4
dst: 203.0.113.4 2+2=?
src: 64:ff9b:1::192.0.2.4
dst: 2001:db8:12:34::4 2+2=?
src: 192.0.2.4
dst: 203.0.113.4
src: 203.0.113.4
4 dst: 192.0.2.4
src: 2001:db8:12:34::4
4 dst: 64:ff9b:1::192.0.2.4
src: 203.0.113.4
dst: 192.0.2.4
El resto de la red es SIIT-DC normal.
Las vistas c6 , s6a y s6b son las mismas que en SIIT-DC. La nueva vista c4 es
Data Center
s6b c4
IPv4
BR
203.0.113.6 192.0.2.4
s4
ER
203.0.113.4
y la vista s4 es
Data Center
s4 c4
IPv4
ER BR
203.0.113.4 192.0.2.4
SIIT-DC-2xlat está formalmente definido por RFC 7756 .
NAPT
La traducción de direcciones y puertos de red (NAPT) (generalmente conocida como “NAT” o, más específicamente,
“NAT con estado”) no es un mecanismo de traducción de IPv6 / IPv4, pero podría ayudarlo a comprender la NAT64
con estado debido a sus similitudes.
Por lo tanto, esta sección es un recordatorio de cómo funciona NAPT.
192.168.0.0/24 203.0.113.0/24
(Private Network)
.8 .16
A V
.9 .17
B W
C .10 .1 .1 .18 X
T
NAP
.11 .19
D Y
.12 .20
E Z
NAPT es un truco cuyo propósito es minimizar la cantidad de direcciones IPv4 globales ("reales") que gasta en los
nodos de "Red privada". (¿ Por qué? Porque el mundo oficialmente se ha quedado sin direcciones IPv4 ).
Básicamente, a la red izquierda se le han asignado direcciones 192.168 "falsas" (es decir, direcciones IPv4 "privadas"
), y el trabajo de la máquina NAPT es permutar direcciones de transporte de paquetes con el objetivo de hacerse pasar
por los nodos privados. Engaña a los forasteros haciéndoles pensar que el tráfico iniciado por los nodos privados en
realidad se inició por sí mismo:
A NAP
T V
192.168.0.8:1234
2+2=?
src: 192.168.0.8:1234
dst: 203.0.113.16:80
Aquí está la disposición: Un quiere solicitar una HTTP de recursos de V . Por lo tanto, envía un paquete a
203.0.113.16 : 80 . La dirección de origen es su propia IP, mientras que el puerto de origen se eligió al azar cuando se
enlazó el socket. Todo esto es normal e independiente de NAPT .
A NAP
T V
(1)
192.168.0.8:1234 203.0.113.16:80 203.0.113.1:5678
(3)
I better remember that
192.168.0.8:1234
(2)
is being masked as 2+2=?
203.0.113.1:5678.
src: 203.0.113.1:5678
dst: 203.0.113.16:80
Cuando A ‘s primero paquete llega a NAPT , este último da cuenta de que carece de una asignación para 192.168.0.8 :
1234 , por lo que se abre un nuevo socket (1) hacia la V . (Nuevamente, la dirección de origen es su propia IP,
mientras que el puerto de origen se elige al azar).
A partir de ahora, actuará como intermediario y procederá a copiar los datos recibidos de un socket al otro (2) .
Dado que no existe una relación algorítmica entre la dirección de transporte privado y su correspondiente dirección de
transporte público de enmascaramiento (es decir, se puede usar cualquier dirección pública para enmascarar cualquier
socket privado), el NAPT mantiene una tabla dinámica (3) que recuerda las asignaciones (donde "mapeo ”Se define
como un enlace entre dos sockets). En este caso, almacena la relación entre 192.168.0.8 : 1234 y 203.0.113.1 : 5678
(entre otros):
T
NAP
Private Public
192.168.0.8:1234 203.0.113.1:5678
192.168.0.9:5000 203.0.113.1:8523
... ...
Luego, el mapeo se usa para correlacionar los dos sockets para cada paquete subsiguiente en la conexión, lo que
mantiene el direccionamiento consistente:
A NAP
T V
192.168.0.8:1234 203.0.113.16:80 203.0.113.1:5678 203.0.113.16:80
2+2=4
src: 203.0.113.16:80
dst: 203.0.113.1:5678
I remember
203.0.113.1:5678!
I must send this packet to
192.168.0.8:1234.
2+2=4
src: 203.0.113.16:80
dst: 192.168.0.8:1234
Con esto, ha proporcionado Internet IPv4 a todos los nodos privados, a costa de una única dirección IPv4 pública. (A
diferencia de darle a cada uno de ellos una dirección IPv4 separada).
¡USO!
Desea un NAPT cuando necesita reducir la cantidad de direcciones IPv4 que usa y no le importa IPv6.
Nuevamente, NAPT no es un mecanismo de traducción de IPv4 / IPv6 y Jool no lo implementa. En

Linux, use iptables / nftables estándar para presentar un NAPT. (en el contexto de iptables / nftables, se
llama "Masquerade").
Las asignaciones se crean cuando es necesario y se destruyen después de un cierto tiempo de inactividad. Esta tabla
dinámica es la razón por la que nos referimos a los NAPT como "NAT con estado".
Para fines externos, puede decir que los nodos A a E están "compartiendo" la dirección (o direcciones) global de
NAPT . Puede pensar en NAPT como un dispositivo de intermediario no malicioso que se hace pasar por todos los
involucrados al multiplexar sockets privados con sus propios públicos:
NAPT
192.168.0.8:1000 203.0.113.17:1234 203.0.113.1:5678 203.0.113.16:80
A 192.168.0.8:1234 203.0.113.16:80 203.0.113.1:9638 203.0.113.16:2222 V
192.168.0.8:3000 203.0.113.18:8080 203.0.113.1:8523 203.0.113.16:50000
192.168.0.9:5000 203.0.113.16:50000 203.0.113.17:22
B 192.168.0.9:5001 203.0.113.18:1024 203.0.113.1:7412 203.0.113.17:1234 W
192.168.0.9:5002 203.0.113.1:7894 203.0.113.17:9999
192.168.0.10:2020 203.0.113.17:9999 203.0.113.1:1478 203.0.113.18:1024
C 192.168.0.10:7755 203.0.113.16:2222 203.0.113.18:3500 X
192.168.0.10:6543 203.0.113.1:5555 203.0.113.18:8080
Por ejemplo, 192.168.0.8 : 1234 cree que está hablando directamente con 203.0.113.16 : 80 , pero NAPT de hecho está
repitiendo furtivamente su tráfico. Debido a que NAPT ha abierto su propio socket a 203.0.113.16 : 80 , este último
cree que está hablando con NAPT y ni siquiera es consciente de la existencia de 192.168.0.8 : 1234 .
Esta es la vista de la red privada (es idéntica a la red real):
192.168.0.0/24 203.0.113.0/24
(Private Network)
.8 .16
A V
.9 .17
B W
C .10 .1 .1 .18 X
T
NAP
.11 .19
D Y
.12 .20
E Z
Y esta es la vista desde los nodos externos:
203.0.113.0/24
.16
V
.17
W
NAPT .1 .18 X
.19
Y
.20
Z
Hay un par de cosas más de las que deberíaMostrar

Traducido al: español
estar consciente con respecto a NAPT:
texto original Opciones ▼
NAPT se diseñó generalmente con el objetivo de permitir que un conjunto limitado de clientes (es decir, el lado
izquierdo de la red privada) acceda a cualquier número de servidores (el lado derecho público) con el costo de una
sola dirección IPv4 pública. El resultado algo desafortunado es que la comunicación solo se puede iniciar desde la red
privada de forma predeterminada. ¿Por qué? Porque, en ausencia de un estado, el NAPT puede tener sentido a partir
de una dirección de destino de salida, pero no de una dirección de destino de entrada. El paquete 192.168.0.8:5000
→ 203.0.113.16:80simplemente se dirige a 203.0.113.16:80, pero NAPT no puede saber a cuál de los nodos
privados 203.0.113.16:5000 → 203.0.113.1:80pertenece el paquete entrante (nuevamente, asumiendo que la tabla
de asignaciones está vacía). Esta es la razón por la que debe configurar el reenvío de puertos si desea, por ejemplo,
publicar un servidor HTTP detrás de un NAPT. Regla de reenvío de puertos[192.168.0.8:80, 203.0.113.1:80],
por ejemplo, es una configuración estática que reserva permanentemente la 203.0.113.1:80máscara para el
192.168.0.8:80servicio y permite que los paquetes entrantes sean "traducidos a la dirección de red" incluso en
ausencia del estado dinámico requerido habitual.
En segundo lugar, el número de máscaras públicas disponibles para un NAPT está limitado a 65536 por protocolo de
transporte (suponiendo que no desee excluir los puertos del sistema), por dirección IPv4 pública. ¿Por qué? Porque
tanto TCP como UDP otorgan 65536 puertos a cada dirección IP. Esto significa que, si su NAPT se hace pasar por 130
nodos privados y solo tiene una dirección IPv4 pública, entonces cada uno puede tener como máximo ~ 500 (65536
divididos por 130) sockets simultáneamente, al menos para hablar con los nodos a través del NAPT. Esta limitación
no es realmente notable en NAPT, ya que a menudo se usa para brindar servicios a hogares con ~ 10 o incluso ~ 20
dispositivos que interactúan con Internet, pero podría convertirse en un asunto más urgente dependiendo de lo que
quiera hacer con su Stateful NAT64.
NAT64 con estado

Stateful NAT64 (a menudo abreviado como “NAT64” en esta documentación) es más o menos lo mismo que NAPT.
La única diferencia es que la "Red privada" es en realidad una red IPv6:
2001:db8::/96 203.0.113.0/24
::8 .16
A V
B ::9 .17 W
::a ::1 .1 .18

C T X
D ::b .19 Y
E ::c .20 Z
Una vez que llega un paquete saliente, su dirección de origen se traduce exactamente de la misma manera que en
NAPT, mientras que su dirección de destino se traduce de acuerdo con pool6:
A T V
[2001:db8::8]:1234 [64:ff9b:1::203.0.113.16]:80 203.0.113.1:5678 203.0.113.16:80
2+2=4
src: [2001:db8::8]:1234
dst: [64:ff9b:1::203.0.113.16]:80 2+2=4
src: 203.0.113.1:5678
dst: 203.0.113.16:80
src: 203.0.113.16:80
4 dst: 203.0.113.1:5678
src: [64:ff9b:1::203.0.113.16]:80
dst: [2001:db8::8]:1234
Casi todo lo demás se aplica:
[2001:db8::8]:1000 [64:ff9b:1::203.0.113.17]:1234 203.0.113.1:5678 203.0.113.16:80
A [2001:db8::8]:1234 [64:ff9b:1::203.0.113.16]:80 203.0.113.1:9638 203.0.113.16:2222 V
[2001:db8::8]:3000 [64:ff9b:1::203.0.113.18]:8080 203.0.113.1:8523 203.0.113.16:50000
[2001:db8::9]:5000 [64:ff9b:1::203.0.113.16]:50000 203.0.113.17:22
B [2001:db8::9]:5001 [64:ff9b:1::203.0.113.18]:1024 203.0.113.1:7412 203.0.113.17:1234 W
[2001:db8::9]:5002 203.0.113.1:7894 203.0.113.17:9999
[2001:db8::a]:2020 [64:ff9b:1::203.0.113.17]:9999 203.0.113.1:1478 203.0.113.18:1024
C [2001:db8::a]:7755 [64:ff9b:1::203.0.113.16]:2222 203.0.113.18:3500 X
[2001:db8::a]:6543 203.0.113.1:5555 203.0.113.18:8080
¡USO!
NAT64 es útil cuando tiene hasta un cierto número grande de nodos IPv6 (es decir, limitado al número de
direcciones de transporte disponibles para T ) que desean interactuar con cualquier número de nodos IPv4
.
Así que es como un SIIT tradicional con esteroides, excepto que su estado hace que sea difícil crear
redundancia para él .
Vista IPv6:
2001:db8::/96 64:ﬀ9b:1::203.0.113.0/120
::8 ::10 (.16)

A V
B ::9 ::11 W
::a ::1 ::1 ::12

C T X
::b ::13
D Y
E ::c ::14 Z
Vista IPv4:
203.0.113.0/24
.16
V
.17 W
.1 .18
T X
.19
Y
.20 Z
Básicamente, un NAT64 con estado es similar a un SIIT, pero tiene todas las ventajas y desventajas de NAPT. Puede
representar todos sus nodos IPv6 con la menor cantidad posible de direcciones IPv4, pero está limitado a 65536
conexiones por direcciones IPv4 públicas y, en ausencia de reenvío de puertos, todas las comunicaciones deben
comenzar desde el lado de IPv6.
También puede hacer comparaciones con SIIT-DC. En cierto modo, un NAT64 con estado es una especie de SIIT-DC
inverso; El primero se siente como en casa cuando tiene un puñado de clientes IPv6 que necesitan acceder a cualquier
cantidad de servidores de Internet IPv4, mientras que el segundo es más adecuado cuando tiene un puñado de
servidores IPv6 a los que debe acceder cualquier cliente de Internet IPv4. .
En el contexto de NAT64, normalmente no se dice que la red IPv6 es "Privada", porque el punto es que también debe
estar conectada a Internet IPv6:
A B C
IPv6 T IPv4
R D E
<More IPv6 infrastructure> <Your (IPv6) network(s)> <IPv4 Internet>
De esta manera, A a E son nodos solo de IPv6, pero tienen acceso a ambas Internet (la de IPv6 a través del enrutador R
y la de IPv4 a través de T ).
La NAT64 con estado está definida por RFC 6146 y la mayoría de las veces se combina con DNS64 (que tiene una
pequeña introducción aquí ).
464XLAT
464XLAT es básicamente un SIIT-DC-2xlat donde el BR es un NAT64 con estado en lugar de un SIIT. Creo que es
más utilizado por los ISP. (A diferencia de los centros de datos de SIIT-DC).
ISP
s6
IPv6
c6a 2001:db8::ab:cd
2001:db8:12:34::6a
c6b
2001:db8:12:34::6b s4
PLA
T IPv4
192.0.2.4
c4 T
CLA
pool6:
203.0.113.4 64:ff9b:1::/96
pool6:
64:ff9b:1::/96
EAMT:
IPv6 IPv4
2001:db8:12:34::4 203.0.113.4
En el contexto de 464XLAT, el ER se llama CLAT ("Traductor del lado del cliente") y el BR se llama
PLAT ("Traductor del lado del proveedor") No mires demasiado en eso
PLAT ( Traductor del lado del proveedor ). No mires demasiado en eso.
Para ser claros: PLAT es el NAT64 con estado. El CLAT sigue siendo un SIIT. Dado que las conexiones Stateful
NAT64 tienen que comenzar desde el lado de IPv6, realmente no tiene sentido que CLAT sea un NAT64.
c4 s4
T T
CLA PLA
203.0.113.4 192.0.2.1 192.0.2.4
2+2=?
src: 203.0.1.113.4:1234
dst: 192.0.2.4:80 2+2=?
src: [2001:db8:12:34::4]:1234
dst: [64:ff9b:1::192.0.2.4]:80 2+2=?
src: 192.0.2.1:5678
dst: 192.0.2.4:80
src: 192.0.2.4:80
4 dst: 192.0.2.1:5678
src: [64:ff9b:1::192.0.2.4]:80
4 dst: [2001:db8:12:34::4]:1234
src: 192.0.2.4:80
dst: 203.0.113.4:1234
¡USO!
Por qué querrías hacer esto? Si es un ISP, puede usar 464XLAT para brindar Internet IPv4 a sus clientes,
sin tener IPv4 en su infraestructura. (Cada "isla IPv4" es una premisa del cliente, cada CLAT es su
enrutador doméstico).
Si no es un ISP, aún puede emplear 464XLAT si tiene una puerta de enlace NAT64 a IPv4 Intenet, pero
algunas de sus aplicaciones del lado de IPv6 aún no son compatibles con IPv6. Al igual que en SIIT-DC-
2xlat , el punto es una infraestructura principalmente IPv6 con pequeñas islas IPv4 como solución.
(464XLAT es para NAT64 lo que SIIT-DC-2xlat es para SIIT-DC ).
BIBless NAT64
En construcción.
MAP-T
El soporte MAP-T en Jool se encuentra actualmente en desarrollo tardío. Saldrá en Jool 4.2.0. Ver
descargas .
(Nota: Esta es una simplificación excesiva que se entiende como una introducción general. La terminología está
particularmente oculta porque tengo algunos problemas con la oficial. Lea el resumen de MAP-T después de esto para
obtener más información).
Suponga que es un proveedor de servicios de Internet (ISP) con 4 clientes, pero solo tiene una dirección IPv4 libre
para distribuir entre ellos.
192.0.2.1
IPv6
ISP
(IPv6)
IPv4
La idea de MAP-T es "subdividir" su dirección IPv4 en porciones iguales y entregar cada porción a un cliente por
separado. (Y haga que el resto de la nube ISP sea puramente IPv6).
¿Cómo se "subdivide" una dirección IPv4? Recordando que cada dirección tiene 65536 puertos por protocolo de
transporte:
192.0.2.1
0
1 slice 0 slice 1
2 0 16384
3 1 16385
4 2 16386
5 ... ...
. 16382 32766
. 16383 32767
.
. slice 2 slice 3
. 32768 49152
. 32769 49153
. 32770 49154
. ... ...
. 49150 65534
65533 49151 65535
65534
65535
Por supuesto, no es posible asignar físicamente una porción de una dirección IPv4 a un nodo, y ahí es donde entran los
traductores de MAP:
192.0.2.1, ports 0-16383
CE0
192.0.2.1, ports 16384-32767
CE1
IPv6
R6
ISP (IPv6)
2001:db8::/32
BR IPv4
CE2
192.0.2.1, ports 32768-49151
192.0.2.1, ports 49152-65535
CE3
(Nota: esos segmentos de direcciones no se asignan físicamente. Tenga en cuenta que la nube del ISP sigue siendo
IPv6).
Customer Edges (CE) y Border Relays (BR), como de costumbre, se asegurarán de que todos, sin saberlo, estén
hablando del protocolo que todos los demás quieren escuchar.
Cada hogar utilizará direcciones privadas (192.168.xy) y cada CE consistirá en un NAPT tradicional encadenado a un
traductor. El NAPT reducirá el espacio de direcciones privadas al segmento asignado y el traductor convertirá el
paquete resultante en algo que pueda atravesar la red IPv6.
He aquí un ejemplo:
Supongamos que hemos decidido reservar la subred 2001: db8: ce :: / 48 para todas nuestras necesidades de CE, y
estamos usando 64: ff9b: 1 :: / 96 para enmascarar Internet IPv4 como de costumbre. El cliente 192.168.0.4 está detrás
del CE que posee el segmento 2 (puertos 32768-49151) (y por lo tanto posee el prefijo 2001: db8: ce : 2 :: / 64) y
desea enviar un paquete al servidor HTTP de Internet IPv4 203.0.113.56 .
CE2
NAPT XLAT BR
192.168.0.4 203.0.113.56
src: 192.168.0.4:12345
dst: 203.0.113.56:80
src: 192.0.2.1:40000
dst: 203.0.113.56:80
2+2=?
2+2=?
El paquete primero obtiene NAPT de una dirección de transporte IPv4 privada a una dirección de transporte IPv4
pública pseudoaleatoria que puede ser utilizada por la CE.
Aunque se le puede perdonar si nunca ha realizado NAPT en un rango de puertos reducido, puede estar seguro de que
se trata de una operación NAT con estado perfectamente normal. El paquete ya sería enrutable, si tuviéramos una red
IPv4 a mano.
CE2
NAPT XLAT BR
192.168.0.4 203.0.113.56
src: 192.0.2.1:40000
dst: 203.0.113.56:80
src: [2001:db8:ce:2::]:40000
dst: [64:ff9b:1::203.0.113.56]:80
2+2=?
2+2=?
A continuación, el paquete se MAP-T correctamente. La dirección de origen contiene el identificador de segmento de

la CE , y pool6 se antepone a la dirección de destino como de costumbre.
(Por cierto: estoy mintiendo. El formato de dirección que se usa para traducir la fuente es significativamente más
complicado que eso, pero entiendes el punto. Contiene el "prefijo CE" y el ID del segmento , y todo lo demás es una
pifia).
CE2
NAPT XLAT BR
192.168.0.4 203.0.113.56
src: [2001:db8:ce:2::]:40000
dst: [64:ff9b:1::203.0.113.56]:80
src: 192.0.2.1:40000
dst: 203.0.113.56:80
2+2=?
2+2=?
El BR refleja la parte de traducción de lo que hizo el CE, pero no la parte NAPT.
CE2
NAPT XLAT BR
192.168.0.4 203.0.113.56
src: 203.0.113.56:80
dst: 192.0.2.1:40000
src: [64:ff9b:1::203.0.113.56]:80
dst: [2001:db8:ce:2::]:40000
4
El servidor responde. La BR aplica la transformación adecuada a cada dirección.
Quizás se esté preguntando: dado que todos los CE técnicamente poseen la dirección 192.0.2.1 , ¿cómo sabe el BR
que el CE previsto es 2 y no uno de los demás? Porque, por configuración, BR sabe que el puerto 40000 pertenece al
segmento 2 .
CE2
NAPT XLAT BR
192.168.0.4 203.0.113.56
src: [64:ff9b:1::203.0.113.56]:80
dst: [2001:db8:ce:2::]:40000
src: 203.0.113.56:80
dst: 192.0.2.1:40000
4
src: 203.0.113.56:80
dst: 192.168.0.4:12345
4
El paquete se encamina entonces a la CE que posee el prefijo que está destinado a . Las cosas terminan sucediendo al
revés.
Por supuesto, si bien MAP-T es una técnica que se preocupa principalmente por transferir tráfico IPv4 a través de una
red troncal IPv6, no hay nada que le impida asignar también direcciones IPv6 a sus clientes y que el tráfico se enrute
normalmente. (A través del enrutador R6).
Entonces, ¿qué logramos con esta manipulación pseudoconvolucionada de direcciones? Bueno, hemos ensamblado un
464XLAT en el que el PLAT no tiene estado y, por lo tanto, se puede replicar para obtener redundancia. Además, es
interesante notar que, debido a que los segmentos están preasignados, un cliente malintencionado no puede agotar
todas nuestras direcciones de transporte público; solo agotarían los suyos.
Aquí; tener una tabla de comparación:
464XLAT MAP-T
No es necesario realizar el registro BIB /
Es posible que su gobierno lo obligue a realizar un registro de
Sesión, porque todas las asignaciones están
sesiones / BIB.
predefinidas por configuración.
El PLAT asigna direcciones de transporte público a los clientes bajo
A todos se les asigna el mismo número de
demanda. (Los clientes que necesitan muchas direcciones de
direcciones de transporte público.
transporte público obtendrán más que aquellos que necesitan pocas).
Un cliente no puede robar las direcciones de
Un cliente puede realizar DoS a otros clientes agotando el grupo de
transporte público de otros clientes porque
direcciones de transporte público de PLAT.
todas están preasignadas por configuración.
MAP-T está formalmente definido por RFC 7599 y, en gran medida, RFC 7597 .
Una advertencia: es mi opinión personal que estos no son los RFC mejor escritos jamás ideados por el
IETF, y si los va a consumir, le sugiero que lea el Apéndice B de RFC 7597 en lugar de la sección de
RFC 7597. 5.1. (Y omita 5.1 por completo).
O simplemente lea el resumen de MAP-T de Jool .


Introducción A La Traducción de IPv4 - IPv6

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción A La Traducción de IPv4 - IPv6

Cargado por

Copyright:

Formatos disponibles

12/10/21, 11:26 AM Introducción a la traducción de IPv4 / IPv6

Traducido al: español Mostrar texto original Opciones ▼

Documentación > Introducción > ¿Qué es SIIT / NAT64?