Resumen

  • La revisión 01 de draft-dong-sidrops-rpki-rtr-moa-pdu, publicada el 9 de septiembre de 2026, incorpora retiros completos y parciales cuando un conjunto se reparte entre varios PDU, además de reglas de refresco, reintento, caducidad y número de serie. Sigue siendo un Internet-Draft individual activo, no un documento adoptado por SIDROPS ni una norma del IETF.
  • El propio texto deja el orden y el comportamiento de respaldo entre MOA y ROA de IPv6 a una especificación complementaria prevista. Una matriz pública de resultados en ambos planos permitiría comparar implementaciones sin quitar al operador la decisión final.

Un caché recibe un MOA que autoriza un prefijo de mapeo IPv6 para cuatro prefijos IPv4. Para transportarlo, divide la lista en dos mensajes. Días después, el titular retira uno de cada mensaje original. Si el router necesitara recordar aquel reparto accidental, el formato del transporte se habría convertido en parte de la autorización.

La revisión 01 evita ese error. Un retiro completo puede llegar reunido en un solo PDU o repartido como antes. Un retiro parcial puede usar uno o varios PDU, pero su unión debe contener exactamente los prefijos eliminados. El router quita las autorizaciones correspondientes sin exigir que el número de mensajes coincida con el de la fase de anuncio.

La revisión 00 no resolvía ese caso. La comparación oficial muestra además un orden canónico para los prefijos, una nueva sección de ciclo de vida y una delimitación expresa de la lógica de validación.

Es un avance pequeño y correcto: la autoridad corresponde al mapeo autorizado, no al modo en que TCP permitió fragmentar una lista en un momento concreto.

Un borrador individual junto a un trabajo de grupo

El estado institucional no se deduce del nombre del archivo. La página del Datatracker y la entrada de su API clasifican el PDU como presentación individual activa. No tiene flujo IETF, Area Director responsable, shepherd ni nivel normativo previsto. El historial registra la versión de Guozhen Dong el 9 de septiembre, y la entrada de presentación conserva fecha documental y autores.

Que sidrops aparezca en el identificador no equivale a adopción. El perfil MOA al que cita sí es un documento del grupo SIDROPS; el PDU, por ahora, no. Tampoco existe aún una asignación IANA por el mero hecho de que el borrador la solicite.

Para entender dónde queda la decisión, conviene no mezclar cinco capas.

El titular crea primero un MOA firmado. El perfil MOA 04 vincula un prefijo de mapeo IPv6 con uno o más prefijos IPv4. No es una ruta ni una instrucción de reenvío.

Después, el software de relying party valida el objeto. Aplica el RFC 6488 y confirma que cada prefijo IPv4 está cubierto por la extensión de recursos IP del certificado de entidad final. El perfil aclara que la PKI aporta autorización, no autentica a una persona ni promete no repudio.

El caché transforma el objeto ya validado en un PDU. Es una vista derivada y ordenada para el router. Una sesión autenticada protege el transporte; no sustituye la validación del objeto original.

El router instala luego la entrada en una base local de Mapping Origin Validation. El RFC 8210 define el número de serie como una versión lógica de un caché. No se compara entre cachés o versiones de protocolo y puede no mantenerse tras un reinicio. Versión, identificador de sesión y serial sirven para saber si dos estados son comparables, no para probar por sí solos la voluntad del titular.

Por último llega el anuncio BGP 4map6. El borrador 4map6 06 comprueba que el prefijo de mapeo sea alcanzable, actualiza una base de reglas y aplica controles de distribución. La decisión que afecta al encaminamiento sigue siendo local.

También importa la diferencia entre ROA y MOA. El RFC 9582 perfila la autorización para que un sistema autónomo origine rutas de determinados prefijos. El MOA propuesto autoriza a un prefijo IPv6 a originar un mapeo para prefijos IPv4. Compartir RPKI no convierte ambos actos en uno.

Caducar no es retirar

