Résumé

  • La RFC 7710 avait affecté l’option DHCPv4 160 à la découverte d’un portail captif. Lors d’une expérience menée à l’IETF 106, certains appareils Polycom utilisaient déjà ce code à une autre fin et n’ont pas fonctionné comme prévu lorsqu’ils ont reçu l’URL normalisée.
  • La RFC 8910 a transféré la fonction au code 114. Le registre IANA conserve 160 comme non attribué tout en signalant son ancien emploi et l’usage Polycom : le statut administratif reste ainsi accompagné de sa dette de déploiement.

Une salle de conférence comme banc d’essai

Une norme peut être relue ligne par ligne sans rencontrer le logiciel qui la contredira. L’expérience de réseau de l’IETF 106, organisée à Singapour, a fait l’inverse : elle a présenté le paquet à une population réelle d’équipements. Les clients compatibles avec l’API de portail captif devaient découvrir une venue-info-url. Le mécanisme empruntait alors le code 160, attribué à cette fonction par la RFC 7710 en 2015.

La RFC 8910 rapporte que certains appareils Polycom présents sur ce réseau employaient 160 pour d’autres usages. La valeur contenant l’URL de l’API les a empêchés de fonctionner comme souhaité. Le texte ne précise ni modèle, ni micrologiciel, ni nombre d’appareils, ni format concurrent, ni panne exacte. Une analyse fidèle doit conserver ce silence au lieu de le remplir par une anecdote technique vraisemblable.

Le constat suffisant est plus étroit. Deux décodeurs attribuaient des conséquences différentes au même octet, sur le même réseau, et le résultat a motivé une modification normative. L’expérience n’a pas accordé de droit rétroactif à l’usage non documenté. Elle a montré que la disponibilité inscrite dans un registre ne décrivait pas tout l’état du parc.

Erik Kline a cosigné la RFC 8910 avec Warren Kumari. La RFC 7710, qu’elle remplace, était signée par Kumari, Olafur Gudmundsson, Paul Ebersman et Steve Sheng. La bonne attribution est donc collective. Kline importe ici comme coauteur du texte qui a transformé un échec d’interopérabilité en trace publique durable, non comme inventeur unique du mécanisme ou arbitre des produits concernés.

« Attribué » ne signifie pas « ignoré partout ailleurs »

Dans DHCPv4, le code d’une option tient sur un octet. Le registre permet aux concepteurs de partager un vocabulaire ; sans lui, chaque valeur deviendrait une devinette. Mais le téléphone, le terminal ou l’équipement de salle ne consulte pas IANA avant de traiter une réponse DHCP. Il exécute une version de logiciel installée parfois des années auparavant.

Le registre établit donc l’autorité sémantique : il indique quel usage la communauté de normalisation reconnaît. Il ne constitue pas un scanner universel des firmwares. Un constructeur a pu utiliser une valeur libre pour un besoin privé, un brouillon a pu être abandonné après intégration, ou un produit a pu rester en service bien après la disparition de sa documentation.

Quand le serveur envoie 160 sous forme d’URL, un client CAPPORT y voit une donnée valide. Un autre parseur peut attendre une structure différente et engager une autre transition d’état. La collision n’est pas une divergence d’opinion visible par un humain ; elle est automatique. C’est pourquoi une affectation correcte peut produire un incident de compatibilité sans que le paquet soit malformé selon la norme.

La RFC 3679 avait déjà institutionnalisé cette prudence. Elle rendait à IANA des codes dont les projets n’avaient jamais abouti ou n’étaient pas entrés en usage général, mais réservait d’autres valeurs connues dans des appareils malgré l’absence de RFC publiée. L’enquête sur le terrain et la règle formelle sont deux pièces du même dossier d’attribution.

Le registre conserve la cicatrice

La RFC 8910, publiée en septembre 2020 sur la voie normative, a choisi le code DHCPv4 114 pour le portail captif. Le registre actuel des paramètres BOOTP et DHCP d’IANA associe bien 114 à DHCP Captive-Portal et renvoie à cette RFC.

Le code 160 est désormais marqué Unassigned. Pris seul, ce mot évoque une case blanche. La ligne complète raconte autre chose : 160 avait été attribué par la RFC 7710 et il est connu pour être aussi utilisé par Polycom. La note protège le prochain choix contre l’amnésie. Elle ne prétend pas que l’usage subsiste aujourd’hui ; elle avertit que l’histoire du nombre ne se résume pas à son statut courant.

La renumérotation ne concernait que DHCPv4. L’option de portail captif de DHCPv6 demeure 103 et celle des annonces de routeur IPv6, 37. Ces espaces ont des largeurs et des registres distincts. Dire que « CAPPORT est passé de 160 à 114 » sans qualifier DHCPv4 crée une confusion de namespace au moment même où l’on décrit sa réparation.

Le nouveau nombre ne répare pas à distance les anciens équipements. Il donne aux implémentations futures un point de convergence. Les serveurs doivent modifier leur configuration, les clients compatibles doivent demander ou accepter 114, les relais doivent le transporter et les opérateurs doivent vérifier la fonction finale. Entre la publication et cette convergence existe une période mixte où 160, 114 ou aucun des deux peuvent apparaître.

Tester la fonction, pas seulement le bail

Une migration raisonnable commence par l’inventaire. Quels modèles et versions partagent le domaine de diffusion ? Quels serveurs et relais modifient les options ? Quels appareils dépendent d’un démarrage automatique ou d’un service vocal qui pourrait échouer sans alerte claire ?

Vient ensuite un essai en laboratoire avec la valeur exacte, sa longueur et un contenu représentatif, puis un canari sur un segment hétérogène mais limité. L’opérateur doit comparer l’acquisition d’adresse, le renouvellement, l’achèvement du démarrage, l’enregistrement du service et la tâche applicative réelle. Recevoir un bail prouve que DHCP a avancé ; cela ne prouve pas que l’équipement remplit sa mission.

Il faut également tester le retrait de l’option. Un retour arrière crédible est une configuration serveur prête à supprimer 114 du segment, pas la promesse de diagnostiquer chaque terminal après une panne. Lorsque des appareils anciens ne peuvent être mis à jour, l’isolation du segment ou une politique DHCP différente peut coûter moins cher qu’une migration uniforme qui ignore le parc.

Une norme crédible publie aussi ses résultats négatifs

Le choix de 114 n’est pas une capitulation devant un usage privé. Si toute convention silencieuse valait droit de propriété, aucun registre partagé ne pourrait fonctionner. Mais persister avec 160 au seul motif de son attribution aurait fait supporter le coût de la collision aux exploitants et aux utilisateurs.

La décision crédible relie les deux autorités. IANA tient le registre commun ; un essai borné montre ce que font effectivement les implémentations observées. La norme peut alors conserver son objectif tout en changeant le moyen. Le compte rendu doit rester proportionné : lieu, catégorie limitée d’appareils, effet observé et décision prise, sans accusation plus large.

Ce type de résultat négatif a une forte valeur. Un succès ne vaut que pour la cohorte testée. Une collision publiée révèle l’hypothèse défaillante et donne à d’autres équipes une raison vérifiable de ne pas la répéter. La RFC 8910 ne gomme pas 160 ; elle en fait un avertissement exploitable.

Sources