Network Working Group J.Postel Request for Comments: 1042 J. Reynolds ISI Deja obsoleto: RFC-948 Febrero de 1988 Un estándar para la Transmisión de Datagramas IP sobre redes IEEE 802 Estado de este memorándum Este RFC especifica un método estándar de encapsulamiento de los datagramas del Protocolo Internet (IP) [1] y de las solicitudes y respuestas del Protocolo de Resolución de Dirección (ARP) [2] sobre redes IEEE 802. Este RFC especifica un protocolo estándar para la comunidad Internet. La distribución de este memorándum es ilimitada. Reconocimiento Este memorándum no existiría sin la muy valiosa contribución de Drew Perkins de Carnegie Mellon University, Jacob Rekhter del T.J. Watson Research Center, IBM Corporation y Joseph Cimmino de la Universidad de Maryland. Introducción La meta de esta especificación es permitir implementaciones compatibles e interoperables para la transmisión de datagramas IP y solicitudes y respuestas ARP. Para lograr esto puede ser necesario en algunos casos limitar el uso que IP y ARP hacen de las capacidades de un estándar IEEE 802 en particular. Las especificaciones IEEE 802 definen una familia de estándares para Redes de Área Local (Local Area Networks, LANs) que negocian con las Capas Físicas y de Enlace de Datos como se define por el Modelo de Referencia para la Interconexión de Sistemas Abiertos de ISO (ISO/OSI). Se han definido varios estándares de la Capa Física (802.3, 802.4 y 802.5) [3,4,5] y un estándar de la Capa de Enlace de Datos (802.2) [6]. Los estándares IEEE de la Capa Física especifican la Capa Física ISO/OSI y la Subcapa de Control de Acceso al Medio de la Capa de Enlace de Datos ISO/OSI. El estándar 802.2 de la Capa de Enlace de Datos especifica la Subcapa de Control de Enlace Lógico de la Capa de Enlace de Datos ISO/OSI. Este memorándum describe el uso de IP y ARP sobre los tres tipos de redes. En este momento no es necesario que el uso de IP y ARP sea consistente a través de los tres tipos de redes, sólo que sea consistente en cada tipo. Esto puede cambiar en el futuro si se definen nuevos estándares IEEE 802 y los estándares existentes son Postel & Reynolds [Página 1] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 revisados permitiendo interoperabilidad en la Capa de Enlace de Datos. Es la meta de este memorándum especificar lo suficiente sobre el uso de IP y ARP en cada tipo de red para asegurar que: (1) todo equipo usando IP o ARP sobre redes 802.3 interoperará, (2) todo equipo usando IP o ARP sobre redes 802.4 interoperará, (3) todo equipo usando IP o ARP sobre redes 802.5 interoperará. Por supuesto, la meta de IP es la interoperabilidad entre computadoras conectadas a diferentes redes, cuando esas redes están interconectadas mediante una puerta de enlace IP [8]. El uso de puentes transparentes compatibles con IEEE 802.1 para permitir interoperabilidad a través de diferentes redes no está completamente descrito, pendiente de la terminación de ese estándar. Descripción Las redes IEEE 802 se pueden usar como redes IP de alguna clase (A, B o C). Estos sistemas usan dos campos de Punto de Acceso a Servicio de Enlace (LSAP) del encabezado LLC de la misma manera que ARPANET usa el campo "enlace". Además, esta es una extensión del encabezado LLC llamado Protocolo de Acceso a Sub Red (SNAP). Los datagramas IP son enviados sobre redes IEEE 802 encapsulados dentro de las capas LLC 802.2 y SNAP de enlace de datos, y las capas de redes físicas 802.3, 802.4 o 802.5. El SNAP es usado con un Código de Organización indicando que los siguientes 16 bits especifican el código EtherType (como se lista en Números Asignados [7]). Normalmente, toda comunicación se realiza usando comunicación 802.2 tipo 1. Los sistemas consistentes en la misma red IEEE 802 pueden usar comunicación 802.2 tipo 2 después de verificar que se soporta por ambos nodos. Se hace esto usando el mecanismo 802.2 XID. Sin embargo, la comunicación tipo 1 es el método recomendado en este momento y debe ser soportado por todas las implementaciones. El resto de esta especificación asume el uso de comunicación tipo 1. Las redes IEEE 802 pueden tener direcciones físicas de 16 o de 48 bits. Esta especificación permite el uso de uno u otro tamaño de dirección en una red IEEE 802 dada. Observe que el estándar 802.3 especifica una tasa de transmisión de entre 1 y 20 megabit/segundo, el estándar 802.4 especifica 1, 5 y 10 megabit/segundo y el estándar 802.5 especifica 1 y 4 megabit/segundo. Postel & Reynolds [Página 2] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Las tasas típicas de transmisión usadas son 10 megabit/segundo para 802.3, 10 megabit/segundo para 802.4 y 4 megabit/segundo para 802.5. Sin embargo, esta especificación para la transmisión de Datagramas IP no depende de la tasa de transmisión. Formato del encabezado Encabezado ...--------+--------+--------+ Cabecera MAC | 802.{3/4/5} MAC ...--------+--------+--------+ +--------+--------+--------+ | DSAP=K1| SSAP=K1| Control| 802.2 LLC +--------+--------+--------+ +--------+--------+---------+--------+--------+ |Protocolo Id o Org Cod. =K2| EtherType | 802.2 SNAP +--------+--------+---------+--------+--------+ La longitud total del encabezado LLC y del encabezado SNAP es 8 octetos, haciendo que el protocolo 802.2 termine en un bonito límite. El valor K1 es 170 (decimal). El valor K2 es 0 (cero). El valor de control es 3 (Información no numerada). Asociación de dirección El mapeo de direcciones de Internet de 32 bits a direcciones IEEE 802 de 16 o 48 bits se debe realizar mediante el procedimiento de descubrimiento dinámico del Protocolo de Resolución de Dirección (ARP) [2]. Las direcciones Internet son asignadas arbitrariamente en redes Internet. Cada implementación de equipo debe conocer su propia dirección Internet y responder a las solicitudes de Resolución de Dirección apropiadamente. Debe también usar ARP para traducir direcciones Internet a direcciones IEEE 802 cuando lo necesite. Los detalles ARP El protocolo ARP tiene varios campos que parametrizan su uso en un contexto específico [2]. Estos campos son: Postel & Reynolds [Página 3] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 hrd 16 - bits El Código de Tipo de Hardware pro 16 - bits El Código de Tipo de Protocolo hln 8 - bits Octetos en cada dirección de hardware pln 8 - bits Octetos en cada dirección de protocolo op 16 - bits Código de Operación El código de tipo de hardware asignado para las redes 802 (de todo tipo) es 6 (vea [7] página 16). El código de tipo de protocolo para IP es 2048 (vea [7] página 14). La longitud de la dirección de hardware es 2 para direcciones IEEE 802 de 16 bits, o 6 para direcciones IEEE 802 de 48 bits. La longitud de la dirección de protocolo (para IP) es 4. El código de operación es 1 para solicitud y 2 para respuesta. Dirección de difusión La dirección Internet de difusión (la dirección compuesta por la red con la parte de host toda en unos binarios) se debe asociar a la dirección IEEE 802 de difusión (compuesta por todos unos binarios) (vea [8] página 14). Formatos de portadora Algunas versiones de Unix 4.x bsd usan un método de encapsulamiento diferente para obtener un mejor rendimiento de la red con la arquitectura de memoria virtual VAX. Los sistemas consistentes en la misma red IEEE 802 pueden usar este formato entre ellos. Los detalles del método de encapsulamiento de portadora pueden ser encontrados en [9]. Sin embargo, todos los equipos deben estar habilitados para comunicarse usando el método estándar (no de portadora). Orden de byte Como se describe en el Apéndice B de la especificación del Protocolo Internet [1], el datagrama IP es transmitido a través de redes IEEE 802 como una serie de bytes de 8 bits. Este orden de transmisión de byte se llama "big-endian" [11]. Unidad Máxima de Transmisión La Unidad Máxima de Transmisión (MTU) difiere en los diferentes tipos de redes IEEE 802. A continuación hay comentarios sobre los MTU para Postel & Reynolds [Página 4] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 cada tipo de red IEEE 802. Sin embargo, en una red en particular todos los equipos deben usar el mismo MTU. En adelante, los términos "tamaño máximo de paquete" y "unidad máxima de transmisión" son equivalentes. Formato del frame (marco) y aspectos del nivel MAC Para todos los tipos de hardware Los datagramas IP y las solicitudes y respuestas ARP son transmitidas en el formato de Información No numerada 802.2 LLC Tipo 1 estándar, código de control 3, con los campos DSAP y SSAP del encabezado 802.2 establecidos en 170, el valor SAP globalmente asignado para SNAP [6]. El Código de Organización de 24 bits en el SNAP es cero, y los restantes 16 bits son el EtherType tomado de Números Asignados [7] (IP = 2048, ARP = 2054). Los paquetes IEEE 802 pueden tener una restricción de tamaño mínimo. Cuando sea necesario, el campo datos se debe rellenar (con octetos de cero) para satisfacer los requerimientos de tamaño de marco mínimo de IEEE 802. Este relleno no es parte del datagrama IP y no está incluido en el campo de longitud total del encabezado IP. Por compatibilidad (y sentido común) el tamaño de paquete mínimo usado con datagramas IP es de 28 octetos, que son 20 (encabezado IP mínimo) + 8 (LLC+encabezado SNAP) = 28 octetos (sin incluir el encabezado MAC). El tamaño de paquete mínimo usado con ARP es de 24 octetos, que es 20 (ARP con direcciones de hardware de 2 octetos y direcciones de protocolo de 4 octetos) + 8 (LLC+encabezado SNAP) = 24 octetos (sin incluir el encabezado MAC). En situaciones típicas, el tamaño de paquete usado con ARP es de 32 octetos, que es 28 (ARP con direcciones de hardware de 6 octetos y direcciones de protocolo de 4 octetos) + 8 (LLC+encabezado SNAP) = 32 octetos (sin incluir el encabezado MAC). Los paquetes IEEE 802 pueden tener una restricción de tamaño máximo. Se intenta que las implementaciones soporten paquetes de longitud máxima. Para propósitos de compatibilidad, el tamaño de paquete máximo usado con datagramas IP y solicitudes y respuestas ARP debe ser consistente en una red en particular. Postel & Reynolds [Página 5] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Las implementaciones de puerta de enlace deben estar preparadas para aceptar paquetes de longitud máxima y fragmentarlos cuando sea necesario. Las implementaciones de equipo deberían estar preparadas para aceptar paquetes de longitud máxima, sin embargo los equipos no deben enviar datagramas mayores de 576 octetos a menos que ellos tengan conocimiento explícito de que el destino está preparado para aceptarlos. Un equipo puede comunicar su preferencia de tamaño en aplicaciones basadas en TCP mediante la opción de Tamaño de Segmento Máximo TCP [10]. Los datagramas en redes IEEE 802 pueden ser mayores que el tamaño de paquete máximo predeterminado de Internet, en general, de 576 octetos. Los equipos conectados a una red IEEE 802 deberían tener esto en mente cuando envían datagramas a equipos que no están en la misma red IEEE 802. Puede ser apropiado enviar datagramas menores para evitar fragmentación innecesaria en puertas de enlace intermedias. Por favor vea [10] para información adicional. Detalles de IEEE 802.2 Aunque que no es necesario soportar IP y ARP, todas las implementaciones requieren soportar servicio Clase I del estándar IEEE 802.2. Esto requiere soporte de Órdenes de Información No numerada (Unnumbered Information, UI), Órdenes y Respuestas de Identificación de Intercambio (eXchange IDentification, XID) y Órdenes y Respuestas de enlace de prueba (TEST). Cuando una orden XID o TEST es recibido se debe devolver una respuesta; con las direcciones Destino y Origen, y las DSAP y SSAP intercambiadas. Cuando se responde a una orden XID o TEST el significado del bit poll/final se debe preservar. Esto es, una orden recibida con el bit poll/final no establecido (n. del t., establecido: puesto a 1, no establecido: puesto a 0) debe devolver la respuesta con el bit poll/final no establecido y viceversa. La orden o respuesta XID tiene un valor de campo de control LLC de 175 (decimal) si poll no está establecido o 191 (decimal) si poll está establecido. (Vea apéndice sobre Números) La orden o respuesta TEST tiene un valor de campo de control LLC de 227 (decimal) si poll no está establecido o 243 (decimal) si poll está establecido. (Vea apéndice sobre Números) Postel & Reynolds [Página 6] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Un marco de orden se identifica con el bit de orden superior de la dirección SSAP no establecido. Un marco de respuesta tiene el bit de orden superior de la dirección SSAP puesto a uno. Los marcos de respuesta XID deberían incluir un campo de Información 802.2 XID de 129.1.0 indicando servicio de Clase I (sin conexión). (tipo 1). Los marcos de respuesta TEST deben repetir el campo de información recibido en el correspondiente marco de orden TEST. Para IEEE 802.3 Una implementación en particular de una Capa Física IEEE 802.3 se denota usando tres campos. Los tres campos son tasa de datos en megabit/segundo, tipo de medio, y máxima longitud de segmento en cientos de metros. Una combinación de parámetros 802.3 es 10BASE5 que especifica una tasa de transmisión de 10 megabit/segundo, medio banda base, y segmentos de 500 metros. Esto corresponde a las especificaciones de la familiar red "Ethernet". El encabezado MAC contiene 6 (2) octetos de dirección origen, 6 (2) octetos de dirección destino, y 2 octetos de longitud. La portadora MAC contiene 4 octetos de Secuencia de Control de Marco (Frame Check Sequence, FCS), para un total de 18 (10) octetos. Las redes IEEE 802.3 tienen un tamaño mínimo de paquete que depende de la tasa de transmisión. Para redes 802.3 de tipo 10BASE5 el tamaño mínimo de paquete es 64 octetos. Las redes IEEE 802.3 tienen un tamaño máximo de paquete que depende de la tasa de transmisión. Para redes 802.3 de tipo 10BASE5 el tamaño máximo de paquete es 1518 octetos incluyendo todos los octetos entre la dirección de destino y la FCS inclusive. Esto permite 1518 - 18 (encabezado MAC+portadora) - 8 (LLC+encabezado SNAP) = 1492 para el datagrama IP (incluyendo el encabezado IP). Observe que 1492 difiere de 1500 que es el MTU para redes Ethernet. Para IEEE 802.4 El encabezado MAC contiene 1 octeto de control de marco, 6 (2) octetos de dirección origen, y 6 (2) octetos de dirección destino. La portadora MAC contiene 4 octetos de Secuencia de Control de Frame (FCS), para un total de 17 (9) octetos. Postel & Reynolds [Página 7] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Las redes IEEE 802.4 no tienen tamaño mínimo de paquete. Las redes IEEE 802.4 tiene un tamaño máximo de paquete de 8191 octetos incluyendo todos los octetos entre el control de marco y la FCS inclusive. Esto permite 8191 - 17 (encabezado MAC+portadora) - 8 (LLC+encabezado SNAP) = 8166 para el datagrama IP (incluyendo el encabezado IP). Para IEEE 802.5 El estándar actual para token ring, IEEE 802.5-1985, especifica la operación de redes de un solo anillo. Sin embargo, muchas implementaciones de 802.5 han agregado extensiones para redes multi-anillo usando encaminamiento de origen de paquetes en la capa MAC. Existe actualmente un Suplemento Borrador para IEEE 802.5, "Mejora para Redes Multi Anillo" que intenta estandarizar estas extensiones. Desafortunadamente, el borrador más reciente (10 de noviembre de 1987) está aún en un desarrollo inicial. Más importante, difiere significativamente de las implementaciones existentes. En consecuencia, las implementaciones existentes de 802.5 [13] son descritas pero no se intenta especificar un futuro estándar. El encabezado MAC contiene 1 octeto de control de acceso, 1 octeto de control de marco, 6 (2) octetos de dirección origen, 6 (2) octetos de dirección destino, y (para redes multi-anillo) 0 a 18 octetos de Campo de Información de Encaminamiento (Routing Information Field, RIF). La portadora MAC contiene 4 octetos de FCS, para un total de 18 (10) a 36 (28) octetos. Hay un octeto adicional de estado de marco luego del FCS. Detalles de Extensión Multi Anillo La presencia de un Campo de Información de Encaminamiento esta indicada por el Bit Más Significativo (Most Significant Bit, MSB) de la dirección origen, llamado Indicador de Información de Encaminamiento (Routing Information Indicator, RII). Si el RII es igual a cero, no hay un RIF presente. Si el RII es igual a 1, hay un RIF presente. Aunque el RII es indicado en la dirección origen, no es parte de una dirección de capa MAC de estaciones. En particular, el MSB de una dirección destino es el indicador de dirección individual/de grupo, y si se establece causará que algunos marcos sean interpretados como multidifusión. Las implementaciones deberían ser cuidadosas para establecer el RII a cero antes de pasar las direcciones de origen a otras capas de protocolo que se puedan confundir por Postel & Reynolds [Página 8] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 su presencia. El RIF consiste de un campo de Control de Encaminamiento (Routing Control, RC) de dos octetos seguido por 0 a 8 campos de Designador de Ruta (Routing Designator, RD) de dos octetos. El RC para los marcos de difusión a todas las rutas está formado de la siguiente manera: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B | LTH |D| LF | r | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Observe que cada marca tick representa una posición de bit. B - Indicadores de Difusión: 3 bits Los Indicadores de Difusión se usan para indicar el encaminamiento deseado para un marco en particular. Un marco puede ser encaminado a través de una sola ruta especificada, a través de toda ruta distinta no repetida en una red multi anillo, o a través de una sola ruta determinada por un algoritmo de árbol de expansión tal que el marco aparece exactamente una vez en cada anillo. Los valores que pueden ser usados en este momento son (en binario): 000 - Sin difusión (ruta especificada) 100 - Difusión a todas las rutas (difusión global) 110 - Difusión de una sola ruta (difusión limitada) Todos los demás valores están reservados para un futuro uso. LTH - Longitud: 5 bits Los bits de Longitud se usan para indicar la longitud o el campo RI, incluyendo los campos RC y RD. Sólo se permiten valores pares entre 2 y 30 inclusive. D - Bit de Dirección: 1 bit El bit D especifica el orden de los campos RD. Si D es igual a 1, los campos de designador de encaminamiento se especifican en orden inverso. LF - Marco largo: 3 bits Postel & Reynolds [Página 9] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Los bits LF especifican el máximo MTU soportado por todos los puentes a lo largo de una ruta específica. Todos los marcos de difusión multi anillo deberían transmitirse con un valor al menos tan largo como el MTU soportado. Los valores usados son: LF (binario) MAC MTU IP MTU 000 552 508 001 1064 1020 010 2088 2044 011 4136 4092 100 8232 8188 Todos los demás valores están reservados para un futuro uso. El receptor debería comparar el LF recibido con el MTU. Si el LF es mayor o igual que el MTU entonces no se toma ninguna acción; sin embargo, si el LF es menor que el MTU el marco es rechazado. Actualmente hay tres acciones posibles si LF < MTU. El primero es el requerido para esta especificación (rechazar el marco). El segundo es reducir el MTU para todos los equipos para igualar el LF. Y el tercero es mantener un MTU separado por comunicación basada en equipo sobre los LFs recibidos. r - reservado: 4 bits Estos bits están reservados para un futuro uso y deben ser puestos en 0 por el transmisor e ignorados por el receptor. No es necesario para una implementación interpretar los designadores de encaminamiento. Su formato se deja sin especificar. Los designadores de encaminamiento deben ser transmitidos exactamente como se reciben. Las redes IEEE 802.5 no tienen un tamaño mínimo de paquete. Las redes IEEE 802.5 tienen un tamaño máximo de paquete basado en el tiempo máximo que un nodo puede retener el testigo. Este tiempo depende de muchos factores incluyendo la tasa de emisión de datos y el número de nodos en el anillo. La determinación del tamaño máximo de paquete se vuelve más compleja cuando se consideran redes multi anillo con puentes. Postel & Reynolds [Página 10] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Tomando un tiempo de retención de testigo de 9 milisegundos y un anillo de 4 megabit/segundo, el tamaño máximo de paquete posible es 4508 octetos incluyendo todos los octetos entre el control de acceso y la FCS inclusive. Esto permite 4508 - 36 (encabezado MAC+portadora con RIF de 18 octetos) - 8 (LLC+encabezado SNAP) = 4464 para el datagrama IP (incluyendo el encabezado IP). Sin embargo, se sabe que algunas implementaciones actuales limitan los paquetes a 2046 octetos (permitiendo 2002 octetos para IP). Se recomienda que todas las implementaciones soporten paquetes IP de al menos 2002 octetos. Por convención, los puentes de encaminamiento de origen usados en redes 802.5 multi anillo no soportarán paquetes mayores de 8232 octetos. Con un encabezado MAC+portadora de 36 octetos y el LLC+encabezado SNAP de 8 octetos, el datagrama IP (incluyendo el encabezado IP) no puede exceder los 8188 octetos. Un puente de encaminamiento de origen enlazando dos anillos puede ser configurado para limitar el tamaño de paquetes reenviados a 552 octetos, con un encabezado MAC+portadora de 36 octetos y el LLC+SNAP de 8 octetos, el datagrama IP (incluyendo el encabezado IP) puede estar limitado a 508 octetos. Esto es menos que el MTU IP predeterminado de 576 octetos, y puede causar problemas de rendimiento significativos debido a una excesiva fragmentación de datagramas. Una implementación no requiere soportar un MTU de menos de 576 octetos, aunque se sugiere que el MTU sea un parámetro configurable por el usuario para permitirlo. Las redes IEEE 802.5 soportan tres tipos diferentes de difusión. Las difusiones a todas las estaciones son enviadas sin RIF o con los Indicadores de Difusión puestos en 0 y sin Designadores de Encaminamiento, y son copiadas por todas las estaciones en el anillo local. Las difusiones a Todos las Rutas son enviadas con los correspondientes Indicadores de Difusión, y resulta en una cantidad de copias igual al número de rutas distintas, no repetidas, que un paquete puede seguir en un anillo en particular. La difusión de una Sola Ruta resulta en exactamente una copia de un marco siendo recibido por todas las estaciones en la red multi anillo. El procedimiento de descubrimiento dinámico de dirección es difundir una solicitud ARP. Para limitar el número de difusiones a todos los anillos a un mínimo es conveniente (aunque no requerido) que una solicitud ARP primero sea enviada como una difusión a todas las estaciones, sin un Campo de Información de Ruteo (RIF). Postel & Reynolds [Página 11] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Si la difusión a Todas las Estaciones (anillo local) no es soportada o si la difusión a todas las estaciones no es exitosa después de que ha transcurrido un tiempo razonable, entonces se envía la solicitud ARP como una difusión a todos las rutas o a una sola ruta con un RIF vacío (sin designadores de encaminamiento). Una difusión a todas las rutas es preferible ya que esta produce un aumento de la tolerancia a fallos. En un entorno con múltiples puentes redundantes, la difusión a todas las rutas permite operaciones a pesar de fallos en el puente del árbol de expansión. Sin embargo las difusiones a una sola ruta pueden ser usadas si IP y ARP deben usar el mismo método de difusión. Cuando se recibe una solicitud o respuesta ARP, todas las implementaciones deben entender los marcos sin RIF (anillo local) y marcos con un RIF vacío (también desde el anillo local). Si la implementación soporta encaminamiento de origen multi anillo, entonces un RIF no vacío es almacenado para futuras transmisiones al equipo originando la solicitud o respuesta ARP. Si el encaminamiento de origen no es soportado, todos los paquetes con RIFs no vacíos deberían ser ignorados. Esta política permitirá a todas las implementaciones en un ambiente de un solo anillo interoperar, ya sea que soporten o no las extensiones multi anillo. Es posible que cuando se envíe una solicitud ARP mediante una difusión a todas las rutas múltiples copias de la solicitud lleguen al destino como resultado de que la solicitud está siendo reenviada por varios puentes. Sin embargo, estas "copias" habrán tomado diferentes rutas, entonces los contenidos de los RIF diferirán. Una implementación de ARP en este contexto debe determinar cual de estas "copias" usar e ignorar las otras. Hay tres estrategias obvias y lícitas: (1) tomar el primero e ignorar el resto (esto es, tener una entrada en el caché ARP sin cambios), (2) tomar el último, (esto es, siempre actualizar el caché ARP con el último mensaje ARP), o (3) tomar uno con la ruta más corta, (esto es, reemplazar la información del caché ARP con la última información del mensaje ARP si esta es de una ruta más corta). No hay problemas de incompatibilidad para interoperación de diferentes implementaciones si eligen diferentes estrategias, la elección es tomada por cada implementador. El receptor de la solicitud ARP debe enviar una respuesta ARP como un mensaje punto a punto usando la información RIF. La información RIF debería conservarse separada de la tabla ARP. Esto es, tener, en principio, la tabla ARP para asociar direcciones IP a direcciones 802 de 48 bits, y la tabla RIF para asociar las rutas de origen 802.5, si es necesario. En las implementaciones prácticas puede ser conveniente almacenar la Postel & Reynolds [Página 12] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 información ARP y RIF juntas. Almacenar la información junta puede acelerar el acceso a la información cuando se usa. Por otra parte, en una implementación generalizada para todo tipo de redes 802 se puede desperdiciar una cantidad significativa de memoria en una caché ARP si el espacio para la información RIF estuviese siempre reservado. Las difusiones IP (datagramas con un dirección IP de difusión) deben ser enviadas como difusiones 802.5 de una sola ruta. A diferencia de ARP, las difusiones de todas las rutas no son convenientes para IP. Recibir múltiples copias de difusiones IP tendría efectos no deseados en muchos protocolos usando IP. Como con ARP, cuando un paquete IP es recibido, todas las implementaciones deben entender los marcos sin RIF y los marcos con un RIF vacío. Ya que las actuales interfases de hardware permiten sólo una dirección de grupo, y ya que las direcciones funcionales no son globalmente únicas, IP y ARP no usan ninguna de estas características. Además, en las redes 802.5 estilo IBM hay sólo 31 direcciones funcionales disponibles para definición de usuario. La precedencia IP no debería estar asociada a la prioridad 802.5. Todos los paquete IP y ARP deberían ser enviados en la prioridad 802.5 predeterminada. La prioridad predeterminada es 3. Después de la transmisión de un paquete, 802.5 proporciona indicadores de marco no copiado y dirección no reconocida. Las implementaciones pueden usar estos indicadores para permitir alguna detección y corrección de errores. Si el bit de marco no copiado es establecido pero el bit de dirección no reconocida no lo es, ha ocurrido una congestión en el receptor. Se recomienda, aunque no se requiere, que los equipos deberían retransmitir los paquetes con problemas un pequeño número de veces (4) o hasta que no ocurra la congestión. Si el bit de dirección no reconocida está activo, una implementación tiene 3 opciones: (1) ignora el error y lanza el paquete, (2) devuelve un mensaje ICMP de destino inalcanzable al origen, o (3) borra la entrada ARP que fue usada para enviar este paquete y envía una nueva solicitud ARP a la dirección de destino. La última opción es la preferida de este enfoque ya que esto permitirá recuperarse exitosamente de fallas en el primer puente o router de salto y direcciones de hardware cambiadas. Interoperación con Ethernet Postel & Reynolds [Página 13] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 Es posible usar el protocolo de nivel de enlace Ethernet [12] en el mismo cable físico con el protocolo de nivel de enlace IEEE 802.3. Una computadora conectada a un cable físico usado de esta manera puede potencialmente leer ambos paquetes, Ethernet y 802.3, de la red. Si una computadora lee ambos tipos de paquetes, debe mantener rastros del protocolo de enlace que fue usado con cada una de la otras computadoras en la red y usar el protocolo de enlace apropiado cuando envía paquetes. Uno debería notar que en ese ambiente, los paquetes de difusión del nivel de enlace no alcanzarán a todas las computadoras conectadas a la red, sólo a aquellas usando el protocolo de nivel de enlace usado por la difusión. Ya que debe asumirse que muchas computadoras leerán y enviarán usando sólo un tipo de protocolo de enlace, se recomienda que si este ambiente (una red con ambos protocolos de enlace) es necesario, se use una puerta de enlace IP como si hubiesen dos redes distintas. Observe que la MTU para Ethernet permite un datagrama IP de 1500 octetos, y la MTU para la red 802.3 permite sólo un datagrama IP de 1492 octetos. Apéndice sobre números El IEEE prefiere especificar los números en orden de transmisión de bits, u orden de little-endian. Los protocolos de Internet están documentados en orden big-endian en forma de bytes. Esto puede causar alguna confusión sobre los valores apropiados para usar por los números. Aquí están las conversiones para algunos números de interés. Número IEEE IEEE Internet Internet HEX Binario Binario Decimal UI Op Code C0 11000000 00000011 3 SAP for SNAP 55 01010101 10101010 170 XID F5 11110101 10101111 175 XID FD 11111101 10111111 191 TEST C7 11000111 11100011 227 TEST CF 11001111 11110011 243 Info 818000 129.1.0 Referencias [1] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, septiembre 1981. Postel & Reynolds [Página 14] RFC 1042 IP y ARP sobre redes IEEE 802 Febrero 1988 [2] Plummer, D., "An Ethernet Address Resolution Protocol - or - Con- verting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC-826, MIT, noviembre 1982. [3] IEEE, "IEEE Standards for Local Area Networks: Carrier Sense Multi- ple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE, New York, New York, 1985. [4] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus Access Method and Physical Layer Specification", IEEE, New York, New York, 1985. [5] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access Method and Physical Layer Specifications", IEEE, New York, New York, 1985. [6] IEEE, "IEEE Standards for Local Area Networks: Logical Link Con- trol", IEEE, New York, New York, 1985. [7] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, mayo 1987. [8] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC-1009, USC/Information Sciences Institute, junio 1987. [9] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Uni- versidad de California en Berkeley, abril 1984. [10] Postel, J., "The TCP Maximum Segment Size Option and Related Traducción al castellano: Javier Waisbrot (2003), jwais@fi.uba.ar Postel & Reynolds [Página 15]