Resumen

  • RFC 1931 permitió varios servidores Dynamic RARP para soportar fallos, pero exigió que todos los de un segmento se comunicaran con la misma autoridad lógica de direcciones.
  • Un registro administrativo consistente podía seguir equivocado: antes de asignar una dirección marcada como libre, la implementación podía buscar uso real mediante ARP o ICMP.
  • El documento apareció en abril de 1996 como Informational y hoy figura como Legacy. Registró una práctica de ciertas plataformas Sun desde 1988; no definió un estándar ni demuestra que DRARP causara la evolución de DHCP.

La ausencia de respuesta no era una respuesta

RFC 903 definió RARP para una máquina que arrancaba conociendo su dirección de hardware, pero no la de protocolo. Uno o varios servidores conservaban las correspondencias. No había mensaje negativo porque un servidor ignorante no podía hablar por todos los demás.

La consecuencia operativa era una espera sin diagnóstico. El cliente no podía saber si se había perdido el paquete, si el servidor adecuado estaba caído, si su máquina era desconocida, si estaba conectada al segmento equivocado o si no existía ningún servidor. Retransmitir con espera exponencial reducía tráfico; no reducía incertidumbre.

Tampoco existía una instalación realmente nacida de la nada. Alguien tenía que haber preparado la red IP y el sistema de nombres. Recibir una dirección solo abría la puerta a procesos separados: registrar el nombre, reservar recursos de arranque, entregar claves o configurar una contraseña inicial.

RFC 1931 documentó una ampliación denominada Dynamic RARP. Conservaba el formato de RARP, pero añadía una solicitud propia, una respuesta de enlace temporal y un error obligatorio. Si ya existía un enlace permanente, se devolvía REVARP_REPLY; si no, podía crearse un DRARP_REPLY temporal; si la operación no procedía, DRARP_ERROR distinguía restricción, agotamiento, indisponibilidad, movimiento de segmento o fallo indeterminado.

La precisión del estado tenía un límite: describir una causa no autenticaba al servidor ni demostraba que su diagnóstico fuera verdadero. Aun así, transformaba el silencio en una decisión observable y permitía separar reintento, intervención administrativa y cambio de topología.

La ficha actual del RFC Editor mantiene el texto como Informational en la corriente Legacy y señala que no establece ningún estándar de Internet. Según el propio memo, ciertas plataformas de Sun Microsystems usaban DRARP desde 1988; ya no se vendían cuando el documento se publicó en abril de 1996, y DHCP había cubierto parte del papel. Es memoria técnica, no una candidatura tardía al estándar.

El clúster no recibía soberanía por contar nodos

Si varios servidores oían una petición, sus respuestas tenían que coincidir salvo en los campos que identificaban al remitente. Cualquier diferencia era un error de protocolo. Esa condición impedía que la tolerancia a fallos se convirtiera en tolerancia a verdades contradictorias.

Un servidor en cada segmento limitaba el daño de una partición; varios reducían el riesgo de perder una máquina o un tramo de cable. Todos, sin embargo, debían hablar con una misma autoridad de direcciones. La implementación descrita usaba NIS y un servicio RPC centralizado, IPalloc. Administradores y servidores DRARP autorizados podían modificar sus datos. RFC 1931 no normalizó ese servicio ni resolvió sus opciones de seguridad.

La autoridad tenía que administrar enlaces permanentes, enlaces temporales y direcciones disponibles; además debía crear, consultar, borrar, purgar, controlar concurrencia y verificar autorización. Solo había una autoridad por segmento en sentido lógico. Podía particionarse físicamente, pero el texto advertía del coste de implementación y administración.

Por eso «muchos servidores» no equivale a «autoridad descentralizada». La multiplicidad protege la superficie de respuesta. La coherencia protege el acto de asignar. Un sistema replicado puede servir una decisión equivocada con una eficacia impecable.

El cable conservaba derecho de réplica

La autoridad no era infalible. El registro podía considerar disponible una dirección que ya estaba en uso. RFC 1931 recomendaba comprobar la red antes de asignarla y citaba ARP e ICMP Echo como técnicas empleadas.

RFC 826 definió ARP para distribuir bajo demanda correspondencias entre direcciones de protocolo y hardware. Una respuesta aporta evidencia local de que alguien reclama esa dirección ahora. No prueba titularidad, autorización ni disponibilidad futura. La ausencia de respuesta tampoco vence de manera definitiva a una partición, una pérdida o un participante silencioso.

El sistema trabajaba así con tres clases de afirmación. El identificador de hardware era un valor presentado en el enlace. La base de autoridad expresaba el enlace que la organización reconocía. La sonda describía una observación situada en tiempo y segmento. Confundirlas convertía un indicio técnico en identidad y un registro administrativo en hecho físico.

El movimiento entre segmentos exigía que sus autoridades fueran la misma o se comunicaran, y que los identificadores de hardware tuvieran alcance suficiente para no repetirse. Ni siquiera entonces el valor identificaba de forma autenticada a una persona.

Los servidores podían escuchar anuncios de sus pares y denunciar a otro aparentemente descoordinado antes de adoptar modo restringido. No había protocolo para que ambos decidieran cuál era espurio. La detección producía una señal; la autoridad o la administración debía gobernar el conflicto.

Un temporizador no certifica una instalación

La asignación temporal tenía que durar mientras se completaban la instalación y la propagación de registros, incluso durante fallos pasajeros. Una hora resultó suficiente en la implementación inicial, dice el memo. No era una ley universal. La caducidad recuperaba capacidad limitada; no demostraba que el nombre, los recursos de arranque o las credenciales ya estuvieran listos.

Los RFC de DHCP muestran otra partición de responsabilidades. RFC 1541 formalizó ofertas múltiples, selección explícita del cliente, identificador del servidor y vida finita del arrendamiento. RFC 2131 refinó el proceso y permitió que un cliente rechazara una dirección cuando su comprobación local detectaba uso. La comparación no establece una cadena causal desde DRARP; muestra cómo dos diseños acotaron oferta, compromiso y conflicto.

En un ámbito aún más local, RFC 3927 permitió seleccionar, sondear, anunciar y a veces defender una dirección IPv4 link-local. No es enrutable ni equivale a una identidad duradera. RFC 5227 generalizó la detección de conflictos IPv4 con sondas y anuncios ARP. La prueba sigue limitada al enlace y al momento observado; las particiones, la simultaneidad y los actores maliciosos permanecen.

El mínimo acuerdo útil

La idea de Running-Code Primacy de Heng Lu ayuda a entender la sonda. La base de datos coordinaba una realidad simbólica; el tráfico que ya circulaba podía contradecirla. El código en ejecución no abolía la decisión administrativa: la sometía a una prueba antes de convertirla en configuración efectiva.

Minimum Initial Specification sugiere mantener pequeño el contrato común. Los servidores han de coincidir, los fallos han de diferenciarse y el estado temporal debe sobrevivir hasta que sus dependencias se estabilicen. El almacén NIS, el RPC, la duración exacta y la política de autorización pueden cambiar localmente.

Desde las capas de realidad, el registro coordina, la respuesta configura y la sonda refuta. Cada capa ejerce poder sin absorber a las demás. Ese es el legado preciso de RFC 1931: la red podía ser redundante donde hablaba, singular donde escribía y escéptica frente a su propia memoria.

Fuentes

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — ficha actual de RFC 1931
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile