You are on page 1of 35

Network Working Group P.

Srisuresh
Request for Comments: 2663 M. Holdrege
Categora: Informativo Lucent Technologies
Agosto 1999

Terminologa y consideraciones sobre Traduccin de Direcciones IP

Status de este memorndum

Este memorndum proporciona informacin a la comunidad Internet. No


especifica ningn tipo de estndar de Internet. La distribucin de
este memorndum es ilimitada.

Nota de Copyright

Copyright (C) The Internet Society (1999). Todos los derechos


reservados.

Prefacio

El motivo de este documento es aclarar el uso de los trminos usados


en los Traductores de Direcciones de Red. El trmino "Traductor de
Direcciones de Red" tiene distintos significados en contextos
diferentes. La intencin de este documento es definir los diversos
sabores de NAT y estandarizar el significado de los trminos
empleados.

Los autores que se enumeran son los editores de este documento, que
debe su contenido a las contribuciones de los miembros del Working
Group. Se han extrado grandes fragmentos del documento titulado
"Traductor de Direcciones de Red IP", IP Network Address Translator
(NAT), de manera casi literal, para formar la base inicial de este
documento. A los editores les gustara agradecer a los autores Pyda
Srisuresh y Kjeld Egevang dichas contribuciones. A los editores
tambin les gustara dar las gracias a Praveen Akkiraju por sus
contribuciones en la descripcin de los escenarios de despliegue de
NAT. Los editores tambin quisieran agradecer a los miembros del IESG
Scott Bradner, Vern Paxson y Thomas Narten por su detallada revisin
del documento, y por aadir claridad al texto.

Resumen

La "Traduccin de Direcciones de Red", Network Address Translation,


es un mtodo por el cual se mapean las direcciones IP desde un
dominio a otro, en un intento de proporcionar encaminamiento
transparente a las mquinas. Tradicionalmente, los dispositivos de
NAT se han usado para conectar un dominio de direcciones privadas no

Srisuresh & Holdrege Informativo [Pg. 1]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

registradas aislado con un dominio externo de direcciones registradas


globalmente nicas. Este documento intenta describir el
funcionamiento de los dispositivos de NAT y las consideraciones
generales asociadas, y definir la terminologa que se usa para
identificar los diversos sabores de NAT.

1. Introduccin y panorama general

La necesidad de la traduccin de direcciones IP surge cuando las


direcciones IP internas de la red no pueden ser usadas fuera de la
red, bien porque no son vlidas en el exterior, bien porque el
direccionamiento interno debe mantenerse separado de la red externa.

La traduccin de direcciones permite (en muchos casos, salvo en


aquellos descritos en las secciones 8 y 9) que las mquinas de una
red privada se comuniquen de manera transparente con destinos en una
red externa y viceversa. Hay una variedad de sabores de NAT y
trminos que se usan para describirlos. Este documento intenta
definir la terminologa que se usa, e identificar varios sabores de
NAT. El documento tambin intenta describir otras consideraciones
aplicables a los dispositivos de NAT en general.

Sin embargo, dese cuenta que este documento no pretende describir el


funcionamiento de las variantes concretas de NAT ni la aplicabilidad
de los dispositivos de NAT.

Los dispositivos de NAT intentan proporcionar una solucin de


encaminamiento transparente a los sistemas finales que intentan
comunicarse desde dominios de direcciones dispares. Esto se consigue
modificando "al vuelo" las direcciones de los nodos finales y
manteniendo el estado de estos cambios para que los datagramas
pertenecientes a una sesin sean encaminados hacia el nodo final
correcto en cualquiera de los dominios. Esta solucin slo funciona
cuando las aplicaciones no usan las direcciones IP como parte del
propio protocolo. Por ejemplo, identificar los extremos usando
nombres DNS en lugar de direcciones hace a las aplicaciones menos
dependientes de las direcciones reales que el NAT elija, y evita la
necesidad de traducir tambin los contenidos de los paquetes cuando
NAT cambie una direccin IP.

La funcin de NAT no puede por s misma soportar todas las


aplicaciones de manera transparente, y por esta razn a menudo debe
coexistir con "Pasarelas de Nivel de Aplicacin", Application Level
Gateways (ALG). Quienes busquen el despliegue de soluciones
fundamentadas en NAT primero deben determinar sus necesidades de
aplicaciones y valorar las extensiones al NAT (por ejemplo, ALG)
necesarias para proporcionar transparencia a las aplicaciones de su
entorno.

Srisuresh & Holdrege Informativo [Pg. 2]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Las tcnicas IPsec, que estn pensadas para mantener las direcciones
finales de un paquete IP, no funcionarn con NAT intermedio para la
mayora de las aplicaciones en uso. Tcnicas tales como AH y ESP
protegen los contenidos de las cabeceras IP (incluyendo las
direcciones de origen y destino) de su modificacin. An as, la
principal funcin del NAT es alterar las direcciones IP en la
cabecera de un paquete.

2. Terminologa y conceptos usados

Los trminos que se usan ms a menudo en el contexto de NAT se


definen como referencia a continuacin.

2.1. Dominio de direcciones o dominio

Un dominio de direcciones es un dominio de red en el que las


direcciones de red son asignadas a las entidades de manera unvoca,
de manera que los datagramas puedan ser encaminados hacia ellas. Los
protocolos de encaminamiento que se usen en el interior del dominio
de red son los responsables de encontrar las rutas hacia las
entidades a partir de sus direcciones de red. Dese cuenta que este
documento se limita a describir el NAT en entornos IPv4 y no se ocupa
del uso de NAT en otros tipos de entornos (por ejemplo, entornos
IPv6).

2.2. Encaminamiento transparente

El trmino "encaminamiento transparente" se usa a lo largo del


documento para identificar la funcionalidad de encaminamiento que
proporciona un dispositivo de NAT. sta es diferente de la
funcionalidad de encaminamiento que proporciona un dispositivo
encaminador tradicional porque un encaminador tradicional encamina
los paquetes en el interior de un nico dominio de direcciones.

El encaminamiento transparente se refiere al encaminamiento de un


datagrama entre dominios de direcciones dispares, modificando los
contenidos de la direccin en la cabecera IP para que la direccin
sea vlida en el dominio en el cual se encamina el datagrama. La
Seccin 3.2 contiene una detallada descripcin del encaminamiento
transparente.

2.3. Flujo de sesin vs. flujo de paquete

Los flujos de conexin o sesin son diferentes de los flujos de


paquetes. Un flujo de sesin indica la direccin en que se inici la
sesin con referencia a una interfase de red. El flujo de paquetes es
la direccin en la que el paquete ha viajado con referencia a un
inteface de red. Por ejemplo, considere una sesin de telnet

Srisuresh & Holdrege Informativo [Pg. 3]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

saliente. La sesin de telnet consiste en flujos de paquetes tanto en


sentido entrante como saliente. Los paquetes de telnet salientes
llevan las pulsaciones de teclas del terminal y los paquetes
entrantes llevan las pantallas desde el servidor de telnet.

Para los fines de este documento, una sesin se define como el


conjunto de trfico que es gestionado como una unidad para su
traduccin. Las sesiones TCP/UDP se identifican de manera unvoca por
una tupla de (direccin IP origen, puerto TCP/UDP origen, direccin
IP destino, puerto TCP/UDP destino). Las sesiones para peticiones
ICMP se identifican mediante la tupla de (direccin IP origen, ID de
la peticin ICMP, direccin IP destino). El resto de sesiones se
caracterizan por la tupla (direccin IP origen, direccin IP destino,
protocolo IP).

Las traducciones de direcciones realizadas por NAT estn basadas en


la sesin e incluiran la traduccin de los paquetes tanto entrantes
como salientes pertenecientes a esa sesin. La direccin de la sesin
se identifica mediante la direccin del primer paquete de esa sesin
(vea la Seccin 2.5).

Dese cuenta de que no hay garanta alguna de que la idea de una


sesin, determinada por NAT como se acaba de explicar, coincida con
la idea de sesin de la aplicacin. Una aplicacin podra ver un
puado de sesiones (sesiones de NAT) como una nica sesin y podra
incluso no considerar su comunicacin con sus interlocutores como una
sesin. No se garantiza que todas las aplicaciones funcionen a travs
de dominios, incluso usando ALG (definidos a continuacin en la
Seccin 2.9) intermedios.

2.4. Puertos TU, puertos del servidor, puertos del cliente

Para el resto de este documento, nos referiremos a los puertos


TCP/UDP asociados con una direccin IP simplemente como "Puertos TU".

Para la mayora de las mquinas TCP/UDP, el rango de puertos TU


0-1023 es usado por servidores esperando conexiones entrantes. Los
clientes que tratan de iniciar una conexin tpicamente seleccionan
un puerto TU origen en el rango 1024-65535. Sin embargo, este
convenio no es universal y no siempre se sigue. Algunas estaciones
cliente inician conexiones usando un nmero de puerto TU origen en el
rango 0-1023, y hay servidores que escuchan en nmeros de puerto TU
en el rango 1024-65535.

Se puede encontrar una lista de puertos TU asignados a servicios en


la RFC 1700 [Ref 2].

