Le DHCP expliqué : qui donne son adresse IP à votre appareil

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Quand vous connectez un téléphone au Wi-Fi, il obtient une adresse en moins d'une seconde sans que personne ne lui dise laquelle prendre. Derrière cette évidence se cache un protocole précis, le DHCP, et une conversation en quatre messages. Comprendre ce dialogue, c'est pouvoir réparer soi-même la moitié des pannes réseau domestiques.

Le rôle du DHCP dans un réseau domestique

Pour communiquer sur un réseau IP, une machine a besoin d'au moins quatre informations : une adresse, un masque de sous-réseau qui délimite son réseau local, l'adresse de la passerelle par laquelle sortir et celle d'un résolveur DNS. Jusqu'au milieu des années 1990, ces valeurs se saisissaient à la main sur chaque poste, avec les conséquences prévisibles : masques incohérents et surtout doublons d'adresses, qui coupent brutalement les deux machines concernées. Le Dynamic Host Configuration Protocol, normalisé par la RFC 2131 en 1997, supprime ce travail. Il prolonge BOOTP (RFC 951), conçu pour démarrer des stations sans disque dur, dont il reprend le format de paquet.

Chez un particulier, le serveur DHCP n'est pas une machine dédiée : c'est la box elle-même, qui cumule les fonctions de modem, de routeur, de traducteur d'adresses et de serveur DHCP. Elle gère une plage d'attribution, souvent 192.168.1.100 à 192.168.1.200, prise dans les plages privées de la RFC 1918. Ces adresses ne sont pas routables sur Internet : la distinction est détaillée dans notre guide sur les adresses IP publiques et privées, et le mécanisme qui permet à tous vos appareils de partager une seule adresse publique est expliqué dans le NAT expliqué.

Reste un paradoxe : comment demander une adresse quand on n'en a pas encore ? Le protocole travaille à l'étage inférieur. Le premier message part de 0.0.0.0 vers 255.255.255.255, la diffusion générale que toutes les machines du segment reçoivent, et l'identité du demandeur n'est pas une adresse IP mais son adresse MAC, inscrite dans le champ chaddr. Le tout circule en UDP, le serveur écoutant sur le port 67 et le client sur le port 68.

Le dialogue en quatre temps : DORA

L'obtention d'une adresse suit une séquence de quatre messages, retenue sous l'acronyme DORA. L'ensemble se déroule en quelques dizaines de millisecondes sur un réseau sain. Chaque message porte le même identifiant de transaction, le xid, un nombre tiré au hasard par le client qui permet aux deux parties de rattacher une réponse à la bonne demande.

1. 1. DHCPDISCOVER : le client cherche Le client émet en diffusion, depuis 0.0.0.0:68 vers 255.255.255.255:67, un paquet contenant son adresse MAC, son identifiant de transaction, l'option 53 valant 1, souvent son nom d'hôte (option 12) et la liste des paramètres qu'il souhaite recevoir (option 55). S'il connaît une adresse déjà utilisée auparavant, il la suggère via l'option 50.
   En langage courant : l'appareil crie à la cantonade « quelqu'un peut-il me donner une adresse ? Voici ma carte d'identité matérielle ».
2. 2. DHCPOFFER : le serveur propose Le serveur choisit une adresse libre dans sa plage et répond avec l'option 53 valant 2. L'adresse proposée figure dans le champ yiaddr ; la réponse contient déjà le masque, la passerelle, les serveurs DNS, la durée du bail et l'identifiant du serveur (option 54). Elle part en diffusion, ou en unicast vers l'adresse MAC du client si celui-ci n'a pas positionné le drapeau de diffusion.
   En langage courant : la box répond « prends 192.168.1.132, voici aussi la sortie et l'annuaire, c'est valable un certain temps ».
3. 3. DHCPREQUEST : le client accepte Le client formalise son choix avec l'option 53 valant 3, l'adresse retenue dans l'option 50 et l'identifiant du serveur choisi dans l'option 54. Ce message repart en diffusion, et ce détail a une raison précise : si plusieurs serveurs ont fait une offre, tous entendent laquelle a été retenue et libèrent immédiatement les adresses qu'ils avaient mises de côté.
   En langage courant : l'appareil annonce publiquement « j'accepte l'offre de cette box-là », pour que les autres n'attendent pas inutilement.
