DHCP
Les réseaux TCP/IP des années 1980 restaient modestes et leur configuration était entièrement statique. Les administrateurs attribuaient manuellement une adresse IP à chaque machine, qui conservait cette information dans sa mémoire secondaire. Toute modification impliquait une intervention directe sur la console, généralement suivie d'un redémarrage du système. Cette approche artisanale convenait aux infrastructures de l'époque, mais elle allait bientôt montrer ses limites.
La croissance des réseaux et l'arrivée des stations de travail économiques sans mémoire secondaire ont bouleversé cette organisation. Il devenait urgent de centraliser l'administration des liaisons entre adresses IP et matériel informatique. Le protocole RARP (Reverse Address Resolution Protocol) émergea comme première réponse : une machine connectée à un segment réseau pouvait désormais découvrir son adresse IP et initier normalement ses communications TCP/IP. Entre temps, BOOTP (Bootstrap Protocol) facilitait la configuration des stations sans disque en récupérant l'ensemble des paramètres TCP/IP et des données système nécessaires au démarrage. L'introduction des agents relais BOOTP permit de franchir les frontières d'un unique segment réseau. BOOTP intégrait déjà un mécanisme d'extension utilisant le dernier champ de la trame pour des données spécifiques, une idée que DHCP reprendrait.
Le RFC 1531 définit DHCP comme standard en octobre 1993. Cette extension de BOOTP corrigeait deux faiblesses majeures : l'obligation d'intervenir manuellement pour ajouter les informations de configuration de chaque client, et l'impossibilité de réutiliser les adresses IP. Le protocole gagna en popularité, ce qui conduisit à des clarifications successives. En 1997, le RFC 2131 devint la référence pour les réseaux IPv4, statut qu'il conserve encore aujourd'hui.
L'arrivée d'IPv6 imposa le développement de DHCPv6, documenté dans le RFC 3315. Il ne s'agissait pas d'une simple transposition de DHCPv4 aux adresses IPv6, mais d'un protocole substantiellement différent. Le changement le plus notable concernait l'identification des clients : DHCPv4 repose sur l'adresse MAC, tandis que DHCPv6 introduit le DUID (DHCP Unique Identifier). La conception de DHCPv6 abandonne le principe d'une adresse unique par périphérique, autorisant les appareils à solliciter plusieurs adresses. Le RFC 3633 ajouta la délégation de préfixe, une fonctionnalité inédite sans équivalent en DHCPv4. Le RFC 3736 étendit les capacités du protocole pour prendre en charge la configuration des clients utilisant l'auto-configuration sans état des adresses.
L'Internet Systems Consortium (ISC) a joué un rôle déterminant dans le développement de DHCP. L'organisation maintient deux systèmes majeurs : ISC DHCP et Kea. Ted Lemon et Vixie Enterprises écrivirent la première implémentation, ISC DHCP, comme référence pour le nouveau protocole. La version 1.0 sortit en juin 1998, suivie un an plus tard par la version 2.0. La version 3.0, publiée en 2001, intégra le support de la norme de basculement IETF et les mises à jour DDNS asynchrones. La version 4.0, en 2007, apporta le support IPv6.
Une équipe d'ingénierie dédiée travaille sur ISC DHCP depuis 2004. Ted Lemon et Shawn Routhier, anciens employés d'ISC, ont contribué au projet pendant de nombreuses années. Thomas Markwalder assure la maintenance principale depuis 2016, tandis que Francis Dupont participe activement au maintien du logiciel depuis 2007. La communauté a enrichi le projet avec un système de stockage des baux LDAP et un script d'affichage des baux.
Kea représente une implémentation entièrement nouvelle, destinée à remplacer ISC DHCP vieillissant. Conçu initialement dans le cadre applicatif BIND 10 pour supporter plusieurs applications DNS et DHCP, le projet s'est recentré sur DHCP après l'arrêt du développement DNS en 2014. Tomek Mrugalski et Marcin Siodelski ont dirigé le développement initial de Kea, qui se distingue par son interface de gestion REST moderne et son architecture modulaire. Contrairement à ISC DHCP, Kea sépare les démons DHCPv4, DHCPv6 et DNS dynamique, et propose des bibliothèques optionnelles pour étendre les fonctionnalités du serveur DHCP principal.
La communauté DHCP s'est structurée autour d'outils complémentaires. Le logiciel perfdhcp, distribué avec Kea, évalue les performances des serveurs DHCP en générant un trafic important depuis plusieurs clients simulés. Il teste les serveurs IPv4 et IPv6, fournissant des statistiques sur les temps de réponse et les requêtes perdues. Le projet Anterius, issu du programme « Google Summer of Code d'ISC », a démontré la possibilité de développer un tableau de bord de gestion léger pour Kea. Plus récemment, le projet Stork, lancé en 2020, propose une interface web robuste et extensible, s'intégrant avec la base de données temporelle Prometheus et l'outil de visualisation Grafana.
DHCP illustre bien la capacité d'adaptation des protocoles réseau aux besoins changeants de l'informatique. D'un simple outil de configuration automatique, il s'est transformé en un système sophistiqué gérant l'attribution dynamique des adresses dans les réseaux modernes. Son développement continu, porté par une communauté active, lui garantit une pertinence durable face aux défis des infrastructures réseaux contemporaines.