Network Working Group P.

Srisuresh
Request for Comments: 3022 Jasmine Networks
Obsoletos: 1631 K. Egevang
Categoría: Informativo Intel Corporation
Enero 2001
Traductor de Dirección de Red IP Tradicional (NAT Tradicional)
Estado de este memorándum
Este memorándum provee información para la comunidad Internet. No
especifica un estándar Internet de ningún tipo. La distribución de
este memorándum es ilimitada.
Nota de copyright
Copyright (C) The Internet Society (2001). Todos los derechos
reservados.
Prefacio
La operación NAT descrita en este documento extiende la traducción de
dirección introducida en el RFC 1631 e incluye un nuevo tipo de
dirección de red y traducción de puerto TCP/UDP. Además, este
documento corrige el algoritmo ajuste de Suma de Control publicada en
el RFC 1631 e intenta discutir la operación NAT y sus limitaciones en
detalle.
Resumen
La Traducción de Dirección de Red Básica o NAT Básico es un método
por el que las direcciones IP son mapeadas desde un grupo a otro, de
manera transparente para el usuario final. La Traducción de Puerto
Dirección de Red, o NAPT es un método por el que muchas direcciones
de red y sus puertos TCP/UDP (Protocolo de Control de
Transmisión/Protocolo de Datagrama de Usuario) son traducidos a una
sola dirección de red y sus puertos TCP/UDP. Juntas, estas dos
operaciones, son referidas como NAT Tradicional, proporcionando un
mecanismo para conectar un dominio con direcciones privadas a un
dominio externo con direcciones registradas globalmente únicas.
1. Introducción
La necesidad de traducir una Dirección IP surge cuando direcciones IP
de red internas no pueden ser usadas fuera de la red ya sea por
razones de privacidad o porque son inválidas para su uso fuera de la
red.

Srisuresh & Egevang Informativo [Página 1]

RFC 3022 NAT Tradicional Enero 2001

La topología de red fuera de un dominio local puede cambiar de muchas

maneras. Los clientes pueden cambiar proveedores, los backbones
(conexiones de internet con gran ancho de banda) de las compañías
pueden ser reorganizados o los proveedores pueden unirse o separarse.
Siempre que la topología externa cambie, la asignación de dirección
para nodos en el dominio local puede también cambiar para reflejar
los cambios externos. Los cambios de este tipo pueden ser ocultados a
los usuarios en el dominio centralizando los cambios en un solo
router de traducción de dirección.
La Traducción de Dirección Básica permitiría (en muchos casos,
excepto como notamos en [NAT-TERM] y la sección 6 de este documento)
a hosts en una red privada acceder de manera transparente a la red
externa y habilitar acceso desde el exterior a hosts locales
seleccionados. Las organizaciones con una red configurada
predominantemente para uso interno, con una necesidad ocasional de
acceso externo son buenos candidatos para este esquema.
Muchos usuarios de "Oficina Pequeña, Oficina en Casa" (SOHO) y
empleados telecomunicados tienen múltiples nodos de red en sus
oficinas, corriendo aplicaciones TCP/UDP, pero tienen una sola
dirección IP asignada para su router de acceso remoto por su
proveedor de servicio para acceder a redes remotas. Esto siempre
incrementa la comunidad de usuarios de acceso remoto que serían
beneficiados por NATP, que permitiría a múltiples nodos en una red
local acceder simultáneamente a redes remotas usando la única
dirección IP asignada a su router.
Hay limitaciones al uso del método de traducción. Es obligatorio que
todas las solicitudes y respuestas pertenecientes a una sesión sean
routeadas por el mismo router NAT. Una manera de cerciorarse de esto
sería tener un NAT basado en un router frontera que es único para una
zona del dominio, donde todos los paquetes IP son originados desde el
dominio o destinados a él. Hay otras maneras de asegurar esto con
múltiples dispositivos NAT. Por ejemplo, un dominio privado puede
tener dos puntos de salida distintos a proveedores diferentes y el
flujo de la sesión desde los hosts en una red privada puede atravesar
por cualquiera de los dispositivos NAT que tenga la mejor métrica
para un host externo. Cuando uno de los routers NAT falla, el otro
puede encaminar el tráfico para todas las conexiones. Hay sin embargo
una advertencia con este enfoque, en que, el flujo reencaminado puede
fallar en el momento del cambio al nuevo router NAT. Una manera para
vencer este problema potencial es que los routers compartan la misma
configuración NAT e intercambien información de estado para asegurar
que cada uno de ellos puede sustituir al otro.
La traducción de dirección es independiente de la aplicación y a
menudo acompañada por Gateways específicos de aplicación (ALGs) para