2.5. Inicio de una sesin para TCP, UDP y otros

Srisuresh & Holdrege Informativo [Pg. 4]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

El primer paquete de cada sesin TCP intenta establecer una sesin y


contiene informacin para el comienzo de la conexin. El primer
paquete de una sesin TCP puede ser reconocido por la presencia del
bit SYN y la ausencia del bit ACK en los flags TCP. Todos los
paquetes TCP, con la excepcin del primer paquete, deben tener el bit
ACK establecido (N. de T.: bit establecido, puesto a uno, bit no
establecido o ausente, puesto a cero).

Sin embargo, no hay un mtodo determinista de reconocer el comienzo


de una sesin basada en UDP o cualquier otra sesin no TCP. Una
aproximacin heurstica sera asumir que el primer paquete con
parmetros de sesin hasta dicho momento inexistentes (como se define
en la Seccin 2.3) constituye el inicio de una nueva sesin.

2.6. Final de una sesin para TCP, UDP y otros

El final de una sesin TCP se detecta cuando los dos extremos de la


sesin asienten el FIN, o cuando cualquiera de los extremos recibe un
segmento con el bit RST en el campo de flags TCP. Sin embargo, puesto
que es imposible que un dispositivo NAT sepa si los paquetes que ve
sern realmente entregados al destino (podran ser descartados entre
el dispositivo NAT y el destino), el dispositivo NAT no puede
garantizar con seguridad que los segmentos que contienen FIN o SYN
sean los ltimos paquetes de una sesin (es decir, puede haber
retransmisiones). En consecuencia, slo puede asumirse el final de
una sesin despus de un periodo de 4 minutos contados desde el
momento de su deteccin. La necesidad de este periodo de espera
extendido se describe en el RFC 793 [Ref 7], que sugiere una duracin
del TIME-WAIT igual a 2 * MSL ("Vida Mxima del Segmento", Maximun
Segment Lifetime) o 4 minutos.

Dese cuenta que tambin es posible que una conexin TCP termine sin
que el dispositivo NAT sea consciente del evento (por ejemplo, en el
caso de que uno o ambos extremos reinicien). En consecuencia, se
necesita recoger la basura en los dispositivos NAT para eliminar
informacin de estado intil sobre las sesiones TCP que ya no
existan. Sin embargo, por lo general no es posible distinguir entre
conexiones que han estado inactivas durante un largo tiempo de
aqullas que ya no existen. En el caso de sesiones basadas en UDP, no
hay una nica manera de determinar cundo acaba una sesin, ya que
los protocolos basados en UDP son especficos de las aplicaciones.

Se usan muchas aproximaciones heursticas para acabar las sesiones.


Se puede asumir que las sesiones TCP que no se han usado durante
digamos, 24 horas, y las sesiones no TCP que no se hayan usado
durante un par de minutos, estn finalizadas. Esta suposicin
funciona a menudo, pero a veces no. Estos plazos de periodo inactivo
de sesin varan mucho tanto de aplicacin a aplicacin como de

Srisuresh & Holdrege Informativo [Pg. 5]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

sesin a sesin dentro de la misma aplicacin. En consecuencia, los


temporizadores de sesin deben ser configurables. Incluso as, no hay
garanta de poder encontrar un valor satisfactorio. Adems, segn se
dice en la Seccin 2.3, no hay garantas de que el NAT interprete el
fin de la sesin de la misma manera que la aplicacin lo hace.

Otra manera de manejar las finalizaciones de las sesiones es fechar


las entradas y mantenerlas el mayor tiempo posible, y retirar la
sesin que ms tiempo lleve inactiva cuando sea necesario.

2.7. Red pblica/global/externa

Una red global o pblica es un dominio de direcciones con direcciones


de red nicas asignadas por el Internet Assigned Numbers Authority
(IANA) o un registro de direcciones equivalente. Al hablar de NAT a
esta red tambin se la conoce como red externa.

2.8. Red privada/local

Una red privada es un dominio de direcciones independiente de las


direcciones de las red externas. A la red interna tambin se la
conoce alternativamente como red local. El encaminamiento
transparente entre mquinas de un dominio privado y un dominio
externo es proporcionado por un encaminador NAT.

El RFC 1918 [Ref 1] incluye recomendaciones acerca de la asignacin


de espacio para las redes privadas. El Internet Assigned Numbers
Authority (IANA) dispone de tres bloques de direcciones IP, en
concreto 10/8, 172.16/12, y 192.168/16 reservados pata internets
privadas. En notacin pre-CIDR, el primer bloque no ms que un nico
nmero de red de clase A, mientras que el segundo bloque es un
conjunto de 16 redes consecutivas de clase B, y el tercer bloque es
un conjunto de 256 redes consecutivas de clase C.

Una organizacin que decida usar direcciones IP en el espacio de


direccionamiento definido arriba, puede hacerlo sin coordinarse con
el IANA o cualquier otro registro de Internet tales como APNIC, RIPE
y ARIN. As, el espacio de direccionamiento puede ser utilizado de
manera privada por muchas organizaciones independientes al mismo
tiempo. Sin embargo, si ms tarde estas organizaciones independientes
deciden que desean comunicarse con las dems o con la Internet
pblica debern, bien numerar de nuevo sus redes, bien habilitar NAT
en sus encaminadores fronterizos.

2.9. Pasarela de Nivel de Aplicacin, Application Level Gateway (ALG)

No todas las aplicaciones permiten la traduccin sencilla por parte


de los dispositivos NAT; especialmente aquellas que incluyen las

Srisuresh & Holdrege Informativo [Pg. 6]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

direcciones IP y los puertos TCP/UDP en la carga til de los


paquetes. Las "Pasarelas de Nivel de Aplicacin", Application Level
Gateways (ALG), son agentes de traduccin especficos de aplicacin
que permiten que una aplicacin en una mquina de un dominio de
direcciones se conecte a su corresponsal ejecutndose en una mquina
de un dominio diferente, de manera transparente. Una ALG puede
interactuar con NAT para establecer el estado, usar informacin de
estado de NAT, modificar la carga til especfica de la aplicacin y
cualquier otra cosa necesaria para conseguir que la aplicacin
funcione a travs de dominios de direcciones distintos.

Las ALG no tienen porqu usar siempre informacin de estado de NAT.


Pueden echar un vistazo a la carga til y simplemente notificar al
NAT para que aada informacin de estado adicional en ciertos casos.
Las ALG son parecidas a los proxys en que, tanto las ALG como los
proxys, proporcionan comunicacin especfica de aplicacin entre
clientes y servidores. Los proxys utilizan un protocolo especial para
comunicarse con clientes proxy y entregar los datos del cliente a los
servidores y viceversa. A diferencia de los proxys, las ALG no usan
un protocolo especial para comunicarse con las aplicaciones cliente y
no necesitan de cambios en las aplicaciones cliente.

3. Qu es NAT ?

La "Traduccin de Direcciones de Red", Network Address Translation


(NAT), es un mtodo mediante el que las direcciones IP son mapeadas
desde un dominio de direcciones a otro, proporcionando encaminamiento
transparente a las mquinas finales. Existen muchas variantes de
traduccin de direcciones que se prestan a distintas aplicaciones.
Sin embargo, todos las variantes de dispositivos NAT deberan
compartir las siguientes caractersticas:

a) Asignacin transparente de direcciones.

b) Encaminamiento transparente mediante la traduccin de


direcciones (aqu el encaminamiento se refiere al reenvo de
paquetes, no al intercambio de informacin de encaminamiento).

c) Traduccin de la carga til de los paquetes de error ICMP.

A continuacin se muestra un diagrama que ilustra un escenario donde


se habilita NAT en un encaminador fronterizo de la zona, conectado a
Internet a travs de un encaminador regional proporcionado por un
proveedor de servicios.

Srisuresh & Holdrege Informativo [Pg. 7]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

\ | / . /
+--------------------+ WAN . +------------------------+/
|Encaminador Regional|---------------|Encaminador frontera NAT|---
+--------------------+ . +------------------------+\
. | \
. | LAN
. ---------------
Frontera del dominio

Figura 1: Un escenario de operacin NAT tpico

3.1. Asignacin transparente de direcciones

NAT asocia direcciones en la red privada con direcciones en la red


global, y viceversa, para proporcionar un encaminamiento transparente
a los datagramas que atraviesen varios dominios de direcciones. En
algunos casos la asociacin puede extenderse a los identificadores de
nivel de transporte (como los puertos TCP/UDP). La asociacin de
direcciones se realiza al comienzo de una sesin. Las siguientes
subsecciones describen dos tipos de asignaciones de direcciones.

3.1.1. Asignacin esttica de direcciones

En el caso de asignacin esttica de direcciones, existe un mapeo uno


a uno de direcciones para las mquinas entre una direccin privada de
red y una direccin externa de red durante el tiempo en
funcionamiento del NAT. La asignacin esttica de direcciones asegura
que NAT no tiene que administrar la gestin de direcciones con los
flujos de sesin.

3.1.2. Asignacin dinmica de direcciones

En este caso, las direcciones externas son asignadas a las mquinas


