Résumé

  • L’horizon partagé simple taisait une route face au voisin qui l’avait fournie ; le retour empoisonné la renvoyait avec la métrique 16 afin d’interdire explicitement ce chemin de retour.
  • Cette information négative éliminait aussitôt une boucle entre deux routeurs, au prix de messages plus gros, mais ne voyait pas les boucles où trois voisins ou davantage recyclaient la même croyance.

Un RFC venu fixer une pratique existante

En juin 1988, RFC 1058 ne prétendait pas lancer RIP. Le texte mettait par écrit un protocole déjà largement déployé et rapprochait plusieurs implémentations dont les détails divergeaient. Sa forme immédiate venait de routed, distribué avec Berkeley Unix ; sa filiation remontait aux protocoles PUP et XNS de Xerox et, plus largement, aux premiers algorithmes à vecteur de distance.

Cette origine explique la franchise du document. Les mécanismes de stabilité y répondent à des incidents possibles dans du code réel. Un routeur ne reçoit pas une carte du réseau. Pour chaque destination, il conserve une distance et le voisin qui lui a fourni la meilleure proposition. À intervalles réguliers, chacun publie ses distances. La vue globale n’existe nulle part.

RIP était destiné à l’intérieur d’un système autonome de taille modérée. La simplicité de l’échange rendait l’exploitation abordable, mais elle privait chaque annonce de l’historique complet qui permettrait d’en connaître la provenance.

Une rumeur revenue sous un autre nom

Imaginons que A rejoigne un réseau D par B. Lorsque B perd son accès réel à D, il peut encore entendre A annoncer une distance. S’il adopte cette annonce comme solution de remplacement, B oublie que A tenait précisément son information de B. La seconde annonce n’est pas une observation indépendante : c’est la première, copiée puis rendue à son auteur.

Les deux calculs locaux semblent pourtant cohérents. A désigne B, B désigne A, et les paquets tournent pendant que la métrique augmente. RIP nomme ce phénomène le comptage jusqu’à l’infini. La perte de D se transforme temporairement en une destination toujours joignable, mais de plus en plus lointaine.

Le protocole a donc choisi un infini très proche : 16. Une route valide ne peut dépasser 15 sauts. Cette borne réduit l’échelle des réseaux compatibles avec RIP, mais réduit aussi le nombre de mensonges successifs avant que l’échec soit déclaré. L’infini est à la fois une limite de taille et un délai algorithmique.

Se taire ou contredire

L’horizon partagé simple applique une règle de provenance : ne pas renvoyer une route vers l’interface ou le voisin qui l’a enseignée. Si A a appris D auprès de B, D disparaît du message de A à B. La copie ne peut plus se présenter comme une confirmation.

Le retour empoisonné choisit une parole plus coûteuse. A inclut D mais lui attribue 16. Il ne déclare pas que D est absent de l’Internet. Il dit seulement à B : « ne passe pas par moi pour cette destination, car mon propre meilleur chemin revient vers toi ».

L’écart entre silence et négation est temporel. Devant une omission, B peut garder une ancienne route par A jusqu’à l’expiration de son temporisateur. Devant une métrique infinie, il peut retirer ce prochain saut dès réception. L’annonce négative révoque un état encore vivant.

Des octets dépensés pour accélérer le retrait

Sur un réseau de campus partagé, un routeur peut avoir appris des centaines de routes par la même interface. L’horizon simple les omet toutes dans le sens du retour. Le poison les énumère avec la valeur 16. Les messages grossissent et peuvent être remplis de chemins que l’émetteur déconseille.

Dans une photographie stable, ces lignes apprennent peu au voisin. Après une panne, elles deviennent précieuses : elles remplacent un ancien positif au lieu d’attendre qu’il vieillisse. RIP ne dissimule pas le choix économique. L’opérateur peut préférer moins de trafic et une convergence plus dépendante des délais, ou davantage de négations explicites pour retirer plus vite.

