Résumé

  • Le RFC 4957 fait des notifications de couche liaison une entrée de détection d’attachement, pas l’aboutissement d’un service IP.
  • Un changement de point d’accès peut conserver le même sous-réseau, tandis qu’un changement de configuration peut survenir sans événement de lien.

« Link up » paraît définitif : l’association radio est faite, la station Wi-Fi a rejoint un point d’accès ou l’interface Ethernet peut transmettre. Dans un tableau d’incident, ce signal est facilement renommé « connectivité rétablie ». C’est précisément le raccourci que le RFC 4957 empêche de faire.

Ce texte informatif, dont Suresh Krishnan est l’un des éditeurs, inventorie les informations que les technologies d’accès peuvent livrer à IP lorsqu’un équipement change de point d’attachement. Leur rôle est d’accélérer une enquête de configuration. Elles ne certifient ni une adresse utilisable, ni une passerelle, ni un service disponible.

Le RFC le dit sans ambiguïté : une nouvelle connexion de couche liaison peut pousser l’hôte à chercher d’autres indices, par exemple avec une sollicitation de routeur. Elle ne fournit pas à elle seule toutes les entrées nécessaires au processus de détection d’attachement. Préfixes annoncés, joignabilité de la passerelle par défaut et autres preuves IP restent nécessaires. Le signal lance donc une machine d’état ; il n’en est pas l’état final.

Le roaming Wi-Fi fournit l’exemple le plus simple. Un terminal peut quitter un point d’accès et en rejoindre un autre sans quitter le même sous-réseau IP. Compter chaque association comme une reconfiguration produit à la fois du travail inutile et de mauvaises statistiques. L’inverse est aussi vrai : un renumérotage IPv6 peut exiger un changement IP sans notification de lien actif.

Le RFC prévoit même un lien actif non déterministe : l’interface est prête, mais le réseau peut encore bloquer les données. Une indication déterministe ultérieure décrit toujours une condition de couche liaison, selon l’implémentation. Elle ne prouve ni la fin de l’autoconfiguration, ni l’admission par la politique, ni la résolution DNS, ni la réponse d’un service distant, ni l’expérience de l’utilisateur.

Pour l’opérateur, la question est d’abord celle du dessin de la mesure. link_up est une observation locale utile, avec une interface, un point d’attachement, une heure et parfois un contexte radio. Il ne doit pas devenir online, valider le retour d’une application ou clore seul un ticket. Chaque étiquette ajoute une affirmation que le signal n’a pas observée.

La bonne pratique est une échelle de preuves : événement de lien, vérification d’adresse et de préfixe, sonde de passerelle, résolution, réponse de service, puis confirmation visible pour le client. Chaque palier a son observateur, son domaine de panne et sa valeur de responsabilité. Dans un système réparti, un acteur ne doit pas parler à la place des autres.

La leçon durable du RFC 4957 est sobre : un événement de lien est une preuve sur un événement de lien. Sa valeur est de déclencher le test suivant. Il devient trompeur lorsqu’on le présente comme le reçu d’un chemin, d’un service ou d’une expérience qu’il n’a jamais observés.

Sources