4. 4. DHCPACK : le serveur confirme Le serveur valide avec l'option 53 valant 5, inscrit le bail dans sa table et renvoie la configuration complète et définitive. À réception, le client applique les paramètres. Beaucoup d'implémentations émettent alors une requête ARP gratuite pour vérifier que personne d'autre n'utilise l'adresse ; si c'est le cas, le client renvoie un DHCPDECLINE et la séquence recommence.
   En langage courant : la box note le prêt dans son registre, l'appareil se configure, et la connexion fonctionne.

Quatre autres messages complètent le protocole et apparaissent dans les journaux d'une box. Le DHCPNAK est un refus : l'adresse réclamée n'est plus valable, typiquement parce que le client a changé de réseau. Le DHCPDECLINE est l'inverse, émis par le client quand l'adresse reçue est déjà occupée. Le DHCPRELEASE rend le bail avant son terme. Le DHCPINFORM sert à une machine adressée manuellement qui veut seulement récupérer les paramètres annexes, DNS en tête.

Tout ce que le serveur transmet en plus de l'adresse

Réduire le DHCP à la distribution d'adresses est la principale idée reçue sur ce protocole. Un bail transporte un ensemble d'options, codées en triplets type-longueur-valeur et recensées par la RFC 2132 puis par un registre de l'IANA. Voici celles que vous rencontrerez réellement sur un réseau domestique ou en petite entreprise.

Une conséquence pratique passe souvent inaperçue : quand vous modifiez les serveurs DNS dans l'interface de votre box, vous ne touchez pas à la configuration de vos appareils, vous changez la valeur de l'option 6 que la box distribuera au prochain renouvellement de bail. Les appareils déjà connectés gardent l'ancienne valeur jusque-là, d'où l'impression fréquente que « le changement n'a pas été pris en compte ». Notez aussi que l'option 121 n'est pas honorée par tous les clients : sa variante propriétaire numérotée 249 existe précisément parce que l'implémentation a longtemps différé selon les systèmes.

Le bail : durée, renouvellement, expiration

Une adresse DHCP n'est pas attribuée, elle est prêtée pour une durée déterminée : c'est le bail, ou lease. Les box grand public utilisent couramment des baux de l'ordre de la journée, le service DHCP de Windows Server propose historiquement huit jours, et un Wi-Fi de lieu public descend à quelques heures pour recycler vite ses adresses. Le client n'attend pas l'expiration : deux échéances rythment la vie du bail.

T1 : à 50 % du bail	Le client entre en état renewing et envoie un DHCPREQUEST en unicast directement au serveur qui lui a accordé le bail. Un DHCPACK remet le compteur à zéro. Sur un bail de 24 heures, cela se produit au bout de 12 heures.
T2 : à 87,5 % du bail	Si le serveur d'origine n'a pas répondu, le client passe en état rebinding et rediffuse sa demande en broadcast : n'importe quel serveur DHCP du segment peut alors prolonger le bail. Sur 24 heures, cela intervient vers la 21e heure.
Expiration	Sans réponse jusqu'au terme, le client doit abandonner l'adresse, se retirer du réseau IP et recommencer un cycle DORA complet. C'est à ce moment qu'apparaît, si aucun serveur ne répond, l'adresse d'auto-attribution en 169.254.x.x.

Le cas du portable qu'on referme puis qu'on rouvre mérite une explication à part. Au réveil, la machine n'a pas oublié son bail : elle entre dans l'état init-reboot et envoie directement un DHCPREQUEST réclamant l'adresse qu'elle avait avant la veille, sans repasser par la phase Discover. Si vous êtes toujours sur le même réseau et que le bail court encore, le serveur répond DHCPACK et l'adresse ne change pas. Si vous avez changé de réseau (bureau le matin, domicile le soir), le serveur local répond DHCPNAK et la machine repart pour un cycle complet : c'est ce court aller-retour qui explique la seconde d'attente avant que le Wi-Fi ne redevienne fonctionnel.

Pourquoi, alors, une adresse locale change-t-elle sans qu'on ait rien touché ? Quatre causes suffisent à tout expliquer : un appareil éteint plus longtemps que la durée du bail, dont l'adresse est retournée au réservoir ; un redémarrage de la box qui, selon les modèles, efface la table des baux ; une plage d'attribution trop étroite pour le nombre d'objets connectés du logement ; une adresse MAC aléatoire présentée à chaque association, qui fait passer le téléphone pour un appareil neuf. Aucune de ces causes n'affecte votre adresse publique, qui obéit à une logique distincte détaillée dans notre guide sur l'IP fixe.

Réserver une adresse pour un appareil

Une réservation, aussi appelée bail statique, consiste à indiquer au serveur DHCP : « lorsque cette adresse MAC se présente, donne-lui toujours cette adresse-là ». L'appareil continue de faire du DHCP normalement, il reçoit simplement toujours le même résultat.

