Summary

  • Le RFC 1383 proposait de trouver dans le DNS inverse un relais d'accès à un réseau périphérique multiconnecté, au lieu de faire annoncer toutes ses routes internes aux routeurs de transit.
  • Dans le logiciel expérimental décrit, un ICMP « destination inaccessible » déclenchait la requête DNS. Le RFC avertissait que le premier paquet pouvait être perdu ; une entrée DNS ne constatait pas non plus que le relais fonctionnait.

Le paquet part. Le routeur répond qu'il ne connaît pas le réseau de destination. Un gestionnaire lit cet échec, interroge le DNS et prépare enfin une route pour les paquets suivants. Dans le RFC 1383 de décembre 1992, Christian Huitema avait fait d'une impasse de routage le signal de départ d'une nouvelle recherche. Le premier paquet risquait d'être sacrifié pour éviter de modifier le code IP ordinaire.

L'urgence était la croissance des tables. Le texte donnait alors plus de 5 000 réseaux annoncés dans NSFNET et plus de 7 000 dans EBONE. Une annonce supplémentaire occupait de la mémoire, circulait dans les échanges de routes et demandait parfois une décision de politique à chaque opérateur de transit. L'agrégation hiérarchique promettait de réduire la facture, mais un client à plusieurs fournisseurs pouvait vouloir garder ses adresses sans appartenir à l'espace d'un seul.

Huitema reprenait l'idée du MX du courrier. Un domaine périphérique D possédait deux passerelles, I1 et I2, visibles depuis l'Internet. Elles connaissaient les réseaux internes, sans annoncer chacun d'eux à la table mondiale. L'émetteur cherchait l'adresse de destination dans in-addr.arpa, recevait une liste expérimentale de passerelles RX et orientait le paquet vers l'une d'elles par routage à la source. Le prototype glissait RX, une préférence et une adresse IP dans un enregistrement TXT. Un type DNS RX définitif restait à inventer.

La décision devait être prise une fois, près de l'origine. Faire interroger le DNS à chaque routeur de transit aurait imposé une mise à jour générale et multiplié les recherches. Deux routeurs pourraient aussi choisir I1 puis I2 à tour de rôle et fabriquer une boucle. Une route indiquée par la source maintenait le choix cohérent jusqu'à la passerelle d'accès.

Deux passerelles réduisaient la dépendance à un point de défaillance et à un seul fournisseur. Leur présence dans le DNS ne disait pourtant rien de leur état actuel. L'émetteur devait écarter celles qu'il savait inaccessibles ; la vitesse de détection restait ouverte. Les données RX de D devaient, elles aussi, être servies par des noms de domaine accessibles depuis le cœur de l'Internet. Une porte cachée derrière la panne qu'elle doit réparer ne peut pas publier son propre mode d'emploi.

Le logiciel séparait un gestionnaire de requêtes DNS et un transmetteur dans le noyau. Un ICMP d'inaccessibilité déclenchait l'interrogation ; en attendant, les paquets vieillissaient en file et pouvaient expirer. Sans résultat RX, la destination était marquée inaccessible. Le RFC jugeait préférable une intégration directe au routage IP si l'on pouvait le modifier : elle épargnerait le premier paquet. Le registre officiel classe le document comme expérimental, et sa conclusion disait le code encore en développement à INRIA.

Le marché se trouvait derrière la technique. Si les dorsales facturaient les réseaux annoncés séparément, garder une adresse indépendante d'un fournisseur deviendrait coûteux. RX proposait une autre négociation : moins d'état partagé, plus de recherche et de risque à l'origine. Le DNS pouvait nommer une passerelle. La livraison devait encore prouver qu'elle était ouverte.

Sources