Resumen

  • La sugerencia ACSP 2026.3 describió un resultado concreto: ante un ROA /16 con maxLength /24, las longitudes de /16 a /24 para el mismo Origin AS se consideraban redundantes, pero las de /25 a /32 podían aportar una autorización nueva.
  • ARIN dio la sugerencia por completada después de cambiar la FAQ; la versión actual dice «any prefix covered», sin conservar el intervalo bloqueado ni el contraejemplo permitido.
  • La solución proporcionada no exige una FAQ extensa: basta un recibo versionado con cinco pruebas, resultados esperados y códigos de motivo iguales en la web, REST y OT&E.

Lo primero es reconocer lo que funcionó

El expediente ACSP 2026.3 se abrió el 13 de enero de 2026. Chris Woodfield no envió una objeción genérica. Citó el ejemplo problemático, relató lo que había observado al probarlo, señaló la diferencia exacta y ofreció una redacción alternativa. ARIN contestó el 18 de febrero que había actualizado la FAQ y cerró la sugerencia como completada.

Ese recorrido es valioso. Un mecanismo de participación sirve cuando transforma experiencia operativa en una respuesta pública dentro de un plazo razonable. Cinco semanas son un buen resultado. También es razonable el objetivo de producto: desde que los ROA alojados se autorrenuevan, mantener un segundo objeto que no añade autoridad dejó de ser una medida necesaria para evitar la caducidad. Reducir duplicados puede hacer más comprensible la lista de autorizaciones y disminuir errores al modificarlas o borrarlas.

No hace falta discutir ninguna de esas decisiones para detectar el problema pendiente. ARIN puede escoger una regla de admisión más estricta que la sintaxis general de los objetos RPKI. Una FAQ puede ser breve. Lo que debe examinarse es si el cierre conserva una prueba pública del significado de la regla corregida.

La propuesta no solo corregía una frase: fijaba una frontera

El texto anterior, tal como aparece en el expediente, tomaba como punto de partida un ROA con prefijo /16 y maxLength /24. Decía que impediría crear otro ROA, con el mismo Origin AS, para cualquier prefijo dentro de ese /16. El autor de la sugerencia explicó que sus pruebas mostraban otra cosa.

Según su relato, una nueva autorización del mismo AS era rechazada si su máscara estaba entre /16 y /24: no otorgaba nada que el ROA existente no hubiera autorizado ya. En cambio, un prefijo entre /25 y /32 seguía estando dentro del espacio de direcciones del /16, pero quedaba fuera de la longitud máxima autorizada. Crear un ROA separado para ese intervalo sí era posible en la prueba descrita.

La redacción sugerida preservaba ambas mitades. Además, proponía hablar de objetos «redundantes» en lugar de «solapados». La diferencia no es estética. Dos prefijos pueden solaparse en el plano de direcciones y, aun así, expresar autorizaciones distintas porque cambia maxLength o el AS de origen. El contraejemplo /25 convierte la explicación en un test de aceptación.

La FAQ actual de RPKI mantiene la idea de que la autorrenovación volvió innecesarios los duplicados y añade que los ROA ya no pueden solaparse. Para el /16 con maxLength /24, afirma que se bloqueará otro ROA del mismo Origin AS con «any prefix covered in the existing ROA». Ya no enumera el intervalo de /16 a /24 y tampoco explica que el de /25 a /32 constituía el lado permitido del caso propuesto.

La comparación prueba una omisión textual, no un fallo operativo. No se accedió a una cuenta de cliente ni se repitió el experimento en producción. El comportamiento de enero fue descrito por quien presentó la sugerencia. Puede que el código actual implemente exactamente la frontera correcta y que «covered in» quiera decir «ya autorizado». Lo que falta es la evidencia pública capaz de excluir otras lecturas.

Cobertura de direcciones y coincidencia de autorización

