Résumé

  • Le RFC 947 décrit un processus qui sélectionne des diffusions UDP sur un réseau local et un autre qui les rediffuse sur un réseau distant, sans transformer les passerelles intermédiaires en relais.
  • Ce choix préservait la maîtrise de la configuration par Cronus, tout en obligeant un hôte partagé à réveiller son processus de filtrage pour chaque paquet UDP reçu.

Une question sans destinataire connu

Pour trouver une ressource dans Cronus, il était pratique de poser la question par diffusion plutôt que de connaître à l’avance l’adresse du serveur. Cette commodité s’arrêtait à la frontière du réseau physique. Une passerelle savait transporter des échanges entre machines identifiées sur des réseaux distincts ; elle ne propageait pas pour autant toutes les diffusions émises sur un Ethernet. La distinction est essentielle : le problème n’était pas l’absence de communication entre réseaux, mais l’impossibilité de conserver, à distance, une méthode de découverte locale.

Le RFC 947, signé par Ken Lebowitz et David Mankins en juin 1985, répond à ce cas précis. Cronus utilisait TCP et UDP, notamment la diffusion pour découvrir des ressources et demander l’état de serveurs. Les auteurs précisent que les messages intéressaient souvent moins de machines qu’ils n’en atteignaient. La multidiffusion leur aurait semblé plus adaptée, mais certaines de leurs implémentations réseau ne la proposaient pas. Il fallait donc prolonger un outil déjà employé, sans prétendre que toute diffusion locale devait devenir un service global.

Le mécanisme retenu sépare deux tâches. Sur le réseau émetteur, un processus « forwarder » examine les diffusions UDP et ne retient que des ports ou adresses de destination configurés. Il lit un fichier qui nomme les répéteurs distants et précise, pour chacun, les paquets à transmettre. Il tente d’ouvrir une connexion TCP vers chacun d’eux et réessaie périodiquement si elle échoue. Un paquet choisi est encapsulé dans un message adressé au répéteur. À l’arrivée, celui-ci utilise l’adresse de diffusion du réseau local distant pour le réémettre, tout en gardant l’adresse source du paquet initial.

Il existe même une variante plus ciblée. Si le fichier nomme une machine qui n’est pas un répéteur, le forwarder remplace la destination de diffusion par l’adresse de cette machine et lui envoie un datagramme unicast. La portée du système se comprend alors sans métaphore excessive : une liste de destinataires, une sélection par destinataire et une remise locale. Les passerelles restent sur le trajet, mais ne décident ni des messages retenus ni de leur rediffusion.

La frontière administrative derrière le schéma

Les auteurs avaient envisagé d’intégrer cette fonction aux passerelles Internet. Ils expliquent pourquoi ils y ont renoncé. Il aurait fallu tenir à jour des tables de destinataires dans ces équipements et étendre le protocole qui distribue leur configuration. Le choix des messages utiles pouvait demander une connaissance du protocole que la passerelle ne possédait pas. Des passerelles fournies par d’autres fabricants auraient pu ignorer cette fonction. Surtout, les responsables du réseau sous-jacent et ceux de Cronus n’étaient pas forcément les mêmes. Déplacer la fonction vers la passerelle aurait déplacé le pouvoir de modifier le service.

Le noyau de Cronus n’était pas une solution gratuite non plus : chacun des noyaux participants aurait dû connaître les adresses des autres, ce qui compliquait les changements de composition et enfermait davantage le mécanisme dans Cronus. Un processus hôte configurable permettait de garder la décision au plus près du besoin. Cette indépendance a toutefois créé une nouvelle responsabilité pour les hôtes qui l’exécutaient.

Un relais qui rediffuse risque de réentendre son propre trafic. Le forwarder refusait donc de se connecter à un répéteur situé sur son réseau et ne transmettait pas les paquets dont l’adresse source n’appartenait pas à ce réseau. Ce sont les précautions documentées contre le retour en boucle, pas une preuve de sécurité générale. Préserver l’adresse source exigeait en outre une capacité spéciale dans l’implémentation TCP/IP de BBN : un processus privilégié pouvait envoyer un paquet avec l’adresse source d’un autre hôte. La conservation de cette adresse n’authentifiait pas l’expéditeur.

Une expérience convaincante dans ses limites

Le déploiement décrit comprenait deux Ethernet séparés par deux autres réseaux locaux ; les messages passaient au moins deux passerelles. Les processus tournaient sur un VAX sous 4.2BSD UNIX avec le logiciel réseau de BBN. Après plusieurs mois, les auteurs jugeaient le dispositif satisfaisant pour leurs besoins. Leur constat porte sur cette installation, sans fournir un bilan indépendant de performances ni un chiffre d’adoption.

Ils décrivent en revanche clairement la charge imposée à l’hôte partagé. Le forwarder en espace utilisateur se réveillait pour tous les paquets UDP entrants avant de rejeter ceux qui ne correspondaient pas. Les auteurs évoquaient un filtrage dans le noyau, en conservant configuration et rediffusion dans le programme utilisateur. Ils envisageaient aussi une machine spécialisée à base de microordinateur. Le RFC ne présente ni l’une ni l’autre comme réalisée.

Le RFC 919 rappelait déjà que la diffusion fait travailler tous ses destinataires, et le RFC 922 traitait la diffusion IP en présence de sous-réseaux. Le témoignage Cronus est plus singulier : il rend visible le lieu exact du choix, de l’administration et de la dépense de calcul. Le RFC 1112, publié plus tard sur la multidiffusion IP, n’établit pas le sort ultérieur de cette expérience.

Sources