Resumen

  • El borrador de GROW permite que src-members nombre el registro IRR de un conjunto referido, pero ordena que esa restricción no se propague a las referencias recursivas del objeto elegido.
  • Mientras convivan lectores nuevos y antiguos, una lista final no demuestra cómo fue obtenida; el control requiere un recibo de procedencia y una comparación exacta de ambos resultados antes del despliegue.

Dos archivos pueden tener ocho mil líneas y superar la misma prueba de formato. Si uno contiene tres prefijos que el otro no, la igualdad del contador es inútil. Si ambos contienen exactamente los mismos prefijos pero proceden de copias y reglas de búsqueda distintas, la igualdad puede durar solo hasta la siguiente actualización.

Ese problema no empieza en el router. Empieza mucho antes, cuando una herramienta expande un nombre RPSL a través de una red de objetos repartidos entre Internet Routing Registries. draft-ietf-grow-rpsl-registry-scoped-members-00 propone una mejora concreta: añadir src-members a los objetos as-set y route-set para escribir tanto la clave como el registro que debe proporcionar el siguiente conjunto.

La notación parece resolver la procedencia. En realidad resuelve una selección inmediata. La diferencia define qué evidencia debe acompañar a una política generada.

El mismo nombre puede existir en varios registros

RPSL permite miembros directos —números de sistema autónomo o prefijos— y referencias a otros conjuntos. Estos últimos pueden volver a referirse a más conjuntos. Los registros IRR son fuentes independientes y no garantizan que una clave primaria sea única en todo el ecosistema. Un servidor con varios registros replicados puede disponer de más de un AS-EXAMPLE.

Según el borrador, una búsqueda ambigua puede escoger un objeto que no era el previsto. El resultado puede introducir política de encaminamiento no intencionada. La búsqueda también puede no encontrar el objeto correcto y omitir rutas legítimas. El documento menciona fugas, secuestros favorecidos y pérdida de conectividad como riesgos de estas clases de error. No presenta un nuevo incidente identificado ni un censo de implementaciones; el artículo no convierte esas posibilidades en hechos desplegados.

Con src-members, una referencia como RIPE::RS-SECOND obliga al lector compatible a hacer coincidir el nombre del registro y la clave. Si el lector no conoce ese registro, no hay coincidencia. El dato desconocido debe quedar visible; sustituirlo por una copia sin ámbito haría desaparecer la elección del autor.

Pero el ámbito no baja por todo el árbol. Cuando el lector abre RS-SECOND en RIPE, examina los atributos de ese objeto. Una referencia descendiente con su propio src-members puede nombrar otro registro. Una referencia antigua en members o mp-members vuelve a depender del algoritmo previo de selección de fuentes. La calificación del padre no gobierna ese salto.

El parámetro de la consulta inicial funciona igual. El software debe permitir restringir la búsqueda de la raíz a un registro, pero no debe extender automáticamente la restricción al resto de la expansión. Pedir RIPE::RS-FIRST no significa pedir «todo desde RIPE».

La transición conserva una sombra sin ámbito

El diseño protege a los consumidores antiguos. members y mp-members continúan porque esos programas no reconocerán src-members. Los objetos tampoco cambiarán a la vez. Algunos permanecerán sin convertir y otros quedarán convertidos solo en parte.

Cuando un objeto autoritativo contiene src-members, el registro debe comprobar que cada referencia aparece también, después de eliminar el prefijo del registro, en los atributos históricos. Si el usuario no envía esos atributos, el software autoritativo debería generarlos. Si el usuario ya los envió, no debe reescribirlos. Un espejo no autoritativo no debe crear la sombra.

La operación inversa está prohibida: no se puede deducir con fiabilidad RIPE::RS-SECOND a partir de RS-SECOND. Precisamente falta la fuente. Una migración responsable debe tratar esa ausencia como información irrecuperable, no como un valor que el sistema pueda adivinar.

Así nace una doble lectura legítima. El programa nuevo sigue la referencia calificada. El antiguo ve la misma clave sin prefijo y aplica su orden local entre registros. El objeto supera la validación porque los nombres coinciden después de quitar el ámbito; los objetos recuperados no tienen por qué coincidir.

