Protocolo de Resolución de Direcciones (ARP):

El protocolo ARP es un protocolo estándar específico de red. Su status es electivo.
El protocolo de resolución de direcciones es responsible para convertir las direcciones de protocolo de alto nivel (direcciones IP) para direcciones de red física. Primero, consideremos algunos tópicos generales en Ethernet.

Ethernet vs IEEE 802.3

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

1. El estándar que emitió en 1978 Xerox Corporation, Intel Corporation y Digital Equipment Corporation, habitualmente llamado Ethernet (o DIX Ethernet).
2. El estándar international IEEE 802.3, un estándar definido más reciente.

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

• El campo tipo en Ethernet se usa para distinguir entre protocolos diferentes que se ejecutan en el cable coaxial, y permite su coexistencia en el mismo cable físico.
• La longitud máxima de una trama Ethernet es 1526 bytes. Esto significa una longitud del campo de datos por encima de 1500 bytes. La longitud del campo de datos de 802.3 también está limitada a 1500 bytes para redes de 10 Mbps, pero es distinta para otras velocidades de transmisión.
• En la trama MAC 802.3, la longitud del campo de datos se indica en la cabecera 802.3. El tipo de protocolo it carries están indicados en la cabecera 802.2 (protocolo de alto nivel), ver figura superior.
• En la práctica sin embargo, pueden coexistir ambos formatos de trama en el mismo coaxial físico. Esto se hace usando números de tipo de protocolo (campo tipo) más grandes que 1500 en la trama Ethernet. Sin embargo, se necesitan drivers de dispositivos diferentes para manejar cada uno de estos formatos.

Por tanto, para propósitos prácticos, la capa física Ethernet y la IEEE 802.3 son compatibles. Sin embargo, la capa de enlace de datos Ethernet y la IEEE 802.3/802.2 son incompatibles.

Capa de Control del Enlace de Datos (LLC)

Arriba, IEEE 802.3 usa un concepto conocido como Punto de Acceso al Servicio de Enlace (LSAP) que usa una cabecera de 3 bytes:
donde DSAP y SSAP simbolizan el Punto de Acceso al Servicio de Origen y Destino respectivamente. El comité del IEEE asigna los números para estos campos.
Debido al crecimiento del número de aplicaciones que usan IEEE 802 como protocolo de capa más baja, se realizó una extensión al protocolo IEEE 802.2 en la forma del Protocolo de Acceso a SubRedes (SNAP). Es una extensión de la cabecera LSAP, y su uso se indica con el valor 170 en los campos SSAP y DSAP de la trama LSAP anterior.
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ándar para la Transmisión de Datagramas IP sobre Redes Ethernet especifica sólo el uso de tipo de redes Ethernet. Los valores asignados al campo tipo son:
   • 2048 (hex 0800) para datagramas IP
   • 2054 (hex 0806) para datagramas ARP
2. 1985: RFC 948 - Dos Métodos para la Transmisión de Datagramas IP sobre Redes IEEE 802.3 especifica dos posibilidades:
   1. El método Ethernet compatible: las tramas se envían en una red IEEE 802.3 real de la misma manera que en una red Ethernet, es decir, usando el campo de longitud de datos IEEE 802.3 como el campo tipo Ethernet.
   2. Formato IEEE 802.2/802.3 LLC tipo 1: usando la cabecera LSAP 802.2 con IP utilizando el valor 6 para los campos SSAP y DSAP.
   El RFC indica claramente que el método IEEE 802.2/802.3 es el método preferido, es decir, que se supone que todas las implementaciones IP futuras de las redes IEEE 802.3 usan el segundo método.
   
3. 1987: RFC 1010 - Números Asignados (ahora obsoleto por el RFC 1700 de 1994) notes that as a result of IEEE 802.2 evolution y the need for more internet protocol numbers, a new approach was developed based on practical experiences exchanged during the August 1986 TCP Vendors Workshop. It states in an almost completely overlooked part of this RFC that from now on all IEEE 802.3, 802.4 y 802.5 implementations should use the Sub-Network Access Protocol (SNAP) form of the IEEE 802.2 LLC: DSAP y SSAP fields set to 170 (indicating the use of SNAP) y then SNAP assigned as follows:
   • 0 (cero) como código de organización.
   • Campo EtherType:
     • 2048 (hex 0800) para datagramas IP
     • 2054 (hex 0806) para datagramas ARP
     • 32821 (hex 8035) para datagramas RARP
     Estos son los mismos valores que los usados en el campo tipo Ethernet.
     
4. 1988: RFC 1042 - Estándar para la Transmisión de Datagramas IP sobre Redes IEEE 802.

