Resumen

  • RFC 9897 especifica cómo negociar MP-DCCP, anunciar direcciones y autenticar un subflujo adicional dentro de una conexión existente.
  • MP_CONFIRM y MP_JOIN acreditan hechos de control acotados; no demuestran uso por el planificador, recepción oportuna, reordenación, conmutación ni un resultado resiliente para la aplicación.

La consola está en verde. El segundo subflujo terminó el intercambio, el identificador de conexión coincide y el HMAC vincula la unión con quienes abrieron el primer flujo. Entonces llega la pregunta que importa: cuando empeoró la ruta primaria, ¿qué datagrama crítico cruzó la alternativa? El registro de control no puede decirlo.

RFC 9897, publicado como Proposed Standard en enero de 2026, amplía DCCP para operar por múltiples rutas. La ficha del RFC Editor fija esa identidad. El servicio base de RFC 4340 sigue siendo de datagramas no fiables con control de congestión. Presentar varios subflujos como una conexión no los convierte en un flujo fiable de bytes.

El primer subflujo negocia la capacidad multipath e intercambia material de clave propio de cada host. Uno posterior incluye MP_JOIN, el identificador del par y un nonce nuevo; MP_HMAC comprueba su pertenencia a la conexión original. Es una defensa valiosa frente a un flujo que se atribuya esa pertenencia. Pero la asociación correcta todavía no revela qué paquete de la aplicación le asignó el planificador.

El anuncio de dirección es un hecho anterior. MP_ADDADDR comunica una dirección y, opcionalmente, un puerto, protegido por HMAC y ordenado con una secuencia que separa datos nuevos de obsoletos. El par puede conservarlo o descartarlo. MP_CONFIRM hace fiable el intercambio de la opción, pero el RFC excluye expresamente el procesamiento posterior de aquello que se confirma. Un anuncio confirmado no establece un subflujo; un subflujo establecido no prueba uso del plano de datos.

La separación forma parte del diseño. MP-DCCP aporta números de secuencia para la conexión, información RTT e indicaciones de prioridad. Deja en los extremos el algoritmo de planificación, la reordenación opcional y la política que decide cuándo y en qué orden agregar o retirar subflujos. Ni siquiera hay un procedimiento que negocie su número máximo; cada implementación debe administrar sus límites.

Ahí se decide el comportamiento real. Una estrategia de movilidad puede intentar la ruta alternativa si la principal deja de servir, pero elegir la mejor pareja de origen y destino sigue siendo una decisión local. En uso concurrente, el planificador decide paquete a paquete; el control de congestión y una posible reordenación moldean el resultado. Dos subflujos pueden compartir el mismo cuello de botella: contarlos no acredita dominios de fallo independientes ni capacidad extra.

La seguridad también tiene un límite preciso. RFC 9897 protege las uniones y ciertos mensajes dentro de su modelo de claves, pero no incorpora todas las garantías criptográficas que una aplicación pueda exigir; remite a protecciones de extremo a extremo como DTLS sobre DCCP. Un identificador de dirección tampoco elimina los middleboxes. DCCP-UDP ofrece encapsulación para atravesarlos, aunque RFC 9897 la mantiene fuera de MP-DCCP.

La especificación toma vocabulario e ideas de señalización de RFC 8684 y cita RFC 8041 al tratar límites de rutas. Son contexto, no licencia para transferir a MP-DCCP las propiedades de entrega o la experiencia de MPTCP. El registro IANA de DCCP acredita las asignaciones de Feature 10, Option 46, versión 0 y las subopciones; no acredita soporte ni uso correcto.

La operación necesita unir cuatro libros. El de control conserva negociación, anuncios, confirmaciones, uniones, nonces, tipos de clave, cierres y retornos. El de ruta conserva decisiones del planificador, cuádruplas, permiso de congestión, tiempos, pérdidas y cuellos compartidos. El receptor conserva llegadas, huecos, tardanzas y reordenación. El servicio registra si alcanzó el objetivo exacto de conmutación, demora, continuidad o agregación.

La especificación inicial mínima de Heng Lu explica por qué el RFC no debe imponer un planificador universal: el acuerdo interoperable puede ser delgado y las decisiones futuras quedarse donde se observan y revierten. La primacía del código en ejecución reclama paquetes y resultados. Las capas de realidad impiden que el símbolo autenticado del registro gobierne un resultado posterior.

La norma da a la segunda ruta una forma disciplinada de unirse. La resiliencia empieza sólo cuando la evidencia continúa más allá.

Sources