Resumen

  • RFC 1868 respondió a un fallo de Proxy ARP: un equipo remoto podía desconectarse de un servidor de comunicaciones y regresar por otro antes de que los vecinos eliminaran del caché la dirección física del primero.
  • UNARP era una respuesta ARP no solicitada con longitud de dirección de hardware igual a cero. Los receptores compatibles debían borrar la entrada de la IP de origen; los que no conocían la extensión debían rechazar la trama abreviada.
  • El envío del broadcast no certificaba qué pares lo recibieron, qué analizadores lo aceptaron, qué cachés cambiaron, qué asociación se aprendió después ni si volvió a pasar tráfico útil.

El número regresó antes de que caducara su antigua puerta

En una batería de módems, un ordenador remoto se conecta primero mediante CS1. Su dirección IP parece pertenecer a la misma red local que Host A, aunque el equipo se encuentra detrás del servidor de comunicaciones. Cuando Host A pregunta por ARP, CS1 responde en nombre del remoto y entrega su propia dirección de hardware. Host A guarda esa asociación y envía las tramas posteriores a CS1.

El RFC 1027 documentó este uso de Proxy ARP como técnica de compatibilidad. Permitía ocultar subredes y rutas a máquinas que no estaban preparadas para conocerlas. Pero la comodidad convertía una realidad de encaminamiento en una entrada local: una IP que debía alcanzarse a través de una dirección física intermediaria.

Si el usuario cuelga y vuelve a conectarse por CS2 antes de que expire el caché de Host A, la IP conserva su identidad y la puerta cambia. Host A no ve la nueva sesión. Sigue enviando a CS1 porque la entrada antigua no está dañada como dato; ha quedado desfasada como descripción del mundo.

Cada host mantenía su propia versión

El RFC 826 definió ARP para distribuir correspondencias entre direcciones de protocolo y direcciones de hardware. Una solicitud pregunta; una respuesta ofrece información del emisor que el receptor puede incorporar a su tabla y reutilizar.

No existe en ese diseño una transacción central que obligue a todas las estaciones a confirmar la misma versión. La tabla está dentro de cada host. Esa independencia mantiene sencilla la resolución local, pero permite que dos vecinos conserven recuerdos de edades distintas durante una mudanza.

El RFC 1122 exigió por ello algún mecanismo de invalidación. Mencionó el vencimiento temporal, el sondeo unicast, el aviso de la capa de enlace y la información descendente desde una capa superior después de un problema de entrega. Podían combinarse, pero no observaban lo mismo. Que venza un reloj no prueba una reconexión; que falte una respuesta no localiza al usuario; que una capa superior reporte un error no identifica por sí sola el nuevo intermediario.

Una respuesta ARP deliberadamente incompleta

El RFC 1868, publicado como Experimental en noviembre de 1995, no creó una base de datos común ni un protocolo de movilidad. Reutilizó el opcode 2 de ARP Reply. Mantuvo el tipo de protocolo IPv4 y una longitud de dirección de protocolo de cuatro octetos, pero puso en cero la longitud de hardware. La IP del host que partía aparecía como origen y 255.255.255.255 como destino de protocolo. Al desaparecer ambos campos de hardware, quedaban dieciséis octetos antes de la cabecera de enlace.

Un receptor que implementara la extensión debía eliminar la entrada de caché asociada a la IP de origen. El servidor no necesitaba recordar si había respondido antes como Proxy ARP; podía emitir UNARP siempre que se desconectara el remoto. Un host que abandonara ordenadamente una LAN también podía enviarlo por sí mismo.

La decisión comparaba dos costes. Un borrado innecesario forzaba otra consulta. Mantener una dirección obsoleta prolongaba el envío al servidor equivocado. RFC 1868 prefirió provocar nueva incertidumbre antes que conservar una continuidad falsa.

Sin embargo, borrar no era descubrir. Después de aceptar UNARP, Host A aún debía preguntar, escuchar una respuesta nueva, aprender la dirección de CS2 y probar el camino con datos. La ausencia de una asociación antigua no demostraba la presencia de la correcta.

El silencio protegía la compatibilidad y ocultaba el resultado

La longitud cero servía como frontera entre implementaciones. RFC 1868 esperaba que los nodos preparados reconocieran la semántica especial y que una pila antigua rechazara el paquete corto en vez de grabar una dirección de hardware llena de ceros. La convivencia entre ambos tipos de host era parte del diseño.

También recomendó un interruptor de configuración para apagar UNARP si alguna implementación de proveedor reaccionaba mal. La norma permitía, por tanto, una negativa local. Publicar el formato no obligaba al código instalado a interpretarlo ni demostraba que la opción estuviera activa.

Desde el servidor que emitía el broadcast, la falta de respuesta admitía demasiadas explicaciones. Un par pudo recibir y borrar, recibir y descartar, no recibir, tener la función desactivada o carecer de la entrada. El protocolo no recogía una lista de confirmaciones. La expectativa del documento de que la extensión sería ampliamente compatible seguía siendo una previsión, no una medición de despliegue.

Tres anuncios siguieron sin ser tres recibos

El RFC 2176 llevó en 1997 una variante relacionada a IPv4 sobre MAPOS. Allí UNARP tenía un código de operación específico y conservaba direcciones físicas reales. Un nodo que entraba en servicio emitía tres copias separadas por treinta segundos. El receptor borraba una asociación IP solamente cuando la dirección física anunciada difería de la ya almacenada.

Repetir disminuía la probabilidad de que una sola pérdida dejara intacto el estado viejo. Comparar evitaba retirar una asociación que ya señalaba al nodo correcto. Pero la redundancia de emisión no era consenso. El mismo RFC exigía aparte el envejecimiento del caché y la limpieza inmediata cuando se perdía el enlace. Ninguna señal recibió autoridad exclusiva sobre la realidad.

El RFC 3790 clasificó más tarde RFC 1868 como una extensión dependiente de IPv4 para borrar entradas ARP. Eso confirma su función documental; no prueba quién la implantó ni qué resultado obtuvo.

Afirmar la nueva presencia tampoco cerraba el trayecto

El RFC 5227 explicó después que una solicitud ARP contiene una afirmación y una pregunta. Los campos del emisor proponen una asociación; los del objetivo buscan otra. Un Probe pregunta si la dirección está ocupada mientras anuncia la intención de usarla. Un Announcement declara que el emisor ya la usa.

UNARP pronunciaba la frase inversa: deja de usar la asociación anterior. Tanto la declaración positiva como la negativa llegan como entradas a un receptor que conserva autoridad sobre su estado local. Ninguna garantiza que todos los pares estén de acuerdo, que no exista conflicto, que la siguiente trama llegue o que la aplicación alcance su fin.

La lección no exige convertir ARP en un libro mayor central. Exige no inflar los nombres de sus huellas. «Broadcast de salida emitido», «trama vista en este punto», «entrada borrada en este host», «nueva asociación aprendida» y «primer paquete reenviado» son recibos diferentes. Decir «la red olvidó» exige observaciones que una sola transmisión no contiene.

Fuentes y límites

Los RFC 826, 1027 y 1122 sostienen la descripción de ARP, Proxy ARP e invalidación de cachés. RFC 1868 especifica la extensión experimental; RFC 2176 ofrece una variante de enlace posterior; RFC 3790 la clasifica y RFC 5227 precisa la semántica de probes y anuncios. Estas fuentes prueban formatos y conductas prescritas. No prueban adopción actual, compatibilidad universal, conformidad de un producto, un ataque o incidente concreto, ni entrega satisfactoria en una red real.