RFC 3115 : le code en service a départagé le texte et IANA

Résumé

RFC 3025 donnait les numéros 37 et 133 aux extensions CVSE et NVSE ; IANA avait inscrit 38 et 134. RFC 3115 a rendu le premier texte obsolète parce que les implémentations courantes suivaient IANA.
Le numéro commandait un comportement de compatibilité : en dessous de 128, une extension inconnue faisait jeter tout le message ; à partir de 128, le récepteur pouvait sauter l’extension et poursuivre.

Le silence d’un agent mobile

Un nœud mobile envoie une demande d’enregistrement. L’agent étranger ne répond pas. Vu depuis l’émetteur, ce silence peut signifier un paquet perdu, un authentificateur invalide, une absence d’état ou une extension critique inconnue. Le protocole ne renvoie aucun indice supplémentaire dans ce dernier cas : « silently discard » ordonne de ne plus traiter le datagramme et de ne pas signaler l’erreur à l’expéditeur.

À l’intérieur du récepteur, pourtant, RFC 3115 attendait une trace. L’implémentation devait pouvoir journaliser l’erreur, conserver le contenu du datagramme jeté et incrémenter un compteur. La frontière entre opacité sur le réseau et visibilité opérateur était intentionnelle.

C’est dans ce mécanisme que deux chiffres erronés deviennent une histoire de gouvernance. RFC 3025, publié en février 2001, avait créé une extension critique propre aux vendeurs ou organisations, CVSE, de type 37, et une extension normale, NVSE, de type 133. Le dépôt IANA avait assigné 38 et 134. En avril, RFC 3115 a repris la spécification, énuméré les deux écarts dans une note de l’éditeur et déclaré RFC 3025 obsolète.

La justification tient en une phrase rare : les implémentations courantes suivaient les assignations IANA. Le texte n’a donc pas imposé ses constantes à un réseau déjà en mouvement. Il s’est réaligné sur les valeurs que les machines échangeaient.

La source ne fournit ni noms de produits, ni versions, ni mesure d’adoption. Elle ne documente aucun incident. Elle prouve seulement que le comportement observé était suffisamment établi pour déplacer le registre normatif. C’est précisément sa force : ne pas exagérer l’observation permet de voir la décision réelle.

« Critique » décrivait le prix de l’ignorance

Depuis RFC 2002, l’espace des extensions Mobile IP était coupé en deux. Lorsqu’un récepteur rencontrait un type inconnu entre 0 et 127, il devait abandonner le message entier. Pour un type inconnu entre 128 et 255, il utilisait la longueur pour franchir les octets qu’il ne comprenait pas, puis traitait le reste.

CVSE 38 appartient donc à la zone non franchissable. NVSE 134 appartient à la zone franchissable. « Critique » ne voulait pas dire prestigieux ou sensible dans l’absolu ; le mot promettait que le message ne conservait pas sa signification sans l’extension. « Normal » promettait le contraire : le récepteur pouvait perdre la fonction privée sans perdre nécessairement le message.

Les deux couples, 37/38 et 133/134, restaient du bon côté de la frontière 128. L’erreur n’inversait donc pas toute la politique. Elle cassait la reconnaissance précise. Un équipement programmé pour 38 ne voyait pas un CVSE lorsqu’un autre émettait 37. Côté normal, l’échec pouvait passer presque inaperçu : le type 133 inconnu était sauté et l’enregistrement poursuivait sa route sans la fonction attendue.

Cette asymétrie produit deux symptômes différents. Une divergence critique ressemble à une disparition. Une divergence normale ressemble à une réussite amputée. Compter seulement les refus ne révèle pas la seconde ; compter seulement les enregistrements acceptés ne révèle pas la fonction privée perdue.

Reconnaître l’enveloppe ne suffisait pas

RFC 3115 séparait deux questions de parsing. Première question : le récepteur connaît-il le type externe 38 ou 134 ? Deuxième question : une fois l’enveloppe ouverte, connaît-il le Vendor/Org-ID et le sous-type administré par cette organisation ?

Si le type CVSE externe restait inconnu, la règle 0–127 imposait le silence et l’abandon. Si le type 38 était reconnu mais que le numéro d’entreprise ou le sous-type privé ne l’était pas, le protocole disposait désormais d’une structure suffisante pour refuser explicitement. Une demande déclenchait un code de rejet. Dans une réponse, un nœud de transit produisait un refus vers l’entité suivante ; un destinataire final considérait la réponse comme rejetée.

Pour NVSE, un identifiant ou sous-type privé inconnu faisait simplement sauter cette extension. Le reste demeurait traitable.

Un journal qui écrit seulement « vendor extension inconnue » fusionne ainsi deux pannes très différentes. Il faut préserver le type externe, la réussite du décodage de l’enveloppe, le numéro d’entreprise, le sous-type, le sens de circulation, le rôle du nœud et la décision prise. Sinon, on ne peut distinguer une constante obsolète dans le parseur d’une capacité privée absente.

Un numéro d’entreprise n’était pas une procuration

Les deux formats contenaient un Vendor/Org-ID de quatre octets. L’octet de poids fort valait zéro ; les trois autres transportaient le code SMI Private Enterprise Number. L’organisation administrait ensuite son propre sous-type de deux octets et la valeur associée.

Cette délégation répartissait l’autorité. IANA attribuait les types Mobile IP externes et les codes de refus. Le registre des numéros d’entreprise identifiait le titulaire du sous-espace. Le titulaire définissait ses sous-types. L’émetteur choisissait quoi envoyer. Le récepteur choisissait quoi implémenter. Les associations de sécurité Mobile IP protégeaient le message lorsque le protocole l’exigeait. La politique locale décidait encore si l’enregistrement était acceptable.

