Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Autoconfiguration en mode stateful (DHCP)

Objectifs du chapitre

L’objectif de ce chapitre est d’aborder une autre méthode d’autoconfiguration disponible en IPv6, méthode basée sur l’utilisation d’un serveur DHCP (stateful autoconfiguration). Nous détaillerons le fonctionnement de ces mécanismes, notamment en comparant DHCP version 4 et version 6.

Si nous souhaitons exercer un plus grand contrôle sur la configuration automatique des différents postes d’un réseau, il est possible d’utiliser un ou plusieurs serveurs DHCP pour distribuer les paramètres de configuration. Ces serveurs peuvent aussi permettre d’affecter aux postes des paramètres plus nombreux que ceux intervenant dans une autoconfiguration autonome.

Modification de la méthode de configuration des postes

Nous avons vu dans le chapitre précédent que, par défaut, la méthode de base est l’autoconfiguration stateless.

Si nous souhaitons que les postes se configurent via un serveur DHCP, il faut leur notifier qu’ils doivent solliciter un serveur DHCP.

Il est possible de modifier le mode de configuration au niveau de chaque poste mais le plus simple est d’utiliser les RA (Router Advertisement) pour leur communiquer cette information.

Nous commencerons par étudier les modifications à apporter côté routeur (ou firewall) pour ce faire.

1. Les drapeaux de configuration

Si nous analysons un avertissement de routeur (RA) décomposé par Wireshark, nous constatons la présence de deux drapeaux (flags) : M (Managed address configuration) et O (Other configuration) dans les paramètres généraux du RA :


Frame 1: 150 bytes on wire (1200 bits), 150 bytes captured 
(1200 bits) on interface  
Ethernet II, Src: fc:99:47:fa:0e:7e, Dst: 33:33:00:00:00:01 
.../... 
Internet Control Message Protocol v6 
    Type: Router Advertisement (134) 
    Code: 0 
    Checksum: 0x9665 [correct] 
    [Checksum Status: Good] 
    Cur hop limit: 64 
    Flags: 0x00 
        0... .... = Managed address configuration: Not set 
        .0.. .... = Other configuration: Not set 
        ..0. .... = Home Agent: Not set 
        ...0 0... = Prf (Default Router Preference): Medium (0) 
        .... .0.. = Proxy: Not set 
        .... ..0. = Reserved: 0 
)
 

Nous trouverons aussi des drapeaux L (On Link) et A (Autonomous address-configuration) pour chaque préfixe :


Frame 1: 150 bytes on wire (1200 bits), 150 bytes captured 
(1200 bits) on interface 0 
.../... 
    ...

Fonctionnement du DHCPv6

Il est assez voisin dans son principe du serveur DHCP v4. Nous pouvons paramétrer un ou plusieurs serveurs DHCP situés sur le même lien que le poste client ou, au travers d’un relais DHCP, sur un autre lien.

L’ensemble des messages se base sur UDP avec le port d’écoute 546 pour les clients DHCP et 547 pour les serveurs DHCP. Voici les messages prévus par le RFC 3315 par ordre numérique de type (nombre entre parenthèses). Nous avons également précisé, quand cela était pertinent, le message ayant un rôle voisin mais pas forcément identique en version 4 :

  • SOLICIT (1) envoyé par un client pour recenser les serveurs DHCP disponibles (équivalent v4 : DHCPDISCOVER).

  • ADVERTISE (2) envoyé par un serveur proposant ses services en réponse au message SOLICIT (équivalent v4 : DHCPOFFER).

  • REQUEST (3) envoyé par un client à un serveur pour demander les paramètres de configuration (équivalent v4 : DHCPREQUEST).

  • CONFIRM (4) envoyé par un client pour vérifier que son adresse ou ses adresses sont toujours valides (pas d’équivalent v4).

  • RENEW (5) envoyé par un client au serveur qui lui a donné ses paramètres pour demander un prolongement du bail ou mettre à jour les paramètres si ceux-ci ont changé depuis (équivalent v4 : DHCPREQUEST).

  • REBIND (6) envoyé par le client à tout serveur DHCP disponible, généralement quand le serveur DHCP d’origine n’a pas répondu, pour demander un prolongement du bail ou mettre à jour les paramètres si ceux-ci ont changé depuis (équivalent v4 : DHCPREQUEST).

  • REPLY (7) envoyé par le serveur à un client pour lui indiquer tous ses paramètres ou pour confirmer la bonne réception d’un RELEASE ou d’un DECLINE (équivalent v4 : DHCPACK et DHCPNACK). Il sert également pour confirmer ou refuser l’utilisation par un client de l’adresse demandée par celui-ci dans un message CONFIRM.

  • RELEASE (8) envoyé par le client au serveur d’origine pour lui indiquer la vacance des adresses préalablement affectées (équivalent v4 : DHCPRELEASE).

  • DECLINE (9) envoyé par le client pour lui indiquer que l’adresse...

Différences avec DHCPv4

1. Relais DHCP

Le fonctionnement est un peu différent de celui intervenant en version 4.

Le principe est le suivant :

  • Le client envoie une requête DHCP sur le réseau.

  • L’agent effectuant le relais retransmet cette demande sous forme d’un message RELAY FORWARD (type 12) au serveur (ou éventuellement à un autre agent de relais puisque la cascade d’agent est parfaitement prévue dans ce mécanisme). La requête initiale du client est contenue dans les champs Relay Message Option.

  • Le serveur DHCP envoie la réponse dans un message de type RELAY REPLY (type 13), plus précisément dans le champ Relay Message Option.

  • L’agent extrait la réponse du serveur et la fait parvenir au client.

À noter que les échanges entre les agents relais et les serveurs sont protégés en IPsec avec ou sans cryptage (selon le degré de confidentialité des informations à échanger).

De plus, l’authentification peut également renforcer cette sécurité.

2. Reconfiguration de paramètres

Autre point fondamental de différence qui peut grandement faciliter la tâche d’un administrateur réseau pour une renumérotation : le serveur DHCP peut notifier d’un changement intervenu dans ses paramètres par un multicast comportant un message de type RECONFIGURE (type 19). Cela implique alors que tous les clients envoient au serveur DHCP un message de type RENEW ou INFORMATION REQUEST (au choix du serveur DHCP) pour acquérir les informations à mettre à jour. Ces changements seront donc quasiment immédiatement pris en compte par tous les clients DHCP concernés.

3. Mise en œuvre

a. Sur les serveurs

Serveur Windows Server 2008 et 2012

Il faut d’abord affecter une adresse IPv6 à la carte réseau en choisissant la version 6 dans les Propriétés de Connexion au réseau local :

images/05EP101-v2.png

Puis en cliquant sur Propriétés, nous allons renseigner les adresses IPv6 du serveur, des DNS... :

images/05EP102-v2.png

Ensuite, dans le service DHCP (en supposant qu’il soit déjà installé), il faut sélectionner le nœud IPv6 :

images/05EP110-v2.png

En faisant un clic droit sur le dossier IPv6, nous pouvons choisir Nouvelle étendue dans le menu contextuel :

images/05EP111-v2.png

L’assistant...

Pour aller plus loin

1. Les principaux RFC

Voici une liste des principaux RFC concernant les mécanismes et notions abordés dans ce chapitre. Ils contiennent de nombreux détails permettant d’approfondir ceux-ci :

  • RFC 4861 - Neighbor Discovery

  • RFC 3756 - Menaces liées à l’autoconfiguration

  • RFC 3315 - DHCPv6

2. Des liens