de la red privada, o viceversa, de manera dinmica, basndose en los
requisitos de uso y el flujo de sesin que el NAT determine
heursticamente. Cuando la ltima de las sesiones que use una
direccin asociada termine, NAT liberar la asociacin para que la
direccin global pueda ser reciclada para su posterior uso. La
naturaleza exacta de la asignacin de direcciones es especfica de
cada implementacin de NAT.

3.2. Encaminamiento transparente

Un encaminador NAT se sita en la frontera entre dos dominios de


direcciones y traduce las direcciones en las cabeceras IP para que
cuando el paquete abandone un dominio y entre en otro, pueda ser
correctamente encaminado. Puesto que los dispositivos NAT tienen
conexiones a mltiples dominios de direcciones, deben tener cuidado

Srisuresh & Holdrege Informativo [Pg. 8]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

de no propagar inadecuadamente informacin (por ejemplo, va


protocolos de encaminamiento) acerca de redes desde un dominio de
direcciones a otro, donde tal anuncio sera juzgado inaceptable.

Hay tres fases en la traduccin de direcciones, que se explican a


continuacin. En conjunto, estas fases resultan en la creacin,
mantenimiento y terminacin del estado de las sesiones que pasan a
travs de los dispositivos NAT.

3.2.1. Asociacin de direcciones

La asociacin de direcciones es la fase en la que la direccin IP de


un nodo local es asociada con una direccin externa, o viceversa, con
el objetivo de su traduccin. La asociacin de direcciones es fija
con asignaciones estticas de direcciones, y es dinmica al comienzo
de la sesin con asignaciones dinmicas de direcciones. Una vez
realizada la asociacin entre las dos direcciones, todas las
sucesivas sesiones con origen o destino en esta mquina usarn la
misma asociacin para la traduccin de paquetes basada en sesin.

Las nuevas asociaciones de direcciones se hacen al comienzo de una


nueva sesin, si tal asociacin de direcciones no existe an. Cuando
una direccin local est ligada a una direccin externa, todas las
sucesivas sesiones con origen en la misma direccin local, o
dirigidas a la misma direccin local usarn la misma asociacin.

El comienzo de cada nueva sesin resultar en la creacin de


informacin de estado para facilitar la traduccin de los datagramas
pertenecientes a la sesin. Puede haber muchas sesiones simultneas
con origen en la misma mquina, basadas en una nica asociacin de
direcciones.

3.2.2. Bsqueda de direcciones y traduccin

Una vez establecida la informacin de estado para una sesin , todos


los paquetes que pertenezcan a la sesin estarn sujetos a la
bsqueda de la direccin (y en algunos casos, la bsqueda del
identificador de transporte) y a su traduccin.

La traduccin de la direccin o del identificador de transporte para


un datagrama resultar en el reenvo del datagrama desde el dominio
de direcciones origen al dominio de direcciones destino con las
direcciones de red apropiadamente actualizadas.

3.2.3. Desasociacin de direcciones

La desasociacin de direcciones es la fase en la que una direccin


privada deja de estar asociada con una direccin global a efectos de

Srisuresh & Holdrege Informativo [Pg. 9]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

traduccin. NAT llevar a cabo la desasociacin de direcciones cuando


piense que la ltima sesin que usaba dicha asociacin ha terminado.
Consulte la Seccin 2.6 para encontrar algunos mtodos heursticos
para manejar el final de las sesiones.

3.3. Traduccin de los paquetes de error ICMP

Todos los mensajes de error ICMP (con la excepcin del tipo de


mensaje Redirect) necesitarn ser modificados al pasar a travs de
NAT. Los tipos de mensaje de error ICMP que necesitan ser modificados
por el NAT incluirn Destination-Unreachable, Source-Quench, Time-
Exceeded y Parameter-Problem. NAT no debera intentar la modificacin
de un mensaje de tipo Redirect.

Los cambios en los mensajes de error ICMP incluirn cambios en el


paquete IP original (o partes de l) incluido en la carga til del
mensaje de error ICMP. A fin de que NAT sea completamente
transparente para los nodos finales, las direcciones IP de la
cabecera IP incluida en la carga til del paquete ICMP deben ser
modificadas, el campo suma de verificacin de la misma cabecera IP
debe ser modificado en consonancia, as como la cabecera de
transporte que la acompaa. La suma de verificacin de la cabecera IP
debe ser modificada para reflejar los cambios realizados en la carga
til a las cabeceras IP y de transporte. Adems, la cabecera IP
normal tambin debe ser modificada.

4.0. Varios sabores de NAT

Existen diversas variantes de traduccin de direcciones, cada una de


las cuales se presta a diferentes aplicaciones. La lista de variantes
de NAT que se enumera en las subsecciones siguientes no es ni mucho
menos exhaustiva, pero trata de mostrar las diferencias ms
significativas existentes.

El siguiente diagrama se va a usar como modelo bsico para ilustrar


las variantes de NAT. La mquina Host-A, con direccin Addr-A, se
encuentra en un dominio privado, representado por la red N-Pri. N-Pri
est aislada del dominio de red externo mediante un encaminador NAT.
La mquina Host-X, con direccin Addr-X, se encuentra en un dominio
externo, representado por la red N-Ext. El encaminador NAT con dos
interfases, cada una enganchada a uno de los dominios, proporciona
encaminamiento transparente entre los dos dominios. La interfase
hacia el dominio externo tiene asignada una direccin de Addr-Nx y la
interfase hacia el dominio privado tiene asignada una direccin de
Addr-Np. Adems, se puede considerar que las direcciones Addr-A y
Addr-Np corresponden a la red N-Pri y que las direcciones Addr-X y
Addr-Nx corresponden a la red N-Ext.

Srisuresh & Holdrege Informativo [Pg. 10]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

----------------
( Dominio )
( Direcciones ) +--+
( Externo )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| Encaminador |
| |
| NAT |
+--------------+
|(Addr-Np)
|
----------------
( Dominio )
+--+ ( Direcciones )
|__|------( Privado )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)

Figura 2: Un modelo base para ilustrar la terminologa de NAT.

4.1. NAT Tradicional (o) NAT Saliente

El NAT tradicional permitir, en la mayora de los casos, que las


mquinas en el interior de una red privada accedan de manera
transparente a mquinas en la red externa. En un NAT tradicional, las
sesiones son unidireccionales, salientes desde la red privada. Esto
contrasta con el NAT bidireccional, que permite sesiones en los
sentidos tanto saliente como entrante. Se puede encontrar una
descripcin detallada del NAT bidireccional en la Seccin 4.2.

A continuacin se describen las propiedades de los dominios


soportados por el NAT tradicional. Las direcciones IP de las mquinas
en la red externa son nicas y vlidas tanto en la red externa como
en la interna. Sin embargo, las direcciones de las mquinas en la red
privada son nicas slo en el interior de la red privada y pueden no
ser vlidas en la red externa. En otras palabras, el NAT no anunciar
las redes privadas al dominio externo. Pero las redes del dominio
externo pueden ser anunciadas en el interior de la red privada. Las
direcciones usadas en el interior de la red privada no deben
solaparse con las direcciones externas. Cualquier direccin dada debe
ser, bien una direccin privada, bien una direccin externa; no
ambas.

Srisuresh & Holdrege Informativo [Pg. 11]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Un encaminador NAT tradicional en la Figura 2 permitir a la mquina


Host-A iniciar sesiones hacia Host-X, pero no en el sentido
contrario. Tambin, N-Ext es encaminable desde el interior de N-Pri,
mientras que N-Pri puede no ser encaminable desde N-Ext.

El NAT tradicional se usa principalmente en lugares que usan


direcciones privadas y desean permitir sesiones salientes desde sus
instalaciones.

Existen dos variantes del NAT tradicional, lase NAT bsico y NAPT
(Network Address Port Translation). Se discuten en los siguientes
apartados.

4.1.1. NAT bsico

Con el NAT bsico, un bloque de direcciones externas se reserva para


traducir direcciones de mquinas en el dominio privado segn originen
sesiones hacia el dominio externo. Para los paquetes salientes desde
la red privada, la direccin IP de origen y campos relacionados tales
como las sumas de verificacin de las cabeceras IP, TCP, UDP e ICMP
son traducidos. Para los paquetes entrantes, se traducen la direccin
IP de destino y las sumas de verificacin recin enumeradas.

Un encaminador NAT bsico en la Figura 2 puede ser configurado para


traducir N-Pri en un bloque de direcciones externas, por ejemplo
desde Addr-i hasta Addr-n, seleccionadas de la red externa N-Ext.

4.1.2. Network Address Port Translation (NAPT)

La "Traduccin de Direccin de Red y Puerto", Network Address Port


Translation (NAPT), extiende la nocin de traduccin un paso ms
all, porque tambin traduce el identificador de transporte (por
ejemplo, los nmeros de puerto TCP y UDP, y los identificadores de
peticin ICMP). Esto permite que los identificadores de transporte de
un cierto nmero de mquinas privadas sean multiplexados en los
identificadores de transporte de una nica direccin externa. NAPT
permite a un conjunto de mquinas compartir una nica direccin
externa. Dese cuenta que NAPT se puede combinar con NAT bsico para
que se use un bloque de direcciones externas en conjunto con la
traduccin de puertos.

