Résumé

  • draft-ietf-snac-simple-12 automatise la liaison d’un réseau IPv6 terminal à un lien d’infrastructure, mais traite séparément adressabilité, joignabilité et découverte.
  • Un redémarrage peut faire apparaître un nouveau préfixe alors que des hôtes conservent l’ancien ; une RA récente ou un service visible ne prouve donc pas la continuité de l’application.
  • Le reçu utile conserve les transitions, les durées de vie, la route réellement installée, la découverte et une transaction liée à l’adresse choisie.

Deux fins d’incident

Un routeur SNAC relie un réseau terminal — par exemple un maillage d’objets contraints — à un lien Ethernet ou Wi-Fi adjacent. Le projet de l’IETF vise une expérience sans administration manuelle. Cette simplicité dépend pourtant d’un ensemble d’états qui n’expirent pas au même endroit.

La révision 12 distingue trois objectifs. Un hôte doit obtenir une adresse utilisable hors du réseau terminal. Les hôtes d’infrastructure doivent disposer d’une route de retour. Les services doivent être découvrables par DNS ou DNS-SD. Le quatrième objectif, implicite pour l’utilisateur, est que l’application termine son opération. Ce dernier ne se déduit d’aucun des trois premiers.

Cette différence explique les deux heures de fin. La découverte peut revenir avant la route. Une route peut revenir avant que l’hôte abandonne une ancienne adresse. L’application peut réessayer avec un choix de source différent longtemps après que le routeur s’est déclaré stable.

Un préfixe « convenable » a encore besoin de son routeur

Sur le lien d’infrastructure adjacent, le routeur commence par la découverte IPv6 du RFC 4861. S’il trouve un préfixe on-link convenable, il entre dans STATE-SUITABLE. Sinon, après les sollicitations prévues, il passe à STATE-BEGIN-ADVERTISING et en fournit un.

La convenance n’est pas une propriété permanente du préfixe. Le routeur horodate les Router Advertisements. Une RA âgée de plus de STALE_RA_TIME, dix minutes par défaut, ne compte plus. En parallèle, il vérifie la joignabilité du routeur annonceur ; au-delà de soixante secondes de temps joignable, il lance les sollicitations de voisin nécessaires.

Ces contrôles répondent à deux pannes différentes. Un voisin peut répondre tout en ayant cessé d’émettre les RA dont dépend un nouvel hôte. Une RA peut être récente tandis que son émetteur vient de disparaître. La chaîne d’octets valide n’a donc pas l’autorité de déclarer sa propre continuité.

La dépréciation maintient volontairement deux réalités

Quand il doit fournir le préfixe, le routeur l’annonce avec une durée préférée et une durée valide de trente minutes par défaut. Il annonce aussi, sous forme de Route Information Options du RFC 4191, les préfixes OSNR qui rendent les hôtes terminaux joignables hors de leur réseau.

Si un meilleur préfixe apparaît, le routeur ne supprime pas brutalement l’ancien. Dans STATE-DEPRECATING, il fixe sa durée préférée à zéro et réduit progressivement sa durée valide. Si le meilleur candidat disparaît pendant cet intervalle, il peut reprendre l’annonce de son propre préfixe.

Le mécanisme est réversible au niveau du routeur. La mémoire des hôtes, elle, est distribuée. Ils n’ont pas reçu les mêmes RA au même instant et certains ont pu manquer une diffusion multicast. Le tableau d’état du routeur ne dit pas quelle adresse un client utilise encore.

Le RFC 8978 décrit cette famille de « renumérotations éclair », où le nouveau préfixe arrive sans retrait fiable de l’ancien. Ses valeurs générales de sept jours et trente jours ne sont pas les trente minutes par défaut du préfixe fourni par SNAC. Les confondre serait une erreur. Elles montrent toutefois la même limite : « valide » signifie que le temporisateur local n’est pas terminé, pas que le chemin reste utile.

Le routeur qui revient ne récupère pas son passé

