Résumé

  • draft-ietf-intarea-dhcp-rate-signaling-00 propose deux débits directionnels sur 64 bits et un type qui distingue information, couche 2 et couche 3. Le nombre décrit une politique de service ; il n’est pas une mesure instantanée de capacité.
  • Le détenteur de l’autorité change au fil du message : le client suggère, le serveur répond, un relais peut remplacer la valeur, et DHCPv6 peut viser plusieurs relais avec des valeurs différentes.
  • Une exploitation fiable doit conserver le message et sa durée de vie, relire la configuration réellement installée, identifier la file active puis observer débit, pertes, marquages et latence. Aucune de ces preuves ne peut être déduite de la précédente.

Un routeur résidentiel reçoit dans une réponse DHCPv6 un débit descendant de 1 000 000 000 bit/s. Son interface affiche aussitôt « 1 Gbit/s ». L’outil de configuration annonce que le façonnage a réussi. Pourtant, lorsque la sauvegarde d’un ordinateur sature la liaison, l’appel vidéo du foyer se dégrade.

Il n’y a pas forcément contradiction. Le milliard peut être la valeur commerciale du profil, pas le résultat d’une mesure. Il peut compter les octets de couche 2 alors que le test présente une charge utile de couche 3. Le routeur peut avoir attaché l’AQM à une interface inactive. Une limitation plus basse peut exister dans l’ONT, le réseau d’accès ou le BNG. Le lien Ethernet local peut, lui, négocier un débit supérieur.

Ce scénario est analytique ; il ne décrit aucun incident recensé. Il sert à lire correctement le projet de groupe de travail, révision 00. Le protocole transporte un énoncé utile. Il ne délivre pas le reçu de son exécution.

Une même valeur, trois réalités

Dans les opérations d’accès, le mot « débit » recouvre souvent trois objets. Le premier est le produit vendu ou la politique attribuée à l’abonné. Le deuxième est la limite effective d’un shaper, d’un policer ou d’une file. Le troisième est ce qu’un flux a obtenu sur un chemin donné, à un moment donné.

L’option proposée transporte surtout le premier objet afin que des équipements puissent construire le deuxième. Seule l’observation établit le troisième. Il faut donc séparer :

Reçu Contenu minimal Ce qu’il ne démontre pas
Signal DHCP octets bruts, sens, type, message, transaction, bail, serveur ou relais installation d’une limite
Contrôle effectif équipement, interface, file, algorithme, valeur relue, modèle d’en-têtes, heure position du goulot ou qualité rendue
Résultat compteurs, marquages ECN, pertes, délai et débit pour une charge définie autorité commerciale ou intention initiale

La séparation permet de revenir en arrière et d’attribuer une défaillance. La fusion produit l’inverse : une base indique que le débit est « appliqué » alors qu’elle ne possède qu’un nombre reçu.

La couche de comptage fait partie du contrat

Les sous-options montante et descendante encodent chacune un entier non signé de 64 bits en bit/s. Le Rate Type précise ce que l’on compte.

Le type 2 désigne la couche 2 : en-tête Ethernet et charge utile, sans FCS ni intervalle intertrame selon le calcul recommandé. Le type 3 désigne la couche 3 : en-tête IP et charge utile, sans dépendre du nombre de balises VLAN ou de tunnels. L’absence de Rate Type impose l’interprétation couche 2. Le type 0 est purement informatif : il est interdit de l’appliquer à l’interface, au shaper, au policer ou à l’AQM.

Un débit L2 de 1 Gbit/s et un débit L3 de 1 Gbit/s ne laissent pas la même place aux données applicatives. La comparaison avec un test de vitesse n’est valide qu’après avoir exposé le périmètre d’octets, l’encapsulation et la méthode. Une interface qui affiche seulement « 1 Gbit/s » détruit cette information essentielle.

Une valeur de type réservée ou inconnue fait rejeter l’option entière ; un sous-code inconnu est simplement ignoré. Si un sous-code apparaît plusieurs fois, la dernière occurrence l’emporte. La décision de décodage doit rester dans la piste d’audit, pas seulement son résultat normalisé.

Zéro possède deux sens distincts selon le champ. Un débit directionnel égal à zéro retire une limite antérieure et revient à la configuration par défaut ; il ne mesure pas une capacité nulle. Un Rate Type égal à zéro signifie « affichage ou télémétrie seulement ». Confondre ces deux règles peut maintenir une vieille limitation ou, à l’inverse, transformer une information en ordre.

« Autoritaire » ne veut pas dire « vrai partout »

Un client DHCPv4 annonce son intérêt dans la Parameter Request List. Il peut proposer une limite ou un type dans DHCPREQUEST, mais ce n’est qu’un indice. Le serveur décide et le client suit le DHCPACK. Un débit présent dans DHCPOFFER peut aider à choisir un serveur, mais il ne doit pas modifier les interfaces.

Le raisonnement est parallèle en DHCPv6 : ORO demande l’option, Request peut suggérer, REPLY porte la réponse applicable. ADVERTISE ne suffit pas. RECONFIGURE peut ensuite provoquer Renew ou Information-request avant T1.