Para los paquetes salientes de la red privada, NAPT traducir la


direccin IP de origen, el identificador de transporte origen y los
campos relacionados tales como las sumas de verificacin de las
cabeceras IP, TCP, UDP e ICMP. El identificador de transporte puede
ser el puerto TCP/UDP o el ID de la peticin ICMP. Para los paquetes
entrantes, se traducen la direccin IP de destino, el identificador
de transporte destino y las sumas de verificacin de las cabeceras IP

Srisuresh & Holdrege Informativo [Pg. 12]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

y de transporte.

Un encaminador NAPT en la Figura 2 puede ser configurado para


traducir las sesiones con origen en N-Pri en una nica direccin
externa, Addr-i.

Muy a menudo, la direccin de la interfase externa del encaminador


NAPT, Addr-Nx, se usa como la direccin hacia la que mapear N-Pri.

4.2. NAT bidireccional (o) NAT de doble sentido

Con el NAT bidireccional, las sesiones pueden iniciarse tanto desde


mquinas en la red pblica como desde mquinas en la red privada. Las
direcciones de la red privada se asocian a direcciones globales
nicas, esttica o dinmicamente, segn se establecen las conexiones
en cualquier sentido. El espacio de nombres (es decir, sus "Nombres
de Dominio Plenamente Cualificados", Fully Qualified Domain Names
(FQDN)) entre las mquinas de las redes privada y externa se supone
nico extremo a extremo. Las mquinas en el dominio externo acceden a
las mquinas del dominio privado usando DNS para la resolucin de
direcciones. Debe utilizarse un DNS-ALG junto con NAT bidireccional
para facilitar el mapeo de nombres a direcciones. En concreto, el
DNS-ALG debe ser capaz de traducir las direcciones del dominio
privado en consultas DNS y las respuestas en sus direcciones del
dominio externo asociadas, y viceversa, segn los paquetes DNS viajan
entre los dominios privado y externo.

Los requisitos del espacio de direcciones indicados para los


encaminadores NAT tradicionales son tambin aplicables aqu.

Un encaminador NAT bidireccional en la Figura 2 permitir que Host-A


inicie sesiones hacia Host-X, y que Host-X inicie sesiones hacia
Host-A. Al igual que con NAT tradicional, N-Ext es encaminable desde
el interior de N-Pri, pero N-Pri puede no ser encaminable desde N-
Ext.

4.3. NAT doble

El NAT doble es una variante del NAT en el que tanto las direcciones
de origen como de destino son modificadas mediante NAT cuando el
datagrama atraviesa dominios de direcciones. Esto contrasta con el
NAT tradicional y con el NAT bidireccional, donde slo se traduce una
de las direcciones (bien la de origen, bien la de destino). Dese
cuenta que no hay algo as como "NAT simple".

El NAT doble es necesario cuando los dominios privado y externo


tienen colisiones de direcciones. El caso ms habitual donde podra
ocurrir esto es cuando un lugar ha numerado (inadecuadamente) sus

Srisuresh & Holdrege Informativo [Pg. 13]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

nodos internos usando direcciones pblicas que han sido asignadas a


otra organizacin. Alternativamente, un sitio puede haber cambiado de
uno a otro proveedor, pero manteniendo las direcciones (internamente)
que le haban sido asignadas por el primer proveedor. De esta manera,
ese proveedor podra ms tarde reasignar estas direcciones a algn
otro cliente. El elemento clave en estos casos es que la direccin de
la mquina en el dominio externo puede haber sido asignada a la misma
direccin que una mquina en el sitio local. Si esas direcciones
aparecieran en un paquete, ste sera reenviado al nodo interno en
lugar de al dominio externo a travs del dispositivo de NAT. El NAT
doble intenta puentear estos dominios traduciendo las direcciones de
origen y destino de los paquetes IP, segn el paquete atraviesa
dominios.

El NAT doble funciona como se describe a continuacin. Cuando Host-A


desea iniciar una sesin hacia Host-X, emite una peticin DNS para el
Host-X. Un DNS-ALG intercepta la consulta DNS, y en la respuesta que
devuelve a Host-A el DNS-ALG sustituye la direccin del Host-X con
una que sea adecuadamente encaminable en el sitio local (digamos
Host-XPRIME). Entonces el Host-A inicia la comunicacin con Host-
XPRIME. Cuando los paquetes atraviesan el dispositivo NAT, la
direccin IP de origen se traduce (como en el caso de NAT
tradicional) y la direccin de destino se traduce a Host-X. En los
paquetes de vuelta desde Host-X se lleva a cabo una traduccin
similar.

A continuacin se describen las propiedades de los dominios


soportados por NAT doble. Las direcciones de red de las mquinas en
la red externa son nicas en las redes externas, pero no en el
interior de la red privada. De igual manera, las direcciones de red
de las mquinas en la red privada son nicas slo en el interior de
la red privada. En otras palabras, el espacio de direcciones usado en
la red privada para localizar mquinas en las redes privada y pblica
no est relacionado con el espacio de direcciones usado en la red
pblica para localizar mquinas en las redes privada y pblica. El
NAT doble no debera poder anunciar las redes locales a la red
externa, y viceversa.

Un encaminador NAT doble en la Figura 2 permitira al Host-A iniciar


sesiones hacia Host-X, y al Host-X iniciar sesiones hacia Host-A. Sin
embargo, N-Ext (o un subconjunto de N-Ext) no es encaminable desde el
interior de N-Pri, y N-Pri no es encaminable desde N-Ext.

Es tpico utilizar NAT doble cuando el espacio de direcciones usado


en la red privada se solapa con direcciones usadas en el espacio
pblico. Por ejemplo, digamos que un sitio privado usa el espacio de
direcciones 200.200.200.0/24, que est oficialmente asignado a otro
sitio en la Internet pblica. Host_A (200.200.200.1) en el espacio

Srisuresh & Holdrege Informativo [Pg. 14]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

privado trata de conectar con Host_X (200.200.200.100) en el espacio


pblico. Para que esta conexin funcione, la direccin de Host_X se
mapea a una direccin diferente para Host_A, y viceversa. El NAT
doble situado en la frontera del sitio privado se puede configurar
como sigue:

Privado a Pblico: 200.200.200.0/24 -> 138.76.28.0/24


Pblico a Privado: 200.200.200.0/24 -> 172.16.1.0/24

Flujo de datagramas: Host_A(Privado) -> Host_X(Pblico)

a) En la red privada

DA: 172.16.1.100 SA: 200.200.200.1

b) Despus de la traduccin del NAT doble

DA: 200.200.200.100 SA: 138.76.28.1

Flujo de datagramas Host_X (Pblico) -> Host_A (Privado)

a) En la red Pblica

DA: 138.76.28.1 SA: 200.200.200.100

b) Despus de la traduccin del NAT doble, en la red privada

SA: 200.200.200.1 DA: 172.16.1.100

4.4. Multihomed NAT

Existen limitaciones en el uso de NAT. Por ejemplo, las peticiones y


las respuestas pertenecientes a una sesin deben ser encaminadas a
travs del mismo encaminador NAT, puesto que un encaminador NAT
mantiene la informacin de estado para las sesiones establecidas a
travs suyo. Por esta razn, a menudo se sugiere que los
encaminadores NAT se siten en un encaminador fronterizo nico para
un dominio, donde todos los paquetes IP estn, bien originados en el
dominio, bien destinados a l. Sin embargo, tal configuracin
llevara al encaminador NAT a convertirse en [un punto vulnerable
centralizado: ].

Para asegurar que la conectividad de una red privada con las redes
externas se mantiene an cuando uno de los enlaces NAT falle, a
menudo es deseable conectar la red privada al mismo o mltiples
proveedores de servicio con mltiples conexiones desde el domino
privado, tanto desde la misma como desde diferentes mquinas NAT.

Srisuresh & Holdrege Informativo [Pg. 15]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Por ejemplo, una red privada podra tener enlaces hacia dos
proveedores diferentes y las sesiones desde las mquinas privadas
podran fluir a travs del encaminador NAT con una mejor mtrica al
destino. Cuando uno de los encaminadores NAT falle, el otro podra
encaminar el trfico para todas las conexiones.

Mltiples mquinas NAT o mltiples enlaces en la misma mquina NAT,


compartiendo la misma configuracin de NAT, pueden proporcionarse
respaldo a prueba de fallos entre s. En tal caso, es necesario que
el dispositivo NAT de respaldo intercambie informacin de estado para
que el NAT de respaldo pueda hacerse cargo de la carga de sesiones de
manera transparente cuando el NAT primario falle. El NAT de respaldo
se simplifica cuando la configuracin est basada en mapas estticos.

5.0. IP Especfico de Dominio, Realm Specific IP (RSIP)

El "IP Especfico de Dominio", Realm Specific IP (RSIP), se usa para


caracterizar la funcionalidad de una mquina consciente de los
dominios en un dominio privado, mquina que asume direcciones IP
especficas del dominio para comunicarse con mquinas en los dominios
privado o externo.

