Tabla de contenidosFuncionamiento de IGMP

2.8 ARP("Address Resolution Protocol")

Figura: ARP("Address Resolution Protocol")

El protocolo ARP es un protocolo estándar específico de las redes. Su status es electivo.

El protocolo de resolución de direcciones es responsable de convertir las dirección de protocolo de alto nivel(direcciones IP) a direcciones de red físicas. Primero, consideremos algunas cuestiones generales acerca de Ethernet.

2.8.1 Ethernet versus IEEE 802.3

Se pueden usar los siguientes formatos de trama en el cable coaxial de Ethernet:

1. El estándar lanzado en 1978 por Xerox Corporation, Intel Corporation y Digital Equipment Corporation, llamado habitualmente Ethernet (o Ethernet DIX).
2. El estándar internacional IEEE 802.3, definido más recientemente.

La diferencia entre estos dos estándares está en el uso de uno e los campos de la cabecera, que contiene un número de tipo de protocolo para Ethernet y la longitud de los datos del trama en IEEE 802.3.


Figura: formatos de trama en Ethernet e IEEE 802.3

• El campo de tipo en Ethernet se usa para distinguir diferentes protocolos ejecutándose en el mismo cable coaxial, y permite su coexistencia en el mismo cable físico.
• La longitud máxima de un trama de Ethernet es de 1526 bytes. Esto significa un campo de datos de hasta 1500 bytes. La longitud del campo de datos en 802.3 está limitada también a 1500 bytes para redes a 10 Mbps, pero es distinta para otras velocidades de transmisión.
• En el trama MAC de 802.3, la longitud del campo de datos la indica la cabecera. El tipo de protocolo figura en la cabecera del protocolo 802.2(de nivel superior), ver Figura - Formatos de trama para Ethernet e IEEE 802.3
• En la práctica, no obstante, ambos formatos de bloque pueden coexistir en un mismo cable físico. Esto se consigue utilizando números de tipo de protocolo(campo de tipo) superiores a 1500 en la trama Ethernet. Sin embargo, es necesario que distintos controladores sean capaces de manejar cada uno de estos formatos.

Así, a efectos prácticos, la capa física de Ethernet e IEEE 802.3 son compatibles. A pesar de todo, las capas de enlace de Ethernet y de IEEE 802.3/802.2 no lo son.

La capa LLC("Logical Link Control") de 802.2

El IEEE 802.3 usa un concepto conocido como LSAP("Link Service Access Point") que utiliza una cabecera de 3 bytes:


Figura: Cabecera de LSAP en IEEE 802.2

donde DSAP y SSAP significan Destination y Source Service Access Point, respectivamente. Los números para estos campos son asignados por un comité IEEE.

Debido al número creciente de aplicaciones que emplean IEEE 802 como protocolo para los niveles inferiores, se le hizo una extensión en la forma del SNAP ("Sub-Network Access Protocol"). Se trata de una extensión a la cabecera de LSAP, y el valor 170 de los campos SSAP y DSAP indica su uso.


Figura: Cabecera de LSAP en IEEE 802.2

En la evolución de TCP/IP

se han establecido tres estándares, que describen el encapsulamiento de las tramas IP y ARP en estas redes:

1. 1984: RFC 894 - Estándares para la transmisión de datagramas IP en redes Ethernet especifica sólo el uso de las redes Ethernet. Los valores asignados al campo de tipo son:

2048 (hex 0800)

para datagrama IP

2054 (hex 0806)

para datagrama ARP

2. 1985: RFC 948 - Dos métodos para la transmisión de datagrama IP en redes IEEE 802.3 especifica dos posibilidades:
1. El método compatible con Ethernet: las tramas se envían en un red IEEE 802.3 como si se tratase de una red Ethernet network, es decir, usando el campo de longitud de IEEE 802.3 como campo de tipo, violando por tanto las reglas de IEEE 802.3.
2. Formato IEEE 802.2/802.3 LLC tipo 1: usando la cabecera 802.2 LSAP con IP, con el valor 6 para los campos SSAP y DSAP.

El RFC indica claramente que el método IEEE 802.2/802.3 es el preferido, es decir, se supone que todas las implementaciones futuras de IP en redes IEEE 802.3 deberían usarlo.

