Résumé

  • Dans RFC 9892, le VID Ethernet occupe douze bits : 0x000 ignore le VLAN, 0xFFF est réservé et 0xFFE est la dernière valeur explicite.
  • RFC 9895 impose ce traitement, mais sa section de gestion mentionne 0x0000, 0xFFFF et la plage 0x00010xFFFE; aucune errata correspondante n’était affichée lors de notre vérification.

Un formulaire d’exploitation proposait d’enregistrer la valeur 65534 pour un VLAN. La base l’acceptait. Le problème n’était pas encore un paquet perdu : il se trouvait quatre bits avant le paquet, dans la définition de ce que l’interface autorisait.

RFC 9895 normalise l’extension DLEP dite IEEE 802.1Q Aware Credit Window. Le modem décrit au routeur les flux Ethernet associés à des fenêtres de crédit. Les critères peuvent combiner destination DLEP, identifiant VLAN et PCP. Le routeur ne doit envoyer vers le modem qu’avec un crédit suffisant.

Cette extension repose expressément sur RFC 9892 pour la classification et sur RFC 9893 pour les fenêtres. Une implémentation qui annonce le type d’extension 5 doit prendre en charge les messages, Data Items et traitements correspondants. Le lien entre les textes n’est donc pas informatif : il définit l’assemblage protocolaire.

Dans cet assemblage, RFC 9892 réserve quatre bits de l’octet logique à NumPCPs et douze au VID. Le schéma et le texte concordent : zéro signifie que le VID est ignoré, 0xFFF est réservé, les valeurs explicites vont de 0x001 à 0xFFE.

La section 3 de RFC 9895 emploie des bornes différentes. Elle écrit zéro 0x0000, réserve 0xFFFF et permet 0x0001 à 0xFFFE. Il ne s’agit pas seulement d’ajouter un zéro à gauche : les deux dernières bornes dépassent douze bits. Les versions HTML et XML officielles contiennent la même phrase. La recherche d’errata RFC 9895 ne renvoyait aucun dossier au moment de la rédaction.

Cette observation ne confère pas à BTW le pouvoir de corriger la norme. Elle ne prouve pas davantage qu’un équipement commercial comporte une faille. Elle établit un conflit textuel public, puis oblige chaque intégrateur à montrer quelle règle son système exécute.

Pour l’encodage, la dépendance fournit une réponse praticable. RFC 9895 exige le traitement RFC 9892, dont le champ effectif reste sur douze bits. Une valeur supérieure à 0xFFE ne peut être conservée comme VID explicite. La solution sûre consiste à la refuser à l’entrée, à consigner ce refus et à soumettre le conflit au processus d’errata.

La solution dangereuse est de laisser chaque couche improviser. Une API peut accepter un entier 16 bits, un contrôleur peut conserver la valeur, puis une bibliothèque C appliquer un masque. 0x1001 devient alors VLAN 1. Une autre bibliothèque lève une erreur. Un troisième produit reporte l’échec à l’initialisation DLEP. L’identité du flux dépendrait non de la configuration déclarée, mais de l’endroit où les bits excédentaires disparaissent.

Le retour de configuration doit être testé lui aussi. Si l’API relit 0x1001 tandis que le modem a installé 0x001, l’audit décrit une intention et la file exécute une autre réalité. Un statut « appliqué » n’est probant que s’il couvre la valeur sérialisée et l’état installé chez le pair.

L’ordre des classificateurs augmente l’enjeu. RFC 9892 donne la priorité au couple VLAN/PCP lorsqu’une règle Ethernet et une règle Diffserv correspondent simultanément. La fenêtre DSCP de RFC 9894 ne constitue donc pas un filet de sécurité automatique. Un VID tronqué peut sélectionner une fenêtre Ethernet réelle et écarter le traitement attendu.

Les jokers masquent une autre classe de défaut. RFC 9895 avertit qu’un joker VID ou PCP peut capturer des flux inattendus, y compris ceux apparus après la configuration. Si une règle explicite est rejetée et qu’un joker prend sa place, la connectivité subsiste, mais la séparation change. Le test de disponibilité passe; le contrôle de ressources échoue.

La négociation de l’extension ne prouve pas non plus l’identité des validateurs. Les pairs annoncent leur soutien pendant l’initialisation. Un routeur incapable de supporter toutes les fenêtres proposées peut en retenir un sous-ensemble ou réinitialiser la session; l’écart doit être signalé. Cette discipline de visibilité devrait couvrir aussi les valeurs VID rejetées, normalisées ou masquées.

Une campagne de conformité commence par les frontières : accepter 0x001 et 0xFFE; refuser 0xFFF, 0x1000, 0xFFFF, les nombres négatifs et les bits hauts; n’accepter zéro que pour la sémantique « ignorer le VID ». Elle suit ensuite le même objet depuis l’interface jusqu’aux octets, au parseur pair, à la règle installée et à la relecture.

Il faut ajouter des cas Ethernet contre Diffserv, règle explicite contre joker, reconnexion, réduction du nombre de files et fenêtre sans crédit. RFC 9893 gouverne l’autorisation d’émettre vers le modem; elle ne répare pas une mauvaise classification et ne certifie pas la livraison. RFC 2475 sépare lui aussi classification, conditionnement, comportement par saut et service.

Le registre IANA DLEP attribue la valeur 5 à l’extension. Ce registre coordonne un code commun, pas la validation d’un panneau d’administration. La primauté du code en exécution de Lu Heng ramène l’autorité à la transition vérifiable. La spécification initiale minimale rend cette transition assez étroite pour être testée; les couches de réalité empêchent le statut du document de remplacer la preuve.

Le code local n’abroge pas une RFC. Une interprétation opérationnelle doit rester explicite, réversible et portée vers l’amont. La question de clôture est donc concrète : quel composant refuse le treizième bit, et quel témoin prouve qu’il ne réapparaît jamais sous une autre forme ?

Sources