Résumé

  • RFC 3316 recommandait de réutiliser un nouvel acquittement TCP, un rapport de réception RTCP ou une réponse SIP comme preuve qu’un paquet récent avait franchi le routeur de premier saut.
  • Cette preuve ne valait que pour la progression observée : elle pouvait rafraîchir l’état du voisin et éviter une sonde NUD, mais ne garantissait ni la réussite de l’application, ni la permanence du chemin, ni la validité de n’importe quel trafic entrant.

Sur une liaison cellulaire du début des années 2000, le paquet de trop n’était pas nécessairement une donnée utile. Il pouvait être une question de contrôle à laquelle l’hôte possédait déjà la réponse.

La détection d’inaccessibilité des voisins d’IPv6, NUD, conserve une appréciation récente de la joignabilité du prochain saut. Quand cette appréciation vieillit alors que du trafic continue de partir, l’hôte peut envoyer une Neighbor Solicitation en unicast et attendre la Neighbor Advertisement sollicitée. Sur Ethernet, cet échange accompagne naturellement la résolution d’adresse. Le modèle GPRS et UMTS décrit par RFC 3316 était différent : la liaison ressemblait à un point à point, le seul voisin de l’hôte était le routeur par défaut déjà découvert et il n’existait pas d’adresse de couche 2 à résoudre.

La résolution disparaissait, pas le besoin de détecter un premier saut défaillant.

Le profil proposait donc de regarder ailleurs avant d’émettre une sonde : un protocole supérieur avait-il déjà démontré qu’un paquet envoyé récemment avait progressé ?

La règle générale de Neighbor Discovery donnait le raisonnement. Un nouvel acquittement TCP montre que des données antérieures ont atteint le pair distant. Si ce pair est hors lien, ces données ont nécessairement traversé le routeur de premier saut. Une confirmation de bout en bout contient alors un fait local : au moment du passage, le prochain saut était joignable. L’hôte peut injecter ce fait dans son Neighbor Cache au lieu de demander immédiatement au routeur de se confirmer lui-même.

RFC 3316 adaptait cette logique aux applications cellulaires largement fondées sur UDP. UDP ne fournit pas d’acquittement de livraison ; il fallait donc que l’application révèle un signal doté du bon sens causal. Pour RTP, un bloc de rapport RTCP indiquant que certains paquets avaient été reçus par le pair pouvait convenir. Pour SIP, la réponse à une requête montrait que cette requête était arrivée. Lorsqu’un hôte cellulaire se trouvait côté serveur SIP, l’envoi d’une réponse ne suffisait généralement pas ; la réception ultérieure d’un ACK pouvait en revanche montrer que la réponse à l’INVITE avait atteint l’autre extrémité.

Ces signaux n’étaient pas de simples voyants verts. Chacun devait impliquer la livraison d’un trafic sortant récent. Un datagramme entrant sans rapport ne convenait pas. Une Router Advertisement non sollicitée non plus : elle prouvait seulement le trajet du routeur vers l’hôte, alors que NUD devait évaluer le trajet de l’hôte vers son prochain saut. Voir de l’activité n’est pas démontrer le sens du chemin que l’on teste.

La conclusion restait temporaire. Une confirmation supérieure pouvait placer l’entrée du Neighbor Cache dans l’état REACHABLE pour une durée bornée. Sans nouvelle preuve, l’entrée vieillissait vers STALE ; une émission pouvait l’amener à DELAY, puis à PROBE, où les Neighbor Solicitations dédiées reprenaient. RFC 3316 n’a donc pas supprimé NUD. Il a évité de reposer une question pendant qu’un échange applicatif actif fournissait déjà une réponse valable.

L’économie avait un motif concret. La bande passante radio était limitée et l’utilisateur pouvait être facturé au volume. Supprimer des messages inutiles pouvait préserver la capacité et le coût d’usage. Le texte ne mesure toutefois aucun gain de paquets, de batterie ou de facture. Il décrit un profil d’implémentation fondé sur la topologie et sur des indices déjà disponibles.

RFC 7066, qui a remplacé RFC 3316 en 2013, a conservé les exemples TCP, RTCP et SIP, étendu le contexte à EPS et ajouté la réponse DNS comme indice possible. Cette continuité confirme la persistance du raisonnement dans le profil, non son déploiement dans un appareil ou un réseau particulier.

La leçon n’est pas de confier le routage à l’application. Elle est de ne réutiliser une preuve entre couches que lorsque l’implication est explicite. Le retour du pair renseigne sur le premier saut parce que le paquet sortant a dû le franchir. La conclusion s’arrête là : un rapport RTCP ne garantit pas une bonne qualité média, une réponse SIP ne termine pas un appel, un routeur joignable ne rend pas le service disponible et le succès d’un paquet ne promet rien au suivant.

Sources : RFC 3316, RFC 2461, RFC 4861, RFC 7066, RFC 7849, RFC 8504, RFC 3550 et RFC 3261.