Ce n'est pas un raffinement d'administrateur : quatre situations ordinaires l'exigent. Une imprimante installée par son adresse IP devient introuvable dès que celle-ci change, et le pilote est à réinstaller sur chaque poste. Un NAS monté automatiquement au démarrage échoue silencieusement pour la même raison. Une caméra consultée depuis une application locale devient inaccessible. Enfin, toute redirection de port pointe vers une adresse interne fixe : si l'appareil visé change d'adresse, la redirection continue de fonctionner mais envoie le trafic vers le mauvais équipement, ce qui est pire qu'une panne franche.

La marche à suivre est semblable sur toutes les box, même si les libellés varient : « baux statiques », « baux permanents », « adresses réservées » ou « DHCP statique ».

1. Relever l'adresse MAC de l'appareil Elle figure souvent sur une étiquette au dos du matériel, dans le menu « informations » d'un téléphone ou d'un téléviseur, et toujours dans la liste des appareils connectés de la box. Six paires hexadécimales, du type a4:5e:60:1f:2b:c8.
2. Ouvrir l'interface d'administration de la box Depuis le réseau local, à l'adresse de la passerelle : 192.168.1.1, 192.168.0.1 ou 192.168.1.254 selon l'opérateur. L'accès demande le mot de passe d'administration, qui ne doit pas être celui d'origine.
3. Trouver la section DHCP Elle se situe dans les réglages réseau ou avancés. Notez au passage la plage d'attribution dynamique, vous en aurez besoin à l'étape suivante.
4. Choisir une adresse cohérente Elle doit appartenir au même sous-réseau que la box. Certaines interfaces imposent de la prendre dans la plage dynamique, d'autres exigent au contraire qu'elle soit à l'extérieur. Un usage répandu consiste à réduire la plage dynamique, par exemple de .100 à .200, et à ranger les équipements fixes en dessous, de .2 à .50.
5. Associer la MAC et l'adresse, puis enregistrer La box vous propose généralement de sélectionner un appareil déjà connu plutôt que de saisir la MAC à la main : c'est plus sûr, une erreur d'un seul caractère rendrait la réservation inopérante.
6. Forcer la prise en compte La réservation ne s'applique pas instantanément : l'appareil garde son bail en cours. Redémarrez-le, ou libérez puis renouvelez son bail avec les commandes de la section suivante, puis vérifiez que l'adresse obtenue est bien celle attendue.

Pourquoi passer par la box plutôt que de saisir une adresse fixe sur l'appareil ? Parce que les deux approches ne réagissent pas du tout de la même façon au moindre changement.

Diagnostiquer une panne DHCP

Le symptôme le plus caractéristique est une adresse commençant par 169.254. Cette plage, définie par la RFC 3927 et connue sous le nom d'APIPA chez Microsoft, est réservée à l'auto-attribution : faute de réponse DHCP, le système tire au sort une adresse dans 169.254.0.0/16, vérifie par ARP que personne ne l'utilise et se la donne. La machine peut alors parler aux autres machines du même câble, mais elle n'a ni passerelle ni DNS, donc aucun accès à Internet. Cette plage figure parmi les adresses IP réservées qu'il est utile de reconnaître d'un coup d'œil.

D'autres symptômes pointent vers le DHCP : une adresse obtenue mais aucune navigation possible (passerelle ou DNS absents), un message « conflit d'adresse IP détecté », ou un appareil qui fonctionne en Ethernet et pas en Wi-Fi. Voici une progression qui isole la cause sans tâtonner.

1. 1. Lire la configuration réellement obtenue Avant toute manipulation, regardez ce que l'appareil a reçu : adresse, masque, passerelle, DNS, et surtout l'identité du serveur DHCP ayant répondu. C'est cette dernière information qui distingue une absence de réponse d'une mauvaise réponse.
2. 2. Écarter la couche physique Un câble mal enfiché ou une association Wi-Fi qui échoue produisent exactement le même symptôme qu'une panne DHCP. Vérifiez que l'interface est bien active et associée avant d'accuser le protocole.
3. 3. Forcer un nouveau bail Libérez le bail en cours puis demandez-en un neuf. Si l'appareil obtient immédiatement une adresse correcte, le problème était un bail périmé ou incohérent, et l'affaire est close.
4. 4. Tester un second appareil Si le téléphone obtient une adresse et pas l'ordinateur, la box va bien : cherchez du côté du poste, en particulier son pare-feu local, qui doit laisser passer l'UDP sur le port 68, ou un pilote réseau défaillant.
5. 5. Examiner la box Le serveur DHCP est-il activé ? La plage d'attribution est-elle saturée ? Un logement moderne héberge facilement plusieurs dizaines d'équipements connectés, et une plage réduite à vingt adresses se remplit sans qu'on s'en aperçoive. Élargissez-la ou réduisez la durée des baux.
6. 6. Vérifier l'unicité du serveur Si la configuration obtenue varie d'un appareil à l'autre ou d'un jour à l'autre, suspectez un second serveur DHCP : c'est l'objet de la section suivante. Une fois l'adresse correcte obtenue, confirmez le chemin complet avec un ping et un traceroute vers la passerelle puis vers l'extérieur.