Srisuresh & Egevang Informativo [Página 2]

RFC 3022 NAT Tradicional Enero 2001

realizar monitoreo de carga útil y alteraciones. FTP es el ALG más

popular residente en dispositivos NAT. Las aplicaciones requiriendo
intervención ALG no deben tener sus cargas útiles codificadas, acción
que efectivamente desactivaría el ALG, salvo que el ALG tenga la
llave para desencriptar la carga útil.
Esta solución tiene la desventaja de quitar el significado extremo a
extremo de una dirección IP, y compensando esto con mayor presencia
en la red. Como un resultado, la seguridad del nivel de red IP
extremo a extremo asegurada por IPsec no puede ser asumida para los
hosts finales, con un dispositivo NAT de enrutado. La ventaja de esta
aproximación sin embargo es que puede ser instalada sin cambios en
los hosts o en los routers.
Las definiciones de términos como "Dominio de Dirección", "Ruteo
Transparente", "Puertos TU", "ALG" y otros, usados a lo largo de este
documento pueden encontrarse en [NAT-TERM].
2. Reseña del NAT Tradicional
La operación de Traducción de Dirección presentada en este documento
se llama "NAT Tradicional". Hay otras variantes de NAT que no serán
exploradas en este documento. El NAT Tradicional permitiría a hosts
en una red privada acceder transparentemente a hosts en una red
externa, en muchos casos. En un NAT Tradicional, las sesiones son
unidireccionales, salientes de la red privada. Las sesiones en la
dirección opuesta pueden ser permitidas en una base excepcional
usando mapeos de dirección estáticos para hosts preseleccionados. NAT
Básico y NAPT son dos variantes de NAT Tradicional, en que la
traducción en NAT Básico es limitada sólo a direcciones IP, mientras
que las traducciones en NAPT son extendidas para incluir la dirección
IP y el identificador de transporte (como puerto TCP/UDP o ID de la
petición ICMP).
A menos que se mencione lo contrario, la Traducción de Dirección o
NAT a lo largo de este documento pertenece al NAT Tradicional, es
decir al NAT Básico o al NAPT. Sólo los routers de frontera de la
zona como los descriptos en la figura 1 a continuación pueden ser
configurados para realizar traducción de dirección.

Srisuresh & Egevang Informativo [Página 3]

RFC 3022 NAT Tradicional Enero 2001

| / . /
+---------------+ WAN . +--------------------+/
|Router Regional|----------------------|Router de Zona c/NAT|---
+---------------+ . +--------------------+
. | .
| LAN
. ---------------
Frontera de zona
Figura 1: Configuración de NAT Tradicional
2.1. Reseña de NAT Básico
La operación de NAT Básico es como se describe a continuación. Una
zona con un conjunto de direcciones de red privadas puede ser
habilitada para comunicarse con una red externa mapeando
dinámicamente el conjunto de direcciones privadas a un conjunto de
direcciones de red válidas globalmente. Si el número de nodos local
es menor o igual que las direcciones en el conjunto global, cada
dirección tiene garantizada una dirección global para ser mapeada a
ella. De lo contrario, los nodos habilitados para tener acceso
simultáneo a la red externa son limitados por el número de
direcciones en el conjunto global. Direcciones locales individuales
puede ser estáticamente mapeadas a direcciones globales específicas
para asegurarse acceso garantizado hacia afuera o para permitir
acceso al host local desde hosts externos mediante una dirección
pública fija. Sesiones múltiples simultáneas puede ser iniciadas
desde un nodo local, usando el mismo mapeo de dirección.
Las direcciones dentro de la zona son locales para este dominio y no
son válidas fuera de él. De este modo, las direcciones dentro de la
zona pueden ser reusadas por alguna otra. Por ejemplo, una sola
dirección de Clase A puede ser usada por muchas zonas. En cada punto
de salida entre una zona y el backbone, NAT está instalado. Si hay
más de un punto de salida es de gran importancia que cada NAT tenga
la misma tabla de traducción.
Por ejemplo, en el caso de la figura 2, ambas zonas A y B
internamente usan el bloque de dirección privada A 10.0.0.0/8 [RFC
1918]. La zona NAT de A es asignada al bloque de dirección clase C
198.76.29.0/24, y la zona NAT de B es asignada al bloque de
dirección de clase C 198.76.28.0/24. Las direcciones de clase C son
globalmente únicas y ningún otro conjunto NAT puede usarlas.

Srisuresh & Egevang Informativo [Página 4]

RFC 3022 NAT Tradicional Enero 2001

