Résumé

  • Le RFC 3679 a distingué les numéros d’options proposés mais récupérables des codes PXE et Apple déjà utilisés, quoique dépourvus de description dans un RFC publié.
  • Le RFC 3942 a organisé la transition des codes de la plage privée. Plus tard, le RFC 8910 a déplacé le signalement des portails captifs du code 160 après qu’un essai eut révélé un usage concurrent par Polycom. Un registre constate une coordination, pas un recensement des appareils déployés.

Une bibliographie vide ne signifiait pas un réseau vide

DHCP transporte de petits paramètres pendant la configuration d’une adresse : masque de sous-réseau, routeur ou autres informations de service. Les numéros d’option forment un espace partagé. Garder indéfiniment le numéro d’une proposition abandonnée réduit la place disponible ; réattribuer un code réellement déployé peut amener deux appareils à interpréter différemment le même champ.

En janvier 2004, le RFC 3679 a traité les deux risques. Il a recensé des affectations antérieures dont les propositions avaient expiré, n’avaient jamais reçu de définition publiée ou n’étaient plus utilisées par le protocole de basculement de l’époque. Ces numéros pouvaient revenir dans le pool disponible de l’IANA. Mais une autre section signalait que les options PXE 93, 94 et 97 étaient largement utilisées sans RFC publié. Elle mentionnait aussi des usages Apple des codes 95 et 112 à 114 sans documentation RFC. Le texte demandait de maintenir ces affectations pendant que le groupe de travail DHC en décidait la suite. Le critère déterminant n’était donc pas la publication seule, mais l’usage signalé. RFC 3679

Cette séparation n’affirmait pas que tout usage non documenté méritait un numéro public permanent. Le RFC précisait les motifs de récupération code par code et traitait séparément les cas PXE et Apple connus. Pour les numéros récupérables, il demandait à l’IANA de les replacer dans le pool après les numéros jamais attribués ou déjà rendus. C’était un mémo informatif, pas une preuve que chaque implémentation citée existait toujours ni que toutes les affectations avaient été réglées sur le terrain. Statut du RFC 3679

D’une liste à une transition

Plus tard en 2004, le RFC 3942 a élargi l’espace des options DHCPv4 publiquement définies de 1–127 à 1–223 en reclassant la partie supérieure, jusque-là réservée à l’usage privé. Cette décision ne pouvait pas effacer les configurations locales déjà en place. La norme a donc prévu une transition : un code privé connu pouvait être déclaré indisponible pendant que les éditeurs prévenaient le groupe de travail et l’IANA ; une affectation publique provisoire ouvrait un délai de notification de six mois puis un délai de dix-huit mois pour produire un Internet-Draft. Les sites étaient invités à migrer vers la plage privée restante. RFC 3942

La règle en cas de conflit était plus stricte. Si plusieurs éditeurs démontraient un usage raisonnablement répandu du même numéro, aucun ne pouvait le conserver comme code privé : chacun devait demander une affectation publique ordinaire. Cela ne déclarait pas l’usage privé illégitime. Cela reconnaissait qu’un même numéro ne peut coordonner deux significations incompatibles au seul motif que chaque éditeur l’a utilisé localement. Le RFC a aussi rejeté une extension 16 bits, coûteuse pour les premiers adoptants, ainsi qu’un nouveau format ou cookie magique, qui auraient accru les coûts de compatibilité et de découverte.

Le conflit ultérieur qui rend la nuance concrète

Le RFC 4578 a ensuite décrit les options PXE 93, 94 et 97 comme largement utilisées, tout en notant que les clients PXE demandaient aussi les codes 128–135, non officiellement affectés à PXE et susceptibles d’entrer en conflit avec d’autres usages sur un même réseau. La distinction est utile : constater qu’un client demande un code ne lui confère pas une affectation officielle.

Un cas plus explicite est apparu avec les portails captifs. Le RFC 7710 utilisait d’abord l’option DHCPv4 160 pour annoncer l’URI d’un portail. Pendant un essai sur le réseau de l’IETF 106, certains appareils Polycom utilisaient 160 à d’autres fins ; lorsque l’URI du portail y était transportée, ils ne fonctionnaient pas comme prévu. Le RFC 8910 a donc déplacé le signal vers l’option 114, mis à jour le RFC 3679 et rendu le code 160 à l’état « non attribué », tout en signalant l’usage Polycom connu. Les auteurs décrivent un conflit observé pendant cet essai, pas sa fréquence sur l’ensemble des réseaux. RFC 7710 RFC 8910

Le registre IANA actuel retrace plusieurs destins : le code 83 porte ensuite iSNS, les codes 88 et 89 des options BCMCS, le 114 le portail captif, tandis que le 96 reste non attribué. Les codes 126 et 127 le sont également. Ce sont des états de registre, non la preuve qu’aucun réseau actif n’émet ces valeurs. Une affectation ultérieure ne prouve pas davantage que toutes les implémentations antérieures ont disparu. Registre IANA BOOTP/DHCP RFC 4174 RFC 4280

La Note 72 ultérieure de Lu Heng fournit un écho conceptuel limité : un registre de coordination et la réalité opérationnelle sont deux types de preuves distincts. Elle porte sur l’unicité des numéros Internet, pas sur l’attribution des options DHCP, et n’a ni causé ni approuvé ces décisions. La leçon pratique vient ici des RFC eux-mêmes : récupérer un numéro exige d’examiner son usage, et sa réattribution relève d’une transition, pas d’une simple correction administrative. Note 72

Sources

Contexte normatif complémentaire