Windows

ipconfig /all
# Repérez : Bail obtenu, Bail expirant, Serveur DHCP, Passerelle par défaut

ipconfig /release
ipconfig /renew
# Sur une carte précise, ajoutez son nom : ipconfig /renew "Wi-Fi"

netsh interface ipv4 show config
# Vérifie si l'interface est bien en mode automatique (DHCP)

netsh interface ipv4 set address name="Wi-Fi" source=dhcp
netsh interface ipv4 set dnsservers name="Wi-Fi" source=dhcp
# Repasse une interface configurée en fixe vers le mode DHCP

Linux

ip a
ip route
# Adresses des interfaces, puis la route par défaut (la passerelle)

sudo dhclient -r enp3s0 && sudo dhclient -v enp3s0
# Libère puis redemande un bail ; -v affiche le dialogue DORA en clair

nmcli device show enp3s0
sudo nmcli connection down "Wi-Fi maison" && sudo nmcli connection up "Wi-Fi maison"
# La plupart des distributions récentes utilisent le client DHCP intégré
# à NetworkManager : dhclient peut être absent, nmcli prend le relais.

journalctl -u NetworkManager --since "10 min ago" | grep -i dhcp
# Les journaux nomment le serveur qui a répondu et l'adresse accordée

macOS

ipconfig getpacket en0
# Affiche le dernier paquet DHCP reçu, option par option : masque,
# routeur, DNS, durée du bail, identifiant du serveur. Très utile.

sudo ipconfig set en0 DHCP
# Force un nouveau cycle complet sur l'interface en0

Android et iOS

Sur mobile, tout passe par l'interface graphique. Sous Android, ouvrez les paramètres Wi-Fi, touchez le réseau puis modifiez ses paramètres : le champ « Paramètres IP » doit être sur DHCP et non sur « Statique ». Sous iOS, dans les réglages Wi-Fi, touchez le bouton d'information à côté du réseau : l'onglet « IP automatique » propose un bouton « Renouveler le bail » qui déclenche un DHCPREQUEST immédiat. Dans les deux systèmes, l'option « oublier ce réseau » puis une reconnexion efface toute configuration résiduelle ; c'est souvent la manipulation la plus rapide.

Deux serveurs DHCP sur le même réseau

Le protocole n'a aucun mécanisme d'autorité : rien ne dit à un client quel serveur est légitime, il retient la première offre reçue. Sur un réseau domestique, la cause est presque toujours la même : un second routeur, un ancien modem recyclé ou un répéteur Wi-Fi raccordé sans que son propre serveur DHCP ait été désactivé. La signature est reconnaissable : certains appareils accèdent à Internet et d'autres non sans logique apparente, deux machines côte à côte affichent des passerelles ou des sous-réseaux différents, l'impression et le partage de fichiers cessent entre appareils pourtant sur le même Wi-Fi, et le problème se déplace au fil des redémarrages, signe qu'une course entre deux offres se rejoue à chaque connexion.

Le diagnostic tient en une comparaison : relevez sur plusieurs appareils l'identité du serveur ayant répondu, ligne « Serveur DHCP » de ipconfig /all, champ server_identifier de ipconfig getpacket en0 sur macOS, journaux de NetworkManager sous Linux. Deux valeurs différentes confirment le diagnostic, et la seconde vous donne directement l'adresse de l'intrus.

La correction consiste à ne conserver qu'un seul serveur. Sur l'équipement ajouté : désactivez sa fonction DHCP, donnez-lui une adresse fixe hors de la plage dynamique de la box, et raccordez-le d'un port LAN vers un port LAN de la box, jamais par son port WAN, qui créerait un second niveau de traduction d'adresses. Beaucoup de matériels proposent un mode « point d'accès » ou « bridge » qui applique ces réglages en une case à cocher. Redémarrez ensuite les appareils concernés : tant qu'ils gardent leur ancien bail, ils continuent d'utiliser la mauvaise passerelle.