| /
+---------------+
|Router Regional|
+---------------+
WAN | | WAN
| |
Zona A .............|.... ....|............ Zona B
| |
{s=198.76.29.7,^ | | v{s=198.76.29.7,
d=198.76.28.4}^ | | v d=198.76.28.4}
+--------------------+ +--------------------+
|Router de Zona c/NAT| |Router de Zona c/NAT|
+--------------------+ +--------------------+
| |
| LAN LAN |
------------- -------------
| |
{s=10.33.96.5, ^ | | v{s=198.76.29.7,
d=198.76.28.4}^ +--+ +--+ v d=10.81.13.22}
|--| |--|
/____ /____
10.33.96.5 10.81.13.22
Figura 2: Operación NAT Básica
Cuando el host 10.33.96.5 en la zona A desea enviar un paquete al
host 10.81.13.22 en la zona B, este usa la dirección 198.76.28.4
globalmente única como destino, y envia el paquete a su router
primario. El router de la zona tiene un ruteo estático para la red
198.76.0.0 entonces el paquete es reenviado a la conexión WAN. Sin
embargo, NAT traduce la dirección origen 198.76.29.7 antes de que el
paquete sea reenviado. Del mismo modo, los paquetes IP en la ruta de
regreso van a pasar a través de traducciones de dirección similares.
Observe que esto no requiere cambios a los hosts o a los routers. Por
ejemplo, por lo que a la zona A le concierne, 198.76.28.4 es la
dirección usada por el host en la zona B. Las traducciones de
dirección son transparentes para los hosts finales en muchos casos.
Por supuesto, esto es sólo un ejemplo. Hay numerosos temas para ser
explorados.
2.2. Reseña de NAPT
Digamos, una organización tiene un red IP privada y una conexión WAN
a un proveedor de servicio. El router de zona de la red privada es
asignado a una dirección válida globalmente en la conexión WAN y los
demás nodos en la organización usan direcciones IP que tienen sólo
significado local. En este caso, a los nodos en la red privada se les

Srisuresh & Egevang Informativo [Página 5]

RFC 3022 NAT Tradicional Enero 2001

puede permitir acceder simultáneamente a la red externa, usando la

única dirección IP registrada con la ayuda de NAPT. NAPT permitiría
mapeos de tuplas del tipo (direcciones IP local, número de puerto TU
local) a tuplas del tipo (dirección IP registrada, número de puerto
TU asignado).
Este modelo es adecuado para los requerimientos de muchos grupos de
"Oficina Pequeña, Oficina en Casa" (SOHO) para acceder a redes
externas usando una sola dirección IP asignada del proveedor de
servicio. Este modelo debe ser extendido para permitir acceso
entrante mapeando estáticamente un nodo local por cada puerto de
servicio TU de la dirección IP registrada.
En el ejemplo de la figura 3 a continuación, la zona A internamente
usa el bloque de dirección de clase A 10.0.0.0/8. La interfase WAN
del router de zona es asignada a la dirección IP 138.76.28.4 por el
proveedor de servicio.

| /
+--------------------------------+
|Router del Proveedor de Servicio|
+--------------------------------+
WAN |
|
Stub A .............|....
|
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024}
+---------------------+
|Router de Zona c/NAPT|
+---------------------+
|
| LAN
--------------------------------------------
| ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23,
| ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017}
| |
+--+ +--+ +--+
|--| |--| |--|
/____ /____ /____ 10.0.0.1 10.0.0.2 .....
10.0.0.10
Figura 3: Operación de Traducción de Puerto Dirección de Red
(NAPT)

Cuando el host 10.0.0.10 de la zona A envía un paquete TELNET al host

Srisuresh & Egevang Informativo [Página 6]

RFC 3022 NAT Tradicional Enero 2001

138.76.29.7, este usa la dirección globalmente única 138.76.29.7 como