RFC 1058 permet même une formule hybride : empoisonner pendant la période où l’ancienne route risque de subsister, puis revenir à l’omission. La valeur 16 ne change pas de sens ; seule change la durée pendant laquelle on paie pour la transporter.

Une boucle de deux, pas une preuve universelle

Le résultat le plus net concerne deux routeurs. Si A et B se désignent mutuellement pour D, chacun reçoit de l’autre une annonce infinie sur le chemin de retour. La boucle tombe sans attendre l’expiration.

Avec trois routeurs, la généalogie se cache. A peut dépendre de B, B de C et C de A. Aucun n’entend nécessairement sa propre information revenir directement du voisin qui l’a reçue. L’horizon partagé ne voit pas le cercle entier. Les métriques continuent alors leur ascension vers 16.

Les mises à jour déclenchées réduisent cette fenêtre. Dès qu’un prochain saut se dégrade, le routeur diffuse le changement sans attendre le cycle périodique. Les voisins dont la route dépend de lui adoptent la hausse et la propagent. Mais les messages restent asynchrones : ils peuvent être retardés, croiser une annonce périodique ou rencontrer une autre modification. Une cascade rapide n’est pas une transaction globale.

Retirer avant d’effacer

RIP sépare également invalidation et suppression. Lorsqu’une route expire, elle demeure un temps dans la table avec la métrique 16 et continue d’être annoncée. Ce n’est qu’après le délai de collecte qu’elle est effacée. Une disparition immédiate économiserait une ligne, mais abandonnerait chez les voisins des copies positives sans correctif.

Le poison a donc sa propre durée d’utilité. Une révocation doit rester visible assez longtemps pour atteindre ceux qui conservent encore l’état révoqué. L’effacement vient ensuite.

La même limite en IPv4, IPv6 et sur les liaisons à la demande

RFC 1812 a rendu l’horizon partagé obligatoire pour une implémentation RIP et le retour empoisonné recommandé. Il a toutefois préservé un réglage opérateur, précisément parce que le coût des annonces peut être important, et conseillé de limiter la période d’empoisonnement.

RFC 2080 a repris le mécanisme dans RIPng pour IPv6. Il qualifie le poison de mode préféré, tout en demandant un choix par interface entre absence d’horizon, horizon simple et poison. Le format d’adresse change ; le risque qu’une information dérivée revienne comme preuve neuve demeure.

Sur les circuits qui ne devaient s’ouvrir qu’en cas de besoin, RFC 2091 a ajouté des mises à jour déclenchées ordonnées et acquittées. Même ce transport plus fiable impose le poison. Livrer sûrement une assertion circulaire ne la rend pas vraie.

RFC 2453 conserve enfin le même ensemble pour RIPv2 : 16, horizon, poison, déclenchement et limite à deux routeurs. Les extensions du paquet n’ont jamais transformé cette protection locale en connaissance du chemin complet.

Ce que signifiait réellement « inaccessible »

La route empoisonnée établissait une seule proposition négative : dans cet échange, le routeur qui annonce ne doit pas servir de prochain saut pour une route qu’il a lui-même apprise en revenant par le destinataire. Elle ne prouvait ni l’absence mondiale de la destination, ni la perte de toutes les alternatives, ni une faute du voisin.

Cette modestie fait sa valeur historique. Sans transporter tout le chemin, RIP a rendu une part de la provenance exploitable par la direction de l’annonce, une métrique finie et une durée. Le protocole a stoppé rapidement la boucle qu’il pouvait reconnaître et a laissé écrite la frontière de celles qu’il ne pouvait pas voir.

Sources et limites de preuve

Ces textes établissent le mécanisme et ses exigences, pas les réglages actuels des fournisseurs, la part de déploiement, le temps de convergence d’un réseau précis ni l’intention d’un opérateur. Trigger RIP reste propre aux circuits visés par RFC 2091 ; la préférence de RIPng ne démontre pas l’activation du poison sur chaque interface.