3. 1987: RFC 1010 - Números asignados (ahora obsoleto por el RFC 1700 de 1994) señala que como resultado de la evolución de IEEE 802.2 y de la necesidad de más números de protocolo, se desarrolló una nueva aproximación al problema basada en el intercambio de experiencias prácticas que tuvo lugar durante la convención de distribuidores de TCP de agosto de 1986. Afirma que de ahora en adelante en todas las implementaciones de IEEE 802.3, 802.4 y 802.5 se debería emplear la versión SNAP("Sub-Network Access Protocol") del IEEE 802.2 LLC: con los campos DSAP y SSAP fijados a 170(indicando el uso de SNAP) y asignando SNAP del modo siguiente:

• 0 (cero) como código de organización.
• Campo EtherType:

1. 1988: RFC 1042 - Estándar para la transmisión de datos en redes IEEE 802.

Sin embargo, en la práctica, todavía hay implementaciones de TCP/IP que utilizan el viejo método LSAP(RFC 948 o 1042). Tales implementaciones no se comunicarán con implementaciones más recientes.

Notar además que el último método cubre no sólo las redes IEEE 802.3, sino también las redes IEEE 802.4 y 802.5.

2.8.2 Descripción de ARP

En una sola red física, los hosts individuales se conocen en la red a través de su dirección física. Los protocolos de alto nivel direccionan a los hosts de destino con una dirección simbólica (en este caso la dirección IP). Cuando tal protocolo quiere enviar un datagrama a la dirección IP de destino w.x.y.z, el manejador de dispositivo no la entiende.

En consecuencia, se suministra un módulo(ARP) que traducirá la dirección IP a las dirección física del host de destino. Utiliza una tabla(llamada a veces caché ARP) para realizar esta traducción.

Cuando la dirección no se encuentra en la caché ARP, se envía un broadcast en la red, con un formato especial llamado petición ARP. Si una de las máquinas en la red reconoce su propia dirección IP en la petición, devolverá una respuesta ARP al host que la solicitó. La respuesta contendrá la dirección física del hardware así como información de encaminamiento8(si el paquete ha atravesado puentes durante su trayecto) tanto esta dirección como la ruta se almacenan en la caché del host solicitante. Todos los posteriores datagramas enviados a esta dirección IP se podrán asociar a la dirección física correspondiente, que será la que utilice el manejador de dispositivo para mandar el datagrama a la red.

ARP se diseño para ser usado en redes que soportasen broadcast por hardware. Esto significa, por ejemplo, que ARP no funcionará en una red X.25.

2.8.3 Concepto detallado de ARP

ARP se emplea en redes IEEE 802 además de en las viejas redes DIX Ethernet para mapear direcciones IP a dirección hardware. Para hacer esto, ha de estar estrechamente relacionado con el manejador de dispositivo de red. De hecho, las especificaciones de ARP en RFC 826 sólo describen su funcionalidad, no su implementación, que depende en gran medida del manejador de dispositivo para el tipo de red correspondiente, que suele estar codificado en el microcódigo del adaptador.

2.8.3.1 Generación del paquete ARP

Si una aplicación desea enviar datos a una determinado dirección IP de destino, el mecanismo de encaminamiento IP determina primero la dirección IP del siguiente salto del paquete (que puede ser el propio host de destino o un "router") y el dispositivo hardware al que se debería enviar. Si se trata de una red 802.3/4/5, deberá consultarse el módulo ARP para mapear el par <tipo de protocolo, dirección de destino> a una dirección física.

El módulo ARP intenta hallar la dirección en su caché. Si encuentra el par buscado, devuelve la correspondiente dirección física de 48 bits al llamador(el manejador de dispositivo). Si no lo encuentra, descarta el paquete (se asume que al ser un protocolo de alto nivel volverá a transmitirlo) y genera un broadcast de red para una solicitud ARP.


Figura: Paquete de petición/respuesta ARP

Donde:

Hardware address space

Especifica el tipo de hardware; ejemplos son Ethernet o Packet Radio Net.

Protocol address space

Especifica el tipo de protocolo, el mismo que en el campo de tipo EtherType en la cabecera de IEEE 802.

