L’option inconnue indiquait tout de même la conduite à tenir : comment IPv6 a borné l’ignorance

Résumé

• Dès RFC 1883, les deux bits de tête du type d’une option TLV IPv6 indiquaient à un nœud qui ne la reconnaissait pas s’il devait la sauter, abandonner le paquet ou l’abandonner en renvoyant une erreur ICMPv6 précisément localisée.
• Un troisième bit déclarait la mutabilité des données en chemin. Ce contrat limitait l’improvisation, mais ne garantissait ni traitement par chaque routeur, ni passage dans les équipements intermédiaires, ni confiance dans l’option.

Un logiciel ancien pouvait comprendre la limite sans comprendre le sens

Un destinataire reçoit un en-tête Destination Options. Il connaît la structure TLV, lit un type et une longueur, puis rencontre une valeur qu’il n’a jamais implémentée. Le contenu lui est opaque ; la frontière en octets, elle, ne l’est pas.

La première spécification publiée d’IPv6, RFC 1883 en décembre 1995, avait prévu cette rencontre. Le type sur huit bits ne servait pas uniquement de numéro. Ses deux bits supérieurs portaient l’action à effectuer en cas de non-reconnaissance. Le bit suivant disait si les données pouvaient être modifiées avant la destination finale.

L’extension ne recevait donc pas un permis de circuler. Elle livrait à un processeur ignorant une instruction bornée, que celui-ci pouvait appliquer sans inventer le sens des données.

Quatre réponses tenaient dans deux bits

Avec 00, le nœud saute l’option et poursuit l’analyse de l’en-tête. La longueur déclarée lui permet de trouver l’octet suivant. 01 impose l’abandon du paquet. 10 ajoute l’envoi à la source d’un message ICMPv6 Parameter Problem, Code 2, dont le pointeur désigne le type inconnu. 11 prévoit le même signalement, sauf si l’adresse de destination est multicast.

Ces valeurs ne classent pas les options entre bonnes et mauvaises. Elles décrivent ce que l’absence de parseur autorise encore. Une option 00 peut contenir des données dangereuses pour une politique locale ; une option 11 peut être parfaitement légitime mais incompatible avec ce nœud.

Le pointeur ICMP apporte une preuve utile : un processeur a buté sur cet octet précis. Il n’apporte pas une mesure universelle. La réponse peut être limitée, filtrée ou perdue, et son silence ne dit pas si le paquet a été ignoré, bloqué ailleurs ou jamais reçu.

Le cas multicast restait visible

La différence entre 10 et 11 attache au type la règle de signalement vers une source multicast. Dans le premier cas, le rapport part même si la destination était multicast ; dans le second, il est supprimé.

Cette différence rend le risque de trafic d’erreur observable. L’exploitant sait quel comportement le type réclame, puis peut vérifier les limites de débit et les réponses réellement émises. Il ne doit pas déduire qu’un multicast est hostile ni qu’une réponse sera toujours livrée.

La mutabilité ne devait pas devenir une fausse intégrité

Le troisième bit traite une autre question. Zéro affirme que les données de l’option ne changent pas en chemin ; un indique qu’elles peuvent changer. Lorsque le paquet porte un Authentication Header, les données d’une option marquée mutable sont remplacées conceptuellement par des octets nuls lors du calcul et de la vérification de la valeur d’authentification.

IPv6 évitait ainsi de signer comme invariant un champ destiné à évoluer. Mais l’exclusion ne donne aucun droit général de modification. La spécification propre à l’option décide encore quel nœud peut écrire quelle valeur ; le bit signale seulement que cette zone ne peut pas soutenir une promesse d’immuabilité de bout en bout.

Le préfixe faisait partie de l’identité complète

RFC 2460 a précisé que ces trois bits ne formaient pas une politique détachable d’un numéro sur cinq bits. Les huit bits ensemble identifient l’option. Deux motifs qui partagent les cinq bits inférieurs mais diffèrent au sommet sont deux types distincts.

Le même espace de types sert aux en-têtes Hop-by-Hop Options et Destination Options, même si la définition d’une option peut limiter son emplacement. Le traitement suit aussi l’ordre du paquet. Un récepteur ne peut pas chercher plus loin une option familière et l’exécuter avant l’option inconnue qui la précède.

L’ordre empêche une lecture opportuniste : si la première option impose l’abandon, une option ultérieure ne peut pas réhabiliter le paquet après coup.

Une option inconnue n’était pas un en-tête inconnu

La distinction est essentielle. Les bits d’action appartiennent à une option TLV située dans un en-tête d’options déjà reconnu. Ils ne donnent pas automatiquement une longueur ni une conduite à tenir pour une valeur Next Header inconnue.

RFC 6564 a donc recommandé d’utiliser une nouvelle option de destination lorsque ce mécanisme suffit, plutôt que de créer un nouvel en-tête d’extension. Pour les futurs en-têtes devenus indispensables, il a imposé une forme commune portant une longueur. Les anciens formats ne sont pas devenus uniformes pour autant.

RFC 7045 sépare ensuite les rôles. Le destinataire jette un paquet dont il ne reconnaît pas un en-tête d’extension. Un nœud intermédiaire ne devrait généralement pas jeter le paquet pour cette seule raison ; s’il inspecte la chaîne, il doit entretenir sa connaissance des types enregistrés. Ce n’est pas la même opération que lire les bits d’une option inconnue à l’intérieur d’un conteneur connu.

Le terrain a révélé la limite du contrat

Les pare-feu, répartiteurs et routeurs rapides cherchent souvent l’en-tête de transport. Une chaîne longue ou inconnue peut dépasser leur capacité d’analyse, forcer un passage lent ou masquer les champs nécessaires à une règle locale.

RFC 8200 conserve les quatre actions, mais n’impose le traitement Hop-by-Hop aux nœuds de transit que lorsqu’ils sont explicitement configurés. RFC 9098 décrit le choix difficile d’un équipement qui ne trouve pas l’information voulue : transmettre sans l’inspection attendue, jeter, ou consommer une voie de traitement plus rare.

Les trois bits n’abolissent pas ce coût. Ils rendent seulement déterministe la réaction d’un processeur arrivé jusqu’à l’option.

Ce que le type n’autorisait jamais

00 ne signifie pas « sûr ». 11 ne signifie pas « attaque ». Le bit mutable n’autorise pas n’importe quel intermédiaire à écrire. Un type enregistré ne prouve pas le support du chemin, et un message ICMP ne certifie ni l’émetteur ni son intention.

La force du mécanisme vient de sa modestie : une règle commune, une décision au bord local, puis des paquets réels pour prouver le déploiement.

Sources et limites de preuve

La règle naît dans RFC 1883, est clarifiée par RFC 2460 et demeure dans RFC 8200. Les limites relatives aux nouveaux en-têtes et aux nœuds de transit viennent des RFC 6564 et 7045 ; les contraintes d’exploitation, de RFC 9098. Ces textes ne mesurent pas le support ou le taux de perte actuel de tous les réseaux.