La propia validación limita la expresividad moderna para no romper la sombra. No se permiten a la vez RIPE::AS-OTHER y ARIN::AS-OTHER si ambas referencias quedarían reducidas a AS-OTHER en el campo histórico. Aunque las cadenas modernas son diferentes, la representación antigua no puede distinguirlas.

La compatibilidad es gradual por diseño. Por eso el estado «válido en el registro» no prueba «igual para todos los compiladores».

Un recibo para el proceso de expansión

La prueba debe empezar antes de la lista final. El recibo de procedencia de resolución conserva la clave raíz, el registro que restringió la consulta inicial y la identidad exacta del resolutor. Incluye versión, compatibilidad con src-members, lista de registros habilitados y un identificador verificable de cada copia: serie, instantánea o hash de contenido.

Después registra cada salto. ¿Qué objeto padre se leyó? ¿En qué registro? ¿Qué atributo originó el enlace? ¿Qué referencia estaba escrita? ¿La selección de fuente era explícita o dependía del algoritmo local? ¿Qué objeto fue elegido y cuál era su hash? Esa secuencia transforma un resultado opaco en un cálculo reproducible.

Los fallos también forman parte del resultado. Registro desconocido, objeto ausente, nombre ambiguo, ciclo, límite de profundidad o límite de volumen deben quedar asociados al salto exacto. Si la herramienta omite silenciosamente una rama, el resultado puede parecer limpio y seguir siendo incompleto.

Durante la transición, el operador calcula dos vistas: la expansión consciente del nuevo atributo y la expansión que producirán los consumidores históricos que todavía importan. Guarda ambos hashes y la diferencia exacta de miembros. Un resultado idéntico reduce el riesgo inmediato, pero no permite olvidar versiones ni fuentes. Un resultado distinto exige propietario, decisión, plazo y mecanismo de reversión.

El recibo termina enlazando esos datos con la versión del compilador, sus filtros, reglas de normalización, hash de la configuración generada, destino y autorización de cambio. Así evita que una organización demuestre una consulta correcta mientras despliega otro artefacto.

Saber cómo se obtuvo no significa que sea verdadero

La procedencia no convierte cualquier IRR en autoridad sobre el origen de una ruta. No valida relaciones comerciales, no reemplaza RPKI y no demuestra que una intención de política sea prudente. Su función es más limitada: permitir examinar la transformación entre objetos y configuración.

Tampoco obliga a divulgar secretos. Los hashes de objetos y resultados, los identificadores de fuente, las funciones de decisión y las referencias de cambio pueden preservar la cadena sin publicar credenciales ni el contenido íntegro de los filtros.

Si las dos vistas difieren, la respuesta no debe ser un rechazo automático. El ámbito explícito puede estar corrigiendo justamente el error del método antiguo. Sin embargo, si un generador antiguo sigue instalado en una filial o en un proveedor, su lectura puede llegar a la red. La diferencia obliga a identificar consumidores y a elegir un plan, no a suponer una migración terminada.

Los ciclos y las cotas de recursión completan la cuestión. El borrador exige detectar referencias circulares y recomienda limitar profundidad o tamaño para evitar consumo excesivo. Modificar esos límites puede modificar el conjunto final aunque ningún mantenedor toque RPSL. Por eso también son entradas de gobernanza.

El prefijo de registro añade una decisión que antes quedaba implícita. El error sería volver a hacerla invisible al terminar el cálculo. La lista sirve para configurar; el camino sirve para responder por la configuración.

Fuentes

  1. Registro del borrador sobre miembros RPSL con ámbito
  2. Historial del borrador actual
  3. Revisión 00 en HTML
  4. Revisión 00 en texto
  5. XML de la revisión 00
  6. Registro del borrador precursor
  7. Historial del precursor
  8. Revisión 01 del precursor
  9. Mandato de GROW
  10. Documentos de GROW
  11. Anuncio de adopción del grupo
  12. Repositorio de los autores
  13. RFC 2622: Routing Policy Specification Language
  14. RFC 4012: extensiones multiprotocolo de RPSL
  15. RFC 2725: seguridad del sistema de políticas
  16. RFC 2650: uso práctico de RPSL
  17. RFC 7682: consideraciones sobre los IRR
  18. RFC 7909: definición del problema y uso de RPKI
  19. Lu Heng: especificación inicial mínima, decisión futura localizada y adopción voluntaria
  20. Lu Heng: The Policy Mirror