Résumé

  • Dans la RFC 6709, « courant » ne désigne ni un petit correctif ni une faible quantité de code. Une extension ne relève de cette catégorie que si le protocole de base et les implémentations déjà déployées peuvent l’ignorer sans conséquence; s’ils doivent évoluer, le changement peut être majeur, même si le format transmis bouge peu.
  • Ce classement ne dispense pas d’examen par des experts. La RFC 6709 recommande de limiter les procédures sans examen et rappelle que même une extension courante peut bénéficier d’un avis expert; la RFC 4775 explique pourquoi les nouveaux attributs RADIUS doivent être discutés avec des spécialistes de l’architecture et des usages existants.

Un même mot, deux décisions

Dans un examen de protocole, deux questions peuvent se confondre. Quel effet l’extension aura-t-elle sur le protocole et sur les systèmes qui l’utilisent déjà ? Quel niveau de relecture faut-il avant que d’autres puissent s’y fier ? L’étiquette « courant » paraît répondre aux deux. La RFC 6709 montre qu’elle ne le peut pas.

L’Internet Architecture Board (IAB) a publié la RFC 6709 en septembre 2012 comme document informatif. Elle s’adresse aux concepteurs du protocole de base comme à ceux des extensions. Le texte reconnaît que l’extensibilité facilite l’évolution progressive, mais qu’elle peut aussi créer des problèmes d’interopérabilité, d’exploitation et de sécurité. La distinction entre extension courante et extension majeure relie les effets probables d’une proposition au niveau d’examen qu’elle peut justifier. Ce sont des recommandations d’architecture, pas une norme Internet ni une règle universelle d’approbation.

La RFC s’inscrit dans une histoire plus longue. Elle cite la RFC 1263, le mémo de 1991 intitulé « TCP Extensions Considered Harmful », comme avertissement antérieur sur les coûts des extensions. Ce document porte son propre débat historique : la RFC 6709 ne reprend pas la controverse sur la frontière entre versions de TCP. Elle estime plutôt que les considérations génériques sur la conception d’extensions n’avaient pas encore été réunies. La RFC 4775, publiée en 2006 comme BCP 125, avait fourni les procédures d’extension des protocoles IETF. La RFC 6709 voulait expliciter le test architectural à appliquer à ce travail.

« Majeure » décrit l’impact, pas la taille du paquet

La RFC 6709 propose huit familles de questions. Une implémentation du protocole sous-jacent doit-elle changer ? La proposition modifie-t-elle une hypothèse architecturale, par exemple en ajoutant un état de session à un protocole conçu sans état ? Ouvre-t-elle un nouvel usage ou une nouvelle échelle susceptible d’augmenter le trafic, la taille des paquets ou la charge de traitement au-delà des capacités des systèmes existants ? Respecte-t-elle le modèle d’extension prévu par le protocole ?

Modifie-t-elle la syntaxe, relie-t-elle des changements entre plusieurs protocoles, touche-t-elle au modèle de sécurité ou aux performances des déploiements existants ?

Un seul de ces effets peut conduire à classer le travail comme majeur. Un nouveau type de message ou un nouveau transport peut exiger une mise à jour même des implémentations déployées qui ne souhaitent pas utiliser la nouvelle fonction. Un changement peut ne modifier aucun octet transmis et pourtant introduire une charge que les anciens algorithmes ne supportent pas. Si le protocole de base ne définit pas de traitement sûr et uniforme des extensions inconnues, une proposition apparemment mineure peut devenir majeure par défaut.

Ce sont les tests de conception proposés par la RFC 6709, pas un barème chiffré ni un diagnostic sur un produit actuel.

La question sous-jacente est de savoir qui doit changer et ce qui arrive à ceux qui ne changent pas. Le volume de code est un mauvais indicateur. Un champ court peut modifier l’analyse d’un message; une valeur plus longue, définie par un fournisseur, peut rester invisible pour le protocole de base. Selon la RFC 6709, le premier cas pourrait être majeur et le second courant, à condition que les conditions de compatibilité soient réellement satisfaites.

« Courante » avait un contour strict

Une extension pouvait être dite courante si elle ne répondait pas aux critères de changement majeur et si le protocole de base la traitait comme une donnée opaque. Elle ne devait pas transformer profondément le motif des messages et des réponses. Ni la spécification de base ni les implémentations déjà déployées ne devaient être modifiées, sauf celles qui choisissaient d’utiliser l’extension. Les autres implémentations ne devaient pas en subir les effets; en général, elles devaient pouvoir l’ignorer sans conséquence négative.

La RFC 6709 cite les options DHCP propres aux fournisseurs, les attributs RADIUS propres aux fournisseurs, les identifiants d’objet d’entreprise pour les modules MIB et les types MIME définis par des fournisseurs. Leur intérêt n’est pas d’être de petites additions. C’est qu’elles peuvent s’insérer dans l’espace que le protocole avait prévu, sans changer ce que doivent faire les systèmes qui n’y participent pas.

