Résumé

  • Publié le 7 septembre 2026, draft-ietf-dtn-bibe-00 est un nouveau document de travail du groupe DTN. Il remet BIBE en chantier autour de l’encapsulation et de la segmentation, sans reprendre le mécanisme historique de transfert de garde.
  • Chaque bundle encapsulant est un nouvel objet BPv7. Sa livraison ne prouve ni que tous les segments sont arrivés au même élément, ni que l’état a été conservé, ni que le bundle intérieur a été reconstruit et remis au BPA.
  • Les rapports BP peuvent observer l’avant et l’après de la décapsulation. Les rejets et expirations qui surviennent entre les deux ne sont visibles que dans les journaux et compteurs locaux.

Imaginons quatre segments et quatre confirmations. Chacun des bundles extérieurs atteint l’endpoint prévu. Deux sont remis à un membre, deux à un autre. Les deux éléments de décapsulation disposent donc de données valides, mais incomplètes. À l’expiration, chacun efface son état. Il n’y a pas de contradiction : toutes les livraisons extérieures ont bien eu lieu, tandis qu’aucune réception intérieure n’a jamais été créée.

C’est la frontière précise ouverte par la révision 00 de Bundle-in-Bundle Encapsulation. Le texte, daté du 7 septembre, appartient désormais au groupe de travail DTN, mais reste un Internet-Draft susceptible de changer ou d’expirer. Il décrit un comportement observable : capturer les octets d’un bundle, les transporter entiers ou par morceaux dans des bundles BPv7 ordinaires, puis les restituer à un endpoint configuré. Il ne démontre aucun déploiement ni aucune interopérabilité.

Le bundle extérieur n’est pas une copie modifiée de l’intérieur. Le nœud d’entrée le crée comme une nouvelle source. Sa destination est l’endpoint de décapsulation, pas le destinataire final. Son horodatage, sa durée de vie, ses indicateurs, ses blocs d’extension et sa politique de sécurité appartiennent à un trajet autonome. L’intérieur ne fournit que des octets opaques.

Cette indépendance rend le tunnel utile. Une protection de confidentialité sur la charge extérieure peut cacher jusqu’aux adresses source et destination du bundle intérieur. Un domaine peut appliquer sa politique de routage, de file d’attente ou de sécurité sans altérer l’objet transporté. Une version du Bundle Protocol peut même traverser un réseau d’une autre version.

Mais l’indépendance produit aussi deux registres. La livraison extérieure signifie que la charge est arrivée à un élément enregistré pour l’endpoint. La réception intérieure n’existe que lorsque l’élément remet un bundle entier au BPA, directement ou après réassemblage complet. Entre ces deux faits se trouvent une capacité optionnelle, une mémoire finie et des choix locaux.

La segmentation commence par un seuil configuré par endpoint. Il limite les octets intérieurs placés dans chaque bundle, pas les en-têtes, l’encodage CBOR ni les blocs BPSec ajoutés autour. L’émetteur affecte ensuite un Transfer ID et produit des plages qui couvrent l’objet une fois, dans l’ordre. Cet identifiant est interprété avec l’EID de destination et l’identifiant du nœud source extérieurs ; il n’indique ni ordre, ni fraîcheur, ni perte.

Une fois le premier segment demandé, BIBE ne prévoit aucun signal d’annulation. Un abandon côté émission ressemble exactement à une perte sur le trajet. L’état partiel reste donc occupé jusqu’à l’expiration commune, sauf si la politique locale le supprime plus tôt. Le même Transfer ID ne peut être réutilisé sans danger tant que l’ancien transfert peut encore produire un segment.

Les règles de réassemblage sont nettes. Une plage qui dépasse la longueur totale est mal formée. Une longueur totale changeante ou un chevauchement contradictoire corrompt le transfert et entraîne son rejet ; une duplication identique est bénigne. Un élément qui ne prend pas en charge le réassemblage — optionnel — doit éliminer les charges segmentées. Une pression mémoire peut aussi provoquer une éviction anticipée. Dans tous ces cas, aucun bundle intérieur n’atteint le BPA.

