Résumé

  • Le Datatracker de l’IETF date draft-ietf-pim-gaap-23 du 3 septembre 2026 et place le document en AD Followup ; il s’agit toujours d’un Internet-Draft expérimental, et non d’un RFC approuvé.
  • La version 23 impose 239.0.0.0/10 pour IPv4 et la plage expérimentale définie par le RFC 10028 pour IPv6 afin que des implémentations indépendantes utilisent le même espace de calcul.
  • Le texte reconnaît cependant qu’après une partition un côté peut retenir le candidat +1 et l’autre +2 pour le même nom. Les adresses étant différentes, aucune collision ne se déclenche et le groupe peut rester scindé après la reconnexion.
  • L’absence de collision ne prouve donc pas la convergence du nom de groupe. L’expérience doit observer l’adresse finale et la capacité des participants à se retrouver.
  • Un reçu local de convergence préserverait cette preuve ; il s’agit d’une proposition éditoriale de Daniel Kade, pas d’une exigence de l’IETF.

Une règle commune là où la configuration pouvait diverger

Le journal du Datatracker enregistre la version 23 du Group Address Allocation Protocol le 3 septembre. Le même mouvement fait passer le sous-état du document de Revised I-D Needed à AD Followup et ramène l’examen IANA à Version Changed - Review Needed. Ces mentions décrivent un dossier en cours. Elles ne constituent ni une approbation de l’IESG ni une publication comme RFC.

Le journal des modifications de la version 23 indique qu’elle répond au DISCUSS et aux commentaires d’Éric Vyncke. La portée de l’événement apparaît dans le texte lui-même : une source de divergence est supprimée, tandis qu’une autre devient explicite.

GAAP cherche à attribuer des adresses de groupe multicast sans serveur central d’allocation. Une application fournit un nom de groupe. Le protocole calcule au plus quatre candidats à partir de SHA-256 : le nom, puis ce nom suivi de +1, +2 ou +3. Un nœud annonce le premier candidat dans un message Claim et attend environ un intervalle périodique, soit une minute. S’il ne reçoit pas de revendication où une autre appellation emploie la même adresse réseau, l’application peut commencer à s’en servir. En cas de collision, elle essaie le candidat suivant.

Ce modèle conserve peu d’état collectif. Les nœuds n’ont pas l’obligation de mémoriser les annonces des autres ; chacun suit ses propres allocations et temporisateurs. Après un redémarrage, cet état souple est reconstruit par de nouvelles annonces. La légèreté est voulue. Elle suppose néanmoins que deux logiciels écrits séparément partagent les mêmes paramètres de départ.

La comparaison officielle entre les versions 22 et 23 montre le changement. Les plages d’usage applicatif ne sont plus configurables par l’opérateur. Selon le nouveau raisonnement, une plage réglable ne serait vraiment compatible qu’avec elle-même : l’opérateur contrôle les applications de son domaine, mais pas l’implémentation GAAP que chacune incorpore.

Pour IPv4, la valeur obligatoire devient 239.0.0.0/10. Le document s’appuie sur le RFC 2365, qui recense des blocs disponibles pour étendre la portée Organization-Local, et sur le RFC 5771 pour le cadre d’attribution multicast. Pour IPv6, il choisit les identifiants 0xFE000000–0xFEFFFFFF, réservés à l’usage expérimental par le RFC 10028. Cette dernière plage n’appartient pas à GAAP : d’autres protocoles expérimentaux peuvent l’utiliser.

Cette fixation est une décision d’interopérabilité réelle. Elle empêche deux implémentations conformes de définir chacune « sa » plage avant même de calculer une adresse. Elle n’assure pas pour autant qu’elles retiendront ensuite la même adresse pour un nom donné.

La reconnexion peut préserver deux réponses licites

Le mécanisme de réparation d’une partition sait traiter un scénario précis : les deux côtés emploient la même adresse pour un nom de groupe. Quand la communication revient, les annonces se rencontrent, les horodatages peuvent être comparés et une résolution est possible.

Le scénario ajouté à la version 23 est moins visible. Sur un premier côté, une collision locale sans rapport avec la partition force le nom commun à abandonner son candidat initial au profit de +1. Sur l’autre, une collision locale différente conduit le même nom à +2. Chaque choix respecte la liste fermée des candidats et peut être parfaitement cohérent dans son îlot.