Hardware address length

Especifica la longitud(en bytes) de la dirección hardware del paquete. Para IEEE 802.3 e IEEE 802.5 será de 6.

Protocol address length

Especifica la longitud(en bytes) de las direcciones del protocolo en el paquete. Para IP será de 4.

Operation code

Especifica si se trata de una petición(1) o una solicitud(2) ARP.

Source/target hardware address

Contiene las direcciones física hardware. En IEEE 802.3 son direcciones de 48 bits.

Source/target protocol address

Contiene las direcciones del protocolo. En TCP/IP son direcciones IP de 32 bits.

Para el paquete de solicitud, la dirección hardware de destino es el único campo indefinido del paquete.

2.8.3.2 Recepción del paquete ARP

Cuando un host recibe un paquete ARP(bien un broadcast o una respuesta punto a punto), el dispositivo receptor le pasa el paquete al módulo ARP, que lo trata como se indica en Figura - Recepción del paquete ARP.


Figura: Recepción del paquete ARP

El host solicitante recibirá esta respuesta ARP, y seguirá el algoritmo ya comentado para tratarla. Como resultado, la tripleta <tipo de protocolo, dirección de protocolo, dirección hardware> para el host en cuestión se añadirá a la caché ARP. La próxima vez que un protocolo de nivel superior quiera enviar un paquete a ese host, el módulo de ARP encontrará la dirección hardware, a la que se enviará el paquete.

Notar que debido a que la petición ARP original fue un broadcast en la red, todos los host en ella habrán actualizado la dirección del emisor en su propia caché(sólo si previamente ya existía esa entrada) en la tabla.

2.8.4 ARP y subredes

El protocolo ARP es el mismo aunque haya subredes. Recordar que cada datagrama IP pasa primero por el algoritmo de encaminamiento IP. Este algoritmo selecciona el manejador de dispositivo que debería enviar el paquete. Sólo entonces se consulta al módulo ARP asociado con ese manejador.

2.8.5 Proxy-ARP o subnetting transparente

El Proxy-ARP se describe en el RFC 1027 - Usando ARP para implementar pasarelas de subredes transparentes, que de hecho es un subconjunto del método propuesto en el RFC 925 - Resolución de direcciones Multi-LAN. Es otro método para construir subredes locales, sin necesidad de modificar el algoritmo de encaminamiento IP, pero con modificaciones en los routers, que interconectan las subredes.

2.8.5.1 Concepto de Proxy-ARP

Considerar una red IP, dividida en subredes, interconectadas por "routers". Utilizamos el algoritmo IP "viejo", lo que significa que ningún host conoce la existencia de múltiples redes físicas. Si se toman los hosts A y B, que se hallan en distintas redes físicas dentro de la misma red IP, y un "router" entre las dos subredes:


Figura: Hosts interconectados por un "router"

Cuando el host A quiere enviar un datagrama IP al host B, primero ha de determinar la dirección de red física del host B usando ARP.

Como A no puede diferenciar entre las redes físicas, su algoritmo de encaminamiento IP piensa que el host B está en su misma red local y envía un broadcast de petición ARP. El host B no lo recibe, pero sí el "router" R. R entiende de subredes, es decir, ejecuta la versión de subred del algoritmo de encaminamiento y será capaz de ver que el destino de la petición ARP(en el campo de dirección de protocolo de destino) está localizado en otra red física. Si las tablas de encaminamiento de R especifican que el siguiente salto a otra red se produce a través de un dispositivo diferente, replicará al ARP como si fuera el host B, diciendo que la dirección de B es la del mismo "router".

El host A recibe esta respuesta ARP, la introduce en su caché y enviará los siguientes paquetes dirigidos a B al "router" R, que los retransmitirá a la subred adecuada.

El resultado es subnetting transparente:

• Los host normales(como A y B) desconocen el subnetting, por lo que usan el algoritmo de encaminamiento clásico.
• Los "router" entre subredes":

1. Utilizan el algoritmo IP para subredes.
2. Usan un módulo ARP modificado, que puede responder en nombre de otros hosts.

Figura: "Router" Proxy-ARP

Tabla de contenidosRARP ("Reverse Address Resolution Protocol")