Resumen

  • La RFC 1475 situaba en cada datagrama un identificador de 64 bits cuyo significado pertenecía al router que lo había emitido para su vecino inmediato.
  • Un agregado, un cambio de ruta, una conversión de protocolo o un valor inválido obligaban a tomar otra decisión; la continuidad del número no demostraba continuidad del trayecto.
  • Su publicación experimental, la evolución hacia CATNIP y el posterior estado Historic documentan la vida de una propuesta, no prueban que una red concreta la desplegara.

El punto donde el agregado se abre

Supongamos que una tabla contiene una entrada amplia para una región de direcciones. Mientras todos los destinos cubiertos salen por el mismo sitio, un atajo asociado a esa entrada puede ahorrar trabajo. Pero llega un router donde dos componentes del agregado se separan. Allí ya no basta saber «pertenece a este bloque». La máquina debe inspeccionar el destino exacto, elegir la rama y escribir el identificador que el próximo router le había proporcionado.

La RFC 1475, publicada en junio de 1993, hizo explícita esa frontera. TP/IX —también llamado Internet Protocol version 7— proponía direcciones más largas, cambios de transporte y un campo de 64 bits denominado forward route identifier. El campo podía acelerar el reenvío, pero no eliminaba el momento de decisión. Cuando el conocimiento prestado era demasiado general, el router recuperaba la autoridad local.

Por eso el nombre puede inducir a error. «Identificador de ruta» parece el nombre de una ruta ya resuelta y contenida en el paquete. El mecanismo era otro: una referencia privada, quizá un índice de tabla o incluso una dirección de memoria, que un router entregaba a un vecino para que este se la devolviera con el tráfico. Fuera de la máquina emisora, la referencia era opaca.

A, B y C no compartían un diccionario

El ejemplo de la especificación coloca los routers A, B y C entre los hosts X e Y. C anuncia a B una ruta hacia Y e incluye una referencia interna de C. B no necesita descifrarla: conserva el valor como un objeto opaco. Luego B construye su propia ruta a través de C y anuncia a A otra referencia, válida dentro de B.

X origina el datagrama con cero en el campo. A realiza una búsqueda normal por dirección de destino, escoge B, coloca la referencia de B y envía. B reconoce su propia clave, encuentra la ruta que conduce a C, reemplaza el valor por la referencia de C y reenvía. C consume la clave que él mismo creó, borra el campo antes del último tramo y entrega a Y. El destino identifica su propia dirección y no necesita interpretar el supuesto identificador de ruta.

La misma posición binaria tuvo tres regímenes de autoridad. Antes de A, cero pedía una decisión. Entre A y B, el valor pertenecía a B. Entre B y C, pertenecía a C. Al final, podía ignorarse. Ni A conocía el objeto interno de B ni B conocía el de C. La interoperabilidad residía en devolver la cifra, no en compartir su significado.

Una captura de paquetes conservaría los bits pero no sus diccionarios. Dos routers podrían reutilizar el mismo número para objetos distintos; dos números diferentes podrían conducir al mismo enlace. Para reconstruir la decisión harían falta el emisor, la generación de la tabla, el destino comprobado, el instante, el resultado de validación y la interfaz de salida.

Un valor inválido no cerraba el camino

La RFC exigía cautela precisamente porque una referencia podía parecerse a una dirección de memoria. El router debía validar el rango y la alineación y probablemente comprobar que la ruta referida correspondía al destino del datagrama. Si el identificador no era válido, debía ignorarlo en silencio y hacer la búsqueda ordinaria que habría hecho ante un cero.

Así, el atajo afectaba al coste de decidir, no a la fuente última de corrección. El destino y el estado local seguían mandando. Un acierto de la clave tampoco bastaba como prueba de entrega: solo demostraba, como máximo, que una referencia fue aceptada en un instante. Faltaban la selección de salida, la recepción siguiente y el resultado final.

El cero tampoco significaba «no hay ruta». Era un estado normal en el origen, después de ciertas conversiones o cuando no existía una referencia aprovechable. Confundir la ausencia de atajo con la ausencia de conectividad transformaría una señal de rendimiento en un veredicto operativo.