destino, y envía el paquete a su router primario. El router de zona
tiene un ruteo estático para la subred 138.76.0.0/16 entonces el
paquete es reenviado a la conexión WAN. Sin embargo, NAPT traduce la
tupla de dirección origen 10.0.0.10 y puerto origen TCP 3017 en los
encabezados IP y TCP a la 138.76.28.4 globalmente única y un puerto
TCP únicamente asignado, por decir 1024, antes de que el paquete sea
reenviado. Los paquetes en la ruta de regreso pasan a través de una
traducción de dirección y puerto TCP similar por la dirección IP de
destino y el puerto TCP de destino. De nuevo, se observa que esto no
requiere cambios en los hosts o los routers. La traducción es
completamente transparente.
En esta configuración, sólo las sesiones TCP/UDP son permitidas y
deben originarse desde la red local. Sin embargo, hay servicios como
DNS que demandan acceso entrante. Pueden ser otros servicios para los
que una organización desee permitir acceso de sesión entrante. Es
posible configurar estáticamente un puerto de servicio TU bien
conocido [RFC 1700] en el router de zona para ser dirigido a un nodo
específico en la red privada.
Además de las sesiones TCP/UDP, los mensajes ICMP, con la excepción
del tipo de mensaje de REDIRECCION pueden ser monitoreados por el
router NAPT. Los paquetes de tipo de petición ICMP son traducidos de
forma similar a los paquetes TCP/UDP, en que el campo identificador
en el encabezado del mensaje ICMP será mapeado únicamente a un
identificador de petición de la dirección IP registrada. El campo
identificador en mensajes de petición ICMP es configurado por el
emisor de la petición y devuelto sin cambios en un mensaje de
respuesta. Entonces, la tupla de (Dirección IP local, Identificador
de petición ICMP local) es mapeado a un tupla de (Dirección IP
registrada, identificador de petición ICMP asignada) por el router
NAPT para identificar únicamente peticiones ICMP de todo tipo desde
alguno de los hosts locales. Las modificaciones a los mensajes ICMP
de error son discutidas en una sección posterior, como las que
involucran modificaciones a la carga útil de ICMP o bien a los
encabezados IP e ICMP.
En la configuración NAPT, donde la dirección IP registrada es la
misma que la dirección IP de la interfaz WAN del router de zona, el
router debe distinguir entre sesiones TCP, UDP o petición ICMP
originadas desde si mismo y originadas desde los nodos en la red
local. Todas las sesiones entrantes (incluidas sesiones TPC, UDP y
peticiones ICMP) son supuestamente dirigidas al router NAT como el
nodo final, salvo que el puerto de servicio de destino esté
estáticamente mapeado a un nodo diferente en la red local.
Otros tipos de sesiones que TCP, UDP y petición ICMP simplemente no

Srisuresh & Egevang Informativo [Página 7]

RFC 3022 NAT Tradicional Enero 2001

son permitidas desde los nodos locales, servidos por un router NAPT.
3.0. Fases de traducción de una sesión
Las fases de traducción con NAT tradicional son las mismas que las
descriptas en [NAT-TERM]. Las siguientes subsecciones identifican
elementos que son específicos del NAT Tradicional.
3.1. Ligando la dirección
Con NAT Básico, una dirección privada es ligada a una dirección
externa, cuando la primera sesión saliente es iniciada desde el host
privado. Subsecuentemente a esto, todas las otras sesiones salientes
originadas desde la misma dirección privada usarán la misma dirección
unida por la traducción de paquete.
En el caso de NAPT, donde muchas direcciones privadas son mapeadas a
un sola dirección globalmente única, la unión sería desde la tupla de
(dirección privada, puerto TU privado) a la tupla de (dirección
asignada, puerto TU asignado). Como con NAT Básico, esta unión es
determinada cuando la primera sesión saliente es iniciada por la
tupla de (dirección privada, puerto TU privado) en el host privado.
Mientras que no es una práctica común, es posible tener una
aplicación en un host privado que establece múltiples sesiones
simultáneas originadas desde la misma tupla de (dirección privada,
puerto TU privado). En este caso, un sola unión para la tupla de
(dirección privada, puerto TU privado) puede ser usado para la
traducción de paquetes pertenecientes a todas las sesiones originadas
desde la misma tupla en un host.
3.2. Búsqueda y traducción de dirección
Después de que una unión de dirección o unión de tupla (dirección,
puerto TU) en el caso de NAPT es establecida, se puede mantener un
estado para cada una de las conexiones usando la unión. Los paquetes
pertenecientes a la misma sesión estarán sujetos a la búsqueda de
sesión para propósitos de traducción. La naturaleza exacta de la
traducción es discutida en la sección siguiente.
3.3. Desligando la dirección
Cuando la última sesión basada en una unión de dirección o de tupla
(dirección, puerto TU) es terminada, su unión puede ser terminada.
4.0. Traducciones de paquete
Los paquetes pertenecientes a sesiones manejadas por NAT pasan por
una traducción en una u otra dirección. Las consecuencias de la

Srisuresh & Egevang Informativo [Página 8]

RFC 3022 NAT Tradicional Enero 2001

traducción de paquete individual son cubiertas en detalle en las