Un "Cliente IP Especfico de Dominio", Realm Specific IP Client


(cliente RSIP), es una mquina en una red privada que adopta una
direccin en el dominio externo cuando se conecta a mquinas en ese
dominio, para lograr la comunicacin extremo a extremo. En estas
condiciones, los paquetes generados por una mquina en cualquier
extremo estaran basados en direcciones que son nicas extremo a
extremo en el dominio externo y no requieren de traduccin por un
proceso intermedio.

Un "Servidor IP Especfico de Dominio", Realm Specific IP Server


(servidor RSIP), es un nodo que reside en los dominios privado y
externo, y que puede facilitar el encaminamiento de los paquetes del
dominio externo dentro de un dominio privado. Estos paquetes son,
bien generados por un cliente RSIP, bien dirigidos a un cliente RSIP.
El servidor RSIP tambin puede ser el nodo que asigne las direcciones
del dominio externo a los clientes RSIP.

Existen dos variantes de RSIP, llamadas "IP de Direccin Especfica


de Dominio", Realm-Specific Address IP (RSA-IP), e "IP de Direccin y
Puerto Especficos de Dominio", Realm-Specific Address and Port IP
(RSAP-IP). Estas variantes se discuten en las siguientes
subsecciones.

5.1. IP de Direccin Especfica de Dominio (RSA-IP)

Un cliente de Direccin IP Especfica de Dominio (RSA-IP), cuando se

Srisuresh & Holdrege Informativo [Pg. 16]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

conecta a una mquina en un dominio externo, adopta una direccin de


un espacio de direcciones externo. Una vez que un cliente RSA-IP
asume una direccin externa, ninguna otra mquina en los dominios
privado o externo puede asumir la misma direccin, hasta que esa
direccin sea liberada por el cliente RSA-IP.

A continuacin se discuten las alternativas de encaminamiento que se


pueden intentar para los paquetes RSA-IP extremo a extremo dentro del
dominio privado. Una aproximacin podra ser enviar el paquete por un
tnel hasta el destinatario. La cabecera externa se puede traducir
mediante NAT como habitualmente, sin afectar a las direcciones que se
usan en la cabecera interna. Otra posibilidad sera establecer un
tnel bidireccional entre el cliente RSA-IP y el encaminador frontera
que separa los dos dominios de direcciones. Los paquetes desde y
hacia el cliente seran enviados por el tnel, pero los paquetes
seran reenviados de la forma habitual entre el encaminador
fronterizo y el destino remoto. Dese cuenta que el tnel ENTRE el
cliente Y el encaminador fronterizo puede no ser necesario. Podra
bastar simplemente con reenviar el paquete directamente. Esto debera
funcionar siempre que la red interna no est filtrando paquetes en
funcin de sus direcciones de origen (que en este caso seran
direcciones externas).

Por ejemplo, Host-A en la Figura 2 anterior, podra asumir una


direccin Addr-k del dominio externo y actuar como un cliente RSA-IP
para permitir las sesiones extremo a extremo entre Addr-k y Addr-X.
Se puede ilustrar el paso de los paquetes extremo a extremo dentro
del dominio privado de la siguiente manera:

Srisuresh & Holdrege Informativo [Pg. 17]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Primer mtodo, usando un encaminador NAT intermedio para traducir:


=================================================================

Host-A Encaminador NAT Host-X


------ --------------- ------

<Cabecera IP externa, con


src=Addr-A, Dest=Addr-X>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-k, Dest=Addr-X>
-------------------------------->

<Cabecera IP externa, con


src=Addr-K, Dest=Addr-X>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-k, Dest=Addr-X>
------------------------------->
.
.
.

<Cabecera IP externa, con


src=Addr-X, Dest=Addr-k>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X, Dest=Addr-k>
<----------------------------------

<Cabecera IP externa, con


src=Addr-X, Dest=Addr-A>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X, Dest=Addr-k>
<-------------------------------------

Srisuresh & Holdrege Informativo [Pg. 18]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Segundo mtodo, usando un tnel dentro del dominio privado:


==========================================================

Host-A Encaminador NAT Host-X


------ --------------- ------

<Cabecera IP externa, con


src=Addr-A, Dest=Addr-Np>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-k, Dest=Addr-X>
----------------------------->

<Paquete extremo a extremo,


con src=Addr-k, Dest=Addr-X>
------------------------------->

.
.
.

<Paquete extremo a extremo,


con src=Addr-X, Dest=Addr-k>
<--------------------------------

<Cabecera IP externa, con


src=Addr-Np, Dest=Addr-A>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X, Dest=Addr-k>
<---------------------------------

Pueden existir otras alternativas que considerar.

Un cliente RSA-IP tiene las siguientes caractersticas. El conjunto


de todas las operaciones llevadas a cabo por un cliente RSA-IP puede
denominarse "RSA-IP".

1. Es consciente de a quin pertenecen sus nodos interlocutores.

2. Asume una direccin del dominio externo cuando se comunica con las
mquinas en ese dominio. Tales direcciones pueden ser asignadas
estticamente u obtenidas dinmicamente (mediante un protocolo an
por definir) desde un nodo capaz de asignar direcciones del
dominio externo. El servidor RSA-IP poda ser el nodo que
coordinase la asignacin de direcciones del dominio externo.

Srisuresh & Holdrege Informativo [Pg. 19]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

3. Encaminar los paquetes a las mquinas externas usando una


estrategia adecuada para el servidor RSA-IP. En todos los casos,
el cliente RSA-IP probablemente necesitar actuar como uno de los
extremos del tnel, capaz de encapsular los paquetes extremo a
extremo, al tiempo que reenva y desencapsula en el trayecto de
vuelta.

El Servidor de Direccin IP Especfica de Dominio (Servidor RSA-IP)


es un nodo que reside tanto en el dominio privado como en el externo,
y que proporciona encaminamiento en el interior de un dominio privado
a los paquetes del dominio externo especficos de los clientes RSA-
IP. Un servidor RSA-IP puede ser descrito como aqul que dispone de
las siguientes caractersticas.

1. Puede ser configurado para asignar direcciones desde el dominio


externo a los clientes RSA-IP, bien esttica o dinmicamente.

2. Debe ser un encaminador que resida tanto en el dominio de


direcciones privado como en el externo.

3. Debe ser capaz de proporcionar un mecanismo para encaminar los


paquetes del dominio externo dentro del dominio privado. De las
dos aproximaciones descritas, la primera de ellas requiere que el
servidor RSA-IP sea un encaminador NAT que proporcione
encaminamiento transparente para la cabecera externa. Esta
aproximacin requiere que el interlocutor externo sea un extremo
del tnel.

Con la segunda aproximacin, un servidor RSA-IP podra ser


cualquier cualquier encaminador (incluyendo un encaminador NAT)
que pueda ser un extremo del tnel con los clientes RSA-IP. El
encaminador extrera del tnel los paquetes extremo a extremo
salientes de los clientes RSA-IP y los reenviara a las mquinas
externas. En el camino de vuelta, localizara el tnel del cliente
RSA-IP, basado en la direccin destino de los paquetes extremo a
extremo y encapsulara el paquete en un tnel para reenviarlo al
cliente RSA-IP.

Los clientes RSA-IP pueden intentar cualquiera de las tcnicas IPsec,


a saber, identificacin y confidencialidad en modo transporte o
tnel, usando cabeceras AH y ESP en los paquetes encapsulados.
Cualquiera de las tcnicas de tneles pueden ser adaptadas para la
encapsulacin entre el cliente RSA-IP y el servidor RSA-IP, o entre
el cliente RSA-IP y las mquinas externas. Por ejemplo, la
encapsulacin IPsec en modo tnel es un tipo de encapsulacin vlido
que asegura la autenticacin y la confidencialidad IPsec de los
paquetes extremo a extremo encapsulados.

Srisuresh & Holdrege Informativo [Pg. 20]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

5.2 Direccin y Puerto IP especficos de Dominio (RSAP-IP)

Direccin y Puerto IP Especficos de Dominio (RSAP-IP) es una


variante de RSIP que permite a mltiples mquinas privadas usar una
nica direccin externa, multiplexando segn los IDentificadores de
transporte (es decir, los nmero de puerto TCP/UDP y los
IDentificadores de consulta ICMP).

Se puede definir el "Cliente RSAP-IP" como parecido a un cliente RSA-


IP con la variacin de que un cliente RSAP-IP asume una tupla
(direccin externa, identificador de transporte) cuando se conecta a
mquinas en el domino externo para lograr la comunicacin extremo a
extremo. En este caso, la comunicacin de un cliente RSAP-IP con los
nodos externos puede quedar limitada a sesiones TCP, UDP e ICMP.

Un "Servidor RSAP-IP" se parece a un servidor RSA-IP en que facilita


el encaminamiento de paquetes del dominio externo pertenecientes a
los clientes RSAP-IP en el interior de un dominio privado. Lo
habitual es que el servidor RSAP-IP tambin sea el que asigne las
tuplas (direccin externa, identificador de transporte) a los
clientes RSAP-IP.

Un encaminador NAPT intermedio puede valer como servidor RSAP-IP,


