Resumen

  • RFC 826 empezó donde terminaba la decisión de ruta: elegida una dirección de protocolo inmediata, todavía faltaba la dirección física necesaria para emitir una trama en la red local.
  • La petición difundida preguntaba por el destino y, al mismo tiempo, enseñaba a los vecinos cómo contestar al solicitante. Una caché local convertía esa observación en acción repetible.
  • Las reglas posteriores sobre caducidad, Proxy ARP y conflictos mostraron que la correspondencia no era identidad. Un gateway podía contestar por otro equipo y un arrendamiento DHCP podía fracasar ante la realidad del enlace.

El destino que la ruta no podía escribir

Cuando IP consulta la tabla de rutas, puede concluir que el destino está conectado directamente o que hay que entregar el paquete a un router. En ambos casos escoge una interfaz y una dirección IP inmediata. La tarjeta Ethernet necesita otra cosa: una dirección de hardware para el campo de destino de la trama.

RFC 826, publicado por David C. Plummer en noviembre de 1982, resolvió esa discontinuidad. El módulo de Address Resolution buscaba en una tabla el par formado por tipo de protocolo y dirección objetivo. Si existía, devolvía los 48 bits de Ethernet. Si faltaba, preguntaba en el segmento ya elegido por el enrutamiento.

El mensaje conservaba separados ambos mundos. Incluía tipo de hardware, tipo de protocolo, longitud de las direcciones, operación y direcciones de emisor y objetivo en cada espacio. Así podía generalizarse más allá de IPv4 y del Ethernet original. No calculaba una dirección a partir de otra: recogía una correspondencia dinámica.

Esa posición en la arquitectura importa. Para un servidor remoto, el paquete IP nombra al servidor, mientras la trama local suele nombrar al router. ARP no descubre la ruta completa ni la propiedad del destino final. Hace ejecutable un solo salto ya decidido.

Una pregunta para todo el vecindario

Al no hallar la entrada, el host anuncia su dirección física y de protocolo, indica la dirección de protocolo buscada y difunde la petición. Todas las estaciones del dominio de broadcast pueden oírla. La que se reconoce como objetivo responde directamente al solicitante.

La difusión resuelve el desconocimiento inicial; la respuesta unicast evita repetirlo. RFC 826 prefirió este intercambio bajo demanda a anuncios periódicos de tablas completas. Una LAN no debía pagar cada pocos segundos por correspondencias que casi ningún par utilizaría.

El diseño inicial podía descartar el paquete que provocó la búsqueda y confiar en la retransmisión superior. En 1989, RFC 1122 aconsejó guardar al menos el último paquete pendiente por destino. El detalle mejora el inicio de una comunicación, pero la cola sólo espera una decisión: no certifica el dato que llegará.

También era necesario limitar la pregunta. RFC 1122 exigió protección contra una lluvia de solicitudes y recomendó como máximo una por segundo para cada dirección. Un silencio puede deberse a ausencia, pérdida, separación del enlace o una máquina dormida. Aumentar indefinidamente el volumen no aclara cuál.

Aprender antes de distinguir pregunta y respuesta

El algoritmo receptor de RFC 826 actualizaba primero la correspondencia del emisor. Si ya conocía su dirección de protocolo, sustituía la dirección física por la observada. Si la máquina era el objetivo y no tenía la entrada, la creaba. Sólo después miraba el opcode para decidir si debía responder.

La petición tenía por ello una doble dirección informativa. Pedía una ruta local hacia el objetivo, pero entregaba una ruta de vuelta hacia quien preguntaba. El destinatario podía aprender antes de hablar. Incluso un monitor pasivo podía registrar actividad de protocolos superiores con sólo comprender el formato ARP.

La sustitución rápida ayudaba tras cambios de interfaz o movimiento. Al mismo tiempo, dejaba claro que la tabla aceptaba afirmaciones no autenticadas. Lo más reciente no es necesariamente lo legítimo. ARP ofrece evidencia local suficiente para operar, no una prueba criptográfica ni jurídica.

RFC 826 planteó envejecimiento y timeouts sin fijarlos. RFC 1122 convirtió la eliminación de datos obsoletos en obligación y pidió configurar el timeout cuando se usara. Describió también sondeo unicast y avisos de capas inferiores o superiores. La variedad de métodos conserva una idea: la velocidad del caché sólo es sostenible si existe una manera de revocar su pasado.

Cuando contestó el intermediario

RFC 1027, de octubre de 1987, documentó Proxy ARP para una transición muy concreta. La red de la Universidad de Texas necesitaba dividirse en subredes, pero varios sistemas operativos de fabricantes distintos no entendían todavía esas subredes.