La revisión 01 importa los temporizadores Refresh, Retry y Expire del RFC 8210. Cuando vence Refresh, el router solicita una vista completa y debería mantener temporalmente los datos MOA ya instalados. Si no obtiene respuesta, reintenta. Al superar Expire sin refresco correcto, debe eliminar todos los datos MOA y dejar de tomar decisiones MOV basadas en ellos hasta recuperar la conexión.

El texto también exige que un cambio en los datos MOA incremente el número de serie. Así se puede detectar una vista antigua o desincronizada dentro del contexto adecuado.

Un retiro y una caducidad responden a hechos distintos. El primero comunica que autorizaciones concretas han cambiado. La segunda limita cuánto tiempo se puede seguir usando toda una vista que ya no se puede actualizar. Un retiro parcial puede dejar otras entradas vigentes; una caducidad saca la información MOA del cálculo completo.

Ninguna de las dos cosas demuestra por sí sola que la ruta 4map6 se retiró, que la FIB cambió o que el tráfico volvió a fluir. Un registro del caché, una entrada MOV y un resultado de paquetes son evidencias diferentes.

El punto de decisión se delega a un texto esperado

El perfil MOA reconoce que una autorización correcta del titular IPv4 no basta si un tercero origina de forma maliciosa el prefijo IPv6 que transporta el mapeo. Por eso recomienda desplegar también validación ROA de IPv6.

El PDU repite la dependencia, pero declara fuera de alcance la interacción detallada, incluido el orden de validación y el comportamiento de fallback. Dice que esa materia se abordará en una especificación de verificación MOA que se espera acompañe al perfil.

En el corte de esta investigación, las búsquedas públicas del Datatracker por nombres MOA y títulos de Mapping Origin devolvieron el perfil, el PDU y materiales de reuniones, no un documento vigente que desempeñara esa función anunciada. Es una observación sobre el expediente público, no una afirmación sobre código privado ni sobre lo que pueda publicarse después.

La ausencia se vuelve práctica al combinar resultados. ¿Qué ocurre si el MOA es válido y el ROA IPv6 da Invalid? ¿Y si da NotFound? ¿Se impide instalar la entrada, se reduce su preferencia, se marca como no evaluada o se aplica una regla local? Si el caché MOA está dentro del margen de Expire pero cambia la ruta IPv6, ¿qué reloj y qué evidencia gobiernan? Tras reconectar, ¿se reinstala primero y se verifica después, o al revés?

El serial no puede decidirlo. Solo ordena versiones comparables de un caché. Tampoco una retirada exacta establece la precedencia entre dos planos de autorización.

El propio 4map6 limita de momento el problema a un entorno controlado, un solo operador o pocos operadores cooperantes. Señala que una expansión requerirá autenticación específica en otro documento. Un acuerdo privado puede producir una política funcional para ese conjunto; no debería convertirse por omisión en el significado universal del protocolo.

La matriz mínima que falta

No propongo añadir campos al PDU. Propongo publicar una matriz de resultados de dos planos en la especificación complementaria o en cada perfil operativo.

Cada fila debería unir el resultado y el motivo del MOA con el caché, la versión de protocolo, el identificador de sesión, el serial y la hora de observación; añadir el resultado ROA IPv6 del prefijo de mapeo; y declarar orden, bloqueo o degradación, estado local conservado o borrado, versión de política, acción del router y prueba exigida para restaurar.

La cobertura mínima incluye MOA válido con IPv6 Valid, Invalid y NotFound; MOA inválido o caducado; datos de caché antiguos pero aún dentro del intervalo; datos ya expirados; retiro parcial; retiro total; reinicio del caché y resincronización. NotFound debe conservarse como tal. Un control no ejecutado no debe presentarse como aprobado.

Esta propuesta aplica el límite de la Minimum Initial Specification de Heng Lu: hacer comparable el mínimo compartido y dejar la política final en manos de cada red. Running Code Primary exige además conservar prueba de la regla que realmente se ejecutó. Es análisis editorial mío, no texto del IETF, SIDROPS ni de los autores.

La revisión 01 ya consigue algo valioso: un conjunto autorizado puede salir de la base sin quedar atrapado en su empaquetado histórico. La siguiente pieza debe explicar cómo vuelve a entrar cuando dos pruebas cuentan historias distintas.

Fuentes