NRTMv4 : le brouillon de Sasha Romijn ne disait pas ce qu’elle voulait

Résumé

Sasha Romijn, créatrice et mainteneuse initiale d’IRRD, a cosigné NRTMv4, le protocole qui synchronise les miroirs des registres Internet.
Quand IRRD et RIPE NCC ont produit des implémentations séparées, leur désaccord a renvoyé Romijn à son brouillon : la règle écrite différait de celle qu’elle voulait exprimer.
Un relecteur de l’IESG a ensuite corrigé un exemple IPv6 qui utilisait route au lieu de route6. Le document de l’IETF attend toujours son approbation finale.

Le détail tient en un mot : route ou route6. Dans un exemple RPSL destiné à une adresse IPv6, un relecteur de l’IESG a repéré le mauvais type d’objet. Cette faute n’a pas provoqué de panne. Elle a été découverte pendant l’examen du protocole, précisément là où un exemple est censé empêcher deux équipes de coder deux règles différentes.

Sasha Romijn connaît ce problème de l’intérieur. Développeuse indépendante, elle a créé et maintenu IRRD version 4 et cosigné NRTMv4. Ce protocole transporte des enregistrements de registres Internet vers des bases miroir. Les opérateurs s’appuient sur ces données pour construire des filtres de routage et configurer leurs réseaux. Un miroir incertain laisse une question simple sans réponse : quelle copie est à jour ?

Avec NRTMv3, l’initialisation par un dump et la récupération des changements empruntaient des voies différentes. Les numéros de série dépendaient de l’instance interrogée, et le protocole signalait mal l’état réel de la synchronisation. NRTMv4 publie plutôt des instantanés et de petits fichiers delta par HTTPS. Un fichier de notification signé énumère les fichiers et leurs empreintes. Le client vérifie la signature, puis compare chaque fichier à l’empreinte annoncée.

La spécification a pris forme dans plus d’un dépôt de code. Romijn et RIPE NCC ont construit leurs implémentations en parallèle, mais séparément. Lorsque leurs résultats ont divergé, Romijn a d’abord pensé que RIPE NCC avait mal appliqué la règle. Son code suivait son intention ; le brouillon, lui, formulait autre chose. La comparaison a exposé des lacunes dans les premières versions avant qu’une interprétation locale ne devienne la règle par défaut.

L’exemple IPv6 a montré la même faiblesse à plus petite échelle. Un objet route ne remplaçait pas l’objet route6 requis par l’exemple. Pour un lecteur pressé, ce n’est qu’une étiquette. Pour une personne qui implémente le protocole, c’est une instruction.

En mai 2026, Romijn a déclaré que cinq implémentations étaient interopérables. Selon sa présentation, RIPE NCC utilisait déjà NRTMv4 en production et IRRD fonctionnait comme client et serveur. La documentation actuelle de RIPE publie l’URL de production du fichier de notification et la clé publique. Au 2 novembre 2026, l’IETF affiche le brouillon -11 dans la file de l’éditeur des RFC, avec l’approbation finale en attente.

Un texte de protocole n’est pas éprouvé parce que son auteur peut le faire tourner. Il doit guider aussi le code écrit ailleurs. Pour les miroirs qui distribuent des données de routage, cette différence sépare une intention personnelle d’une règle que plusieurs systèmes peuvent suivre.