Resumen

  • RFC 1293, publicado en enero de 1992, especifica Inverse Address Resolution Protocol como una ampliación de ARP para solicitar la dirección de protocolo asociada a una dirección de hardware dada. Su ejemplo central es un DLCI de Frame Relay asociado a un PVC establecido cuyo extremo remoto no tiene dirección de protocolo conocida.
  • InARP no transmite la solicitud por difusión: el hardware de destino ya se conoce. El receptor puede contestar con una dirección apropiada o ignorar la solicitud si no puede o no quiere responder; el solicitante puede completar una entrada ARP local, cuya información puede envejecer o invalidarse.

El detalle más expresivo del RFC 1293 es el campo que el solicitante deja en cero. La estación conoce su propia dirección de hardware y de protocolo; conoce también la dirección de hardware del destino, el DLCI que identifica el circuito virtual. Lo que no conoce es la dirección de protocolo del objetivo, y ese campo se rellena con cero en la solicitud InARP. El paquete no disimula la ignorancia: la transporta de modo explícito hasta el único destino al que puede preguntar directamente.

Ese diseño separa estados que una descripción operativa suele amalgamar. El circuito puede haber sido anunciado. El DLCI puede identificar una conexión virtual por la WAN. La solicitud puede llegar al destino de hardware conocido. Nada de ello convierte por sí solo el campo de protocolo vacío en una dirección verdadera. RFC 1293 añade un intercambio para averiguarla bajo condiciones, no una regla que permita tratar el identificador de enlace como si fuese el nombre de la otra estación.

El circuito disponible no resolvía la dirección faltante

La motivación del RFC parte de PVC y, eventualmente, SVC de Frame Relay, identificados por un Data Link Connection Identifier. Mediante señalización, la red puede anunciar una conexión virtual nueva con su DLCI. Pero la dirección de protocolo no forma parte de ese anuncio. La estación receptora aprende que existe la conexión y cómo identificarla a nivel Frame Relay, pero sin configuración nueva o un mecanismo de descubrimiento no puede direccionar al otro lado.

El término “inutilizable” del texto tiene un alcance concreto. Se refiere a la posibilidad de usar el nuevo circuito para dirigirse a la estación opuesta. No prueba que el circuito no exista, que la red esté caída, que el proveedor haya incumplido o que el extremo remoto sea inseguro. Una afirmación sobre la disponibilidad de una manija de enlace y una afirmación sobre el conocimiento de un par de protocolo pertenecen a registros distintos.

La lección es que un identificador puede ser completo en su propia capa e incompleto para la operación siguiente. El DLCI no necesita ser ambiguo para que la dirección de protocolo siga faltando. Llamar “vecino conocido” a la combinación antes de recibir una respuesta elimina de la historia el hecho que motivó InARP: aún no se sabe a quién se puede direccionar mediante ese circuito.

Invertir la consulta no hizo equivalentes todos los protocolos inversos

InARP solicita una dirección de protocolo a partir de una dirección de hardware. Conserva el formato de ARP y define 8 para la petición InARP y 9 para la respuesta. La cercanía con Reverse ARP pudo sugerir un atajo, pero el RFC explica por qué RARP no resolvía esta necesidad: su respuesta entrega la dirección de protocolo de la estación solicitante, no la de la estación que recibe la petición y que el solicitante desea aprender.

La dirección de una respuesta importa tanto como el nombre del mecanismo. Preguntar “cuál es mi dirección” y preguntar “qué dirección corresponde a este destino de hardware ya conocido” son operaciones diferentes aunque ambas parezcan invertir algo. RFC 1293 también descarta mecanismos específicos de IP porque busca resolución de direcciones de varios protocolos. No erige un registro de propiedad IP ni un oráculo general de rutas; delimita una correspondencia solicitada para un contexto de red.

Por eso, la ampliación de ARP no debe leerse como autorización para sintetizar una identidad. El solicitante no conoce el dato y lo declara con el campo objetivo en cero. La respuesta depende de la estación que recibe el mensaje y de su configuración. La inversión describe el orden de la información que falta, no una garantía de simetría ni de resultado.

La entrega directa no volvía cierta la respuesta

ARP convencional difunde porque no conoce la dirección de hardware del destino. InARP no lo hace: esa dirección ya es conocida. La estación solicitante coloca sus direcciones fuente de hardware y protocolo, la dirección de hardware objetivo conocida y el campo de dirección de protocolo objetivo a cero; luego encapsula el paquete para la red concreta y lo manda directamente al objetivo.

La ausencia de difusión reduce el alcance de la pregunta. También puede evitar el coste de simular una difusión con copias múltiples y resultar más flexible que depender de configuración estática, como señala el RFC. Pero una pregunta estrechamente dirigida sigue siendo una pregunta. No demuestra que el otro extremo implemente InARP, tenga una dirección adecuada, esté dispuesto a contestar o vaya a conservar la misma relación después de la respuesta.