cuando la encapsulacin externa est basada en TCP/UDP y est
direccionado entre el cliente RSAP-IP y el interlocutor externo. Esta
aproximacin requiere que el interlocutor externo sea uno de los
extremos del tnel basado en TCP/UDP. Usando esta aproximacin, los
clientes RSAP-IP puedes utilizar cualquiera de las tcnicas IPsec,
identificacin y confidencialidad en modo transporte o tnel, usando
cabeceras AH y ESP en los paquetes encapsulados. Sin embargo, dese
cuenta que el modo tnel IPsec no es un tipo vlido de encapsulacin,
puesto que un encaminador NAPT no puede proporcionar encaminamiento
transparente a los protocolos AH y ESP.

Alternativamente, se puede enviar los paquetes por un tnel entre el


cliente RSAP-IP y el servidor RSAP-IP, de manera que el servidor
RSAP-IP sacara los paquetes del tnel provenientes de los clientes
RSAP-IP y los reenviara a las mquinas externas. En el camino de
vuelta, el servidor RSAP-IP localizara el tnel del cliente RSAP-IP,
basndose en la tupla (direccin destino, identificador de
transporte) y encapsulara el paquete original dentro de un tnel
para reenviarlo al cliente RSAP-IP. Con esta aproximacin, no hay
limitacin en la tcnica de tneles utilizada entre el cliente RSAP-
IP y el servidor RSAP-IP. Sin embargo, existen limitaciones que
aplican a la seguridad basada en IPsec de los paquetes extremo a
extremo. Se puede conseguir identificacin e integridad basados en
modo transporte. Pero no se puede permitir la confidencialidad porque
el servidor RSAP-IP debe ser capaz de examinar el identificador de

Srisuresh & Holdrege Informativo [Pg. 21]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

transporte destino para as poder identificar el tnel RSAP-IP por el


que enviar los paquetes que le lleguen. Por esta razn, slo los
paquetes TCP, UDP e ICMP protegidos mediante identificacin AH y ESP
en modo transporte pueden atravesar un servidor RSAP-IP usando esta
aproximacin.

Por ejemplo, supongamos que Host-A de la Figura 2 anterior obtiene


una tupla (Addr-Nx, puerto TCP T-Nx) de un encaminador NAPT para
actuar como cliente RSAP-IP e iniciar sesiones TCP extremo a extremo
con Host-X. El paso de los paquetes extremo a extremo dentro del
dominio privado se puede ilustrar como se muestra a continuacin. En
el primer mtodo, la capa externa del paquete desde Host-A usa
(direccin privada Addr-A, puerto origen T-Na) como tupla origen para
comunicarse con Host-X. El encaminador NAPT intermedio traduce esta
tupla a (Addr-Nx, puerto T-Nxa). Esta traduccin es independiente de
los parmetros de la tupla del cliente RSAP-IP usados en el paquete
encapsulado.

Srisuresh & Holdrege Informativo [Pg. 22]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Primer mtodo, usando un encaminador NAPT intermedio para traducir:


==================================================================

Host-A Encaminador NAPT Host-X


------ ---------------- ------

<Paquete TCP/UDP externo,


con src=Addr-A,
Src Port=T-Na, Dest=Addr-X>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-Nx,
Src Port=T-Nx, Dest=Addr-X>
----------------------------->

<Paquete TCP/UDP externo,


con src=Addr-Nx,
Src Port=T-Nxa, Dest=Addr-X>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-Nx,
Src Port=T-Nx, Dest=Addr-X>
--------------------------------------->

.
.
.

<Paquete TCP/UDP externo,


con src=Addr-X,
Dest=Addr-Nx, Dest Port=T-Nxa>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X,
Dest=Addr-Nx, Dest Port=T-Nx>
<-------------------------------------

<Paquete TCP/UDP externo,


con src=Addr-X,
Dest=Addr-A, Dest Port=T-Na>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X,
Dest=Addr-Nx, Dest Port=T-Nx>
<-----------------------------------

Srisuresh & Holdrege Informativo [Pg. 23]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Segundo mtodo, usando un tnel dentro del dominio privado:


==========================================================

Host-A Encaminador NAPT Host-X


------ ---------------- ------

<Cabecera IP externa, con


src=Addr-A, Dest=Addr-Np>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-Nx,
Src Port=T-Nx, Dest=Addr-X>
----------------------------->

<Paquete extremo a extremo,


con src=Addr-Nx,
Src Port=T-Nx, Dest=Addr-X>
-------------------------------->

.
.
.

<Paquete extremo a extremo,


con src=Addr-X,
Dest=Addr-Nx, Dest Port=T-Nx>
<----------------------------------

<Cabecera IP externa, con


src=Addr-Np, Dest=Addr-A>,
encapsulando
<Paquete extremo a extremo,
con src=Addr-X,
Dest=Addr-Nx, Dest Port=T-Nx>
<----------------------------------

6.0. Redes privadas y tneles

Consideremos el caso donde su red privada se conecta al mundo


exterior mediante tneles. En tal caso, el trfico encapsulado en los
tneles puede o no contener paquetes traducidos dependiendo de las
caractersticas de los dominios de direcciones que un tnel est
enlazando.

Las siguientes subsecciones discuten dos escenarios donde se usan


tneles (a) junto con traduccin de direcciones, y (b) sin
traduccin.

Srisuresh & Holdrege Informativo [Pg. 24]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

6.1. Enviando los paquetes traducidos por el tnel.

Todas las variantes de traduccin de direcciones discutidas en la


seccin anterior pueden aplicarse a los enlaces directamente
conectados as como a los tneles y a las "Redes Privadas Virtuales",
Virtual Private Networks (VPN).

Por ejemplo, una red privada virtual conectada a un socio del negocio
mediante una VPN puede utilizar NAT tradicional para comunicarse con
el asociado. De igual forma, es posible emplear NAT doble, si el
espacio de direcciones del asociado se solapa con la red privada.
Podra haber un dispositivo NAT en un extremo del tnel o en ambos
extremos. En todos los casos, se puede encriptar el trfico a lo
largo de la VPN por razones de seguridad. Aqu la seguridad se
refiere a la del trfico slo a lo largo de las VPN. La seguridad
extremo a extremo requiere confiar en los dispositivos NAT dentro de
la red privada.

6.2. Redes privadas particionadas mediante troncales

Hay muchas situaciones en las que una red privada (por ejemplo, una
red corporativa) se extiende por varias localizaciones, usando
troncales pblicos para la comunicacin entre dichas localizaciones.
En tales casos, no es deseable hacer traduccin de direcciones, tanto
por el hecho de haber muchas mquinas que deseen comunicarse a lo
largo del troncal, necesitando grandes tablas de direcciones, como
por la existencia de ms aplicaciones que dependen de las direcciones
configuradas, en lugar de acudir a un servidor de nombres. A dichas
redes privadas las denominamos redes privadas particionadas mediante
troncales.

Los extremos particionados mediante troncales deberan comportarse


como si fuesen extremos no particionados. Es decir, los encaminadores
en todas las particiones deberan mantener rutas hacia los espacios
de direcciones locales de todas las particiones. Por supuesto, los
troncales (pblicos) no mantienen rutas hacia ninguna de las
direcciones locales. Por lo tanto, los encaminadores fronterizos
deben "tunelar" (mediante VPN) a travs de los troncales usando
encapsulacin. Para hacer esto, cada dispositivo NAT reservar una
direccin global para "tunelar".

Cuando un dispositivo NAT x en el extremo de la particin X desea


entregar un paquete al extremo de la particin Y, encapsular el
paquete en una cabecera IP con direccin destino establecida a la
direccin global del dispositivo NAT y, reservada para la
encapsulacin. Cuando el dispositivo NAT recibe un paquete con esa
direccin destino, desencapsula la cabecera IP y encamina
internamente el paquete. Dese cuenta que no hay traduccin de

Srisuresh & Holdrege Informativo [Pg. 25]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

direcciones en el proceso; slo hay transferencia de paquetes de la


red privada por un tnel troncal en la red externa.

7.0. Caractersticas operacionales de NAT

Los dispositivos de NAT no son conscientes de las aplicaciones,


porque las traducciones estn limitadas slo a las cabeceras
IP/TCP/UDP/ICMP y a los mensaje de error ICMP. Los dispositivos NAT
no modifican la carga til de los paquetes, puesto que stos tienden
a ser especficos de las aplicaciones.

Los dispositivos NAT (sin incluir a las ALG) no examinan ni modifican


la carga til del protocolo de transporte. Por esta razn, en muchos
casos los dispositivos NAT son transparentes a las aplicaciones. Sin
embargo, hay dos reas donde los dispositivos NAT a menudo tienen
dificultades: 1) cuando la carga til de un aplicacin incluye una
direccin IP, y 2) cuando es necesaria seguridad extremo a extremo.
Dese cuenta que esta no es una lista exhaustiva.

Las tcnicas de seguridad en el nivel de aplicacin que no hacen uso


ni dependen de las direcciones IP funcionarn correctamente en
presencia de NAT (por ejemplo, TLS, SSL y SSH). Sin embargo, las
tcnicas de nivel de transporte tales como el modo transporte IPsec o
la opcin de firma TCP MD5 de la RFC2385 [Ref 17] no.