L’affinité vers un élément est donc une propriété opérationnelle, pas un détail de nommage. Un endpoint singleton, notamment sous ipn, satisfait naturellement la contrainte. Un endpoint multidestinataire convient si chaque membre reçoit l’ensemble complet. En revanche, une sélection de membre non déterminée peut disperser les segments et fabriquer deux états qui ne finiront jamais.

BIBE n’ajoute ni accusé de réception ni retransmission. Pour l’encapsulateur, l’opération de transfert est terminée dès que les nouveaux bundles ont été remis au réseau sous-jacent. La fiabilité doit venir d’une couche de convergence, de répétitions, d’un mécanisme de garde ou d’accusé situé ailleurs, ou des applications. Le compte rendu de l’IETF 126 est explicite : la reprise du travail exclut la garde et resserre le périmètre sur encapsulation et segmentation.

Les rapports d’état de la RFC 9171 restent précieux à condition de ne pas les fusionner. Ceux des bundles extérieurs suivent réception, transfert, suppression et livraison dans le tunnel. Ceux du bundle intérieur ne reprennent qu’après présentation au BPA. Si toutes les livraisons extérieures sont confirmées mais qu’aucune réception intérieure n’apparaît, le diagnostic se resserre sur la décapsulation.

Ce resserrement n’explique pas encore la cause. Absence de support, encodage réservé, incohérence de longueur, conflit de plages, éviction et expiration se produisent après la livraison extérieure, alors que les octets ne forment pas encore un bundle intérieur. Le draft précise qu’aucun rapport d’état portant sur l’un ou l’autre bundle ne peut exprimer ces décisions. Elles doivent être exposées localement.

La durée de vie protège sans suffire. Tous les bundles d’un transfert partagent une expiration qui ne peut dépasser celle de l’intérieur. Elle borne la possibilité de complétion et autorise ensuite la réutilisation de l’identifiant. Mais cette date vient de l’émetteur. Un pair hostile peut annoncer une échéance lointaine puis retenir le dernier segment. Le récepteur doit imposer sa propre limite de conservation.

La confiance ne traverse pas automatiquement l’enveloppe. Authentifier le bundle extérieur protège la relation avec le pair du tunnel ; cela n’authentifie pas la source déclarée à l’intérieur. L’opacité qui protège les adresses peut aussi empêcher les nœuds intermédiaires d’appliquer leurs filtres. Le point de décapsulation doit donc refaire le contrôle d’admission normal, et l’intérieur doit porter sa propre protection lorsque sa provenance compte.

La méthode de Heng Lu interdit de gonfler un reçu. Le groupe de travail produit un état de coordination ; le rapport extérieur, une observation de transport ; le réassemblage, un résultat local ; la réception par le BPA, un nouveau fait protocolaire. Le traitement applicatif et l’effet réel viennent encore après.

Une exploitation défendable relie ces faits sans les confondre. Elle conserve pour chaque transfert la source extérieure, l’endpoint, le Transfer ID, l’expiration, les plages, l’élément destinataire réel, les rejets, l’éviction, l’achèvement et l’identité du bundle remis au BPA. Les quatre voyants verts demeurent utiles. Ils disent simplement que quatre charges ont atteint le bord du tunnel — rien de plus.

Sources

  1. IETF Datatracker — Bundle-in-Bundle Encapsulation
  2. Draft de groupe 00
  3. Compte rendu du groupe DTN à l’IETF 126
  4. Draft individuel précédent
  5. Ancien draft de groupe BIBE-CT
  6. RFC 9171 — Bundle Protocol version 7
  7. RFC 9172 — Sécurité du Bundle Protocol
  8. RFC 9758 — Mise à jour du schéma URI ipn
  9. RFC 6169 — Risques de sécurité des tunnels IP
  10. RFC 4459 — MTU et fragmentation dans les tunnels
  11. RFC 2473 — Tunneling générique en IPv6
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality Layers