La forma correcta de registrar el evento no es “el circuito quedó resuelto”, sino “esta estación envió esta consulta para esta dirección objetivo de hardware”. Si llega una respuesta, se agrega otro hecho. Si no llega, el RFC sólo permite conservar el silencio. Atribuirlo a un fallo, a una política concreta o a una identidad inexistente requeriría observaciones ajenas al texto.

El receptor podía responder o guardar silencio

Al recibir una solicitud InARP, una estación puede introducir en su propia caché ARP el mapeo dirección de protocolo/dirección de hardware del solicitante. Puede formar una respuesta usando como destinos las direcciones fuente de la solicitud. Si no puede o no quiere responder, la ignora. No hay en la especificación una respuesta afirmativa sustituta para cubrir esa ausencia.

El silencio es significativo porque conserva un límite de control. La red puede haber anunciado el circuito y el solicitante puede haber alcanzado el destino de hardware; la estación remota todavía decide si entrega una respuesta apropiada. Un registro de solicitud enviada no es un registro de mapeo recibido. Un registro de mapeo recibido no es un registro de autorización, seguridad o tráfico de aplicación.

Cuando llega una respuesta, el solicitante puede completar la entrada ARP y usar la información proporcionada. Esa frase crea un hecho local, no una identidad atemporal. RFC 1293 advierte que la información aprendida mediante InARP puede envejecer o invalidarse en determinadas circunstancias. La entrada describe lo que la estación eligió conservar tras una respuesta, no lo que el mundo seguirá garantizando.

Las direcciones múltiples obligaban a responder según la relación

Un host con varias direcciones de protocolo en una misma interfaz no puede devolver una cualquiera. Debe mirar primero la dirección de protocolo del solicitante y devolver una dirección que corresponda a la red del solicitante. En el caso IP, si el respondedor no tiene una dirección de esa interfaz en la subred solicitada, no debería responder.

La respuesta adecuada no es una propiedad aislada del host remoto. Depende de quién pregunta y de qué red expresa la petición. Un host multi-direccionado puede enviar una solicitud por cada dirección definida para la interfaz; el lado receptor puede contestar algunas o ninguna según su configuración. “El otro extremo tiene direcciones” sigue siendo insuficiente para escribir una entrada concreta.

Esta condición protege contra otro relleno imaginario del campo cero. La caché necesita una dirección adecuada a la relación que se consulta, no una lista de valores posibles. Un resultado correcto en una subred no es evidencia de que otra petición, otra dirección fuente o otra configuración recibirá el mismo resultado.

La caché retiene información; no confiere autoridad duradera

El envejecimiento y la invalidación impiden que un mapeo aprendido se convierta silenciosamente en una identidad permanente. Una caché es una política local de retención. Debe conservar su procedencia: qué DLCI o destino de hardware estaba en la solicitud, qué dirección de protocolo respondió, cuándo sucedió, bajo qué configuración y cuándo se retiró o invalidó la entrada.

Después de ese punto aún hay preguntas no respondidas por el RFC. Puede existir o no una ruta adecuada; puede aceptarse o no el tráfico; una operación puede tener éxito o fracasar por causas posteriores. El protocolo de resolución no contiene un registro de entrega de datos. Tampoco contiene una conclusión de seguridad: su sección de consideraciones de seguridad declara que dichas cuestiones no se abordan.

La disciplina de no ampliar la caché al resultado final hace que InARP sea más útil, no menos. Permite saber exactamente qué redujo la incertidumbre: se aprendió una dirección de protocolo asociada a un destino de hardware por medio de una respuesta. No obliga a fingir que también se aprendió estabilidad, autorización, protección o utilidad de servicio.

Fuente y límites de la evidencia

Este artículo utiliza RFC 1293 — Inverse Address Resolution Protocol. La fuente respalda su condición de estándar y fecha de enero de 1992, el problema DLCI/PVC, la dirección remota de protocolo que falta, el rechazo de RARP y mecanismos sólo IP, los códigos y formato InARP, la petición directa sin difusión, la respuesta condicional o el silencio, la caché, el envejecimiento o invalidación, la selección para hosts multi-direccionados y la afirmación de que no aborda la seguridad.

No respalda que un circuito Frame Relay concreto exista hoy, que un par esté configurado o sea alcanzable, que una respuesta sea correcta, autorizada o segura, que una entrada persista, que haya ruta IP o entrega de paquete, ni que una organización o usuario haya obtenido un resultado. La lectura editorial de que un DLCI conocido no era todavía un veredicto sobre un vecino utilizable no sustituye esas pruebas.