Summary

  • RFC 5237 a retiré la voie d’Expert Review réservée aux informations sous accord de non-divulgation. Les allocations IPv4 Protocol et IPv6 Next Header passent par IESG Approval ou Standards Action sur la base d’une spécification publique susceptible d’être examinée.
  • L’inscription coordonne une signification unique. Elle ne prouve ni code, ni interopérabilité, ni sécurité, ni déploiement. La publicité est une condition de la décision d’allocation, pas un reçu d’exploitation.

Une case perdue pour une raison invisible

La règle antérieure de RFC 2780 autorisait trois chemins : Expert Review, IESG Approval ou Standards Action. L’examen par expert ne devait intervenir que lorsque des informations non divulguées étaient en jeu, l’IESG désignant alors l’expert.

Le compromis semblait étroit. L’entreprise révélait son projet à quelques personnes, protégeait une annonce ou une recherche, puis obtenait un numéro. Pourtant, l’effet de l’allocation n’était pas privé. Chaque pile réseau, analyseur, pare-feu et futur concepteur devait désormais considérer cette valeur comme occupée.

La communauté recevait donc une obligation de coordination sans recevoir le dossier qui la justifiait. Elle devait conserver l’exception, éviter la collision et parfois écrire du code défensif autour d’un sens qu’elle ne pouvait pas vérifier.

RFC 5237 a cessé de faire supporter ce coût aux tiers. Il n’interdit pas de concevoir en secret. Il refuse qu’un secret réclame durablement une parcelle d’un registre partagé.

La rareté impose une question de nécessité

Le champ compte 256 valeurs possibles. Le RFC indiquait qu’en 2008, 55 % étaient utilisés. Ce pourcentage décrit le moment de rédaction ; il ne constitue pas une mesure actuelle du registre.

Le chiffre justifie néanmoins une discipline. Une valeur nouvelle doit résoudre un besoin que les mécanismes existants ne satisfont pas. La décision peut examiner l’existence d’une spécification stable, d’un groupe prêt à l’utiliser, d’une duplication éventuelle et du bon niveau d’abstraction. Un port TCP ou UDP suffit-il ? Faut-il réellement un numéro visible directement dans l’en-tête IP ?

Standards Action demeure pour le travail de normalisation. IESG Approval demeure pour les usages non IETF ou hors Standards Track qui méritent néanmoins une valeur. La suppression vise seulement l’exception confidentielle.

Être public n’est pas devenir une norme

Une spécification publique peut être examinée, contestée et comparée. Cela ne lui confère pas automatiquement le statut de standard IETF. La persistance d’IESG Approval protège précisément des allocations appropriées qui ne passent pas par Standards Action.

Il faut donc conserver plusieurs preuves. Le document public établit ce que le demandeur prétend construire. La décision d’allocation établit que l’usage de la valeur a été autorisé. Le registre IANA conserve le sens assigné. Aucun de ces éléments n’établit qu’un programme fonctionne ou que deux programmes interopèrent.

La publicité ne tranche pas davantage toutes les questions de propriété intellectuelle. Elle permet l’examen requis pour la coordination ; elle ne réécrit pas à elle seule les licences, brevets ou droits commerciaux.

Le registre n’est ni l’auteur ni le laboratoire

IANA administre la table Protocol Numbers conformément aux politiques publiées. Une ligne du registre ne signifie pas qu’IANA a conçu le protocole, choisi sa stratégie commerciale ou testé ses propriétés de sécurité.

Cette distinction protège également IANA d’une autorité imaginaire. Le dépositaire du registre assure la continuité d’une signification unique ; il ne devient pas propriétaire des protocoles ni arbitre général de leur valeur économique.

Dans l’autre sens, le titulaire d’une valeur ne peut pas transformer l’allocation en label de qualité. Le numéro ne prouve pas l’existence d’une implémentation, l’emploi sur un réseau, une compatibilité entre fournisseurs ou un résultat pour les utilisateurs.

L’expérimentation ne disparaît pas

RFC 4727 réserve les valeurs 253 et 254 à l’expérimentation et aux essais. Un prototype peut donc circuler dans un périmètre maîtrisé sans acquérir immédiatement une signification mondiale permanente.

Cette solution comporte des limites. Deux expériences peuvent entrer en conflit. Des équipements intermédiaires peuvent filtrer ou traiter ces valeurs de façon particulière. Le succès dans un laboratoire ne garantit pas le passage sur l’Internet public.

Mais cette imperfection est utile : elle place l’incertitude dans un espace qui l’annonce comme telle. La valeur permanente vient plus tard, lorsque la proposition peut être rendue inspectable et que sa nécessité peut être comparée aux alternatives.

Une règle précise, pas une doctrine universelle

RFC 5237 précise qu’il ne se prononce pas sur les accords de non-divulgation dans d’autres espaces de paramètres. Un registre immense et délégable n’a pas les mêmes contraintes qu’un champ de 256 valeurs interprété par les piles IP.

Le principe économique reste instructif. Le secret procure un bénéfice privé ; la réservation d’un identifiant commun crée un coût collectif. Une bonne politique empêche le premier d’effacer le second.

RFC 8126 a ensuite modernisé le vocabulaire des politiques IANA. Il aide à décrire Specification Required, Expert Review ou IESG Approval, mais il ne faut pas lui faire réécrire l’événement de 2008. RFC 5237, BCP 37, a modifié une règle précise de RFC 2780.

L’allocation doit rester sous la réalité opérationnelle

La chaîne complète commence par une proposition, puis une spécification inspectable, un chemin de décision autorisé et une inscription. Viennent ensuite l’implémentation, les essais interopérables, le déploiement et l’observation du trafic.

Chaque transition peut échouer. Une spécification publique peut révéler une mauvaise architecture. Une valeur allouée peut rester sans code. Deux codes peuvent diverger. Un produit fonctionnel peut ne jamais être activé. Même des paquets observés ne prouvent pas l’utilité annoncée.

La discipline de réalité de Lu Heng évite cette inflation. La transparence vaut mieux qu’une promesse secrète, mais un document public n’est pas du code en fonctionnement. Le registre est un reçu d’unicité, pas un rapport de performance.

Sources

Additional standards record

  1. Texte brut de RFC 5237
  2. Fiche RFC 5237
  3. RFC 5237 dans le Datatracker
  4. Historique de RFC 5237
  5. Errata de RFC 5237
  6. Documents citant RFC 5237