RARP: qué es el Reverse Address Re­so­lu­tion Protocol

¿Qué sucede cuando un ordenador no conoce su propia dirección IP ya que, por ejemplo, no tiene la po­si­bi­li­dad de al­ma­ce­nar­la? En un caso como este, el Reverse Address Re­so­lu­tion Protocol (RARP) puede ser de ayuda, pues se trata de un protocolo para la solicitud inversa de di­re­c­cio­nes. De esta manera, RARP co­n­s­ti­tu­ye la co­n­tra­par­te del Address Re­so­lu­tion Protocol (ARP).

Aunque el Reverse ARP ha caído en desuso, ya que nuevos pro­to­co­los como Bootstrap (BOOTP) o el Dynamic Host Co­n­fi­gu­ra­tion (DHCP) lo han su­s­ti­tui­do, conocer esta te­c­no­lo­gía más antigua también es útil. Por un lado, aún a día de hoy se pueden encontrar apli­ca­cio­nes que funcionan con RARP. Por otro lado, conocer las te­c­no­lo­gías an­te­rio­res ayuda a entender mejor las te­c­no­lo­gías eme­r­ge­n­tes.

En primer lugar, RARP es un protocolo que se publicó en 1984 y que se incluye en la pila de pro­to­co­los TCP/IP. RARP se encuentra en la capa de acceso a la red (el nivel más básico y elemental de la pila) y re­pre­se­n­ta con ello una te­c­no­lo­gía que permite la tra­n­s­mi­sión entre dos puntos dentro de una red. Cada usuario de una red dispone de dos di­re­c­cio­nes (más o menos) únicas: una lógica, la dirección IP, y una física, la dirección MAC (Media Access Control). Mientras que la dirección IP la determina el software, la dirección MAC está vinculada al hardware y se obtiene de la tarjeta de red pro­po­r­cio­na­da por el fa­bri­ca­n­te.

Puede darse la situación de que uno no conozca su propia dirección IP, por ejemplo, porque el di­s­po­si­ti­vo en cuestión no tiene al­ma­ce­na­mie­n­to propio en el que poder guardar dicha dirección. En este tipo de si­tua­cio­nes entra en juego el protocolo Reverse ARP. Basándose en la dirección MAC conocida, el protocolo puede de­te­r­mi­nar cuál es la dirección IP del di­s­po­si­ti­vo. Por lo tanto, cumple un propósito to­ta­l­me­n­te diferente al del protocolo ARP. En este último protocolo la dirección IP es conocida y con ayuda de ARP se averigua la dirección del hardware.

La siguiente in­fo­r­ma­ción se encuentra contenida en campos in­di­vi­dua­les:

• Hardware Address Space: en estos dos bytes se es­pe­ci­fi­ca el tipo de dirección del hardware.
• Protocol Address Space: este campo de dos bytes determina el tipo de protocolo de red.
• Hardware Address Length: estos 8 bits es­ta­ble­cen la longitud n de la dirección del hardware.
• Protocol Address Length: con este campo se determina la longitud m de la dirección de red.
• Opcode: este campo de dos bytes indica de qué operación se trata (código de operación). Una solicitud RARP tiene valor 3, y la respuesta co­rre­s­po­n­die­n­te, valor 4.
• Source Hardware Address: aquí se indica la dirección MAC del so­li­ci­ta­n­te. La longitud real de este campo es n y la determina el valor del campo “Hardware Adress Length”. En una red Ethernet típica hablamos de unos 6 bytes.
• Source Protocol Address: en teoría, en este campo aparece la dirección IP del so­li­ci­ta­n­te, pero dado que si se solicita no se conoce, el campo se muestra in­de­fi­ni­do. Por el contrario, en la respuesta se encuentra la dirección IP del servidor en este campo. La longitud de este campo es m y depende de la longitud de la dirección del protocolo (Protocol Address Length). Por lo general, el campo tiene la longitud de una dirección IPv4, es decir, 4 bytes.
• Target Hardware Address: este campo contiene la dirección MAC de destino. Puesto que una solicitud RARP no tiene un destino es­pe­cí­fi­co, aquí también se recoge la dirección del so­li­ci­ta­n­te. En la respuesta, el servidor incluye además la dirección del cliente so­li­ci­ta­n­te. Este campo también tiene longitud n y, en el caso de una red Ethernet, cuenta con 6 bytes.
• Target Hardware Address: este último campo continúa in­de­fi­ni­do en una solicitud y contiene en la respuesta del servidor la in­fo­r­ma­ción que realmente se busca: la dirección IP del usuario de la red. Este campo también tiene longitud m, ge­ne­ra­l­me­n­te 4 bytes.

Sin embargo, los pro­to­co­los ARP y RARP tienen di­fe­re­n­cias notables. En primer lugar, ambos se di­fe­re­n­cian en los datos, ob­via­me­n­te. Mientras que en la solicitud RARP se conoce la dirección MAC propia y se solicita la dirección IP co­rre­s­po­n­die­n­te, con ARP sucede justo lo contrario: se conoce la dirección IP y debe de­s­cu­bri­r­se la dirección MAC. Ambos pro­to­co­los se di­fe­re­n­cian también por el contenido de sus campos de operación: en este caso, ARP conoce ambos valores 1 (para una solicitud) y 2 (para una respuesta). Por el contrario, RARP utiliza los valores 3 y 4. De esta manera, el servidor es capaz de reconocer según el código de la operación si se trata de ARP o RARP.

El Reverse Address Re­so­lu­tion Protocol tiene algunas de­s­ve­n­ta­jas que han hecho que, fi­na­l­me­n­te, se viera su­s­ti­tui­do por uno más nuevo. Por ejemplo, para poder utilizar el protocolo co­rre­c­ta­me­n­te, el servidor RARP debe en­co­n­trar­se en la misma red física. El ordenador envía la solicitud RARP al nivel más bajo de la capa de red. Por lo tanto, no es posible que un router transmita el paquete. A todo ello se suma que RARP no es capaz de gestionar su­b­ne­t­ti­ng, ya que no se puede tra­n­s­mi­tir ningún tipo de máscara de subred. Si la red está dividida en subredes múltiples, en cada una de ellas tiene que haber un servidor RARP di­s­po­ni­ble.

Además, con la solicitud, el usuario conoce úni­ca­me­n­te cuál es su dirección IP. Como ya hemos me­n­cio­na­do an­te­rio­r­me­n­te, no incluye una máscara de subred, ni permite obtener in­fo­r­ma­ción sobre la puerta de enlace. Por lo tanto, no es posible co­n­fi­gu­rar el ordenador en una red moderna. Estos in­co­n­ve­nie­n­tes son los que fi­na­l­me­n­te han conducido al de­sa­rro­llo de BOOTP y DHCP.