siguientes subsecciones.
4.1. Manipulación de encabezados IP, TCP, UDP e ICMP
En el modelo NAT Básico, el encabezado IP de todos los paquetes debe
ser modificado. Esta modificación incluye la dirección IP (dirección
IP origen para paquetes salientes y dirección IP destino para
paquetes entrantes) y la suma de control IP.
Para las sesiones TCP ([TCP]) y UDP ([UDP]), las modificaciones deben
incluir actualización de la suma de control en los encabezados
TCP/UDP. Esto es porque la suma de control de TCP/UDP también cubre
un pseudo encabezado que contiene las direcciones IP origen y
destino. Como una excepción, los encabezados UDP con suma de control
0 no deben ser modificados. Como para los paquetes de petición ICMP
([ICMP]), no son requeridos cambios adicionales en el encabezado ICMP
como la suma de control en el encabezado ICMP que no incluye las
direcciones IP.
En el model NAPT, las modificaciones al encabezado IP son similares a
las del modelo NAT Básico. Para las sesiones TCP/UDP, las
modificaciones deben ser extendidas para incluir la traducción del
puerto TU (puerto TU origen para paquetes salientes y puerto TU
destino para paquetes entrantes) en el encabezado TCP/UDP. El
encabezado ICMP en los paquetes de petición ICMP deben también ser
modificados para reemplazar el ID de petición y la suma de control
del encabezado ICMP. El ID de petición del host privado debe ser
traducido al ID asignado en los salientes y al revés en los
entrantes. La suma de control del encabezado ICMP debe ser corregida
para contar la traducción del ID de petición.
4.2. Ajuste de la suma de control
Las modificaciones de NAT son por paquete y puede ser un cómputo muy
intensivo, ello involucra una o más modificaciones a la suma de
control, inclusive para traducciones de un sólo campo.
Afortunadamente, tenemos un algoritmo debajo, que hace los ajustes a
la suma de control para los encabezados IP, TCP, UDP e ICMP muy
simple y eficiente. Todos estos encabezados usan una suma de
complementos de uno, esto es suficiente para calcular la diferencia
aritmética entre el antes de la traducción y el después de la
traducción de direcciones y agrega esto a la suma de control. El
algoritmo siguiente es aplicable sólo para desplazamientos pares
(ej.: debajo optr debe estar en un desplazamiento par desde el
principio del encabezado) y longitudes pares (ej.: olen y nlen debajo
deben ser pares). El código de ejemplo (en C) para esto se muestra a
continuación.

Srisuresh & Egevang Informativo [Página 9]

RFC 3022 NAT Tradicional Enero 2001

