Résumé

  • Le projet draft-ietf-intarea-dhcp-rate-signaling-00 transporte une valeur de provisionnement vers les équipements d’accès ; il ne mesure ni la capacité physique de la ligne ni le débit obtenu de bout en bout.
  • Une gouvernance crédible doit conserver séparément le forfait, le débit reçu, son type L2 ou L3, les modifications des relais, le réglage effectivement appliqué, le plafond matériel et les mesures horodatées.

L’écran du routeur ne raconte que la dernière étape

Une valeur reçue du réseau possède une autorité visuelle particulière. Si l’interface d’une box affiche un gigabit par seconde juste après une négociation DHCP, l’abonné peut raisonnablement croire que la ligne vient d’être éprouvée. Pourtant, aucun trafic d’essai n’est nécessaire pour produire ce chiffre.

Le projet DHCP Explicit Rate Signaling répond à un problème d’exploitation. Le lien Ethernet entre un équipement d’abonné et un modem ou un terminal optique peut fonctionner à une vitesse supérieure au forfait provisionné. La box ignore alors où se situe le véritable goulot d’étranglement. Une valeur explicite lui permet de placer une file, un shaper ou un mécanisme d’Active Queue Management plus près de la contrainte réelle. Les relais et commutateurs pratiquant le DHCP snooping peuvent également s’en servir.

Mais l’option ne sonde pas le chemin. Elle véhicule une décision. Le serveur peut tirer le débit d’une configuration locale, de RADIUS ou d’un système de politique externe. Ce que reçoit la box est la projection finale d’une chaîne qui peut commencer dans le catalogue commercial, passer par le profil AAA et être retouchée sur le réseau d’accès.

Le statut du texte exige la même précision. La révision 00 est devenue document du groupe INTAREA le 27 août 2026, après que les présidents eurent constaté un consensus en faveur de l’adoption de la version individuelle. Cette adoption organise le travail collectif ; elle ne transforme pas le texte en RFC. La fiche Datatracker n’indique pas de statut RFC visé et les codes demandés à l’IANA sont encore marqués TBD.

Le mot « débit » recouvre plusieurs comptabilités

Le conteneur proposé comprend deux valeurs de 64 bits, exprimées en bits par seconde, pour les sens montant et descendant. Un troisième sous-champ précise la nature de ce taux.

Le type 0 est informatif : il peut être affiché ou utilisé pour la télémétrie, mais il ne doit pas configurer une interface, un shaper, un policer ou un AQM. Le type 2 décrit une comptabilité de couche 2 et constitue la valeur par défaut lorsque le type manque. Le type 3 décrit une comptabilité de couche 3, limitée à l’en-tête IP et à sa charge utile. Le projet souligne que cette dernière correspond plus souvent au débit commercial et à la base employée par les tests de vitesse.

Deux valeurs identiques en apparence peuvent donc produire des résultats distincts. Un contrôle L2 compte des éléments que l’outil L3 ne voit pas. Les balises VLAN et l’encapsulation font varier l’écart. Inversement, un taux informatif peut être parfaitement fidèle à la politique commerciale tout en étant impropre au réglage d’une file. Si le type fondamental est inconnu, le destinataire doit abandonner l’option entière et revenir à ses valeurs par défaut.

Le zéro est lui aussi une instruction. Il signifie « sans limite » et peut supprimer un réglage déjà installé. L’absence d’option, une option mal formée et un zéro explicitement reçu ne sont donc pas trois écritures du même état. Une console qui les réduit à « 0 Mbit/s » détruit une information nécessaire au diagnostic.

Le serveur décide, le relais peut réécrire

Dans l’échange, le serveur est l’autorité pour le DHCPACK ou le REPLY final. Le client peut annoncer sa capacité, demander l’option ou suggérer un débit maximal et une préférence L2/L3 ; il doit néanmoins accepter la valeur décidée par le serveur. Cette autorité est protocolaire et circonscrite. Elle ne certifie ni l’exactitude du forfait source ni la fraîcheur du profil AAA.

Le chemin réserve surtout plusieurs endroits où la valeur peut changer. En DHCPv4, un relais — y compris un Broadband Network Gateway — peut ajouter, modifier ou retirer l’option avant de la transmettre. Un commutateur L2 peut la lire passivement et installer son propre contrôle de trafic. En DHCPv6, les en-têtes de relais imbriqués permettent d’adresser une valeur au client et d’autres aux nœuds intermédiaires. Chaque relais doit agir sur l’en-tête qui lui est destiné, sans fouiller le message du client.

Une même session peut donc porter plusieurs consignes légitimes. Le BNG, un relais d’accès et la box ne contrôlent pas nécessairement le même point ni le même sens du trafic. Afficher uniquement la valeur finale du client revient à effacer les autres décisions.

