Résumé

  • draft-ietf-intarea-dhcp-rate-signaling-00 permet d’adresser des débits différents au client et aux relais DHCPv6 ; l’emplacement d’une option dans l’encapsulation fait partie de son autorité.
  • Une exploitation sûre doit conserver la valeur reçue, son niveau d’enveloppe, son auteur, sa cible, sa durée de validité, sa transformation locale et le débit réellement appliqué.

Une réponse DHCPv6 traverse parfois plusieurs relais avant d’atteindre un équipement d’abonné. Le projet de l’INTAREA autorise le serveur à placer une option de débit dans la réponse destinée au client et d’autres options dans les couches RELAY-REPL. Cette architecture répond à un besoin réel : le routeur domestique et le relais d’accès ne sont pas forcément censés appliquer la même limite. Le relais peut, par exemple, recevoir une valeur légèrement supérieure afin de laisser passer les pointes, tandis que le routeur place la file active au véritable goulot.

Ce dessin ne fournit pourtant pas une « vitesse de l’abonné » universelle. Il fournit plusieurs instructions situées. Leur signification dépend de l’acteur visé autant que du nombre transporté.

La révision 00 est un Internet-Draft informatif du groupe INTAREA, daté du 27 août 2026 et expirant le 28 février 2027. Les codes d’option et registres qu’elle sollicite ne sont pas encore des allocations définitives. Aucun déploiement d’opérateur précis n’est démontré par le texte. C’est une proposition de mécanisme, non un constat de marché.

L’enveloppe est une frontière d’autorité

Un relais DHCPv6 doit traiter l’option placée dans l’en-tête qui lui est adressé. Il ne doit pas ouvrir la charge destinée au client et y chercher un chiffre commode pour sa propre file. Cette règle paraît technique ; elle porte en réalité une séparation de mandats.

Posséder le paquet englobant ne donne pas autorité sur toutes les décisions qu’il transporte. Le relais voit une réponse pour pouvoir l’acheminer, mais sa visibilité ne transforme pas automatiquement l’instruction du client en instruction de relais. Il faut donc enregistrer le niveau exact d’encapsulation où la valeur a été trouvée, et non seulement le dernier débit observé.

Imaginons 480 Mbit/s dans l’enveloppe du client et 520 Mbit/s dans celle du relais. Le premier chiffre peut servir à façonner au plus près du foyer ; le second peut maintenir le goulot côté client tout en tolérant une brève pointe sur le nœud d’accès. Un tableau qui signale « conflit DHCP : 480 contre 520 » efface la cible et invente une anomalie. Un tableau qui n’en retient qu’un efface une décision.

La provenance minimale comprend donc le serveur ayant sélectionné la valeur, le relais auquel l’enveloppe était destinée, l’identifiant de transaction, le chemin des encapsulations, le type de débit, le sens amont ou aval et l’instant où l’instruction devient applicable.

Voir une offre n’autorise pas encore à agir

Le projet distingue aussi les états du protocole. Un client peut considérer la valeur reçue dans un ADVERTISE pour choisir un serveur, mais il ne doit l’appliquer qu’après la REPLY. L’information précoce peut peser sur le choix d’autorité ; elle n’est pas encore une autorisation de reconfigurer l’interface.

Cette nuance disparaît si un journal ne conserve que « 500 Mbit/s reçus ». La bonne question est : dans quel message ? Le serveur choisi a-t-il repris la valeur dans sa réponse finale ? Un relais l’a-t-il modifiée ? La durée du bail est-elle encore valide ? Le même nombre change de statut au fil de la transaction.

Le client peut lui-même proposer une valeur et un type de couche. Le serveur reste libre d’accepter, de rejeter ou de transformer cette indication. Une proposition envoyée par l’équipement prouve ce qu’il a déclaré, pas le service acheté ni la politique finalement imposée.

Le type donne son sens au nombre

L’option transporte des débits montant et descendant ainsi qu’un type, notamment couche 2 ou couche 3. Deux valeurs identiques ne représentent pas nécessairement la même quantité si l’une inclut les en-têtes de liaison et l’autre non. Une file calibrée sur le mauvais plan de comptage peut déplacer le goulot qu’elle cherchait à contrôler.

La révision 00 impose une prudence utile : un sous-code inconnu peut être ignoré pour préserver l’évolutivité, mais une valeur inconnue dans un champ compris et indispensable à l’interprétation, tel le type de débit, invalide toute l’option. L’équipement revient alors à sa configuration locale. Il ne doit pas sauver les grands nombres et deviner leur sémantique.