Le numéro d’entreprise ne prouvait donc pas l’origine du paquet. Un authentificateur valide ne donnait pas automatiquement un sens à un sous-type inconnu. Un sous-type reconnu ne constituait pas une autorisation. Et un enregistrement accepté ne garantissait pas le service vu par l’abonné.

RFC 3115 autorisait plusieurs CVSE et NVSE, placés après la partie fixe du message. Les nœuds intermédiaires ne devaient pas modifier leur ordre. Une trace digne de confiance conserve donc la séquence exacte, pas une liste triée pour faciliter l’analyse. L’ordre, les octets authentifiés et la décision du parseur appartiennent au même événement.

Quatre codes, trois rôles, plusieurs provenances

Les codes 100 et 101 appartenaient à l’agent étranger. Le premier signalait un CVSE incompris venant du nœud mobile ; le second un CVSE venant de l’agent de rattachement. Les codes 140 et 141 appartenaient à l’agent de rattachement et distinguaient, eux aussi, la provenance mobile ou étrangère.

Ces nombres localisaient un refus, mais ne racontaient pas l’action finale. Ils ne disaient pas si le nœud mobile avait reçu l’information, quelle valeur privée était recherchée, si une autre procédure avait réussi plus tard ni si le trafic utilisateur avait commencé. Ils formaient une articulation entre agents, pas un verdict commercial.

Cette précision est essentielle lorsqu’une réponse traverse un agent intermédiaire. L’agent peut comprendre l’enveloppe CVSE, découvrir un sous-type qu’il ne sait pas traiter, puis transformer la réponse reçue en rejet transmis. Le journal du seul agent de rattachement ne suffit pas ; le journal du seul mobile non plus. L’histoire est distribuée.

Le registre en ligne devenait une infrastructure active

RFC 1700 avait publié en 1994 une photographie des numéros assignés. RFC 3232 expliquera en 2002 que les bases IANA en ligne avaient remplacé cette série de photographies et que RFC 1700 était devenu incomplet, parfois faux. L’épisode de RFC 3115 se situe exactement dans cette transition.

Le registre en ligne pouvait refléter une allocation sans attendre un nouveau recueil imprimé. Le RFC expliquait la sémantique, mais figeait un instant. Aucun des deux n’était suffisant seul : le registre connaissait 38 et 134, pas toutes les règles de traitement ; le document décrivait les règles, mais avait imprimé les mauvais types.

Aujourd’hui, le registre IANA Mobile IPv4 conserve 38 pour CVSE, 134 pour NVSE, ainsi que les quatre codes d’erreur associés, tous référencés à RFC 3115. C’est une preuve de l’état actuel, pas un historique complet des modifications. Pour comprendre le conflit de 2001, il faut garder le registre et les deux RFC côte à côte.

Les usages ultérieurs ont un périmètre mesurable

RFC 4332 a défini des extensions Cisco pour transmettre préfixe du réseau de rattachement, passerelle, DNS, paramètres DHCP et URL de configuration. RFC 4784 a utilisé le type critique 38 et le numéro d’entreprise 12951 pour trois extensions d’une procédure Verizon Wireless de mise à jour dynamique de clés dans des réseaux cdma2000.

Ces textes montrent des usages spécifiés. Ils ne mesurent ni parc installé, ni réussite d’interopérabilité, ni volume de sessions. Confondre une obligation normative avec un déploiement réel reproduirait précisément l’erreur que l’histoire de RFC 3115 apprend à éviter.

RFC 5612 a ensuite réservé le numéro d’entreprise 32473 pour les exemples. Même une documentation fictive avait besoin d’une identité qui ne puisse être confondue avec celle d’une organisation réelle. RFC 6709 élargira encore le diagnostic : les extensions privées accélèrent certaines innovations, mais des règles faibles pour l’inconnu peuvent créer exposition opérationnelle et défaut d’interopérabilité.

RFC 3115 avait déjà rendu ce coût explicite. Ignorer un CVSE pouvait invalider le message entier ; ignorer un NVSE pouvait supprimer une fonction en laissant survivre l’échange. La compatibilité n’était pas une propriété abstraite : elle était un choix de chute.

Le code n’a pas effacé la norme

L’épisode ne dit pas que le code exécuté possède toujours raison. Il montre une correction plus rigoureuse. Le document, le registre et les implémentations avaient chacun une preuve partielle. Le nouveau RFC a réuni allocation et sémantique autour de la valeur qui circulait déjà.

Une capture aurait prouvé ce qu’un émetteur envoyait, pas ce qu’un récepteur comprenait. Un journal de parsing aurait prouvé une décision locale, pas la réussite de l’enregistrement. Un code 140 aurait prouvé un refus par l’agent de rattachement, pas l’expérience finale. L’assertion de RFC 3115 sur les implémentations est plus forte qu’une simple intention, mais plus faible qu’un recensement universel.

Le bon récit conserve ces limites. RFC 3025 a publié 37 et 133. IANA a assigné 38 et 134. Les implémentations courantes ont suivi IANA. RFC 3115 a corrigé la mémoire normative. Le registre et le RFC divergeaient ; le réseau avait déjà tranché, et le standard a choisi de l’écouter.

Le registre et le RFC divergeaient. Le réseau avait déjà tranché : RFC 3115

Pourquoi c'est important

Résumé

Le silence d’un agent mobile

« Critique » décrivait le prix de l’ignorance

Reconnaître l’enveloppe ne suffisait pas

Un numéro d’entreprise n’était pas une procuration

Quatre codes, trois rôles, plusieurs provenances

Le registre en ligne devenait une infrastructure active

Les usages ultérieurs ont un périmètre mesurable

Le code n’a pas effacé la norme

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance