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]