void
checksumadjust (unsigned char *chksum,
unsigned char *optr,
int olen,
unsigned char *nptr,
int len)
/* asumiendo: unsigned char son 8 bits, long son 32 bits.
- chksum apunta a la suma de control en el paquete
- optr apunta al dato viejo en el paquete
- nptr apunta al dato nuevo en el paquete
*/
{
long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x & 0xFFFF;
while (olen)
{
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
if (x<=0) { x--; x&=0xffff; }
olen-=2;
}
while (nlen)
{
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
x=~x & 0xFFFF;
chksum[0]=x/256; chksum[1]=x & 0xff;
}
4.3 Modificaciones al paquete de error ICMP
Los cambios al mensaje de error ICMP ([ICMP]) incluirán cambios a los
encabezados IP e ICMP en la capa saliente como bien cambios a los
encabezados de los paquetes embebidos en la carga útil del mensaje
ICMP-error.
El método para NAT debe ser transparente para el host-final, la
dirección IP del encabezado IP embebido en la carga útil del mensaje
ICMP-error debe ser modificado, el campo de suma de control del
encabezado IP embebido debe ser modificado, y finalmente, la suma de
control del encabezado ICMP debe también ser modificada para reflejar
los cambios a la carga útil.
En la configuración de un NAPT, si el mensaje IP embebido en ICMP

Srisuresh & Egevang Informativo [Página 10]

RFC 3022 NAT Tradicional Enero 2001

resulta ser un paquete TCP, UDP o petición ICMP, también necesitará

modificar el número de puerto TU apropiado en el encabezado TCP/UDP o el
campo Identificador de Petición en el encabezado de Petición ICMP.
Finalmente, el encabezado IP del paquete ICMP también debe ser
modificado.
4.4 Soporte FTP
Una de las aplicaciones más populares, "FTP" ([FTP]) requieriría un ALG
para monitorear la carga útil de la sesión de control para determinar
los parámetros de la sesión de datos resultante. El ALG FTP es una parte
integral de muchas implementaciones NAT.
El ALG FTP requeriría una tabla especial para corregir la secuencia TCP
y reconocer los números con puerto origen FTP o puerto destino FTP. Las
entradas de la tabla deben tener dirección origen, dirección destino,
puerto origen, puerto destino, un contador para números de secuencia y
un temporizador. Nuevas entradas son creadas solo cuando los comandos de
PUERTO FTP o las respuestas PASV son vistas. El número de secuencia del
contador puede ser incrementado o decrecido para cada comando de PUERTO
FTP o respuesta PASV. Los números de secuencia son incrementados en los
entrantes y los números reconocidos son decrecidos en la salida por este
contador.
Las traducciones de carga útil FTP son limitadas a las direcciones
privadas y sus direcciones externas asignadas (codificadas como octetos
individuales en ASCII) para el NAT Básico. Para la configuración NAPT,
sin embargo, la traducción debe ser extendida para incluir los octetos
de puerto TCP (en ASCII) siguientes a los octetos de dirección.
4.5 Soporte DNS
Considerando que las sesiones en un NAT tradicional son
predominantemente salientes desde un dominio privado, el ALG DNS puede
ser obviado para el uso en conjunto con el NAT tradicional como a
continuación. El/Los servidor/es DNS internos al dominio privado
mantienen mapeos de nombres de direcciones IP para hosts internos y
posiblemente para algunos hosts externos. Los servidores DNS externos
mantienen mapeos de nombres para hosts externos aislados y no para
alguno de los hosts internos. Si la red privada no tiene un servidor DNS
interno, todas las solicitudes DNS pueden ser dirigidas a un servidor
DNS externo para encontrar los mapeos de dirección para los hosts
externos.
4.6 Manipulando la opción IP
Un datagrama IP con una de las opciones IP de Registrar Ruta,

Srisuresh & Egevang Informativo [Página 11]

RFC 3022 NAT Tradicional Enero 2001

Encaminamiento de Origen Fijo o Encaminamiento de Origen No Estricto

involucraría registro o uso de direcciones IP de routers intermedios. Un
router NAT intermedio puede elegir no soportar estas opciones o dejar
las direcciones sin traducir mientras que si procesa las opciones. El
resultado de dejar las direcciones sin traducir sería que direcciones
privadas a lo largo del encaminamiento origen son expuestas de extremo
a extremo. Esto no debe poner en peligro la ruta atravesada por el
paquete, de hecho, como cada router se supone que mira sólo al próximo
salto.
5. Temas diversos
5.1. Particionado de Direcciones en Local y Global
Para que NAT opere como es descripto en este documento, es necesario
particionar el espacio de dirección IP en dos partes - las direcciones
privadas usadas internamente para la zona, y las direcciones únicas
globalmente. Una dirección dada debe ser una dirección privada o una
dirección global. Allí no hay superposición.
El problema con la superposición es el siguiente. Digamos que un host en
la zona A desea enviar paquetes a un host en la zona B, pero las
direcciones globales de la zona B se superponen a las direcciones
privadas de la zona A. En este caso, los routers en la zona A no
estarían aptos para distinguir la dirección global de la zona B de sus
propias direcciones privadas.
5.2. Recomendación para el espacio de dirección privado
[RFC 1918] tiene recomendaciones sobre el espacio de dirección asignado
para redes privadas. La Autoridad de Números Asignados de Internet
(IANA) tiene tres bloques de espacio de dirección IP, llamados
10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 para internets privadas. En
la notación pre-CIDR, el primer bloque es sólo un número de dirección de
clase A, mientras que el segundo bloque es un conjunto de 16 redes
contiguas de clase B, y el tercer bloque es un conjunto de 256 redes
contiguas de clase C.
Una organización que decide usar direcciones IP en el espacio de
dirección definido anteriormente puede hacerlo sin una coordinación con
IANA o con un registro de Internet. El espacio de dirección puede de
este modo ser usado privadamente por muchas organizaciones
independientes al mismo tiempo, con operaciones NAT habilitadas en sus
routers frontera.
5.3. Encaminando a Través de NAT
El router corriendo NAT no debe anunciar a las redes privadas al

Srisuresh & Egevang Informativo [Página 12]

RFC 3022 NAT Tradicional Enero 2001

backbone. Solo las redes con direcciones globales pueden ser conocidas
fuera de la zona. Sin embargo, la información global que recibe NAT
desde el router frontera de la zona puede ser anunciado en la zona de la
manera usual.
Típicamente, el router NAT de la zona tendrá un encaminamiento estático
configurado para reenviar todo el tráfico externo al router del
proveedor de servicio a través de la conexión WAN, y el router del
proveedor de servicio tendrá un encaminamiento estático configurado para
reenviar paquetes NAT (ej.: aquellos cuya dirección IP destino cae en el
rango de NAT manejado por la lista de dirección global) al router NAT
sobre la conexión WAN.
5.4. Conmutar de NAT Básico a NAPT
En la configuración NAT Básico, cuando los nodos de la red privada
agotan las direcciones globales disponibles para mapeo (digamos, una red
privada de clase B mapeada a un bloque de dirección global de clase C),
el acceso a la red externa para algunos de los nodos locales es
abruptamente cortado después de que la última dirección global de la
lista de dirección es usada. Esto es muy inconveniente y drástico. Como
un incidente puede ser seguramente evitado opcionalmente permitiendo al
router NAT Básico conmutar a una configuración NAPT para la última
dirección global en la lista de dirección. Haciendo esto asegurará que
los hosts en una red privada tendrán continuidad, acceso ininterrumpido
a los nodos externos y servicios para la mayoría de las aplicaciones.
Observe, sin embargo, que esto puede ser desconcertante si alguna de las
aplicaciones que usaba para trabajar con NAT Básico de repente corta
debido a que conmuta a NAPT.
6.0. Limitaciones NAT
[NAT-TERM] cubre las limitaciones de todas las cualidades de NAT,
ampliamente hablando. Las siguientes subsecciones identifican
limitaciones específicas al NAT Tradicional.
6.1. Privacidad y seguridad
El NAT tradicional puede ser visto como algo que provee un mecanismo de
privacidad como sesiones unidireccionales desde los hosts privados y
donde las direcciones verdaderas de los hosts privados no son visibles
para los hosts externos.
La misma característica que brinda privacidad hace la depuración de
problemas (incluyendo violaciones de seguridad) potencialmente más
difícil. Si un host en una red privada está abusando de Internet de
alguna manera (como tratando de atacar a otra máquina o enviando grandes
cantidades de spam) es más difícil rastrear el origen actual de

Srisuresh & Egevang Informativo [Página 13]

RFC 3022 NAT Tradicional Enero 2001

trastorno porque la dirección IP de los host es ocultada en un router

NAT.
6.2. Respuestas ARP a direcciones globales mapeadas con NAT en una
interfase LAN
NAT debe estar habilitado sólo en routers NAT frontera de una zona. El
ejemplo provisto en el documento para ilustrar el NAT Básico y el NAPT
tiene una conexión WAN a un router externo (ej.: el router del proveedor
de servicio) desde el router NAT. Sin embargo, si la conexión WAN
estuviese reemplazada por una conexión LAN y si una parte o todo el
espacio de dirección global usado para mapeo NAT pertenece a la misma
subred IP como el segmento LAN, se esperaría que el router NAT provea
soporte ARP para el rango de dirección que pertenece a la misma subred.
La respuesta a los pedidos ARP para direcciones globales mapeadas con
NAT con su propia dirección MAC es un deber en una situación con una
configuración NAT Básica. Si el router NAT no responde a estos pedidos,
no hay otro nodo en la red que tenga la propiedad de estas direcciones y
por ende no será respondido.
Este escenario es diferente con una configuración NAPT excepto cuando la
única dirección usada en un mapeo NAPT no es la dirección de la interfaz
del router NAT (como en el caso de la conmutación de NAT Básico a NAPT
explicado en 5.4, por ejemplo).
El uso un rango de dirección desde una subred conectada directamente
para mapeo de dirección NAT obviaría una configuración de encaminamiento
estático en el router del proveedor de servicio.
La opinión de los autores es que una conexión LAN al router del
proveedor de servicio no es muy común. Sin embargo, los vendedores
pueden estar interesados en soportar opcionalmente un proxy ARP sólo en
este caso.
6.3. Traducción de paquetes fragmentados TCP/UDP salientes en configuración NAPT
La traducción de fragmentos TCP/UDP (ej.: aquellos originados en hosts
privados) en una configuración NAPT están condenados a fallar. La razón
es la siguiente. Sólo el primer fragmento contiene el encabezado TCP/UDP
que sería necesario para asociar el paquete a una sesión para propósitos
de traducción. Los fragmentos subsecuentes no contienen información del
puerto TCP/UDP, pero simplemente llevan el mismo identificador de
fragmentación especificado en el primer fragmento. Digamos, dos hosts
privados originaron paquetes TCP/UDP fragmentados al mismo host de
destino. Y, ellos usaron el mismo identificador de fragmentación. Cuando
el host destino recibe los dos datagramas no relacionados, llevando el
mismo id de fragmentación, y desde la misma dirección de host asignada,
es incapaz de determinar a cual de las dos sesiones de datagramas

Srisuresh & Egevang Informativo [Página 14]

RFC 3022 NAT Tradicional Enero 2001

pertenece. Consecuentemente, ambas sesiones serán corrompidas.

7.0. Implementaciones actuales
Muchas implementaciones comerciales están disponibles en la industria
que adhiere a la descripción NAT provista en este documento. El software
de dominio público Linux contiene NAT bajo el nombre de "Enmascaramiento
IP". El software de dominio público FreeBSD tiene la implementación NAPT
corriendo como un demonio. Observe sin enmbargo que el código Linux está
cubierto bajo la licencia GNU y el software FreeBSD está cubierto bajo
la licencia UC Berkeley.
Tanto el software Linux como el FreeBSD son libres, pero puede comprar
los CD-ROMs de estos por mucho menos del costo de distribución. También
están disponibles on-line desde muchos sitios FTP con los últimos
parches.
8.0. Consideraciones de seguridad
Las consideraciones de seguridad descriptas en [NAT-TERM] para todas las
variantes de NAT son aplicables al NAT Tradicional.
Referencias
[NAT-TERM]
Srisuresh, P. y M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, Agosto 1999.
[RFC 1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. y E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, Febrero 1996.
[RFC 1700]
Reynolds, J. y J. Postel, "Assigned Numbers", STD 2, RFC 1700,
Octubre 1994.
[RFC 1122]
Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, Octubre 1989.
[RFC 1123]
Braden R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, Octubre 1989.
[RFC 1812]
Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
Junio 1995.

Srisuresh & Egevang Informativo [Página 15]

RFC 3022 NAT Tradicional Enero 2001

[FTP]
Postel, J. y J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", STD
9, RFC 959, Octubre 1985.
[TCP]
Defense Advanced Research Projects Agency Information Process-
ing Techniques Office, "TRANSMISSION CONTROL PROTOCOL (TCP)
SPECIFICATION", STD 7, RFC 793, Septiembre 1981.
[ICMP]
Postel, J., "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION",
STD 5, RFC 792, Septiembre 1981.
[UDP]
Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
Agosto 1980.
[RFC 2101]
Carpenter, B., Crowcroft, J. y Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, Febrero 1997.
Direcciones de los autores
Pyda Srisuresh
Jasmine Networks, Inc.
3061 Zanker Road, Suite B
San Jose, CA 95134
U.S.A.
Teléfono: (408) 895-5032
Email: srisuresh@yahoo.com
Kjeld Borch Egevang
Intel Dnmark ApS
Teléfono: +45 44886556
Fax: +45 44886051
Email: kjeld.egevang@intel.com
http: //www.freeyellow.com/members/kbre
Declaración de Copyright completa
Copyright (C) The Internet Society (2001). Todos los derechos reservados.
Este documento y las traducciones de el pueden ser copiadas y provistas
a otros, y trabajos derivados que comenten o expliquen de otra manera
esto o asistan en su implementación pueden ser preparados, copiados,
publicados y distribuidos, enteros o en parte, sin restricción de ningún

Srisuresh & Egevang Informativo [Página 16]

RFC 3022 NAT Tradicional Enero 2001

tipo, proporcionando la anterior nota de copyright y este parrafo

incluido en todas esas copias y trabajos derivados. Sin embargo, este
documento no puede ser modificado de ninguna manera, como ser removiendo
la nota de copyright o las referencias a The Internet Society u otras
organizaciones de Internet, excepto si es necesario para el propósito de
desarrollo de estandars de Internet en ese caso los procedimientos para
copyrights definidos en el proceso Estandars de Internet debe ser
seguido, o como requisito para traducirlo a otros idiomas.
Los permisos limitados concedidos anteriormente son perpetuos y no serán
rebocados por The Internet Society o sus sucedores o sus asignados.
Este documento y la información contenida aquí es provista en un "COMO
ES" básico y THE INTERNET SOCIETY Y LA FUERZA DE TAREA DE INGENIERÍA DE
INTERNET RECHAZAN TODAS LAS GARANTÍAS, EXPRESAS O IMPLICITAS, INCLUIDAS
PERO NO LIMITADA A NINGUNA GARANTÍA QUE EL USO DE LA INFORMACIÓN AQUÍ NO
INFRINGIRÁ ALGÚN DERECHO O ALGUNA GARANTÍA IMPLICITA DE COMERCIABILIDAD
O PROPIEDAD PARA UN PROPÓSITO PARTICULAR.
Reconocimiento
La financiación de la función del Editor de RFC la realiza actualmente
The Internet Society.
Traducción al castellano: Javier Waisbrot (2002)

Srisuresh & Egevang Informativo [Página 17]