Concepto detallado ARP

ARP is used on IEEE 802 networks as well as on the older DIX Ethernet networks to map IP addresses to physical hardware addresses. To do this, it is closely related to the device driver for that network. In fact, the ARP specifications in RFC 826 only describe its functionality, not its implementation. The implementation depends to a large extent on the device driver for a network type y they are usually coded together in the adapter microcode.

Generación de paquetes ARP

Si una aplicación desea enviar datos a cierta dirección de destino IP, el mecanismo de enrutamiento IP primero determina la dirección IP del "próximo salto" del paquete (puede ser el propio host de destino, o un router) y el dispositivo hardware al cual se debería enviar. Si se trata de una red IEEE 802.3/4/5, el módulo ARP se debe consultar para hacer corresponder el <tipo de protocolo, la dirección del protocolo de destino> con una dirección física.
El módulo ARP intenta encontrar la dirección en esta caché ARP. Si encuentra la pareja correspondiente, devuelve la correspondiente dirección física de 48 bits al que lo llamó (el driver del dispositivo) que entonces transmite el paquete. Si no encuentra la pareja en su tabla, descarta el paquete (assumption is that a higher-level protocol will retransmit) y generates a network broadcast of an ARP request.
donde:

espacio de direcciones hardware

Especifica el tipo de hardware; ejemplo de ello son Ethernet o Red de Radio por Paquetes.

espacio de direcciones del protocolo

Especifica el tipo de protocolo, igual que el campo EtherType en la cabecera IEEE 802 (IP o ARP).

longitud de direcciones hardware

Especifica la longitud (en bytes) de las direcciones hardware en este paquete. Para IEEE 802.3 y IEEE 802.5 será 6.

longitud de direcciones del protocolo

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

código de operación

Especifica si es una petición ARP (1) o una respuesta (2).

dirección hardware origen/destino

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

dirección del protocolo origen/destino

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

Para el paquete de petición ARP, la dirección hardware de destino es el único campo no definido en el paquete.

Recepción de paquetes ARP

Cuando un host recibe un paquete ARP (una petición de broadcast o una respuesta punto a punto), el driver del dispositivo receptor pasa el paquete al módulo ARP que lo trata como se muestra en la figura.
El host solicitante recibirá esta respuesta ARP y seguirá el mismo algoritmo para tratarlo. Como resultado de esto, se añadirá la tripleta <tipo de protocolo, dirección de protocolo, dirección hardware> para el host deseado a su tabla de búsqueda (cahé ARP). La próxima vez que una protocolo de más alto nivel quiera enviar un paquete a ese host, el módulo ARP encontrará la dirección hardware de destino y se enviará el paquete a ese host.

Proxy-ARP o subnetting transparente

Proxy-ARP se describe en el RFC 1027 - Usar ARP para Implementar Pasarelas de Subred Transparente, que es de hecho 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 enrutamiento IP, pero modificando los routers, que interconectan las subredes.

Concepto de Proxy-ARP

Consideremos una red IP, que está dividida en subredes, interconectada por routers. Usamos el algoritmo de enrutamiento IP "antiguo", que significa que ningún host conoce la existencia de múltiples redes físicas. Consideremos que los hosts A y B que están en diferentes redes físicas con la misma red IP y un router R entre las dos subredes como muestra la figura:
Cuando un host A quiere enviar un datagrama IP a un host B, primera tiene que determinar la dirección de red física del host B usando el protocolo ARP.
Como el host A no puede diferenciar entre las redes físicas, su algoritmo de enrutamiento IP piensa que el host B está en la red física local y envía una petición ARP de broadcast. El host B no recibe este broadcast, pero el router R sí. El router R entiende de subredes, esto es, ejecuta la versión "subnet" del algoritmo de enrutamiento IP y será capaz de ver que el destino de la petición ARP (del campo de dirección de protocolo destino) está en otra red física. Si las tablas de enrutamiento del router R especifican que el próximo salto a esa otra red se hace a través de un dispositivo físico diferente, responderá a ARP como si fuera el host B, diciendo que la dirección de red del host B es la del mismo router R.
El host A recibe esta respuesta ARP, la pone en su caché y enviará futuros paquetes IP para el host B hacia el router R. El router enviará tales paquetes a la subred correcta.
El resultado es subnetting transparente:

• Los hosts normales (tales como A y B) no saben subnetting, así que usan el algoritmo de enrutamiento IP "old".
• Los routers entre subredes tienen que:
  1. Usar el algoritmo IP "subnet".
  2. Usar un módulo ARP modificado, que puede responder en beneficio de otro hosts.