Résumé

  • La RFC 9897 définit la négociation MP-DCCP, l’annonce d’adresses et l’authentification d’un sous-flux supplémentaire au sein d’une connexion existante.
  • MP_CONFIRM et MP_JOIN attestent des faits de contrôle bornés ; ils n’attestent ni l’usage par l’ordonnanceur, ni la réception à temps, ni le réordonnancement, ni le basculement, ni le résultat applicatif.

Le tableau d’exploitation est au vert. Un deuxième sous-flux a terminé sa poignée de main, l’identifiant de connexion correspond et le HMAC rattache la jonction aux parties du premier flux. Le responsable du service pose pourtant une question élémentaire : quel datagramme important a emprunté ce chemin lorsque le chemin principal s’est dégradé ? Le journal de contrôle ne le sait pas.

Publiée comme Proposed Standard en janvier 2026, la RFC 9897 étend DCCP au fonctionnement multipath ; la notice du RFC Editor en fixe l’identité. Le service de base de la RFC 4340 demeure celui de datagrammes non fiables soumis au contrôle de congestion. Plusieurs sous-flux peuvent apparaître à l’application comme une seule connexion sans devenir un flux d’octets fiable.

Le premier sous-flux négocie la capacité multipath et échange du matériel de clé propre aux hôtes. Un flux ultérieur présente MP_JOIN, l’identifiant de connexion du pair et un nonce neuf ; MP_HMAC vérifie son rattachement aux parties initiales. Ce mécanisme empêche qu’un flux quelconque s’autoproclame membre. Il n’indique pas encore quel paquet applicatif l’ordonnanceur lui a confié.

L’annonce d’adresse précède encore cette étape. MP_ADDADDR fait connaître une adresse et, éventuellement, un port ; le HMAC la protège et la séquence distingue l’information récente de l’information périmée. Le pair peut l’enregistrer ou l’écarter. MP_CONFIRM rend l’échange de l’option fiable, mais le texte exclut expressément le traitement ultérieur de la portée de cette confirmation. Une annonce confirmée n’est pas une jonction achevée ; une jonction achevée n’est pas un usage observé du plan de données.

Cette séparation est voulue. MP-DCCP fournit des numéros de séquence au niveau de la connexion, des données RTT et des indications de priorité. Il laisse aux extrémités l’algorithme d’ordonnancement, le réordonnancement facultatif et la politique déterminant quand et dans quel ordre créer ou retirer les sous-flux. Aucun mécanisme ne négocie même leur nombre maximal : l’implémentation doit limiter ses ressources.

C’est dans cette liberté locale que naît le comportement réel. Une stratégie de mobilité peut tenter un chemin de repli lorsque le principal devient impropre, mais le choix de la meilleure paire source-destination reste local. En usage concurrent, l’ordonnanceur choisit paquet par paquet ; contrôle de congestion et éventuel réordonnancement déterminent le résultat. Deux sous-flux peuvent partager le même goulet : les compter ne prouve ni l’indépendance des pannes ni un surcroît de capacité.

La frontière de sécurité est tout aussi nette. La RFC protège la jonction et certains signaux dans son modèle de clés, sans fournir toutes les garanties cryptographiques requises par une application. Elle renvoie notamment à DTLS sur DCCP. Un identifiant d’adresse n’abolit pas non plus les middleboxes. DCCP-UDP décrit une encapsulation de traversée, mais celle-ci reste hors du périmètre de MP-DCCP.

La spécification emprunte du vocabulaire et des idées de signalisation à la RFC 8684, et cite la RFC 8041 à propos des limites de chemins. Ce contexte n’autorise pas à attribuer à MP-DCCP les propriétés de livraison ou l’expérience d’exploitation de MPTCP. Le registre IANA des paramètres DCCP atteste les allocations de Feature 10, Option 46, version 0 et des sous-options ; il n’atteste aucune implémentation.

Il faut donc relier quatre registres. Le registre de contrôle conserve négociation, annonces, confirmations, jonctions, nonces, types de clés, fermetures et replis. Le registre de chemin conserve décisions d’ordonnancement, quadruplets, admission par la congestion, horaires, pertes et goulets communs. Le registre de réception conserve arrivées, trous, retards et réordonnancement. Le registre du service mesure l’objectif exact de basculement, de délai, de continuité ou d’agrégation.

Le principe de spécification initiale minimale de Heng Lu explique pourquoi la RFC n’impose pas un ordonnanceur universel : l’accord interopérable reste mince, les décisions futures demeurent là où elles sont observables et réversibles. La primauté du code en fonctionnement réclame les paquets et le résultat. Les couches de réalité empêchent qu’un symbole authentifié du journal devienne l’autorité sur le service ultérieur.

La norme donne au second chemin une manière disciplinée de rejoindre la connexion. La résilience ne commence que si la preuve va plus loin.

Sources