Network Working Group D. Provan Request for Comments: 1201 Novell, Inc. Obsoletes: RFC 1051 February 1991 Transmisión de tráfico IP sobre redes ARCNET Estado de este memorándum Este memorándum define un protocolo para la transmisión de paquetes IP y ARP sobre Redes de Área Local ARCnet. Este RFC especifica un protocolo de envío estándar IAB para la comunidad Internet, y solicita discusión y sugerencias para mejoras. Por favor refiérase a la ediición actual del "IAB Official Protocolo Standards" para el estado de estandarización y el estado de este protocolo. La distribución de este memorándum es ilimitada. [N.del T.: actualmente, este es el estándar 46, STD0046] 1. Introducción Este memorándum especifica un método de encapsulado de datagramas del Protocolo Internet (IP) [1] y del Protocolo de Resolución de Dirección (ARP) [2] para la transmisión a través de ARCNET [3] usando el "ARCNET Packet Header Definition Standard" (Estándar de Definición de Encabezado de Paquete ARCNET) [4]. Este memorándum ofrece un reemplazo para el RFC 1051. El RFC 1051 usa un protocolo de enmarcado ARCNET que limita los paquetes IP no fragmentados a 508 octetos [5]. 2. Formato del paquete ARCNET En 1989, Apple Computers, Novell, ACTINET Systems, Standard Microsystems y Pure Data Research decidieron usar el protocolo de enlace de datos ARCNET definido en "ARCNET Packet Header Definition Standard" [4]. Comenzaremos con una breve descripción de ese protocolo. 2.1. Enmarcado ARCNET El hardware ARCNET soporta dos tipos de marcos ("marcos"): marcos cortos, que son siempre de 256 octetos de longitud, y marcos largos, que son siempre de 512 octetos de longitud. Todos los marcos comienzan con un encabezado de hardware y terminan con los datos del cliente precedidos por un encabezado de software. El software añade relleno en el medio del paquete entre el encabezado de hardware y el encabezado de software para hacer el marco de la longitud fija apropiada. Sin que lo sepa el software, el hardware elimina este relleno durante la transmisión. Provan [Página 1] RFC 1201 IP sobre ARCNET Febrero 1991 Los marcos cortos pueden tener desde 0 hasta 249 octetos de datos de cliente. Los marcos largos pueden tener desde 253 hasta 504 octetos de datos de cliente. Para manejar marcos con 250, 251 o 252 octetos de datos, el protocolo de enlace de datos introduce un tercer tipo de marco: el marco de excepción ("exception frame"). Se muestran aquí estos tres formatos de marco. Cada bloque representa un octeto si no se dice lo contrario. Marco corto Marco largo Marco de excepción +---------------+ +---------------+ +---------------+ | origen | | origen | | origen | +---------------+ +---------------+ +---------------+ | destino | | destino | | destino | +---------------+ +---------------+ +---------------+ | offset | | 0 | | 0 | +---------------+ +---------------+ +---------------+ . sin uso . | offset | | offset | . (offset - 3 . +---------------+ +---------------+ . octetos) . . sin uso . . sin uso . +---------------+ . (offset - 4 . . (offset - 4 . |ID de protocolo| . octetos) . . octetos) . +---------------+ +---------------+ +---------------+ | split flag | |ID de protocolo| |ID de protocolo| +---------------+ +---------------+ +---------------+ | número de | | split flag | | flag: FF hex | + secuencia + +---------------+ +---------------+ | (2 octetos) | | número de | | relleno: 0xFF | +---------------+ + secuencia + +---------------+ . datos . | (2 octetos) | | relleno: 0xFF | . del cliente . +---------------+ +---------------+ . (256 - offset . . . |(ID protocolo) | . - 4 octetos) . . . +---------------+ . . . . | split flag | +---------------+ . . +---------------+ . . | número de | . client data . + secuencia + . (512 - offset . | (2 octetos) | . - 4 octetos) . +---------------+ . . . datos . . . . del cliente . . . . (512 - offset . . . . - 8 octetos) . . . . . +---------------+ +---------------+ Estos formatos de paquete son presentados como los vería el Provan [Página 2] RFC 1201 IP sobre ARCNET Febrero 1991 software a través del hardware ARCNET. [3] se refiere a esto como el "formato de buffer". El formato actual de paquetes en el alambre es un poco diferente: el ID de destino está duplicado, el relleno entre el campo offset y el campo ID de protocolo no es transmitido, y hay alguna información de enmarcado de hardware. Además, el hardware transmite paquetes especiales para ubicación de buffer y recibe reconocimientos que no están descritos aquí [3]. 2.2. Fragmentación de la capa de enlace de datos El hardware ARCNET limita los marcos individuales a 512 octetos, que permite 504 octetos de datos de cliente. Este protocolo ARCNET de enlace de datos permite a la capa de enlace de datos romper paquetes en hasta 120 fragmentos por transmisión. Esto permite a los clientes ARCNET transmitir hasta 60480 octetos en cada paquete. El "split flag" (bandera de división) describe fragmentos de paquete de la capa de enlace de datos. Existen tres casos: un paquete no fragmentado, el primer fragmento de un paquete fragmentado, y algún otro fragmento de un paquete fragmentado. Los paquetes no fragmentados siempre tiene un "split flag" igual a cero. El primer fragmento de un paquete fragmentado tiene un "split flag" igual a ((T-2)*2)+1, donde T es el número total de fragmentos esperados por el paquete. Los fragmentos subsecuentes de un paquete fragmentado tiene un "split flag" igual a ((N-1)*2), donde N es el número de este fragmento. Por ejemplo el cuarto fragmento de un paquete tendrá siempre el "split flag" con un valor de seis ((4-1)*2). La estación receptora puede identificar el último fragmento de un paquete porque el valor de su split flag de 8 bits será mayor que el split flag del primer fragmento del paquete. Una versión previa de esta definición del protocolo ARCNET de enlace de datos sólo permitía paquetes que pudiesen estar contenidos en dos fragmentos. En esta versión antigua, los únicos "split flag" legales eran 0, 1 y 2. La compatibilidad con este estándar antiguo se puede mantener configurando la longitud de datos máxima de cliente en 1008 octetos. No se permiten más de 120 fragmentos. El mayor valor de "split flag" es EE hex. (Note que el valor de split flag FF hex es usado para marcar paquetes de excepción en lo que de lo contrario sería un campo Provan [Página 3] RFC 1201 IP sobre ARCNET Febrero 1991 de "split flag" de paquete muy largo.) Todos los fragmentos de un solo paquete llevan el mismo número de secuencia. 2.3. Reensamblado de la capa de enlace de datos La sección previa proporcionó suficiente información para implementar el reensamblado de enlace de datos. Para evitar problemas con la asignación del buffer durante el reensamblado, recomendamos asignar suficiente espacio para el reensamblado entero del paquete cuando llegue el primer fragmento. Ya que los fragmentos son enviados en orden, el procedimiento de reensamblado puede ignorar un paquete si recibe un fragmento fuera de orden. Sin embargo, hay un excepción. Es posible que fragmentos recibidos correctamente lleguen duplicados. El software de reensamblado debería ignorar los fragmentos repetidos sin ignorar el paquete. Ya que los fragmentos se enviarán rápidamente, el procedimiento de reensamblado puede ignorar un paquete reensamblado parcialmente si no llegan fragmentos adicionales para él en unos pocos segundos. 2.4. Retransmisión de la capa de enlace de datos Para cada paquete ARCNET de unidifusión, el hardware indica al emisor si el receptor reconoció o no el paquete. Para mejorar la fiabilidad, las implementaciones de enlace de datos deberían retransmitir los paquetes o fragmentos de paquetes no reconocidos. Pueden ser necesarias varias retransmisiones. Los paquetes de difusión, sin embargo, nunca son reconocidos, y, por ende, nunca deberían ser retransmitidos. Puede que los paquetes que se reciben correctamente no sean reconocidos. Consecuentemente, la retransmisión por la implementación del enlace de datos puede causar paquetes o fragmentos duplicados. Los paquetes duplicados no son un problema para IP o ARP. Como se mencionó en la sección previa, el soporte de reensamblado ARCNET debería ignorar cualquier fragmento redundante. 3. Transmisión de datagramas IP y ARP Los datagramas IP y ARP se llevan en el área de datos del cliente de los paquetes ARCNET. El soporte de enlace de datos ubica cada datagrama en un marco ARCNET de tamaño apropiado, fragmentando los datagramas IP mayores de 504 octetos en múltiples marcos como se describió en la sección previa. Provan [Página 4] RFC 1201 IP sobre ARCNET Febrero 1991 4. Asociación de dirección IP Esta sección explica como cada uno de los tres tipos de dirección de 32 bits de Internet básicos es asociado a las direcciones ARCNET de 8 bits. 4.1. Direcciones de unidifusión ("unicast") Una dirección IP de unidifusión es asociada a una dirección ARCNET de 8 bits usando ARP como se especifica en [2]. Una sección posterior cubre los valores específicos que deberían usarse en paquetes ARP enviados en redes ARCNET. Es posible asignar direcciones IP tal que los últimos ocho bits sean los mismos que la dirección ARCNET de 8 bits. Esto permitiría una asociación directa de dirección IP a dirección ARCNET sin usar un protocolo de descubrimiento. Algunas implementaciones pueden proporcionar esto como una opción, pero no es una práctica recomendada. Aunque tal asociación parece atractiva, la experiencia muestra que ARP es una aproximación mucho más flexible y conveniente que tiene un bajo coste. 4.2. Direcciones de difusión Todas las direcciones IP de difusión se deben asociar a la dirección de difusión ARCNET 0. A diferencia de los paquetes de unidifusión, ARCNET no intenta asegurar la entrega de paquetes de difusión, por eso, puede que se pierdan. Esto no tendrá un efecto importante sobre IP ya que ni IP ni ARP esperan que todos los paquetes sean entregados. 4.3. Direcciones de multidifusión Ya que ARCNET no proporciona soporte para multidifusión, todas las direcciones IP de multidifusión deben ser asociadas a la dirección de difusión ARCNET 0. 5. ARP La longitud de dirección de hardware es 1 octeto para paquetes ARP enviados a través de redes ARCNET. El tipo de hardware ARP para ARCNET es 7. Los paquetes de solicitud ARP se difunden dirigiéndolos a la dirección de difusión ARCNET, que es 0. 6. RARP Los paquetes del Protocolo de Resolución Inversa de Dirección [6] se Provan [Página 5] RFC 1201 IP sobre ARCNET Febrero 1991 pueden transmitir también a través de ARCNET. Para el propósito de la transmisión y recepción de enlace de datos, RARP es idéntico a ARP y puede manejarse de la misma manera. Hay unas pocas diferencias que notar, sin embargo, entre RARP cuando corre sobre ARCNET, que tiene una dirección de hardware de un octeto, y Ethernet, que tiene una dirección de hardware de seis octetos. Primero, hay sólo 255 direcciones de hardware diferentes para una ARCNET dada mientras que hay un gran número de direcciones Ethernet posibles. Segundo, las direcciones de hardware ARCNET es más probable que estén duplicadas en diferentes redes ARCNET; la direcciones de hardware Ethernet normalmente serán globalmente únicas: la direcciones de hardware ARCNET son configuradas por interruptores, no fijadas en ROM como lo son en Ethernet. 7. Unidad de transmisión máxima (MTU, "Maximum Transmission Unit") La longitud de paquete IP máxima posible usando este método de encapsulación es de 60480 octetos. Ya que esta longitud no es práctica, todas las implementaciones ARCNET en una red ARCNET dada necesitarán acordar un valor más pequeño. Por ende, el tamaño de paquete máximo DEBE ser configurable en implementaciones de esta especificación. En cualquier case, las implementaciones deben ser capaces de enviar y recibir datagramas IP de hasta 576 octetos de longitud, y son fuertemente alentados a manipular datagramas IP de hasta 1500 octetos de longitud. Las implementaciones pueden aceptar datagramas IP entrantes que sean mayores que su unidad de transmisión máxima configurada. No se requiere que descarten esos datagramas. Para hacer mínima la fragmentación ARCNET, las implementaciones pueden querer afinar un tamaño de paquete IP óptimo de 504 bytes. Esto evita la elevada fragmentación de enlace de datos, pero a expensas de incrementar el número de paquetes IP que deben ser manipulados por cada nodo en la ruta. Además de alentar que las aplicaciones locales generen paquetes más pequeños, una implementación pueden también usar la opción de tamaño de segmento máximo de TCP para indicar una preferencia de segmentos TCP de 464 octetos [7], o puede anunciar un MTU IP de 504 octetos a través de un mecanismo de descubrimiento MTU tal como [8]. Esto informaría a los nodos no ARCNET del tamaño de paquete óptimo más pequeño. 8. Números asignados Datapoint Corporation asigna los IDs del protocolo ARCNET para Provan [Página 6] RFC 1201 IP sobre ARCNET Febrero 1991 identificar diferentes protocolos corriendo en el mismo medio ARCNET. Para implementaciones de esta especificación, Datapoint ha asignado 212 decimal para IP, 213 decimal para ARP y 214 decimal para RARP. Esto no son los números asignados para el encapsulamiento IP definido por el RFC 1051 [5]. Las implementaciones del RFC 1051 pueden existir en la misma ARCNET que implementaciones de esta especificación, aunque ninguna de las dos no sería capaz de comunicarse con la otra. La Autoridad de Números Asignados de Internet (Internet Assigned Numbers Authority, IANA) asigna los valores de tipo de hardware ARP. Ha asignado a ARCNET el tipo de hardware ARP 7 [9]. Reconocimientos Varias personas han revisado esta especificación y proporcionaron comentarios útiles. Querría agradecer a Wesley Hardell en Datapoint y a Troy Thomas en la oficina Novell's Provo por ayudarme a comprender ARCNET. Además, aprecio particularmente el esfuerzo de James VanBokkelen en FTP Software quien me regañó hasta que todos los temas confusos estuvieron despejados. El trabajo pionero en transmisión de tráfico IP en redes ARCNET lo hizo Philippe Prindeville. Referencias [1] Postel, J., "Internet Protocol", RFC 791, DARPA, Septiembre 1981. [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT, Noviembre 1982. [3] Datapoint, Corp., "ARCNET Designer's Handbook", documento número 61610, 2a edición, Datapoint Corporation, 1988. [4] Novell, Inc., "ARCNET Packet Header Definition Standard", Nov- ell, Inc., Noviembre 1989. [5] Prindeville, P., "A Standard for the Transmission of IP data- grams and ARP Packets over ARCNET Networks", RFC 1051, McGill University, Marzo 1988. Provan [Página 7] RFC 1201 IP sobre ARCNET Febrero 1991 [6] Finlayson, R., Mann, T., Mogul, J. y M. Theimer, "A Reverse Address Resolution Protocolo", RFC 903, Stanford, Junio 1984. [7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, Septiembre 1981. [8] Mogul, J., Kent, C., Partridge, C. y K. McCloghrie, "IP MTU Discovery Options", RFC 1063, DEC, BBN, TWG, Julio 1988. [9] Reynolds, J., y J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, Marzo 1990. Consideraciones de seguridad Los temas de seguridad no son discutidos en este memorándum. Dirección del autor Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131 Teléfono: (408) 473-8440 Email: donp@novell.com Traducción al castellano: Javier Waisbrot (2003), jwais@fi.uba.ar Provan [Página 8]