La ruta podía cambiar con el paquete en vuelo

El problema se hacía más visible durante la convergencia. Si la tabla cambiaba mientras viajaban datagramas, algún router debía decidir cómo «volver a poner cada datagrama sobre los raíles». La expresión de la RFC revela el alcance real del campo: el paquete no llevaba un contrato inmutable. Llegaba a una estación cuya topología y estado podían haber cambiado desde que se emitió la clave.

En el punto de agregación, el identificador podía resolver solo la entrada general. En el punto de cambio, podía referirse a una versión caducada del estado. En ambos casos, el router tenía que decidir de nuevo. La proximidad entre datos y estado no convertía una secuencia distribuida de decisiones en un hecho extremo a extremo.

TP/IX también permitía que un identificador de flujo sustituyera al de ruta. Cada router podía mantener un objeto privado de flujo que apuntaba a la ruta elegida. La distinción entre ambos tipos seguía siendo privada. Para el emisor del paquete, un valor no nulo no demostraba que existiera una reserva de recursos, ni capacidad, ni una calidad de servicio cumplida.

RAP añadía una afirmación con fecha de caducidad

La compañera RFC 1476 describía RAP, el protocolo de acceso a rutas. Su comando Add Route debía anunciar una ruta que estuviera cargada realmente en la base de reenvío del emisor en ese momento. El receptor usaría el identificador ofrecido en los paquetes enviados hacia el anunciante.

Era una afirmación más concreta que una promesa abstracta, pero seguía ligada a un instante. RAP disponía de Purge Route para borrar la ruta y revocarla ante los pares a los que se había propagado. La especificación prefería enviar la purga antes de eliminar localmente la entrada, aunque admitía que ese orden no podía imponerse.

Entre la eliminación, el envío de la purga, su propagación y los paquetes ya en vuelo quedaba una ventana. Una clave auténtica podía referirse fielmente a un anuncio anterior y no servir ya para el estado presente. La ficha del RFC 1476 conserva el estado documental; no rellena esa ventana operacional.

Convertir significaba cortar la continuidad

TP/IX aspiraba a que sistemas IPv4 e IPv7 se actualizaran en cualquier orden. Los conversores revelaban otra frontera de custodia. La opción «Don't Convert» regulaba lo que un router podía hacer en el cable, pero un host aún podía transformar internamente el datagrama. Los fragmentos que siguieran caminos distintos y llegaran a conversores diferentes podían perderse. Poseer una dirección híbrida tampoco probaba que la implementación fuera IPv7 nativa.

En la conversión de IPv4 a IPv7, el identificador de ruta hacia delante se ponía a cero. El conversor no fingía que una referencia privada sobrevivía al cambio de arquitectura. Borraba el atajo y obligaba al siguiente dominio a resolver su propia decisión. Dirección, versión, conversión, fragmentos e identificador eran hechos relacionados, no uno solo.

Un expediente histórico, no una captura de producción

El registro del RFC Editor clasifica hoy la RFC 1475 como Historic. La RFC 1752 narró cómo TP/IX pasó a CATNIP, consideró que CATNIP estaba demasiado incompleto para ser elegido y recomendó SIPP de 128 bits como base de IPng. Más tarde, la RFC 6814 dejó obsoleta formalmente la RFC 1475 al retirar opciones antiguas de IPv4. La RFC 791 seguía siendo el punto de referencia de IPv4.

Esa cadena permite afirmar qué se propuso, cómo se evaluó y qué estado normativo recibió. No permite afirmar que toda red rechazó cada idea, que nunca hubo prototipos o que un paquete específico recorrió cierta ruta. Tampoco el rótulo «Next Internet» de 1993 probaba despliegue. La documentación ocupaba una capa; el código ejecutado, el estado de los routers y la observación de tráfico ocupaban otras.

La RFC indicaba además que no trataba cuestiones de seguridad. Validar rango, alineación y destino no convertía la clave en una credencial autenticada. No hay base para inferir autorización, integridad o resistencia frente a entradas maliciosas.

Fuentes