Le texte empêche aussitôt une lecture trop permissive. Il recommande d’utiliser avec parcimonie les mécanismes d’extension courante qui impliquent peu ou pas d’examen, par exemple une attribution au premier arrivé, et de les réserver aux cas peu susceptibles de créer des risques d’interopérabilité, de sécurité ou d’exploitation. Il précise aussi qu’une extension courante peut bénéficier d’un regard expert : une option DHCP opaque mais entièrement non structurée peut être inutilement difficile à traiter pour les clients et les serveurs.

RADIUS sépare clairement les deux questions

La RFC 4775, son document compagnon sur les procédures, rend la différence concrète. Elle réserve un traitement particulier aux attributions de paramètres IANA courantes lorsque la spécification existante comporte des consignes claires. Au-delà, elle demande un examen explicite par des experts IETF. Pour les nouveaux attributs RADIUS, elle recommande une discussion avec des personnes qui connaissent l’architecture du protocole et ses usages existants, car l’absence d’une telle discussion crée un risque d’interopérabilité ou de fonctionnement.

La RFC 6709 cite pourtant les attributs RADIUS propres aux fournisseurs comme exemple d’extensibilité courante. Les deux textes ne se contredisent pas. Ils répondent à des questions différentes. « Courante » demande si l’extension respecte l’architecture et si les systèmes qui ne l’emploient pas peuvent l’ignorer sans risque. La RFC 4775 demande quelle procédure et quelle expertise doivent encadrer la proposition. La RFC 6709 laisse explicitement la porte ouverte à l’examen d’experts même lorsque l’extension passe le test « courant ».

La distinction importe : une publication ou une attribution ne démontre pas à elle seule qu’une extension est sans danger, qu’elle a été implémentée ou que les opérateurs l’ont adoptée. Un examen peut faire émerger des problèmes avant qu’une proposition avance. Il ne remplace ni les tests de l’implémentation réelle ni la preuve de son déploiement.

Trois éléments à garder dans le dossier

Un examen utile rend visibles trois questions. D’abord, que change l’extension dans le protocole de base, ses hypothèses, les échanges ou les ressources consommées ? Ensuite, les implémentations qui ne choisissent pas cette fonction peuvent-elles l’ignorer sans danger ? Enfin, quel niveau d’examen du protocole, de la sécurité et de l’exploitation est justifié par ces deux réponses ?

Si le logiciel existant doit changer, si l’ordre des messages évolue, si un état apparaît, si plusieurs protocoles sont liés ou si une hypothèse de sécurité se déplace, il faut expliquer plus solidement pourquoi l’extension serait courante. Si elle est réellement opaque et ne touche pas les non-participants, cela plaide pour cette classification sans interdire pour autant une expertise. Des cas de test doivent encore montrer le comportement des implémentations; une valeur enregistrée ne prouve pas qu’un chemin déployé la transporte correctement.

La RFC 6709 déconseille aussi d’ajouter davantage d’extensibilité que nécessaire au départ. Elle reconnaît que les futurs usages peuvent être inconnus, sans exiger que la conception initiale anticipe toute demande imaginable. Une règle mesurée en découle : ménager un espace de changement sûr, sans présumer que chaque usage futur y tiendra.

Ce que les sources établissent — et ce qu’elles n’établissent pas

La RFC 6709 documente l’approche de l’IAB pour concevoir les extensions; elle ne recense pas empiriquement les implémentations. La RFC 4775 décrit des procédures, pas la preuve que chaque proposition les a suivies. Ces documents établissent les tests et les mises en garde qu’ils formulent. Ils ne montrent pas combien d’extensions ont été déployées, si un réseau particulier en a adopté une ou si une extension précise a provoqué un incident.

La note 64 de Heng Lu propose un autre angle éditorial : définir seulement les règles communes nécessaires à l’interopérabilité, laisser autant que possible les décisions ultérieures aux participants et considérer un changement comme réel lorsqu’il est implémenté et adopté. Il s’agit d’une interprétation ultérieure de BTW, et non d’une déclaration d’intention de l’IAB. Dans cette lecture, « courant » décrit une frontière de compatibilité; une publication, une inscription dans un registre ou un résultat d’examen ne prouve pas l’adoption.

La valeur historique de la RFC 6709 tient à la question qu’elle rend plus difficile à éluder : les anciens systèmes peuvent-ils ignorer l’extension sans dommage, ou leur demande-t-on de changer ? Une fois la réponse établie, le niveau d’examen peut être choisi délibérément. « Courante » ne veut pas dire inoffensive, et « majeure » ne mesure pas le nombre de lignes écrites.

Sources