Resumen

  • El README de Barry presenta ::/0 como recurso IPv6 predeterminado de una ancla de confianza, pero la incidencia 7 informa que esa grafía falla en campos de certificado y ROA.
  • El código fijado permite dos puntos y barra dentro de un token, pero una cadena sin comillas solo puede empezar por un carácter alfanumérico, $ o . Por eso 0::/0 avanza y ::/0 se detiene antes del parser IP.
  • RFC 4291 admite ::/0 y RFC 5952 lo convierte en la representación canónica. 0::/0 tiene el mismo valor semántico, aunque no es la salida de compresión máxima.
  • No hay prueba de un objeto RPKI defectuoso, un resultado de relying party ni impacto en producción o enrutamiento. La respuesta proporcionada es una tabla de conformidad entre lexer y DER con etapas inequívocas.

El cero que solo abre una puerta

La diferencia cabe en un carácter:

::/0
0::/0

Para IPv6, ambas cadenas expresan la dirección de 128 bits en cero con longitud de prefijo cero. No cambia el conjunto de direcciones. Según la incidencia 7 de LACNIC/barry, sí cambia el recorrido por el programa: la primera grafía provoca un carácter inesperado y la segunda funciona como solución provisional.

Ese límite es particularmente relevante en una herramienta que genera material RPKI, incluso material deliberadamente incorrecto para probar validadores. Un ensayo negativo solo empieza después de que una entrada positiva y legítima se haya convertido en un valor y después en bytes identificables. Si el lenguaje fuente se niega a reconocer la forma canónica, el fallo aún no pertenece al certificado, al ROA ni al relying party. El objeto no nació.

La lectura institucional más sólida es contenida. Los metadatos del repositorio describen un generador pequeño. El README fijado al commit examinado califica tanto el proyecto como la especificación de Repository Descriptor como trabajo en curso y avisa de posibles cambios incompatibles antes de 1.0. Las listas capturadas de releases y tags están vacías. La transparencia de una incidencia abierta es una virtud de esa fase, no una señal de daño operativo.

La reproducción y la traza no son los mismos bytes

La incidencia se abrió el 28 de agosto de 2026. En el corte de evidencia del 6 de septiembre seguía abierta, sin etiquetas, comentarios ni nuevas ediciones. GitHub asigna al informante la relación NONE; no aparece una confirmación, diagnóstico o corrección de un mantenedor.

El informe escribe ::/0 en dos lugares: la extensión de recursos IP de un certificado de CA y ipAddrBlocks en un ROA. Propone 0::/0 como alternativa temporal. Pero hay que conservar una diferencia dentro de la propia prueba. El descriptor mostrado usa la forma canónica en ambos campos; la traza pegada imprime primero un valor ya modificado como 0::/0 y más adelante se detiene en el primer : del otro campo con Unexpected character: : (0x3a).

La conclusión correcta no es descartar la incidencia. Es limitarla. La traza muestra directamente un fallo ante un dos puntos inicial. El texto del informante afirma que ocurre en los dos campos. El material público no demuestra por separado dos fallos byte por byte idénticos en una sola ejecución. Un recibo de conformidad debe guardar los bytes de entrada y su hash justamente para que la copia de una solución provisional no cambie silenciosamente el caso ensayado.

Tampoco hay en la traza un certificado o ROA mal formado, un repositorio publicado o una salida de validación. No acredita cambios de ruta ni participación del RPKI de producción de LACNIC. Cada una de esas afirmaciones requeriría evidencia posterior que no existe en el paquete.

La primera regla explica el comportamiento

La inspección está fijada al commit 994a598321336baf1767f0fbfb460ed96c29fe4f, fechado el 1 de septiembre. Su asunto implementa authorityCertIssuer en AKI y no dice cerrar la incidencia. El historial reciente ofrece un punto temporal, no una prueba sobre cuándo nació el límite.

En src/rpki_tree.c, next_token solo inicia una cadena sin comillas cuando el primer carácter es alfanumérico, $ o . Un : inicial no cumple la condición. El flujo intenta entonces interpretarlo mediante try_emoji y termina declarando inesperado el dos puntos ordinario.

Una vez abierto el token, la regla es distinta: permite dos puntos y barra porque excluye principalmente espacios y separadores estructurales. El cero inicial de 0::/0 no persuade a otra biblioteca de aceptar un prefijo distinto. Satisface la regla de inicio y deja que el resto de la cadena continúe dentro del token.

El propio README muestra por qué no basta con decir que Barry admite direcciones comprimidas. Incluye 2001:db8::/64, que empieza por un dígito hexadecimal y supera la puerta inicial. También asigna ::/0 como recurso IPv6 predeterminado de la ancla de confianza. La documentación y la regla ejecutable divergen exactamente cuando la compresión empieza en el primer carácter.

El parser semántico aparece después. En src/field.c, parse_ip_node divide por /, reconoce IPv6 por la presencia de dos puntos, llama a inet_pton y procesa la longitud. La entrada rechazada nunca llega allí. Por tanto, no hay base para hablar de un error de inet_pton, del largo del prefijo o de la vinculación del campo.

La forma canónica pertenece al camino normal

RFC 4291 permite que :: comprima grupos sucesivos en cero y usa esa forma para la dirección enteramente nula. También define el prefijo como una dirección IPv6 válida seguida de su longitud. ::/0 es una expresión legítima del prefijo que comprende todo IPv6.

RFC 5952 distingue lo que se acepta de lo que se emite. Una implementación debe aceptar las formas legítimas de RFC 4291, mientras que al generar texto debe aplicar una representación canónica y comprimir al máximo. 0::/0 conserva la misma tupla de familia, valor y longitud, pero mantiene un grupo cero que la salida canónica suprime.

Una comprobación local acotada con IPAddr de Ruby normalizó ::/0, 0::/0, 0000::/0 y la dirección cero desplegada al mismo rango. Es un apoyo, no una ejecución de Barry ni una fuente normativa. Sirve para confirmar que el objeto de la prueba debe ser la frontera léxica, no una supuesta diferencia de red.

En la capa de objeto, RFC 3779 codifica el recurso IP como BIT STRING en DER. El bloque de todas las direcciones con longitud cero queda representado por 03 01 00. La grafía original no permanece en el certificado o ROA. Si una forma no supera el lexer, no existe un DER que pueda ser rechazado o aceptado después.

Un recibo pequeño que conserva las etapas

Barry no necesita una promesa genérica de compatibilidad para resolver esta incertidumbre. Una tabla versionada puede guardar, por caso, los bytes exactos del descriptor y su hash; el campo de destino; el resultado del lexer; la familia, valor y longitud normalizados; la representación canónica; el commit del parser y del generador; y el hash del objeto si se alcanzó su construcción.

La etapa terminal debe proceder de una lista estable: descriptor-tokenize, prefix-parse, field-bind, object-build, DER-encode o RP-validate. Así, un rechazo en el generador no puede convertirse por comodidad en un fallo de validación. El invariante mínimo es parse(format(parse(input))): debe conservar la misma tupla. Las formas legítimas equivalentes deben converger en la misma representación DER cuando la generación llega a completarse.

El alcance es deliberadamente pequeño. No certifica el proyecto ni intenta describir todo IPv6. Ofrece algo más útil para un generador de pruebas negativas: una prueba local de qué entrada se aceptó, qué valor se entendió, qué bytes se crearon y quién tomó la decisión terminal.

Fuentes