Résumé

  • La RFC 1058 attribuait aux métriques RIP les valeurs de 1 à 15 ; 16 signifiait « inaccessible » et empêchait de représenter des chemins plus longs.
  • Cette petite valeur d’infini bornait le comptage jusqu’à l’infini, mais n’assurait pas une convergence rapide ; la RFC lui associait d’autres protections contre les boucles.

Une route peut être trop longue pour exister

Supposons qu’une passerelle apprenne la disparition d’un réseau. Un voisin annonce encore une route vers celui-ci, route qu’il avait apprise de la première passerelle. Chacune croit alors que l’autre connaît encore un chemin. La destination a disparu, mais les annonces la maintiennent quelque temps dans les tables.

La spécification de 1988 a fixé un arrêt délibérément proche. Dans la RFC 1058, une métrique de 1 à 15 désignait une route utilisable ; 16 indiquait qu’elle était inaccessible. Ce seize n’était donc pas la mesure d’une distance infinie au sens physique. C’était la frontière choisie par le protocole entre une route qu’il pouvait annoncer et une route qu’il devait retirer.

La contrepartie est immédiate : RIP ne peut représenter un chemin valide dont la métrique dépasse 15. Hedrick destinait le protocole aux réseaux de taille modérée et rapporte que ses concepteurs le jugeaient peu adapté au-delà d’un diamètre de 15. Cette limite réduisait aussi le nombre d’incréments qu’une information périmée pouvait parcourir avant que le comptage ne s’arrête.

Le nombre ne réglait pas tout

La RFC 1058 ne présente pas ce plafond comme un remède complet. Elle décrit le comptage jusqu’à l’infini comme un problème de convergence et expose d’autres précautions : split horizon, reverse empoisonné et mises à jour déclenchées. Elles avaient elles aussi leurs limites. Une mise à jour déclenchée pouvait arriver trop tard pour empêcher une ancienne route de circuler ; le comptage restait donc possible.

La limite rendait l’échec fini d’un point de vue, pas inoffensif. Pendant que les passerelles incrémentaient la métrique, elles pouvaient encore envoyer des paquets sur un chemin erroné. « Seize » indique quand le plan de contrôle cesse de considérer la route comme utilisable ; il ne prouve pas que les paquets précédents ont tous atteint leur destination.

La RFC 2453, consacrée à RIP version 2, a conservé seize comme valeur d’infini tout en exposant les limites et les comportements de boucle du protocole. La RFC 1812 classe RIP parmi les protocoles historiques : une mécanique bien documentée n’est pas pour autant un choix universel.

Un réseau modeste faisait partie du calcul

Seize peut sembler un vestige arbitraire. Le raisonnement de la RFC est plus précis : l’infini doit rester aussi petit que possible, car chaque incrément supplémentaire peut prolonger le comptage après une panne, mais il ne doit pas non plus exclure les trajets ordinaires. Le choix met en balance le diamètre du réseau et le temps de récupération quand une information erronée subsiste.

La valeur devient ainsi une hypothèse d’exploitation, pas un simple détail de champ. L’opérateur qui choisissait RIP acceptait une enveloppe topologique. Au-delà, aucun réglage de temporisateur ne pouvait rendre valide une métrique de 16. Le réseau avait atteint la limite de ce que le protocole savait représenter.

Un nombre borné peut contenir la propagation d’une panne, mais seulement en excluant certains états possibles. Qui en supporte le coût : le mécanisme de convergence, l’opérateur contraint de revoir son architecture ou les utilisateurs dont le chemin n’est plus représentable ? En 1988, RIP rendait ce choix visible. Seize marquait l’endroit où sa carte cessait de promettre qu’elle connaissait la route.

Documents primaires : RFC 1058 ; RFC 2453 ; RFC 1812.