Les répétitions ont elles aussi un ordre : la dernière instance est traitée. Un collecteur qui range les sous-options dans un ensemble non ordonné détruit la possibilité de reproduire la décision. La preuve n’est pas seulement le paquet brut ; elle inclut la décision de l’analyseur et la règle de priorité utilisée.

Le même chiffre peut changer de source

En double pile, le texte donne priorité à DHCPv6 en cas de valeurs divergentes et exige de retenir le protocole source avec la valeur appliquée. Si les deux protocoles annoncent 500 Mbit/s, l’écran peut rester visuellement stable quand le bail DHCPv6 expire et que DHCPv4 prend le relais. Le chiffre ne bouge pas ; sa provenance, sa durée et sa chaîne de confiance changent.

Sans bail DHCPv4 valide, l’équipement retourne à sa configuration par défaut. Dans un contexte PPPoE, la valeur DHCP prime sur celle reçue dans l’authentification PPP, mais la fin de session retire cette autorité. Une valeur valide n’est jamais un droit perpétuel.

Le zéro demande la même discipline. Ici, il signifie absence de limitation ou suppression d’une limite précédemment installée. Il ne mesure pas une ligne sans capacité. Le convertir en statistique de performance fabrique une panne fictive à partir d’une instruction de retrait parfaitement valide.

Du témoin à l’actionneur

Le mécanisme s’étend aux commutateurs pratiquant l’inspection DHCP. Dès qu’un commutateur transforme l’option observée en policer ou en file matérielle, il cesse d’être un simple témoin. Il devient un actionneur de politique.

Il faut alors pouvoir relier l’octet observé à la transaction de configuration : domaine de confiance du port d’entrée, identité de session, niveau d’encapsulation, cible, capacité de l’interface, limite de sécurité, commande envoyée au matériel et état effectivement lu après commit. Un paquet passant devant le commutateur ne prouve pas que cette instruction lui était destinée.

Le texte permet aussi aux relais DHCPv4 de modifier ou de retirer l’option, éventuellement après consultation d’attributs RADIUS ou d’un autre système AAA. La valeur sortie du serveur central et celle reçue par le client sont donc deux pièces de preuve distinctes. RFC 3046 documente déjà le rôle des informations de relais ; RFC 2865 rappelle que l’AAA constitue une autre source d’autorité, avec sa propre fraîcheur.

Un contrôle en clair reste un contrôle

DHCP est souvent transporté sans authentification. Un serveur pirate ou un attaquant sur le chemin peut injecter un débit très faible et produire un déni de service localisé alors que l’adressage IP continue à fonctionner. Un seuil minimal élimine certaines valeurs absurdes. Une limite physique réduit l’effet des valeurs trop élevées. Ni l’un ni l’autre n’authentifie la source.

RFC 3118 définit une authentification DHCP, mais son existence normative ne prouve pas qu’elle est déployée. Le dossier d’exploitation doit constater les protections réelles : ports de confiance, validation de relais, liaison abonné-session, liste de serveurs, mécanismes d’inspection et version de l’enregistrement AAA.

Cette distinction rejoint le principe de la « running code primacy » de Heng Lu : l’autorité se juge dans l’état qui agit, pas dans la description institutionnelle. Une politique centrale peut être légitime et néanmoins être remplacée par un relais, plafonnée par le matériel ou ignorée par l’analyseur. Le reçu final doit montrer ce qui a tourné.

La file n’est pas le résultat

Une connaissance précise du goulot peut aider à placer un shaper et un mécanisme AQM. RFC 7567 explique les dommages causés par les files excessives ; RFC 9330 décrit l’usage de files peu profondes par L4S. Cela ne permet pas de conclure qu’une option DHCP a réduit la latence.

Il faut encore observer la file effective, les marques, les pertes, la distribution de latence, le débit utile, les erreurs et les retours arrière. Le signal est une preuve d’intention. Le commit de configuration est une preuve d’action. L’amélioration du service est une affirmation ultérieure, avec ses propres mesures.

La couche commune à standardiser doit rester mince : direction, plan de comptage, destinataire, état de message, durée, priorité entre protocoles et règle de repli. Elle ne peut garantir ni la vérité du profil abonné, ni la transparence du relais, ni l’efficacité de la file. C’est précisément en refusant cette extension d’autorité qu’un mécanisme interopérable reste gouvernable.

Incertitude

Le projet peut changer, être remplacé ou expirer. Cette enquête n’a vérifié aucun firmware, routeur, relais, commutateur ou réseau de production l’ayant déployé. Les bénéfices de performance et de support sont des motivations proposées ; chaque mise en œuvre doit éprouver ses propres menaces, capacités et sources de politique.

Sources