En modo transporte IPsec, tanto AH como ESP disponen de una


comprobacin de integridad que cubre la carga til en su totalidad.
Cuando la carga til es TCP o UDP, la suma de verificacin TCP/UDP
queda cubierta por la comprobacin de integridad. Cuando un
dispositivo NAT modifica una direccin la suma de verificacin deja
de ser vlida con respecto a la nueva direccin. Normalmente, NAT
tambin actualiza la suma de verificacin, pero esto no es efectivo
cuando se usa AH o ESP. En consecuencia, los receptores descartarn
un paquete bien porque falle la comprobacin de integridad IPsec (si
el dispositivo NAT actualiza la suma de verificacin), bien porque la
suma de verificacin es invlida (si el dispositivo de NAT deja la
suma de verificacin sin modificar).

Dese cuenta que se puede usar el modo tnel ESP de IPsec siempre que
los contenidos del paquete encapsulado no se vean afectados por la
traduccin de la cabecera IP externa. Aunque esta tcnica no funciona
en despliegues NAT tradicionales (es decir, donde las mquinas no son
conscientes de la presencia de NAT), la tcnica es aplicable a IP
Especfica de Dominio segn se describe en la Seccin 5.0.

Dese cuenta que la confidencialidad y la autenticacin del modo de


transporte extremo a extremo basado en ESP es posible para paquetes
tales como los ICMP, donde la carga til IP no se ve afectada por la

Srisuresh & Holdrege Informativo [Pg. 26]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

traduccin de la cabecera IP externa.

Los dispositivos NAT tambin invalidan suposiciones fundamentales de


las infraestructuras de distribucin de clave pblica tales como
Secure DNS RFC2535 [Ref 18] y certificados X.509 con claves pblicas
firmadas. En el caso de Secure DNS, cada DNS RRset se firma con una
clave desde el interior de la zona. Adems, la autenticidad de una
clave especfica se verifica siguiendo una cadena de confianza que
avanza hasta los DNS raz. Cuando un DNS-ALG modifica direcciones
(por ejemplo, en el caso de NAT doble), la verificacin de las firmas
falla.

Puede ser interesante darse cuenta que IKE (protocolo de negociacin


de claves de sesin) es un protocolo de nivel de sesin basado en UDP
y no est protegido por seguridad IPsec de nivel de red. Dentro de
IKE slo se protegen una parte de las cargas tiles individuales. En
consecuencia, las sesiones IKE son posibles a travs de NAT, siempre
que la carga til de IKE no contenga direcciones y/o identificadores
de transporte especficos a un dominio y no al otro. Puesto que IKE
se usa para establecer asociaciones IPsec, y puesto que actualmente
no existen maneras conocidas de hacer que IPsec funcione a travs de
un dispositivo NAT, es un tema futuro de trabajo el aprovechar IKE a
travs de un dispositivo de NAT.

Una de las aplicaciones de Internet ms populares, FTP, no


funcionara con la definicin de NAT segn se ha descrito. La
siguiente subseccin est dedicada a describir cmo se soporta FTP en
los dispositivos NAT. FTP ALG es una parte integral de la mayora de
implementaciones de NAT. Algunos fabricantes pueden optar por incluir
ALG adicionales para soportar otras aplicaciones en el dispositivo
NAT.

7.1. Soporte de FTP

El comando "PORT" y la respuesta "PASV" en la carga til en una


sesin de control FTP identifican la direccin IP y el puerto TCP que
deben ser usados para la sesin de datos a la que dan soporte. Los
parmetros del comando PORT y la respuesta PASV son una direccin IP
y un puerto en ASCII. Se necesita un FTP ALG para monitorizar y
actualizar la carga til de la sesin de control FTP para que la
informacin contenida en la carga til sea la adecuada para los nodos
finales. La ALG tambin debe actualizar el NAT con las tuplas
apropiadas de la sesin de datos y la orientacin de la sesin para
que NAT pueda establecer informacin de estado para las sesiones de
datos FTP.

Puesto que la direccin y el puerto TCP se codifican en ASCII, esto


puede provocar cambios en el tamao del paquete. Por ejemplo,

Srisuresh & Holdrege Informativo [Pg. 27]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

10,18,177,42,64,87 mide 18 caracteres ASCII, mientras que


193,45,228,137,64,87 mide 20 caracteres ASCII. Si el nuevo tamao es
igual al anterior, slo es necesario ajustar la suma de verificacin
TCP como consecuencia de cambiar los datos. Si el nuevo tamao es
inferior o superior al anterior, tambin deben cambiarse los nmeros
de secuencia TCP para hacer patente el cambio de longitud en la parte
de los datos de control TCP. La ALG puede usar una tabla especial
para corregir los nmeros de secuencia y asentimientos de TCP. Ser
necesario llevar a cabo la correccin de los nmeros de secuencia y
asentimiento en todos los paquetes futuros de la conexin.

8.0. Limitaciones de NAT

8.1. Aplicaciones que contienen direcciones IP

No todas las aplicaciones se prestan de manera sencilla a la


traduccin de direcciones mediante dispositivos NAT. En especial, las
aplicaciones que transportan direcciones IP (y puertos TU, en el caso
de NAT) en el interior de la carga til. Se deben usar "Pasarelas de
Nivel de Aplicacin", Application Level Gateways (ALG), para llevar a
cabo traducciones de paquetes pertenecientes a tales aplicaciones.
Opcionalmente las ALG pueden utilizar las asignaciones de direcciones
(y puertos TU) realizadas mediante NAT y llevar a cabo traducciones
especficas a la aplicacin. La combinacin de la funcionalidad NAT
con las ALG no proporcionar la seguridad extremo a extremo
garantizada por IPsec. Sin embargo, se puede utilizar el modo tnel
de IPsec cuando el encaminador NAT acte como uno de los extremos del
tnel.

SNMP es una de esas aplicaciones que contienen direcciones en la


carga til. Los encaminadores NAT no traducirn las direcciones IP en
el interior de los paquetes SNMP. No es infrecuente que un ALG
especfico para SNMP resida en el encamindor NAT para llevar a cabo
traducciones SNMP MIB propias de la red privada.

8.2. Aplicaciones con sesiones de datos y control interdependientes.

Los dispositivos NAT operan asumiendo que cada sesin es


independiente. Las caractersticas de una sesin, como su
orientacin, las direcciones IP de origen y destino, protocolo de la
sesin, y los identificadores del nivel de transporte origen y
destino se determinan de manera independiente al comienzo de cada
nueva sesin.

Sin embargo, hay aplicaciones tales como H.323 que utilizan una o ms
sesiones de control para establecer las caractersticas de las
sesiones que vendrn a continuacin, usando para ello la carga til
de la sesin de control. Tales aplicaciones requieren del uso de ALG

Srisuresh & Holdrege Informativo [Pg. 28]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

especficas de aplicacin que puedan interpretar y traducir las


cargas tiles, en caso necesario. La interpretacin de la carga til
ayudara a que NAT est preparado para las sesiones de datos
venideras.

8.3. Consideraciones de depuracin

NAT incrementa las posibilidades de direccionar errneamente. Por


ejemplo, la misma direccin local puede estar ligada a diferentes
direcciones globales en diferentes momentos, y viceversa. En
consecuencia, cualquier estudio del flujo de trfico basado solamente
en direcciones globales y puertos TU podra resultar confuso y
provocar la malinterpretacin de los resultados.

Si alguna mquina est abusando de Internet de alguna manera (como


tratando de atacar a otra mquina, o incluso enviando grandes
cantidades de correo basura o por el estilo) es ms difcil averiguar
el origen de los problemas porque la direccin IP de la mquina est
oculta en un encaminador NAT.

8.4. Traduccin de paquetes de control FTP fragmentados

La traduccin de los paquetes de control TCP fragmentados "tiene


truco" cuando los paquetes contienen comandos "PORT" o respuestas al
comando "PASV". Claramente, este es un caso patolgico. El
encaminador NAT primero necesitara rensamblar los fragmentos y
entonces traducir antes del reenvo.

Otro caso sera cuando cada uno de los caracteres de los paquetes que
contienen comandos "PORT" o respuestas a "PASV" se envan en
datagramas separados, sin fragmentar. En este caso, NAT simplemente
debera dejar pasar los paquetes sin traducir la carga til TCP. Por
supuesto, la aplicacin fallar si la carga til necesitaba ser
alterada. An as la aplicacin podra funcionar en algunos casos,
sin modificaciones intermedias, cuando los contenidos de la carga
til sean vlidos en ambos dominios. Por ejemplo, los FTP originados
desde una mquina privada funcionaran mientras que atraviesen un
dispositivo NAT tradicional o bidireccional, siempre que la sesin de
control FTP haya utilizado el comando PASV para establecer las
sesiones de datos. La razn es que la direccin y el nmero de puerto
especificados por el servidor FTP en la respuesta PASV (enviada como
mltiples pawuetes no fragmentados) resulta vlida tal cual para la
mquina privada. El dispositivo NAT simplemente ver la siguiente
sesin de datos (con origen tambin en la mquina privada) como una
sesin TCP independiente.