Le temps compte aussi. Une nouvelle négociation, un renouvellement de bail ou un message Reconfigure en DHCPv6 peut remplacer le réglage. En DHCPv4, une valeur offerte dans DHCPOFFER peut aider à choisir un serveur, mais le client ne doit appliquer l’option que dans DHCPACK. Le type de message, la transaction, le bail et son expiration appartiennent donc à la preuve.

Quand deux gigabits se terminent sur un port d’un gigabit

Le projet décrit explicitement le cas où le débit annoncé dépasse la capacité de l’interface physique. Le client devrait plafonner le shaper, le policer ou l’AQM à la vitesse du port. Il devrait montrer à la fois la valeur reçue et la valeur effective, puis journaliser l’écart.

Cette règle sépare déjà trois réalités : l’annonce du réseau, la consigne effectivement appliquée et la capacité du support local. Un test de vitesse en ajoute une quatrième. Son résultat dépend du serveur choisi, du chemin au-delà de l’accès, de la congestion, du transport, du Wi-Fi et de la charge des terminaux. Un bon test peut conforter une hypothèse ; il ne révèle pas l’origine du champ DHCP.

Les conflits entre protocoles accentuent cette nécessité. Le texte préfère la valeur DHCPv6 en cas de désaccord avec DHCPv4 et demande de mémoriser le protocole source. Lorsque le même sous-champ apparaît plusieurs fois, la dernière valeur traitée l’emporte. Dans un environnement PPPoE, l’option DHCP prime sur les indications propriétaires issues de l’authentification PPP. Un zéro ou la fin de session doit rétablir les valeurs par défaut.

Le résultat courant n’explique aucun de ces arbitrages. Sans historique, impossible de savoir si IPv6 a remplacé IPv4, si un relais a corrigé le serveur, si le port a imposé un plafond ou si une session PPP a effacé l’ancien réglage.

Le registre d’autorité du débit

Il faut donc un petit artefact d’exploitation : un registre d’autorité du débit. Il s’agit d’une proposition éditoriale, non d’une exigence du projet IETF.

Le registre identifie le bail ou la session, l’interface, le protocole DHCP, le type de message, l’heure de réception et l’échéance. Il conserve le forfait contractuel s’il est accessible, les valeurs montante et descendante annoncées par le serveur, leur type de comptabilité et la source de politique connue.

Chaque intermédiaire dispose ensuite de sa propre ligne : valeur reçue, valeur transmise, ajout, retrait ou modification, identité du relais ou du BNG, file ou policer installé localement. En DHCPv6, la couche précise de relay-reply doit être visible. Pour un commutateur qui observe sans agir, le registre ne doit pas inventer une application.

Enfin viennent les conséquences : taux du shaper, du policer et de l’AQM, plafond physique, justification du plafonnement, protocole vainqueur et condition de remise à zéro. Les mesures de performance forment une série liée, avec méthode, extrémités et heure propres. Elles ne remplacent jamais la donnée annoncée.

Le vocabulaire participe au contrôle. « Annoncé », « appliqué », « supporté », « contractuel » et « mesuré » désignent cinq faits. L’étiquette unique « vitesse » les confond. Cette distinction peut paraître minutieuse tant que tout fonctionne ; elle devient décisive au premier litige ou à la première migration.

Une valeur plausible peut encore être fausse

DHCP est souvent dépourvu d’authentification de message. Le projet estime qu’un message forgé pourrait injecter un débit artificiellement bas et provoquer un déni de service. Il propose des seuils de vraisemblance configurés par l’opérateur. C’est l’analyse de risque du texte, pas le récit d’un incident observé.

Un seuil écarte l’absurde, non l’imposture crédible. Il peut également bloquer une réduction légitime. La provenance technique doit donc être complétée par l’autorité administrative : quel système a le droit de sélectionner un forfait, quel relais peut le remplacer et quelle équipe répond de l’écart ?

Le registre IANA actuel des paramètres BOOTP/DHCP ne contient pas encore l’option proposée ni ses futurs registres de sous-options et de types. C’est l’état normal d’un projet avec des codes provisoires. Il ne prouve ni refus ni attribution future. Toute expérimentation doit conserver le numéro privé ou provisoire et la version exacte du texte.

La frontière de la preuve

La recommandation RFC 7567 explique l’intérêt de gérer activement les files au voisinage du goulot. La RFC 9330 montre pourquoi L4S dépend de files courtes et de signaux de congestion exploitables. Un débit de provisionnement exact peut améliorer ces mécanismes et, indirectement, l’expérience mesurée.

Il n’en devient pas une mesure. Une réponse DHCP établit qu’une chaîne d’autorité a transmis une consigne à un instant donné. Pour parler de performance, il faut encore connaître les transformations, l’état réellement appliqué, la limite physique et des observations indépendantes. Le nombre est précis ; la nature de l’affirmation doit l’être tout autant.

Sources