À la reconnexion, aucune paire « même adresse, noms différents » n’apparaît. Un côté annonce une adresse, l’autre en annonce une autre. Le prédicat de collision ne réagit pas. Le document précise alors que le groupe reste scindé et qualifie sa résolution de question ouverte pour l’expérience.

Éric Vyncke avait formulé la question dans son bulletin IESG : si les réseaux séparés avaient utilisé +1 et +2, la situation serait-elle détectée et tout le monde convergerait-il ? La nouvelle version rend la limite visible, mais ne définit pas encore le mécanisme qui la franchirait.

Deux états opposés peuvent donc produire le même compteur rassurant : zéro collision. Dans le premier, un nom mène à une adresse commune et les participants se retrouvent. Dans le second, le nom mène à deux adresses et la population applicative reste divisée. Mesurer seulement les collisions revient à confondre absence d’alarme et présence de rendez-vous.

Le RFC 10019, que cite GAAP comme énoncé du problème, demande qu’une solution décentralisée détecte et résolve les collisions d’adresses apparues pendant une partition temporaire. Cette exigence demeure. Le cas désormais décrit est voisin mais différent : deux adresses distinctes pour le même nom. « Collision réparée » et « nom convergent » doivent donc devenir deux résultats observables, et non deux formulations d’un même succès.

Prouver le rendez-vous, pas seulement l’absence d’accident

Le document assume son statut expérimental. Il dit que l’allocation multicast décentralisée fondée sur le hachage n’a pas été déployée. L’expérience doit déterminer si la détection et la résolution des collisions suffisent en pratique, mesurer les taux de collision selon l’échelle et évaluer le trafic périodique des Claims. Elle sera achevée si l’expérience opérationnelle justifie une évolution vers le Standards Track ou si elle révèle une limite fondamentale exigeant une révision.

Le partage silencieux appartient désormais à ce programme. Un compteur peut dire combien de fois deux noms ont abouti à une même adresse et combien de déplacements ont suivi. Il ne peut pas révéler combien de fois un seul nom a persisté sur deux adresses, puisque le protocole ne classe pas cet état comme collision.

On peut préserver la preuve sans transformer GAAP en service centralisé. Un reçu local de convergence du nom de groupe relierait un identifiant du nom respectueux de la confidentialité, les cohortes situées de part et d’autre de la partition, l’indice de candidat utilisé, les adresses retenues, les dates de séparation et de reconnexion, la voie de détection, la joignabilité applicative après retour du lien et le résultat de la réparation. L’examinateur disposerait alors de trois verdicts honnêtes : convergence observée, divergence observée ou observation insuffisante.

Ce reçu est ma proposition d’analyse. Il ne figure ni dans GAAP ni dans une règle de l’IETF, de l’IANA ou du groupe PIM. Il sert seulement à empêcher qu’un événement négatif non observé soit présenté comme la propriété positive que l’expérience devait vérifier.

Dans Minimum Initial Specification, Localized Future Decision, Lu Heng sépare la petite règle commune des choix futurs laissés au terrain. Les plages fixes jouent ici le rôle de spécification initiale minimale. Les techniques de détection, de stockage et de réparation du cas rare peuvent rester locales pendant l’expérience, à condition que leurs résultats soient comparables et conservés.

Running Code Primary fixe le niveau de preuve. Une nouvelle version, une action IANA ou la levée d’un DISCUSS modifie le dossier institutionnel. Seul un test reproductible peut montrer que deux implémentations, confrontées à des collisions locales différentes, reviennent réellement au même couple nom-adresse après la reconnexion.

La version 23 a donc amélioré l’expérience en nommant sa frontière. La bonne suite n’est pas de laisser les plages fixes masquer l’incertitude. C’est de faire de la convergence une observation à part entière.

Sources

  1. Fiche Datatracker de GAAP
  2. Historique du document GAAP
  3. GAAP, version 23
  4. GAAP, version 22
  5. Comparaison officielle des versions 22 et 23
  6. Bulletin IESG de GAAP
  7. RFC 10019 : problème de l’allocation multicast zeroconf
  8. RFC 10028 : identifiants dynamiques de groupe multicast IPv6
  9. RFC 2365 : multicast IP à portée administrative
  10. RFC 5771 : règles IANA pour les adresses multicast IPv4
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary