Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 2131: Dynamic Host Configuration Protocol

Date de publication du RFC : Mars 1997
Auteur(s) du RFC : Ralph Droms (Computer Science Department)
Chemin des normes
Première rédaction de cet article le 8 mars 2007


DHCP est certainement un des plus grands succès de l'IETF. Mis en œuvre dans tous les systèmes, présent dans presque tous les réseaux locaux, on a du mal à se souvenir de la vie « avant » lorsque la configuration de chaque machine était manuelle.

DHCP permet à une machine (qui n'est pas forcément un ordinateur) d'obtenir une adresse IP (ainsi que plusieurs autres informations de configuration) à partir d'un serveur DHCP du réseau local. C'est donc une configuration « avec état », qui nécessite un serveur, par opposition aux systèmes « sans état » qui ne dépendent pas d'un serveur. Deux utilisations typiques de DHCP sont le SoHo où le routeur ADSL est également serveur DHCP pour les trois PC connectés et le réseau local d'entreprise où deux ou trois machines Unix distribuent adresses IP et informations de configuration à des centaines de machines.

Le DHCP spécifié par notre RFC (qui remplace son prédécesseur, le RFC 1541), ne fonctionne que pour IPv4 ; un compagnon, le RFC 3315 traite d'IPv6. DHCP succède à BOOTP (qui était décrit dans le RFC 951), en introduisant notamment la notion de bail (lease), qui limite la durée de vie d'une allocation d'adresse. DHCP est donc un très vieux protocole, mais qui marche très bien. Son héritage BOOTP (il a même récupéré les numéros de ports) rend parfois la lecture du RFC compliquée car plusieurs concepts ont gardé leur nom BOOTP. De plus, certaines fonctions essentielles de DHCP comme le bail sont mises en œuvre par une option BOOTP, à chercher dans le RFC 1533.

DHCP fonctionne par diffusion. Un client DHCP, c'est-à-dire une machine qui veut obtenir une adresses, diffuse sur tout le réseau (DHCP fonctionne au dessus d'UDP) sa demande. Le serveur se reconnait et lui répond.

Le serveur choisit sur quels critères il alloue les adresses IP (notre RFC dit « DHCP should be a mechanism rather than a policy »). Il peut les distribuer de manière statique (une même machine a toujours la même adresse IP) ou bien les prendre dans un pool d'adresses et chaque client aura donc une adresse « dynamique ». Le fichier de configuration ci-dessous montre un mélange des deux approches.

Par exemple, si le logiciel serveur est celui de l'ISC, sa configuration peut ressembler à :

# My domain
option domain-name "sources.org";
# Nameservers that the clients should use
option domain-name-servers ns.sources.org;

option subnet-mask 255.255.255.0;

# Duration of the lease, in seconds
default-lease-time 600;
max-lease-time 3600;

subnet 172.19.1.0 netmask 255.255.255.0 {
  range 172.19.1.8 172.19.1.10;

  # The default router to use. Do note that the DHCP server lets you
  # specify it as a name, not an address
  option routers gw.sources.org;

  # Dynamic pool of IP addresses. Up to twenty clients.
  range 172.19.1.100 172.19.1.120;
}

# This machine has a fixed (static) IP address
host preston {
  hardware ethernet  08:00:20:99:fa:f4;
  fixed-address preston.sources.org;
}

Sur le serveur, toujours avec ce logiciel, le journal indiquera les arrivées et départs des clients :

Mar  8 20:18:38 ludwigVI dhcpd: DHCPDISCOVER from 08:00:20:99:fa:f4 via eth0
Mar  8 20:18:38 ludwigVI dhcpd: DHCPOFFER on 172.19.1.2 to 08:00:20:99:fa:f4 via eth0
Mar  8 20:18:38 ludwigVI dhcpd: DHCPREQUEST for 172.19.1.2 from 08:00:20:99:fa:f4 via eth0
Mar  8 20:18:38 ludwigVI dhcpd: DHCPACK on 172.19.1.2 to 08:00:20:99:fa:f4 via eth0

Le client a d'abord cherché un serveur (section 3.1 du RFC), avec DHCPDISCOVER, le serveur lui a répondu en proposant l'adresse IP 172.19.1.2 (DHCPOFFER), le client l'a formellement demandé (DHCPREQUEST) et le serveur a confirmé (DHCPACK).

Et le client ? Il existe des clients DHCP dans tous les systèmes. Lorsqu'on configure une machine MS-Windows pour « Acquérir automatiquement une adresse IP », c'est en DHCP qu'elle demande. Sur Unix, un client courant est dhclient, ou bien pump. Sur une machine NetBSD, on configure dans /etc/rc.conf l'utilisation de dhclient pour avoir un client DHCP :

dhclient=YES
dhclient_flags=hme0

On notera que le démon dhclient tournera en permanence. Il faut en effet demander périodiquement le renouvellement du bail (délai de dix minutes dans la configuration du serveur vue plus haut). Sur une machine Debian, la configuration du client serait, dans /etc/network/interfaces :

auto eth0
iface eth0 dhcp

Il faut bien noter (et notre RFC le fait dans sa section 7) que DHCP n'offre aucune sécurité. Comme il est conçu pour servir des machines non configurées, sur lesquelles on ne souhaite pas intervenir, il n'y a même pas un mot de passe pour authentifier la communication. Un serveur DHCP pirate, ou, tout simplement, un serveur DHCP accidentellement activé, peuvent donc être très gênants.


Téléchargez le RFC 2131

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)