Ce que le DHCP révèle de vos appareils

Un aspect rarement évoqué : le DHCP est bavard, et il l'est en diffusion, donc à la portée de toute machine du même segment. Trois éléments partent à chaque connexion.

Le nom d'hôte d'abord, transmis dans l'option 12. Il reprend le nom donné à l'appareil lors de sa configuration initiale, lequel comporte fréquemment un prénom : se connecter au Wi-Fi d'un hôtel avec un ordinateur nommé « MacBook de Camille » diffuse cette information à tout le réseau. Renommer ses appareils avec un libellé neutre ne coûte rien et se fait dans les paramètres système de chaque plateforme.

La classe du fournisseur ensuite, option 60, qui annonce le type de système. Combinée à la liste des paramètres demandés, option 55, dont le contenu et l'ordre varient d'une implémentation à l'autre, elle forme une empreinte suffisamment discriminante pour deviner le système d'exploitation, souvent sa famille de versions, parfois le type de matériel : sans qu'aucun logiciel n'ait été installé sur l'appareil.

L'adresse MAC enfin, indissociable du protocole puisqu'elle sert d'identifiant. Ses trois premiers octets désignent le fabricant de la carte réseau via un registre public de l'IEEE, ce qui suffit à distinguer un téléphone d'une console ou d'une ampoule connectée. Stable par nature, elle constituerait un identifiant de suivi idéal d'un réseau à l'autre : d'où la randomisation par réseau désormais active par défaut sur mobile. Attention toutefois, elle masque le matériel mais pas le nom d'hôte, qui continue de partir en clair. Le sujet est détaillé dans notre guide sur l'adresse MAC et sa randomisation.

Ces informations restent locales : elles ne franchissent pas votre box et ne sont pas visibles des sites que vous consultez, qui voient tout autre chose, c'est l'objet de notre guide sur les adresses publiques et privées. Le vocabulaire employé ici, bail, préfixe, unicast, diffusion, est repris et défini dans notre glossaire du réseau.

DHCPv6 et SLAAC : IPv6 fonctionne autrement

En IPv6, la configuration automatique ne repose pas sur le même principe. Le mécanisme par défaut s'appelle SLAAC, pour StateLess Address AutoConfiguration (RFC 4862), et le mot important est sans état : aucun serveur ne tient de registre des adresses distribuées. Le routeur émet des annonces contenant un préfixe réseau, presque toujours un /64 ; chaque machine fabrique elle-même son adresse en y accolant un identifiant d'interface de 64 bits, dérivé de sa MAC ou, sur les systèmes modernes, calculé de façon stable mais opaque pour ne pas exposer le matériel, puis vérifie son unicité par une détection de duplication. Les systèmes actuels génèrent en plus des adresses temporaires renouvelées régulièrement (RFC 8981) pour leurs connexions sortantes : d'où les multiples adresses IPv6 affichées simultanément par une même machine.

Le DHCPv6 (RFC 8415) existe, mais son rôle est plus étroit. Les annonces du routeur portent deux drapeaux : le drapeau M réclame une adresse auprès d'un serveur DHCPv6, le drapeau O signale que seuls des paramètres complémentaires y sont disponibles. Une particularité mérite d'être connue avant de bâtir une architecture dessus : Android ne met pas en œuvre le DHCPv6 avec état, et un réseau distribuant l'IPv6 uniquement par ce biais laisserait ces terminaux sans connectivité. À l'inverse, les annonces de routeur peuvent transporter directement les serveurs DNS (RFC 8106), ce qui rend le DHCPv6 facultatif dans la plupart des déploiements domestiques.

Reste le rôle de l'opérateur. Votre box ne reçoit pas une adresse IPv6 unique mais un préfixe entier, obtenu par délégation de préfixe DHCPv6, souvent un /56 ou un /64 selon les opérateurs français. Elle en annonce une portion sur votre réseau local, et chacun de vos appareils dispose alors d'adresses globalement routables : il n'y a plus de NAT à traverser, c'est le pare-feu qui décide ce qui entre. Ce changement de modèle a des conséquences concrètes sur l'accès distant à un équipement domestique, détaillées dans notre guide IPv6 à la maison, et il est particulièrement utile aux abonnés dont l'adresse IPv4 publique est partagée avec d'autres foyers, situation expliquée dans notre page sur le CGNAT.

Questions fréquentes