Résumé

  • La RFC 2322 décrit une méthode matérielle pour attribuer les adresses d’un réseau temporaire : une pince à linge en bois représentait un numéro IP, et les pinces non attribuées formaient un pool visible.
  • Le jeton rendait l’état de l’attribution observable, mais une personne le distribuait et recopiait l’adresse et les paramètres communs dans l’ordinateur. Selon le récit de terrain de la RFC, un participant a pris l’adresse du routeur par défaut pour la sienne, interrompant le réseau pendant un certain temps.

La RFC 2322 n’est pas une norme DHCP. Publiée le 1er avril 1998 comme mémo informatif, elle décrit le « peg-DHCP » pour des réseaux de terrain et de petits événements sans administration clairement établie. Son récit commence à Hacking In Progress, rassemblement de trois jours organisé aux Pays-Bas en 1997. Les organisateurs s’attendaient à accueillir des ordinateurs variés pour un réseau TCP/IP avec accès à Internet. Ils craignaient les doublons ou les numéros oubliés, ainsi que les incompatibilités d’un serveur logiciel avec les différentes piles IP. La RFC rapporte cette motivation ; elle ne démontre pas que le DHCP ordinaire échouait.

La proposition matérialisait une partie de l’administration. Une pince représentait une adresse. Les pinces non distribuées suspendues à une corde formaient le pool ; celle qui était attachée près du câble réseau d’un ordinateur montrait où l’adresse était utilisée. Des couleurs pouvaient distinguer les sous-réseaux. Pour un événement de courte durée, le serveur pouvait être une tente ou une table où le personnel distribuait les pinces. Dans un cadre moins contrôlé, les participants pouvaient se servir eux-mêmes. Une fiche ou une affiche donnait les paramètres communs : réseau, masque, passerelle et proxy.

La personne les saisissait ensuite dans son ordinateur et ses applications.

Cette dernière étape est déterminante. Le peg-DHCP ne configurait pas l’interface, ne négociait pas de bail et ne vérifiait pas l’identité du détenteur. Il rendait visibles des éléments de gestion auparavant cachés dans l’état d’un serveur, mais l’humain restait l’adaptateur entre la pince, la fiche et le système d’exploitation. La RFC reconnaît le risque de perte ou de corruption lors de la transcription. Elle donne aussi un exemple précis : à l’événement, quelqu’un a saisi l’adresse du routeur par défaut comme adresse de son propre ordinateur, rendant le réseau inutilisable pendant un certain temps.

Le cycle de vie restait tout aussi local. Le client pouvait rapporter la pince au pool lorsqu’il n’avait plus besoin de l’adresse. Sans personnel, il devait la remettre lui-même. La fin de l’événement pouvait servir de durée de validité approximative, puisque les adresses n’étaient plus valables après le rassemblement. Ce n’est pas l’équivalent de l’échange de baux DHCP décrit dans la RFC 2131, où client et serveur communiquent attribution, renouvellement, rebinding et expiration. La comparaison ne signifie pas « manuel = mauvais, automatique = bon » ; elle oppose une garde visible et un jugement humain à un état protocolaire et à des échanges de messages.

La section sécurité de la RFC délimite franchement le mécanisme : une pince perdue pouvait être récupérée et réutilisée ; la pince et les informations communes sur papier étaient lisibles. Le document déconseille d’y échanger des informations privées. Le jeton représentait une attribution, pas l’identité d’une personne ni un droit authentifié d’utiliser l’adresse. L’idée de transporter la pince par un porteur aviaire est explicitement laissée à l’état expérimental, sans prétention de déploiement.

La valeur historique de la RFC 2322 est donc plus limitée et plus intéressante que sa prémisse humoristique : pour un contexte circonscrit, elle transformait un pool caché en état visible et inspectable, tout en exposant le transfert humain. Cette visibilité pouvait aider à repérer une adresse utilisée ; elle ne pouvait empêcher qu’une mauvaise adresse soit saisie dans une machine.

Sources