Résumé

  • RFC 1234, publié en juin 1991, décrit l'encapsulation des datagrammes IPX dans UDP. Le texte autorise une implémentation à voir un internet IP comme un unique réseau IPX et associe un hôte IPX connu à son adresse IP pour l'unicast.
  • La diffusion ne parcourt pas naturellement cet ensemble. Serveurs, routeurs et clients doivent tenir des listes configurées de pairs et envoyer une copie unicast à chacun. Le RFC prévient qu'une ressource peut être visible mais rester injoignable si les diffusions n'atteignent pas tout le groupe de serveurs.

L'unité annoncée était une vue de transport

RFC 1234 résout d'abord une question précise : comment transporter IPX là où le réseau ne transporte que IP. L'encapsulation UDP fournit ce passage. Le choix du numéro d'hôte IPX est révélateur : ses deux premiers octets sont nuls et les quatre derniers reprennent l'adresse IP du nœud. Pour une destination déjà connue, le chemin unicast devient une traduction lisible, non une recherche supplémentaire.

Cela ne transforme pas l'internet IP en LAN physique, en domaine d'administration unique, ni en preuve que toute information de service circule partout. Le RFC dit qu'une implémentation peut le considérer comme un réseau IPX unique. Il ne dit pas que cette abstraction dispense du travail qui permet aux membres d'un groupe de se découvrir.

La nuance est décisive parce qu'IPX exige des facilités de diffusion pour que les serveurs NetWare et les routeurs IPX partageant un réseau se trouvent. Connaître une adresse donne une destination. Poser une question à tous les pairs pertinents exige de savoir qui ils sont et de faire parvenir la question à chacun.

La diffusion devenait une décision de liste

Un broadcast IP couvrant tout l'internet n'est, selon RFC 1234, ni approprié ni disponible. Le mécanisme substitutif n'est pas implicite : chaque serveur et routeur doit conserver une liste de pairs IP construite manuellement. Lorsqu'IPX demande une diffusion, l'implémentation envoie un paquet unicast distinct à chaque entrée de cette liste.

Cette règle déplace la frontière importante. La diffusion ne dépend plus seulement d'un média partagé ; elle dépend de l'exactitude d'une population déclarée et de copies réellement transmises. Le RFC note que plusieurs groupes de pairs peuvent partager le même internet IP sans se connaître, justement parce que chaque liste est faite à la main. Dans un groupe donné, chaque liste devrait contenir tous les pairs du groupe.

Il faut donc éviter de faire de « connecté » un verdict trop large. L'underlay peut joindre deux sites et le tunnel peut les placer dans le même réseau IPX logique, sans que leur demande de découverte atteigne pour autant chaque serveur ou routeur qui doit la recevoir. L'unité de transport et l'exhaustivité de diffusion sont deux faits différents.

Le client devait viser le groupe entier

Le serveur n'est pas seul à supporter cette charge. Un client IPX doit envoyer des diffusions pour découvrir le routeur qui atteint une destination voulue. RFC 1234 prévoit alors, côté client, une liste configurée des adresses IP de tous les serveurs et routeurs du groupe de pairs ; le client envoie une copie du paquet à chaque adresse de sa liste.

La découverte dépend donc de deux choses observables mais distinctes : les listes conservées par les serveurs et routeurs, et la capacité du client à viser tous les groupes de serveurs pertinents. Un tunnel qui livre parfaitement un paquet unicast connu ne corrige pas une entrée oubliée, une adresse périmée ou une copie qui ne parvient jamais à une partie du groupe.

Le RFC formule la conséquence sans raconter d'incident particulier. Si ces paquets ne tendent pas à atteindre l'ensemble du groupe de serveurs, des ressources de l'internet IPX peuvent être visibles par un système terminal tout en restant injoignables par lui. Le conditionnel ne permet pas d'inventer une panne, un opérateur fautif ou une topologie réelle. Il fixe cependant une frontière : voir une ressource et obtenir le chemin nécessaire pour l'atteindre ne sont pas toujours le même résultat de protocole.

Une adresse connue ne résolvait pas la question collective

Le contraste interne du RFC est instructif. L'adresse d'un hôte connu peut être lue dans le numéro d'hôte IPX et devenir une adresse IP de destination. La diffusion, elle, pose une question de composition : qui doit entendre cette demande ? Sa réponse est une liste modifiable, donc une responsabilité maintenue, et non une propriété que le tunnel déduit de la géographie IP.

RFC 1234 évoque le multicast comme une possibilité future, mais indique qu'il n'était alors ni largement disponible, ni muni d'une adresse connue, ni mis en œuvre. Cette réserve est utile : remplacer une liste par un autre mécanisme de groupe ne dispense jamais de rendre le groupe, sa portée et sa défaillance vérifiables.

Le texte ajoute des contraintes qui rappellent la matérialité de l'abstraction. L'MTU IPX par défaut est de 576 octets ; l'encapsulation porte le total IP à 604 octets. Le checksum UDP reste facultatif mais fortement recommandé, IPX n'utilisant normalement pas son propre checksum. Aucune de ces propriétés ne complète une liste de pairs. Elles montrent qu'un « seul réseau » reposait sur plusieurs conditions explicites.

Sources et limites de preuve

La source fermée de cet article est RFC 1234, Tunneling IPX Traffic through IP Networks. Elle établit la date, l'encapsulation UDP, la convention de numéro d'hôte, les listes de pairs, la découverte client, l'avertissement sur visibilité et injoignabilité, l'MTU, le checksum et les limites de sécurité. Elle ne prouve ni un déploiement particulier, ni l'ampleur d'usage, ni une panne nommée, ni une topologie d'organisation, ni l'état actuel du protocole ou du port UDP 213.