Resumen

  • RFC 903 resolvía un problema concreto de arranque en frío: una estación sin disco conocía su dirección física, pero necesitaba una dirección de protocolo antes de poder usar IP.
  • RARP hacía la consulta en la capa de enlace. Un servidor respondía a partir de una tabla de asociaciones entre direcciones físicas y de protocolo; la respuesta no autenticaba al equipo ni demostraba que hubiera terminado de arrancar.
  • El protocolo no definía una respuesta explícita de «no encontrado». Si no oía nada, el cliente debía agotar el tiempo de espera sin saber si faltaba la asociación, se había perdido un paquete o ningún servidor respondió.
  • RFC 950 y BOOTP muestran por qué una dirección no bastaba para configurar un host: también podían hacer falta una puerta de enlace, un servidor de nombres, una máscara de subred y un archivo de arranque.

La primera pregunta llegaba antes que IP

Imaginemos una estación de trabajo sin disco local. Su código de arranque puede leer la dirección física de la interfaz Ethernet, pero no tiene guardada una dirección de Internet. Una consulta IP no resuelve el problema: la máquina todavía no sabe qué dirección de origen usar.

En RFC 903, publicado en junio de 1984, Ross Finlayson, Timothy Mann, Jeffrey Mogul y Marvin Theimer propusieron RARP. El memorando describe a un host que pide su dirección de protocolo a una fuente externa en un medio de difusión como Ethernet. ARP hacía el recorrido inverso: encontraba la dirección física cuando ya se conocía la dirección de protocolo. RARP partía de la dirección física y pedía la dirección de protocolo asociada.

No era un servicio general de identidad. RARP no preguntaba quién era el dueño de la estación ni si una persona tenía derecho a usar una dirección. Daba a un host sin configurar una forma de pedir una asociación concreta antes de poder comunicarse normalmente mediante IP.

El servidor local guardaba la respuesta

RFC 903 separó deliberadamente RARP como protocolo de capa de enlace. Reutilizó el formato de paquete de ARP, pero asignó códigos de operación distintos para la solicitud y la respuesta inversas. Si el host pedía su propia dirección, colocaba la misma dirección física en los campos de origen y de destino. Un servidor que reconociera esa dirección podía contestar con la dirección de protocolo correspondiente.

La respuesta dependía del estado del servidor. El RFC indica que uno o varios servidores RARP mantienen una base de asociaciones entre direcciones físicas y de protocolo. Esto difiere del ARP normal: los hosts acumulan en una caché las correspondencias de sus pares y no hay una separación entre cliente y servidor. RARP introducía, por tanto, una dependencia operativa: el cliente podía preguntar, pero un operador local debía mantener útil la tabla del servidor.

La respuesta era un recibo de correspondencia, no una credencial. El RFC no define una autenticación que vincule la dirección física con una persona, un propietario o un dispositivo autorizado. Tampoco demuestra que el host instalara correctamente la dirección, alcanzara una puerta de enlace o cargara un sistema operativo. Esos son pasos posteriores.

El silencio no quería decir «no existe»

RFC 903 define solicitudes y respuestas inversas, pero ningún paquete de «no encontrado» o error. Los autores explican que varios servidores pueden estar habilitados para responder. En vez de definir una negativa distinta, el RFC indica al solicitante que agote el tiempo de espera si no llega una respuesta dentro de un intervalo razonable.

Así se mantenía pequeño el intercambio, pero el cliente recibía una observación ambigua. El tiempo agotado podía significar que ningún servidor tenía la asociación; también podía haberse perdido la solicitud o la respuesta, estar caído el enlace o no estar disponible ningún servidor. El silencio no distinguía esas situaciones. Un registro de arranque que solo dijera «RARP agotó el tiempo» no podía determinar la causa.

La diferencia importa al reconstruir una falla. La falta de respuesta prueba qué recibió el cliente —nada—, no que la dirección no estuviera asignada. El memorando original deja clara esa frontera, aunque no prescribe un sistema de diagnóstico capaz de aislar cada causa.

Una dirección no configuraba todo el host

Pronto quedó visible el problema más amplio del arranque. RFC 950 cita RARP como una vía para que un host recién iniciado descubra su dirección de Internet y luego enumera otros datos que puede necesitar: la dirección física de una puerta de enlace, la dirección IP de un servidor de nombres y la máscara de subred. El texto considera preferible obtener varios parámetros en una sola solicitud, en vez de emitir varias difusiones.

BOOTP, especificado al año siguiente, conservó la búsqueda de dirección física a IP y a la vez transportó más información de arranque, incluido un nombre de archivo opcional. Su diseño también permitía arrancar a través de puertas de enlace. RFC 951 compara explícitamente ese enfoque IP/UDP con los paquetes RARP de capa de enlace y las modificaciones específicas de kernel o controlador necesarias para acceder a ellos. RFC 1542 aclaró más tarde el comportamiento de los retransmisores BOOTP; RFC 2131 describe DHCP como una evolución de BOOTP que agregó asignación automática reutilizable de direcciones y opciones de configuración.

La secuencia no prueba que todas las redes abandonaran RARP en una fecha determinada. Sí muestra cómo cambió la pregunta: descubrir una dirección preasignada servía, pero arrancar un host a través de redes enrutadas requería un intercambio más amplio y una vía de retransmisión.

Un registro no es la máquina

La Nota 72 de Heng Lu ofrece un marco analítico posterior, no evidencia sobre 1984: un registro describe la realidad, pero no la crea. RARP no era un registro global, aunque la distinción sigue siendo útil. La tabla del servidor coordinaba una asociación local; no convertía la dirección devuelta en prueba de propiedad del equipo, identidad del usuario o funcionamiento correcto.

El aporte histórico del protocolo fue más acotado y práctico. Permitió que un host preguntara al enlace al que ya podía llegar por la única dirección necesaria para empezar a comunicarse mediante IP. Su límite también era su costo: había que mantener las asociaciones locales, el silencio no se explicaba por sí mismo y la respuesta no constituía una configuración completa.

Fuentes

RFC 903 — A Reverse Address Resolution Protocol; RFC 826 — An Ethernet Address Resolution Protocol; RFC 950 — Internet Standard Subnetting Procedure; RFC 951 — Bootstrap Protocol; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol; RFC 2131 — Dynamic Host Configuration Protocol. La Nota 72 es un marco editorial posterior, no una fuente histórica.