Résumé

  • RFC 3936 a partagé les numéros RSVP entre Standards Action, Expert Review et usages privés, sans effacer le comportement déjà codé dans les bits de tête de Class-Num.
  • Le numéro disait donc deux choses différentes : qui pouvait l’attribuer et ce qu’un nœud ancien devait faire d’un objet qu’il ne comprenait pas.

Le sceau de l’entreprise ne suffisait pas

RFC 3936 autorisait plusieurs entreprises à réutiliser le même numéro privé. Pour éviter que leurs formats se confondent, le premier mot de quatre octets devait contenir un numéro d’entreprise SMI provenant du registre public des Private Enterprise Numbers de l’IANA. C’était une imbrication de noms efficace : le code privé pouvait être réemployé, tandis que le mot d’entreprise séparait les grammaires.

Mais ce sceau n’authentifiait rien. Il ne prouvait ni l’identité de l’émetteur, ni la propriété d’un équipement, ni la sûreté du contenu. Un logiciel qui ne reconnaissait pas ce numéro d’entreprise devait encore traiter l’objet selon son Class-Num. La signification interne restait privée ; la conduite imposée au nœud inconnu restait commune.

Cette distinction vient de RFC 2205. L’en-tête d’un objet RSVP contient un Class-Num et un C-Type de huit bits chacun. Si la classe inconnue suit le motif 0bbbbbbb, le nœud rejette le message entier et renvoie une erreur Unknown Object Class. Avec 10bbbbbb, il ignore l’objet sans le transmettre et sans erreur. Avec 11bbbbbb, il ignore sa signification mais le transmet, non examiné et non modifié, dans les messages issus de celui qu’il a reçu. Le dossier officiel de RFC 2205 fixe le statut du texte ; la règle d’exécution, elle, réside dans l’octet.

Trois autorités dans chacun des trois couloirs

RFC 3936, publiée en octobre 2004 comme BCP 96, voulait soumettre les extensions RSVP à un examen suffisant sans interdire l’essai. Elle a donc découpé chaque couloir de comportement en trois zones.

Dans le couloir qui refuse le message, 0–119 relevaient de Standards Action, 120–123 d’Expert Review, et 124–127 de Vendor Private. Dans celui qui élimine seulement l’objet, les plages étaient 128–183, 184–187 et 188–191. Dans celui qui transporte l’objet inconnu, elles étaient 192–247, 248–251 et 252–255. Le registre actuel des paramètres RSVP de l’IANA conserve cette matrice.

Standards Action visait une extension largement acceptée et comprise. Expert Review servait typiquement à l’expérimentation, documentée par un RFC Experimental. Les usages privés n’étaient pas enregistrés un par un. Toutefois, aucun de ces chemins administratifs ne remplaçait les bits de tête. Un code privé 124 pouvait faire refuser tout le message ; un code privé 252 pouvait traverser un ancien nœud intact.

La notice RFC Editor de RFC 3936 indique qu’elle met à jour RFC 2205 et RFC 3209, consacré aux tunnels RSVP-TE. La page des errata de RFC 3936 permet de vérifier les corrections au lieu de modifier silencieusement la règle. Le dossier de RFC 3209 et les extensions GMPLS de RFC 3473 montrent le contexte d’extension, non la preuve d’un déploiement particulier.

Une classe inconnue n’était pas un sous-type inconnu

Le mécanisme des bits de tête ne couvrait que la classe inconnue. Quand la classe était connue mais pas son C-Type, RFC 2205 demandait en général de rejeter le message. Connaître l’enveloppe ne permettait pas de supposer que sa nouvelle variante était inoffensive.

RFC 3936 a donc rendu la politique des C-Type locale à chaque Class-Num. Une nouvelle classe devait définir sa propre règle d’attribution des sous-types. Pour les anciennes classes, Standards Action restait la valeur par défaut, sauf remplacement par un RFC Standards Track ou BCP.

Les sous-objets de route formaient encore un autre espace. RFC 3936 a partagé les types EXPLICIT_ROUTE et RECORD_ROUTE entre normes, expertise et usage privé, avec un mot d’entreprise pour le privé. RFC 2207 fournit le contexte des ports de destination virtuels pour les flux IPsec. Un type de sous-objet n’était pourtant pas un Class-Num et n’héritait pas automatiquement des trois comportements.

Enfin, modifier la procédure d’une entité Standards Action exigeait un RFC Standards Track ; modifier celle d’une entité Expert Review exigeait un RFC Experimental. Le vocabulaire contemporain venait de RFC 2434. RFC 8126 l’a remplacé plus tard, sans devenir l’auteur rétroactif du dispositif de 2004.

Le registre prouve les plages et les affectations publiques. Il ne prouve ni le code installé, ni les valeurs privées utilisées, ni l’interopérabilité. Les essais, traces et versions logicielles seraient nécessaires. Les textes de Heng Lu sur la spécification minimale et l’adoption volontaire et sur la primauté du code en fonctionnement aident à garder ces plans séparés.

RFC 3936 n’a donc pas seulement administré un octet rare. Elle a réparti trois formes d’autorité à l’intérieur de trois réactions déjà exécutables par des machines qui ne connaissaient pas encore l’extension.