Le serveur peut calculer la valeur depuis un profil local, RADIUS ou un système externe. Un relais DHCPv4, notamment un BNG, peut ajouter, modifier ou retirer l’option. L’autorité du serveur définit donc le comportement attendu par le projet ; elle ne prouve ni l’exactitude du profil, ni la fidélité du relais, ni l’état du plan de données.

RFC 2131 et RFC 8415 donnent les cycles de DHCPv4 et DHCPv6. RFC 3046 éclaire le rôle du relais et RFC 2865 celui de RADIUS. Ces protocoles peuvent porter une décision ; ils ne constatent pas son effet final.

Un seul échange DHCPv6 peut viser plusieurs exécutants

Grâce aux en-têtes relais imbriqués, le serveur DHCPv6 peut mettre une valeur dans la REPLY du client et une autre pour un relais intermédiaire. Le projet donne l’exemple d’un policer de relais légèrement supérieur au shaper montant du CPE, afin d’absorber une petite rafale. Chaque relais doit consommer la copie qui lui est destinée, pas inspecter passivement la copie du client.

Il n’existe donc pas toujours un unique « débit DHCP ». Il existe un ensemble indexé par sens, niveau d’encapsulation, destinataire, source de politique, couche de comptage, bail et période de validité. RFC 6221 fournit le contexte du relais DHCPv6 léger. Il ne prouve pas qu’un relais concret a compris l’option proposée ou programmé le matériel.

Le double empilement transforme le nombre en histoire

Si DHCPv4 et DHCPv6 se contredisent, le projet recommande de préférer v6 et exige de mémoriser le protocole source. À l’expiration du bail v6, une valeur v4 encore valide peut survivre et devenir la source des mises à jour suivantes. Sans bail v4 valide, l’équipement revient à son défaut.

Une colonne débit_courant est incapable de reproduire cette décision. Il faut garder les identifiants de bail, les acquisitions, expirations, priorités, remplacements et motifs de remise à zéro.

Avec PPPoE, la valeur DHCP prime celle reçue dans la réponse d’authentification PPP. Mais la session PPP reste le cadre logique : un zéro explicite retire la limite et la fin de session la révoque implicitement. RFC 2516 décrit la session PPPoE. Une valeur persistante après sa fin n’est plus une priorité ; c’est un ordre orphelin.

La borne physique ne localise pas le goulot

Si un serveur annonce 2 Gbit/s à un CPE dont le port WAN est limité à 1 Gbit/s, le projet recommande de plafonner la configuration à 1 Gbit/s, d’exposer les deux valeurs et de journaliser l’écart. C’est une bonne barrière de sécurité.

Elle démontre seulement que la commande locale n’excède pas une limite connue. Elle ne démontre pas que 1 Gbit/s est disponible, ni que la négociation physique est saine, ni qu’aucune file plus lente n’existe en amont. La bonne désignation est « débit local effectif », pas « capacité disponible ».

L’AQM exige une file réelle

La motivation opérationnelle est solide. Lorsque le port du CPE est plus rapide que le service acheté, une file peut se former dans un équipement amont peu contrôlable. Un shaper local réglé près du bon débit peut déplacer le goulot dans le CPE et permettre à une AQM de contenir le délai.

RFC 7567 expose les objectifs d’une gestion active des files. RFC 9330, RFC 9331 et RFC 9332 ajoutent l’architecture L4S, son usage d’ECN et un algorithme DualQ couplé. Il faut encore placer la bonne file, choisir l’algorithme, configurer ECN, classifier les flux et observer les réactions.

Le projet qualifie correctement son option de facilitateur et laisse la conception de l’AQM hors périmètre. Un entier reçu ne sélectionne pas une discipline, ne l’attache pas au bon egress et ne prouve pas que le délai a baissé sans sacrifier le débit.

L’authentification s’arrête à l’auteur

Le projet rappelle que DHCP est généralement en clair et non authentifié. Un serveur pirate ou un acteur sur le chemin peut injecter une valeur très basse et produire un déni de service local. Des seuils peuvent écarter les petites valeurs absurdes, et la borne physique limite les valeurs trop hautes. Ces garde-fous ne disent pas qui a parlé.

Même une authentification future ne suffirait pas à certifier l’exécution. Elle pourrait attribuer l’ordre à un principal reconnu ; elle ne garantirait ni la fraîcheur du profil, ni l’absence de modification par un relais, ni la création de la file, ni le résultat client.

La primauté du code qui fonctionne place l’effet exécuté au-dessus du symbole. La spécification initiale minimale invite à standardiser un noyau étroit tout en laissant l’évolution locale visible et volontaire. Les couches de réalité donnent la question d’audit : sommes-nous devant un message, une configuration, une file physique ou un service observé ?

Un projet publié n’est pas un déploiement

Le Datatracker présente la révision 00 comme projet actif du groupe Internet Area, à statut visé Informational, publié le 27 août 2026 et expirant le 28 février 2027. Son historique montre qu’il remplace le projet individuel. Le XML du groupe, la fiche du prédécesseur et sa révision 01 permettent de contrôler la filiation.

Ce n’est pas un RFC. Les codes restent TBD. Aucune de ces sources ne prouve une implémentation, une interopérabilité, un gain mesuré ou un incident réel.

Sources