Résumé

  • La RFC 3077 conservait le caractère physique unidirectionnel du flux satellite et utilisait des tunnels entre interfaces IP bidirectionnelles pour simuler les échanges de liaison que les récepteurs ne pouvaient pas émettre sur le canal de diffusion.
  • Les annonces DTCP, elles aussi descendantes, aidaient à découvrir les flux et à supprimer les extrémités de tunnel périmées ; elles n’authentifiaient personne, n’imposaient pas une route optimale unique et ne prouvaient pas qu’une application avait reçu ses données.

Publiée en mars 2001, la RFC 3077 part d’une impossibilité concrète : deux équipements partageant une liaison de diffusion ne peuvent pas y mener une conversation dans les deux sens. Le flux envoie des données sur la liaison unidirectionnelle ; le récepteur peut écouter, mais pas répondre. Un flux en émission seule est, dans l’autre sens, « sourd » sur cette interface. Or les protocoles Internet supposent souvent qu’un lien transporte des paquets dans les deux directions : un routeur transmet au prochain saut et attend des réponses ou des mises à jour de routage.

La solution n’a pas consisté à faire transmettre les récepteurs satellites. Chaque récepteur et chaque flux devait également disposer d’une interface classique, bidirectionnelle et reliée à une infrastructure IP. Quand un récepteur voulait envoyer une trame de liaison vers un flux, il l’encapsulait et la transportait dans un tunnel jusqu’à l’adresse Internet de ce flux. Celui-ci la décapsulait et la remettait à sa liaison. La diffusion satellite restait le chemin descendant ; le tunnel fournissait un chemin retour entre équipements choisis.

Pourquoi simuler une liaison plutôt que créer un réseau uniquement au niveau IP ? Une liaison simulée permettait aux protocoles de couche supérieure de continuer à fonctionner sans tenir compte de la physique satellite. La RFC énumère six scénarios de communication possibles sur un réseau de diffusion bidirectionnel. Le sixième — du flux vers le récepteur — existait déjà sur le canal descendant. Le tunnel devait rétablir les cinq autres, notamment récepteur-vers-flux, récepteur-vers-récepteur et plusieurs usages de la diffusion et de la multidiffusion.

Des protocoles comme ARP et les protocoles de routage directement connectés retrouvaient ainsi leur place habituelle dans la pile. Cela ne rendait pas la liaison physique capable d’émettre en retour.

Le document recommande Generic Routing Encapsulation (GRE) pour transporter différents types de paquets dans IP. Dans le format décrit, un paquet IP externe rejoint l’adresse bidirectionnelle du flux ; l’en-tête GRE désigne le protocole de liaison utilisé sur le canal unidirectionnel ; la charge utile est la trame MAC d’origine. D’autres types de tunnel sont possibles si les deux côtés s’accordent sur leur signification. La RFC définit l’adaptation autour du tunnel, pas un système d’autorisation ou de sécurité pour GRE.

Le choix moins évident concerne la découverte des flux vers lesquels tunneliser. Le Dynamic Tunnel Configuration Protocol (DTCP) ne se sert pas du retour Internet pour se découvrir : ses messages HELLO vont des flux aux récepteurs par la liaison unidirectionnelle. JOIN annonce qu’un flux fonctionne ; LEAVE peut signaler son arrêt. HELLO contient aussi un intervalle, une séquence, un type de tunnel et une ou plusieurs adresses IP bidirectionnelles de flux (FBIP). Les récepteurs écoutent l’annonce multidiffusée du DTCP et gardent une liste de flux actifs, de leurs extrémités de tunnel et de temporisateurs.

Un message LEAVE permet de supprimer rapidement une entrée. Si les HELLO cessent, elle finit par expirer. Ce signal reste limité : le flux peut être en panne, ou bien la liaison unidirectionnelle peut l’être. Dans les deux cas, le récepteur ne peut plus présumer que ce flux assure une connectivité bidirectionnelle. L’expiration indique ce qu’il faut cesser de tenter ; elle ne diagnostique pas le composant défaillant et ne prouve pas qu’un paquet applicatif a été transmis.

Le choix du flux reste local. Chaque récepteur choisit son propre flux par défaut. La RFC cite un temps aller-retour plus faible comme exemple, sans imposer une politique commune. Un administrateur peut préférer une autre extrémité de tunnel annoncée, s’il peut mieux la joindre. Même l’adresse MAC du flux sur le réseau unidirectionnel (FUMAC), nécessaire au mécanisme, n’a pas de méthode de découverte universelle spécifiée. Le format coordonne l’échange ; la configuration locale décide encore de l’utilité d’un chemin.

Le mot « bidirectionnel » peut masquer un coût. Une liaison géostationnaire peut ajouter environ 250 millisecondes de délai dans un sens, tandis que le chemin de retour sur Internet a sa propre latence variable. La RFC avertit que des mécanismes de résolution réactive comme ARP peuvent faire attendre un flux, accumuler des paquets, puis épuiser la mémoire tampon et en perdre. C’est un risque d’ingénierie exposé par la spécification, pas une mesure issue d’un service nommé. Les chemins sont réunis, mais leurs délais, capacités et responsables ne deviennent pas symétriques.

La RFC exige donc que les récepteurs désactivent leurs tunnels quand la liaison unidirectionnelle est en panne. Sinon, un routeur pourrait encore recevoir des paquets par un tunnel et croire que le lien sous-jacent fonctionne — ce qui peut tromper un protocole de routage qui évalue son voisin d’après les paquets reçus. La perte d’un flux doit également interrompre les tunnels devenus inutiles. La décapsulation d’une trame n’est qu’un événement dans la chaîne ; elle ne garantit ni une route stable ni un service réussi.

La confiance relève encore d’une autre couche. La RFC avertit que l’usurpation ARP ou IP pourrait donner accès au service à des nœuds non autorisés. Elle indique que les tunnels peuvent être authentifiés, mais ne spécifie aucun mécanisme d’authentification. Les protocoles de routage sur la liaison simulée doivent, eux, utiliser leurs propres mécanismes disponibles afin d’éviter l’injection de fausses routes. Les champs JOIN et les adresses annoncées par DTCP ne sont pas des justificatifs d’identité.

Enfin, la RFC ne promet pas une interopérabilité immédiate. Un profil de déploiement doit préciser le format MAC et le type de tunnel utilisé ; sans GRE, les deux extrémités doivent s’accorder explicitement sur l’interprétation du tunnel. La configuration du routage multicast et la montée en charge restent hors périmètre. La RFC rend une liaison unidirectionnelle utilisable en la composant avec un réseau de retour, sans uniformiser les chemins ni rendre leur confiance implicite.

Sources principales