Le scénario de redémarrage le plus révélateur met en jeu deux routeurs. Le premier annonce un préfixe, puis disparaît. Le second prend le relais avec un autre préfixe. Lorsque le premier revient, il voit le préfixe convenable de son pair et ne reprend pas son ancienne annonce.

Des hôtes peuvent encore utiliser l’ancienne adresse. Le routeur revenu reçoit alors un paquet pour un préfixe qu’il ne considère plus on-link. Il peut l’envoyer vers sa route par défaut ou le perdre. Le projet cite exactement le dommage métier : contrôle d’objets temporairement impossible et automatisations en échec.

Il ne faut pas transformer ce scénario en règle selon laquelle tout redémarrage renumérote. Le projet attend la persistance des préfixes ULA générés et indique qu’un client DHCPv6-PD reçoit souvent le même préfixe. Le danger apparaît lorsque l’état est perdu, que l’absence autorise une prise de relais, que le bail expire ou change, ou qu’un maillage se partitionne puis se réunit.

Un /64 stable partagé réduit le risque. Thread dérive par exemple des éléments ULA de son Extended PAN ID. Mais la condition reste explicite : la stabilité est attendue tant que tous les routeurs du même réseau terminal ne redémarrent pas simultanément.

Le préfixe OSNR produit sa propre période de chevauchement

Le préfixe Off-Stub-Network-Routable peut venir d’une délégation DHCPv6 selon le RFC 9915 ou d’un ULA du RFC 4193. Si son annonceur disparaît, d’autres routeurs peuvent maintenir les routes vers l’ancien préfixe. La coordination permettant de conserver ce préfixe jusqu’au retour du propriétaire est hors du périmètre du projet.

Un pair peut donc annoncer son propre OSNR tandis que les routeurs qui se souviennent de l’ancien continuent d’en publier la route jusqu’à expiration. C’est une protection contre la coupure prématurée, non une preuve que les nouvelles sessions choisissent correctement leur adresse.

Le nom peut être visible sans chemin de retour

Le cas RA Guard fournit un test simple. Les RA du routeur SNAC peuvent être bloquées sur le lien d’infrastructure tandis que mDNS continue à exposer le service. L’interface utilisateur retrouve le nom ; l’hôte d’infrastructure n’installe pas la route vers l’OSNR. Une communication sortante via NAT64 peut même rester possible.

Il faut alors comparer trois preuves : le journal du routeur disant qu’il a émis le RIO, la table de routage d’un hôte indiquant s’il l’a accepté, et la transaction de l’application. Les RFC 6762 et RFC 6763 gouvernent la découverte, pas le transfert.

Conserver l’intervalle au lieu de l’aplatir

Le projet recommande déjà d’horodater renumérotations, dépréciations, invalidations, changement du routeur fournisseur et perte ou retour de la route par défaut. Un reçu de continuité doit y joindre l’identité du démarrage, le rôle du préfixe, l’ancienne et la nouvelle phase, la RA et sa fraîcheur, la preuve de voisinage, les deux durées de vie, le RIO, la route observée chez l’hôte, la découverte et une transaction avec l’adresse choisie.

Ce format minimal n’est pas un registre mondial. Il laisse à l’opérateur la rétention, l’accès et la réparation. Il applique la spécification initiale minimale de Lu Heng : rendre les résultats comparables sans centraliser les décisions futures. Il applique aussi les couches de réalité : message, état calculé, route installée et résultat ne doivent jamais se prêter mutuellement une autorité qu’ils n’ont pas.

Sources

  1. Projet SNAC, révision 12
  2. Historique du projet
  3. HTML de la révision 12
  4. Texte de la révision 12
  5. Différence officielle 11–12
  6. RFC 4861
  7. RFC 4191
  8. RFC 4193
  9. RFC 8978
  10. RFC 6762
  11. RFC 6763
  12. RFC 7084
  13. RFC 6146
  14. RFC 7050
  15. RFC 9915
  16. Lu Heng — Minimum Initial Specification
  17. Lu Heng — On Reality Layers
  18. Lu Heng — Running Code Primary