El RFC 6811 ayuda a ver por qué la palabra importa. En su terminología, una ruta está Covered por un VRP cuando el prefijo del VRP es igual o menos específico y coinciden los bits correspondientes. Para estar Matched, además debe tener una longitud no superior al máximo del VRP y el mismo ASN de origen.

La FAQ no presenta «covered» como un término normativo. Puede ser inglés corriente. Pero para el lector técnico las dos capas están próximas. Un /25 contenido en un /16 está cubierto en el espacio de direcciones; no coincide con un VRP /16 cuyo máximo sea /24. La frase numérica que desapareció era justamente la que impedía mezclar ambas relaciones.

El RFC 6482 define maxLength desde el objeto firmado: es la longitud más específica que el AS puede anunciar; si falta, solo se autoriza el prefijo exacto. El mismo RFC permite que un ROA válido incluya un prefijo englobado por otra entrada e incluso entradas idénticas, aunque desaconseja la que no añade privilegios.

Esto no convierte la política de ARIN en una infracción. La validez criptográfica del objeto, el resultado que un VRP produce al validar una ruta y la decisión del servicio de aceptar una solicitud son controles distintos. ARIN puede limitar su interfaz a un conjunto más limpio. Precisamente por ser una regla de servicio, no una consecuencia inevitable del RFC, conviene publicarla como predicado verificable.

Las interfaces muestran campos, pero no el criterio completo

La guía de ROA de ARIN enumera Origin AS, prefijo y longitud máxima. También afirma que no se admiten duplicados ni solapamientos y remite a la FAQ. No contiene una tabla que diga qué combinación de esos tres valores se acepta.

La guía REST de RPKI documenta una transacción unificada para crear, modificar y eliminar ROA. Esa transacción puede combinarse de forma atómica con operaciones ASPA: o se completa todo o falla todo. El payload expone startAddress, cidrLength y maxLength; la guía remite los errores a un catálogo general. En la captura revisada no aparece la fórmula para decidir redundancia o solapamiento.

La atomicidad abre una pregunta adicional. Si una solicitud elimina el ROA anterior y crea el sustituto, ¿se compara la nueva entrada contra el estado inicial, contra el estado final previsto o contra una secuencia intermedia? La implementación debe resolverlo. Un cliente necesita esa misma semántica para no rechazar localmente algo válido ni enviar una transacción que falle por completo.

El entorno OT&E de ARIN permite experimentar sin afectar a producción. ARIN dice que ofrece el mismo conjunto de funciones, permite crear ROA de prueba y validar payloads de transacciones. También advierte que se alimenta de una instantánea mensual, no está unido a producción, no soporta el correo y no es supervisado activamente por su personal.

Es el lugar apropiado para reproducir una frontera, pero no es por sí solo un contrato. Después de un refresco, cambian los datos de partida; después de una versión, puede cambiar el comportamiento. Si no se guardan valores, versión y resultado esperado, cada prueba vuelve a empezar desde cero.

Un recibo de cinco casos

La respuesta puede ocupar menos espacio que esta explicación. Junto al cierre, ARIN podría publicar un recibo que identifique la revisión de la FAQ, la versión de la regla y su fecha de vigencia. Cada fila incluiría canal, AS existente, prefijo y maxLength, AS y longitud propuestos, resultado esperado y código de motivo estable. La versión de OT&E y la fecha de ejecución completarían la trazabilidad.

Las cinco filas deberían probar: mismo prefijo y mismo AS; prefijo más específico dentro de maxLength; prefijo más específico más allá de maxLength; mismo espacio con otro Origin AS; y una transacción atómica que borra una autorización y crea su reemplazo. Se pueden usar redes de documentación y ASN reservados. No hacen falta datos reales ni claves.

Esta matriz separaría tres hechos. Que una página haya cambiado es un hecho editorial. Que una interfaz acepte o rechace una tupla es un hecho de producto. Que el cierre haya entregado lo pedido es una afirmación de rendición de cuentas. Un enlace versionado permite comprobar los tres sin cargar de tecnicismos la respuesta para principiantes.