Resumen

  • El ejemplo añadido por RFC 2390 mostraba el mismo circuito como DLCI 50 para A y DLCI 70 para B: ambos números eran correctos dentro de sus interfaces.
  • Por esa reescritura, los campos de hardware transportados en InARP llegaban inválidos; el receptor tomaba la dirección Q.922 de la cabecera exterior y la colocaba en el campo de origen.
  • La reparación probaba por dónde entró la trama en el espacio local, no quién era el emisor, qué estaba autorizado a hacer ni si el intercambio había producido un resultado final.

La cifra cambió sin que cambiara el circuito

La historia básica de Inverse ARP ya estaba en RFC 1293: una estación conocía el identificador de un circuito virtual establecido, pero necesitaba conocer la dirección de protocolo del extremo remoto. RFC 2390 no presentó eso como novedad. Al reemplazar el documento anterior en septiembre de 1998, enumeró cambios menores de redacción, un diagrama de paquete, un ejemplo en la sección 7.2 y una sección de seguridad.

El ejemplo fue pequeño, pero hizo visible el problema de los nombres locales. RFC 2427 decía que cada circuito virtual estaba identificado en cada interfaz Frame Relay por un DLCI y que, en la mayoría de los casos, esos identificadores tenían significado estrictamente local.

La estación A, por tanto, usaba DLCI 50 para llegar a B. La red modificaba la cabecera durante el tránsito. B recibía el circuito como DLCI 70. Cincuenta no era un nombre falso y setenta no era una corrección del mismo registro. Eran dos coordenadas para una relación vistas desde fronteras distintas.

El remitente no podía rellenar el dato que pertenecía al receptor

La forma de ARP reserva campos para las direcciones de hardware y de protocolo del origen y del destino. En una red con identificadores globales, el emisor puede escribir su propia dirección de hardware. Con DLCI locales, A no sabe qué número representará el circuito en la interfaz de B.

En la solicitud del ejemplo, A envía por su DLCI 50. El campo ar$sha queda desconocido. El campo de hardware de destino contiene 0x0C21, la codificación Q.922 del DLCI que A conoce. Al llegar a B, la cabecera exterior ya contiene el DLCI 70; con los bits C/R, FECN, BECN y DE a cero, su valor Q.922 es 0x1061.

RFC 2390 dice entonces algo más fuerte que “hay que traducir”: todas las direcciones de hardware dentro del mensaje InARP son inválidas cuando el mensaje llega. La dirección de la cabecera de la trama sí es correcta. El transporte había actualizado el dato de llegada, pero no podía reescribir automáticamente los campos de un protocolo encapsulado.

La interfaz cruzó la frontera de capas de manera controlada

B toma 0x1061 de la cabecera y lo coloca en el campo de hardware de origen. Así, su motor InARP recibe una coordenada que tiene sentido en B. Cuando B responde, su propio campo de origen sale desconocido; A realiza la misma operación y reconstruye 0x0C21 a partir de la trama que recibe.

El RFC admite que la maniobra viola la pureza de la estratificación. También limita con precisión la excepción: la interfaz Frame Relay interviene solo en paquetes entrantes. Esa dirección es lógica. La información necesaria no existe para el emisor antes del tránsito; aparece cuando el receptor observa su etiqueta local.

El campo de hardware de destino no se salva por simetría. También es inválido y InARP no depende de él, de modo que puede llenarse con ceros o ignorarse. La especificación no confunde completar un formato con producir conocimiento. Solo reconstruye el campo respaldado por una observación real.

Una coordenada limpia puede seguir siendo una prueba estrecha

Después de la sustitución, el paquete parece coherente. Esa coherencia no amplía lo que se sabe. La dirección reconstruida significa que una trama entró por una interfaz bajo un valor Q.922 concreto. No demuestra una identidad universal detrás del circuito.

La nueva sección de seguridad de RFC 2390 marca el límite: ARP carece de autenticación, la suplantación de hosts es un problema conocido y el documento no añade mecanismos nuevos. La interfaz puede certificar su propia observación del encabezado. No puede certificar que el interlocutor sea quien dice ser, que la dirección de protocolo anunciada sea legítima o que el interlocutor esté autorizado.

También hay que separar el tiempo. Un DLCI observado ahora no garantiza el estado posterior del circuito. Una respuesta InARP puede alimentar una asociación local, pero esa asociación puede caducar. Un caché no es una prueba de alcanzabilidad continua. La recepción en una interfaz no es entrega a una aplicación. Cada transición necesita su propio recibo.

Los códigos compartidos no controlaban la realidad local

IANA registra el tipo de hardware 15 para Frame Relay y los códigos de operación 8 y 9 para solicitud y respuesta InARP. Esa tabla resuelve una necesidad común: que dos protocolos no utilicen el mismo número con sentidos incompatibles. No convierte los valores de un DLCI en nombres globales ni aprueba una asociación observada.

El diseño distribuye el control. La norma define el mecanismo. El registro protege los códigos. La red decide qué etiqueta aparece en cada borde. La interfaz receptora deriva el campo fuente. El otro extremo decide si responde y qué dirección de protocolo declara. La política local decide si confía operativamente en esa declaración.

Una implementación se equivoca si elimina esas fronteras en cualquiera de las dos direcciones. Si conserva el valor interior, trata una perspectiva remota como si fuera local. Si toma la dirección reconstruida como identidad, convierte una perspectiva local en una verdad universal.

El valor histórico del ejemplo

El diagrama de RFC 2390 separó cuatro cosas que una tabla única habría mezclado: el circuito, el DLCI 50 de A, el DLCI 70 de B y el campo que B reconstruyó después de observar la llegada. La conexión los relacionaba; no los hacía idénticos.

Ese patrón persiste en sistemas modernos aunque Frame Relay ya no ocupe el centro de la conversación. Un identificador de puerto, túnel, sesión o tabla puede ser válido solo dentro de un observador. La arquitectura robusta registra el ámbito, conserva la procedencia y evita que la precisión de una etiqueta se convierta en poder sobre identidad o autorización.

RFC 2390 eligió el mínimo común suficiente. Especificó dónde tomar el dato y qué campo reparar. Dejó las decisiones posteriores en el receptor. Y obligó a reconocer una verdad incómoda: a veces el encabezado exterior conoce mejor la realidad de llegada que el mensaje cuidadosamente estructurado que transporta.

Fuentes