Network Working Group D. Provan Request for Comments: 1234 Novell, Inc. Junio 1991 Encaminamiento del Tráfico IPX a través de redes IP Estado de este Memorándum Este memorándum describe un método de encapsulado de datagramas IPX dentro de paquetes UDP para que el tráfico IPX pueda viajar a través de una red IP. Este RFC especifica un protocolo de seguimiento de estándares IAB para la comunidad de Internet, y solicita debate y sugerencias para mejoras. Por favor remítase a la edición actual de "Estándares de Protocolos Oficiales de la IAB" para el estado de estandarización y estatus de este protocolo. La distribución de este memorándum es ilimitada. Introducción El protocolo de Intercambio de Paquetes de Internet (IPX) (Internet Packet eXchange) es el protocolo de interconexión de redes usado por el conjunto de protocolos de Novell Netware. Para los propósitos de este documento, IPX es funcionalmente equivalente al Protocolo de Datagramas de Internet (IDP) del conjunto de protocolos de "Xerox Network Systems" (XNS) [1]. Este memorándum describe un método de encapsulado de datagramas IPX dentro de paquetes UDP [2] para que el tráfico IPX pueda viajar a través de una red IP [3]. Este RFC permite que una implementación IPX vea una red IP como una única red IPX. Una implementación de este memorándum encapsulará los datagramas IPX en paquetes UDP del mismo modo que una implementación hardware encapsularía los datagramas IPX en sus propios paquetes. Así podrán conectarse redes IPX entre redes que transporten solo tráfico IP. Formato del Paquete Cada datagrama IPX se trasporta en el campo de datos del paquete UDP. Los campos IP y UDP se establecerán normalmente. Los puertos de origen y destino del paquete UDP se establecerán al valor de puerto UDP previsto por la Autoridad de Números Asignados de Internet (IANA) para la implementación de este método de encapsulado. Como en cualquier aplicación UDP, el transmitente tiene la opción de evitar la sobrecarga del cálculo del campo de comprobación poniendo el campo de comprobación UDP a cero. Ya que las implementaciones IPX nunca utilizan el campo de comprobación IPX para evitar errores en los paquetes, es muy recomendable calcular el campo de comprobación Provan [Pág. 1] RFC 1234 IPX on IP Junio 1991 UDP al encapsular IPX. +---------------------+------------+-------------------------------+ | | Cabecera | Cabecera | | | Cabecera IP | UDP | IPX | paquete de | | (20 o más octetos) | (8 octetos)| (30 octetos)| datos IPX | | | | | | +---------------------+------------+-------------------------------+ Figura 1: paquete IPX transportado como datos en un paquete UDP. Paquetes Reservados Los dos primeros octetos de la cabecera IPX contiene el campo de comprobación IPX. Los paquetes IPX nunca se envian con campo de comprobación, asi que todas las cabeceras IPX empiezan con dos octetos FF hexa. Las implementaciones de este proyecto de encapsulado ignorarán todos los paquetes con otro valor distinto en los dos octetos inmediatamente siguientes a la cabecera UDP. Los demás valores se reservan para futuras mejoras de este protocolo de encapsulado. Mapa de direcciones Unicast Las direcciones IPX consisten en un número de red de cuatro octetos y en un número de máquina de 6 octetos. IPX utiliza el número de red para dirigir cada paquete a través de la red IPX a la red de destino. Una vez que el paquete llega a la red de destino, IPX utiliza el número de maquina de 6 octetos como la dirección hardware de esa red. Tambien se intercambian los números de maquina en las cabeceras IPX de los paquetes IPX de Protocolo de Información de Rutado (RIP) (Routing Information Protocol). Esto provee a los nodos finales, y de la misma forma a los routers, la información de la dirección hardware necesaria para reenviar los paquetes entre redes intermedias en camino hacia la red de destino. Para las implementaciones de este memorándum, los 2 primeros octetos del número de maquina serán siempre cero y los cuatro últimos octetos serán la dirección IP de cuatro octetos del nodo. Esto hace insignificante el mapeo de direcciones en transmisiones unicast: los dos primeros octetos del número de maquina se descartan, dejando la dirección IP de cuatro octetos normal. El código de encapsulado debe usar esta dirección IP como la dirección de destino del paquete UDP/IP encaminado. Broadcast entre Servidores Provan [Pág. 2] RFC 1234 IPX on IP Junio 1991 IPX requiere de instrumentos broadcast para para que los servidores NetWare y los routers IPX de la red puedan encontrarse entre sí. Se necesita otro mecanismo, ya que el broadcast en toda la red IP ni es apropiado ni esta disponible. Para este memorándum, cada servidor y router deberá mantener una lista de las direcciones IP de los otros servidores IPX y routers de la red IP. Me referiré a esta lista como la "lista de pares", a miembros individuales como "pares", y a todos los pares en conjunto, incluyendo el nodo local, como el "grupo de pares". Cuando IPX realize una petición broadcast, la implementación del encapsulado simulara el broadcast transmitiendo un paquete unicast independiente a cada par de la lista de pares. Como cada lista de pares se construye a mano, varios grupos de pares pueden compartir la misma red IP sin saber unos de otros. Esto difiere de una red IPX normal en la que todos los pares podrían encontarse unos a otros automáticamente utilizando el broadcast del hardware. La lista de pares en cada nodo debería contener todos los demás pares del grupo de pares. En la mayoría de los casos, la conectividad se resentirá si las peticiones broadcast de un par fallan constantemente en alcanzar a algún otro par del grupo. La lista de pares puede implementarse usando multicast de IP [4], pero ya que los instrumentos multicast no estan ampliamente disponibles por ahora, no se ha asignado una dirección multicast específica y no existe ninguna implementación que use multicast. Ya que se ha desarrollado el multicast IP en las implementaciones IP, puede usarse sencillamente incluyendo en la lista de pares una dirección multicast IP para los servidores y routers. La dirección multicast IP reemplazaría a las direcciones IP de todos los pares, los cuales recibirán paquetes multicast IP desde ese par. Broadcast por Clientes Típicamente, los nodos con cliente Netware no necesitan recibir mensajes broadcast, asi que normalmente no sería necesario incluir los nodos de cliente Netware en la lista de pares en los servidores. Por otro lado, los clientes de una red IPX necesitan enviar mensajes broadcast para localizar a los servidores y descubrir las rutas. La implementación de un cliente de encapsulación UDP puede manejar esto teniendo una lista configurada con las direcciones IP de todos los servidores y routers del grupo de pares que esten activos dentro de la red IP. Al igual que la lista de pares de un servidor, la implementación del cliente simulará los mensajes broadcast enviando una copia del paquete a cada dirección IP de su lista de servidores IPX y routers. Una de las direcciones IP de la lista, quizas la Provan [Pág. 3] RFC 1234 IPX on IP Junio 1991 única, puede ser una dirección broadcast o, cuando esté disponible, una dirección multicast. Esto permite que el cliente comunicarse con miembros del grupo de pares sin saber sus direcciones IP específicas. Es importante tener en cuenta que los paquetes broadcast enviados por un cliente IPX deben llegar a todos los servidores y routers del grupo de pares del servidor. Al contrario que IP, que tiene un mecanismo de redirección unicast, los sistemas finales IPX son responsables de descubrir la información de rutado enviando un paquete mediante broadcast preguntando a un router que pueda reenviar paquetes al destino deseado. Si tales paquetes no tienden a alcanzar a todo el grupo de pares del servidor, el sistema final podría ver los recursos de la red IPX, pero ser inalcanzables por él. Unidad Máxima de Transmisión (MTU, Maximum Transmission Unit) Aunque son posibles paquetes IPX mayores, la unidad de transmisión máxima estándar para IPX son 576 octetos. Por consiguiente, 576 octetos es la unidad de transmisión máxima por defecto recomendada para los paquetes IPX que se estén enviando con esta técnica de encapsulado. Junto con la cabecera UDP de ocho octetos y la cabecera IP de 20 octetos, el paquete IP resultante sería de 604 octetos. Tenga en cuenta que esto es mayor que los 576 octetos de tamaño máximo que debe aceptar una implentación IP [3]. Cualquier implementación IP que soporte esta técnica de encapsulado debe ser capaz de recibir paquetes IP de 604 octetos. Ya que las mejoras en los protocolos y el hardware permiten unidades de transmision IP mayores y sin fragmentar, el tamaño máximo de 576 octetos del paquete IPX puede ser un inconveniente. Por esta razón se recomienda que en las implementaciones de este memorándum el tamaño de la unidad de transmisión máxima IPX sea configurable. Aspectos de Seguridad Utilizar una red de area amplia, de propósito general como la red IP en un lugar normalmente ocupado por el cableado físico introduce algunos problemas de seguridad que no se encuentran normalmente en redes IPX. Los medios de comunicación normales típicamente estan protegidos de forma física del acceso exterior; las redes IP de internet normalmente invitan el acceso desde el exterior. En general, la seguridad de toda la red IPX solo es tan buena como lo sea la seguridad de la red IP atraves de la cual se encamina. Pueden darse la siguiente tipos de ataques: 1) Clientes IPX no autorizados pueden conseguir el acceso a los Provan [Pág. 4] RFC 1234 IPX on IP Junio 1991 recursos a través de ataques a controles de acceso normales como por ejemplo descifrando contraseñas. 2) Pasarelas IPX no autorizadas pueden desviar el tráfico IPX a otras rutas no deseadas. 3) Agentes no autorizados pueden escuchar y manipular el tráfico IPX que pase sobre el medio físico que use la red IP y esté bajo el control de dicho agente. Hasta cierto punto, estos riesgos de seguridad son los típicos a los que se enfrenta cualquier otra aplicación que use una red IP. Se mencionan aquí solo porque IPX normalmente no desconfía del medio de transmisión. Los administradores de la red IPX tendrán que tener en cuenta estos riesgos de seguridad adicionales. Números Asignados La Autoridad de Números Asignados de Internet asigna números de puerto UDP específicos. Se ha asignado el número de puerto 213, decimal, a la técnica de encapsulado IPX descrita en este memorándum [5]. Agradecimientos Esta técnica de encapsulado fue desarollada de forma independiente por Schneider & Koch y por Novell. Quiero agradecer a Thomas Ruf de Schneider & Koch por haber revisado este memorándum para confirmar su adecuación con la implementación de Scheneider & Koch y tambien por sus inestimables sugerencias. Referencias [1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112, Xerox Corporation, Diciembre 1981. [2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, Agosto 1980. [3] Postel, J., "Internet Protocol", RFC 791, DARPA, Septiembre 1981. [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, Agosto 1989. [5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1060, USC/Information Sciences Institute, Marzo 1990. Consideraciones de Seguridad Provan [Pág. 5] RFC 1234 IPX on IP Junio 1991 Vea más arriba la sección "Aspectos de Seguridad" Dirección del Autor Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131 Phone: (408)473-8440 EMail: donp@Novell.Com N.T.: RFC en castellano: http://www.arrakis.es/~pjleon/rfc-es http://lucas.hispalinux.es/htmls/estandares.html LISTA RFC-ES: http://www.rediris.es/list/info/rfc-es.html Provan [Pág. 6]