Si A preguntaba por B y un gateway sabía que B estaba en otra red física, el gateway respondía con su propia dirección de hardware. A guardaba esa dirección y enviaba allí las tramas que contenían paquetes IP para B. En la otra red podía suceder lo mismo para el retorno.

La técnica evitaba modificar todos los hosts. Su transparencia era la ventaja y también la deuda: el endpoint ignoraba el límite que dependía del gateway. La respuesta significaba «puedo encaminar hacia B», no «soy B».

Si varios gateways respondían, la llegada más rápida podía decidir la entrada. Si la ruta del proxy era errónea, la resolución local parecía exitosa aunque el paquete no llegara. La validez de la respuesta dependía de estado externo al mensaje ARP.

Una asignación que aún no podía usarse

La aparición de DHCP no convirtió la base del servidor en una descripción perfecta del cable. RFC 2131, de marzo de 1997, recomienda que el servidor pruebe direcciones reutilizadas y que el cliente compruebe el valor recibido antes de utilizarlo.

El cliente envía una petición ARP con su hardware, la dirección candidata como objetivo y cero como IP de emisor. Pregunta sin contaminar cachés ajenas con una identidad que todavía no ha aceptado. Si detecta un uso previo, debe emitir DHCPDECLINE y reiniciar. Si no, anuncia la nueva correspondencia para desplazar restos del ocupante anterior.

El arrendamiento y la observación no compiten. El primero coordina un inventario y un tiempo de uso. La segunda examina el lugar donde la asignación va a producir tramas. Una decisión administrativa correcta puede encontrar una colisión operativa.

De la consulta a la vigilancia continua

En 2005, RFC 3927 formalizó sondas y anuncios para direcciones IPv4 link-local. El host espera un intervalo aleatorio, envía probes con IP de emisor cero y sólo anuncia la dirección si no aparece conflicto. Contadores y límites frenan la tormenta que produciría un nodo que contestara a todas las candidatas.

La vigilancia sigue mientras la dirección esté activa. Dos LAN separadas pueden elegir el mismo valor y chocar al unirse más tarde. El éxito del arranque no tiene autoridad sobre una topología futura.

RFC 5227, publicado en 2008, extendió el procedimiento a la detección general de conflictos IPv4. Una sonda pregunta si alguien usa la dirección y declara de manera débil la intención de usarla. Un anuncio afirma el uso actual.

Ante una contradicción, un host puede retirarse o defender una vez. Si vuelve a ver conflicto dentro de DEFEND_INTERVAL, normalmente debe dejar la dirección y avisar al agente de configuración. Así dos máquinas no se enzarzan en una defensa infinita. Equipos esenciales pueden configurarse para resistir, pero deben registrar y limitar sus anuncios.

El procedimiento encuentra accidentes; no autentica derechos. Un atacante puede fabricar conflictos y expulsar un servicio. Una ausencia de respuestas tampoco demuestra que nadie aparecerá después. Es una prueba temporal, local y revisable.

La coordinación de códigos no era autoridad de identidad

Las implementaciones necesitan interpretar de igual manera tipos de hardware y opcodes. RFC 5494, de 2009, estableció reglas de IANA para asignar esos números y reservó algunos para experimentación.

Administrar esa gramática no concede control sobre las direcciones expresadas dentro de cada mensaje. IANA puede coordinar qué significa un código sin decidir qué equipo usa una IP en una LAN. La interoperabilidad común y la autoridad sobre una identidad concreta pertenecen a planos distintos.

La memoria que conserva su salida

ARP escaló porque no intentó producir una verdad total. Preguntó sólo en el ámbito donde la siguiente trama debía circular, sólo cuando faltaba un dato y sólo guardó el resultado en quien lo necesitaba. La arquitectura ganó simplicidad al aceptar conocimientos parciales.

Esa parcialidad exige capacidad de corrección. Un proxy puede ocultar un punto único de fallo, un atacante puede hablar primero y una entrada estática puede sobrevivir a su contexto. El caché es útil porque olvida, no a pesar de olvidar.

El cable actúa como testigo, no como soberano. El host decide si admite la afirmación, cuándo la vuelve a probar y qué hace ante el conflicto. La responsabilidad acompaña a quien convierte el dato en una trama.

Fuentes y límites de la evidencia

RFC 826 define el intercambio y el aprendizaje; RFC 1027 muestra respuestas delegadas; RFC 1122 exige invalidación y control de solicitudes. RFC 2131 separa asignación DHCP y comprobación local. RFC 3927 y RFC 5227 aportan sondeo, anuncio y defensa acotada. RFC 5494 coordina los números del protocolo.

Los RFC establecen diseños y requisitos, no fechas universales de despliegue. Una captura prueba que un mensaje apareció en un enlace y momento concretos. No demuestra por sí sola identidad autenticada, propiedad, intención o entrega detrás de un proxy.