8.5. Elevada potencia de clculo

Srisuresh & Holdrege Informativo [Pg. 29]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

NAT es una tarea que implica clculos intensivos incluso con la ayuda
de un algoritmo inteligente para el ajuste de las sumas de
verificacin, puesto que cada paquete de datos implica bsquedas y
modificaciones en la tabla de NAT. En consecuencia, la velocidad de
reenvo del encaminador puede descender considerablemente. Sin
embargo, mientras que la velocidad de proceso del dispositivo de NAT
supere la necesaria para satisfacer la velocidad de lnea, esto no
debera suponer problema alguno.

9.0. Consideraciones de seguridad

Mucha gente considera un encaminador NAT tradicional como un filtro


de trfico unidireccional (sesin por sesin), que restringe las
sesiones provenientes de mquinas externas dirigidas hacia sus
propias mquinas. Adems, cuando la asignacin de direcciones en el
encaminador NAT se lleva a cabo dinmicamente, se hace ms difcil
que un atacante pueda apuntar hacia cualquier mquina concreta en el
dominio NAT. Se pueden usar encaminadores NAT junto con cortafuegos
para filtrar el trfico no deseado.

Si los dispositivos NAT y las ALG no estn en un extremo de la red en


que podamos confiar, esto constituye un problema de seguridad
importante, puesto que las ALG podran espiar la carga til del
trfico de usuario. Se puede cifrar extremo a extremo la carga til
de nivel de sesin, siempre que la carga til no contenga direcciones
IP y/o identificadores de transporte que sean vlidos en uno solo de
los dominios. Con la excepcin de RSIP, la seguridad extremo a
extremo IP en el nivel de red obtenida mediante las actuales tcnicas
IPsec no es posible cuando hay dispositivos NAT por el camino. Uno de
los extremos debe ser un dispositivo NAT. Consulte en la seccin 7.0
la explicacin de porqu no se puede garantizar la seguridad IPsec
extremo a extremo cuando hay dispositivos NAT a lo largo de la ruta.

La combinacin de las funciones de NAT, ALG y cortafuegos,


proporciona un entorno de trabajo transparente para un dominio de red
privado. Con la excepcin de RSIP, no se puede obtenner la seguridad
extremo a extremo garantizada por IPsec para las mquinas finales en
el interior de la red privada (consulte en la seccin 5.0 el
funcionamiento de RSIP). En el resto de casos, si desea obtener
seguridad extremo a extremo mediante IPsec, no deber haber
dispositivos NAT por el camino. Si suponemos que los dispositivos NAT
son parte de una frontera de confianza, se puede utilizar IPsec modo
tnel mediante un encaminador NAT (o una combinacin de NAT, ALG y
cortafuegos) que acte como uno de los extremos del tnel.

Los dispositivos NAT, cuando se combinan con ALG, pueden garantizar


que los datagramas enviados a Internet no tienen direcciones privadas
en las cabeceras o en la carga til. Las aplicaciones que no cumplan

Srisuresh & Holdrege Informativo [Pg. 30]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

estos requisitos pueden ser descartadas por las reglas del


cortafuegos. Por esta razn, no es infrecuente encontrarse con las
funciones de NAT, ALG y cortafuegos integradas para proporcionar
seguridad en las fronteras de una red privada. Se pueden usar
pasarelas NAT como extremos de los tneles para proporcionar
transporte seguro de datos de la VPN a travs de un dominio de red
externo.

A continuacin se muestran consideraciones adicionales de seguridad


asociadas con los encaminadores NAT.

1. Las sesiones UDP son intrnsecamente inseguras. Las respuestas a


un datagrama pueden provenir de una direccin distinta a la
direccin destino utilizada por el remitente ([Ref 4]). En
consecuencia, un paquete UDP entrante podra coincidir slo en
parte con una sesin saliente de un encaminador NAT tradicional
(la direccin destino y el nmero de puerto UDP del paquete
coinciden, pero la direccin y nmero de puerto de origen puede
que no). En tal caso, hay un problema potencial de seguridad en el
dispositivo NAT si permite la entrada de los paquetes que
coinciden slo parcialmente. Este problema de seguridad tambin es
intrnseco a los cortafuegos.

Las implementaciones de NAT que no hacen un seguimiento de los


datagramas de cada sesin, sino que agrupan los estados de
mltiples sesiones UDP usando la misma asociacin de direccin
sobre una nica sesin unificada, pueden comprometer an ms la
seguridad. Esto es debido a que la granularidad en la coincidencia
del paquete sera todava ms limitada, y quedara reducida a la
direccin destino de los paquetes UDP entrantes.

2. Las sesiones multicast (basadas en UDP) son otra fuente de


debilidades de seguridad en los encaminadores NAT tradicionales.
Tambin en este caso los cortafuegos afrontan el mismo dilema de
seguridad que los encaminadores NAT.

Supongamos que una mquina en una red privada inicia una sesin
multicast. El datagrama enviado por la mquina privada puede
desencadenar respuestas en el sentido contrario provenientes de
mltiples mquinas exteriores. Las implementaciones tradicionales
de NAT que utilizan un nico estado para hacer un seguimiento de
una sesin multicast no pueden determinar con seguridad si el
paquete UDP entrante es una respuesta a una sesin multicast
existente o es el comienzo de una nueva sesin UDP iniciada por un
atacante.

3. Los dispositivos NAT pueden ser objeto de ataques.

Srisuresh & Holdrege Informativo [Pg. 31]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Puesto que los dispositivos NAT son mquinas de Internet, pueden


ser objeto de diversos ataques, tales como ataques de SYN flood y
ping flood. Los dispositivos de NAT deben emplear el mismo tipo de
tcnicas de proteccin que utilizan los servidores de Internet.

REFERENCIAS

[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E.


Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, Febrero 1996.

[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,


Octubre, 1994.

[3] Braden, R., "Requirements for Internet Hosts -- Communication


Layers", STD 3, RFC 1122, Octubre 1989.

[4] Braden, R., "Requirements for Internet Hosts -- Application and


Support", STD 3, RFC 1123, Octubre 1989.

[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,


Junio 1995.

[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD


9, RFC 959, Octubre 1985.

[7] Postel, J., "Transmission Control Protocol (TCP) Specification",


STD 7, RFC 793, Septiembre 1981.

[8] Postel, J., "Internet Control Message Protocol Specification"


STD 5, RFC 792, Septiembre 1981.

[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
Agosto 1980.

[10] Mogul, J. and J. Postel, "Internet Standard Subnetting Proce


dure", STD 5, RFC 950, Agosto 1985.

[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address


Behavior Today", RFC 2101, Febrero 1997.

[12] Kent, S. and R. Atkinson, "Security Architecture for the Inter


net Protocol", RFC 2401, Noviembre 1998.

[13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload


(ESP)", RFC 2406, Noviembre 1998.

Srisuresh & Holdrege Informativo [Pg. 32]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,


Noviembre 1998.

[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",


RFC 2409, Noviembre 1998.

[16] Piper, D., "The Internet IP Security Domain of Interpretation


for ISAKMP", RFC 2407, Noviembre 1998.

[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig
nature Option", RFC 2385, Agosto 1998.

[18] Eastlake, D., "Domain Name System Security Extensions", RFC


2535, Marzo 1999.

Direcciones de los Autores

Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.

Telfono: (925) 737-2153


Fax: (925) 737-2110
EMail: srisuresh@lucent.com

Matt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502

Telfono: (510) 769-6001


EMail: holdrege@lucent.com

Traduccin al castellano:

Jos Luis Domingo Lpez


C/ Cruz del Sur 22
28007 Madrid - Espaa

EMail: jdomingo@internautas.org

Srisuresh & Holdrege Informativo [Pg. 33]


RFC 2663 Terminologa y consideraciones sobre NAT Agosto 1999

Declaracin completa de copyright

Copyright (C) The Internet Society (1999). Todos los derechos reser
vados.

Este documento y sus traducciones puede ser copiado y facilitado a


otros, y los trabajos derivados que lo comentan o lo explican o ayu
dan a su implementacin pueden ser preparados, copiados, publicados y
distribudos, enteros o en parte, sin restriccin de ningn tipo,
siempre que se incluyan este prrafo y la nota de copyright expuesta
arriba en todas esas copias y trabajos derivados. Sin embargo, este
documento en s no debe ser modificado de ninguna forma, tal como
eliminando la nota de copyright o referencias a la 'Internet Society'
u otras organizaciones de Internet, excepto cuando sea necesario en
el desarrollo de estndares Internet, en cuyo caso se seguirn los
procedimientos para copyrights definidos en el proceso de Estndares
Internet, o con motivo de su traduccin a otras lenguas aparte del
Ingls.

Este documento y la informacin contenida en l se proporcionan en su


forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK
FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS,
INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE
LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS
IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECI
FICO.

Reconocimientos

En la actualidad, la financiacin para las funciones del editor RFC


es proporcionada por la Internet Society.

Srisuresh & Holdrege Informativo [Pg. 34]

You might also like