Resumen

  • RAP separaba cinco operaciones: filtro receptor, actualización de métricas y opciones, agregación, selección de rutas activas y filtro transmisor para cada par.
  • Una ruta podía quedar en la base candidata sin llegar al reenvío, usarse sin propagarse o anunciarse de forma distinta a cada vecino; el mensaje de control no demostraba el resultado de los paquetes.

El dibujo que impedía saltarse pasos

En RFC 1476, las rutas recibidas de pares no viajaban directamente a la base de reenvío IP. Primero pasaban por un filtro de proximidad y por la agregación. El proceso RAP reunía después una base interna. De ella escogía rutas activas y solo entonces aplicaba filtros de salida para producir los anuncios dirigidos a otros pares.

También entraban rutas estáticas, de interfaces y de protocolos como RIP. Esa pluralidad no daba a ninguna fuente prioridad automática. El estado recibido, el candidato conservado, la ruta activa y el anuncio exportado eran capas distintas.

RAP apareció en junio de 1993 como protocolo Experimental. Aspiraba a usar un modelo de vector distancia desde LAN pequeñas hasta redes de grandes operadores, sin una división fija entre interior y exterior salvo la que introdujera la política. El registro del RFC Editor confirma el documento y su condición histórica. No confirma una instalación, una elección de ruta ni una entrega.

Decisión uno: admitir o borrar la oferta

El filtro receptor podía rechazar rutas demasiado lejanas o demasiado específicas. Un equipo con recursos limitados podía estrechar el umbral. Si después lo abría, surgía un problema temporal: una ruta ya descartada tal vez no volviera a ser anunciada. La política nueva no resucitaba el dato antiguo.

Esta observación convierte la recepción en un hecho con fecha. Para afirmar que una ruta existe tras cambiar el filtro hace falta un nuevo anuncio, un registro anterior al filtro o una función de actualización. La intención de aceptar no sustituye a la evidencia de haber recibido.

Decisión dos: transformar sin fingir comprensión

RAP modificaba métricas al recorrer el camino. Sumaba demora y coste, incrementaba distancia y conservaba el mínimo de MTU y ancho de banda. Además, cada opción llevaba clase, formato y tipo. El diseño solo exigía que todos entendieran la distancia del encabezado; el resto podía ser desconocido.

La clase fijaba la respuesta ante esa ignorancia. Con clase 0 se podía usar y propagar la ruta, pero la opción debía viajar intacta. Con clase 1 se usaba y propagaba la ruta sin reenviar la opción. Con clase 2 se usaba localmente y se detenía su propagación. Con clase 3 se descartaba la ruta completa.

Nada de ello autenticaba el atributo. La clase no certificaba quién lo creó ni si su contenido era verdadero. Tipo y clase eran ortogonales, de modo que dos implementaciones podían asignar consecuencias distintas al mismo tipo. El formato ayudaba a imprimir un valor desconocido para diagnóstico, pero poder leer bytes no era comprender la política.

RFC 1476 negaba incluso una interpretación cómoda de privacidad: borrar una opción de clase 1 no ocultaba necesariamente su contenido en el trayecto previo. Este artículo no repite los bits de acción de opciones IPv6 ni el atributo Partial de BGP. En RAP, las clases sirven para mostrar cómo la extensión alteraba toda la cadena local.

Tres advertencias que no eran intercambiables

Source Restriction declaraba qué fuentes podían usar una ruta. Si la capa de reenvío tenía filtros de seguridad, RAP debía reflejarlos para que el tráfico no eligiera un camino atractivo que terminara en descarte silencioso. Pero propagar ese dato podía revelar información confidencial sobre la configuración. El RFC confiaba en limitar con cuidado su distribución; no ofrecía una prueba de que tal límite se respetara.

AUP era otra cosa. Marcaba que una red solo era utilizable conforme a una política de uso aceptable. El propio texto aclaraba que cooperar con esa señal no creaba una barrera de seguridad. Public añadía una tercera dimensión: parte del recorrido usaba un medio de difusión observable por receptores ajenos al destino. Una restricción de origen, una regla de finalidad y un aviso de exposición física alimentaban decisiones distintas.

Decisión tres: resumir o conservar el detalle

RAP podía incluir rutas específicas dentro de una más amplia cuando compartían par y cumplían condiciones de distancia. Pero no ordenaba agregar siempre. Los atributos de política podían impedir el resumen o hacer que una candidata se eliminara.

RFC 1338 describe el contexto de supernetting y presión de escala de aquellos años. RFC 1476 planteaba además el coste informativo local: el resumen ahorraba recursos, pero podía quitar al siguiente par detalles necesarios para su propia política. El receptor del agregado no veía automáticamente sus contribuyentes.

Decisión cuatro: entrar en la tabla que mueve paquetes

Después de agregar, RAP combinaba candidatos con rutas procedentes de otros protocolos y elegía cuáles cargar en la base de reenvío. La selección podía usar cualquier mezcla de atributos y política local.

Aquí aparece la frontera que un listado de control no puede cruzar por sí solo. Una ruta en la base RAP no demuestra una entrada en la FIB. Una entrada en la FIB tampoco demuestra que un paquete concreto coincidiera con ella, saliera por la interfaz prevista o llegara al destino.

RFC 1058 servía de referencia para el vector distancia de RIP y RFC 1247 para OSPF. RAP quería convivir con esas fuentes. No convertía la convivencia en una regla automática de preferencia.

Decisión cinco: mostrar una vista diferente a cada par

El filtro transmisor solo podía ofrecer un subconjunto de las rutas activas y podía escoger uno diferente por vecino. Una ruta instalada localmente podía no aparecer ante un par. Otra podía salir sin una opción de clase 1. Otra quedaba confinada por clase 2.

El RFC exigía que los filtros de datagramas estuvieran representados en la oferta, con el fin de no atraer tráfico a un agujero negro. Esa obligación era parte de la especificación. Para demostrar que se cumplió en una red real harían falta el filtro efectivo, el anuncio exacto, la decisión del vecino y la observación de paquetes.

La conexión TCP tampoco era el proceso

Los pares RAP usaban una conexión TCP simétrica en el puerto 38 y no confirmaban individualmente cada comando. Poll y No Operation proporcionaban una comprobación en la propia capa RAP. El texto desaconsejaba depender solo de keepalive TCP: TCP podía seguir aceptando datos mientras el proceso RAP remoto ya no respondía.

Al romperse la conexión, cada extremo debía purgar todas las rutas ofrecidas por el otro. Es la norma del protocolo, no un recibo de ejecución. La recuperación de bucles también estaba acotada: el mecanismo de último recurso prometía corrección eventual, no rápida, y un error que reapareciera podía recrear el bucle.

La propuesta y la evidencia disponible

El documento compañero RFC 1475 y su registro sitúan RAP dentro de TP/IX. El artículo anterior ya posee el identificador privado de siguiente salto y la cronología Add/Purge. Esta investigación no los vuelve a contar: se concentra en las decisiones que separaban el anuncio de su destino local y exterior.

RFC 2026 permite leer correctamente las categorías del proceso de estándares. Experimental seguía siendo un estado documental, no una medición de adopción.

La lección coincide con los ensayos de Heng Lu sobre la primacía del código operativo, la especificación mínima y la decisión futura localizada y las capas de realidad. Una oferta puede activar una decisión. No puede hacerse pasar por aceptación, instalación, exportación o resultado.

Fuentes