Revision as of 00:13, 6 June 2015

MOOC:Compagnon_Act33_Livre

La configuration automatique centralisée par DHCPv6

Introduction

L'autoconfiguration avec état vise à réduire les efforts d'installation des machines IPv6, tout comme l'autoconfiguration sans état d'ailleurs. A la différence de cette dernière, elle offre une information de configuration plus riche et un contrôle sur l'affectation des paramètres de configuration.

Les deux techniques d'autoconfiguration ne sont pas exclusives et peuvent coexister dans un même environnement. Par exemple, une machine peut obtenir son adresse unicast globale par l'autoconfiguration sans état et récupérer les informations sur le service de noms (DNS) par l'autoconfiguration avec état.

Tout le mécanisme d'autoconfiguration avec état est bâti sur le modèle du client-serveur et repose sur l'utilisation du protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6)

Principe

Le principe du protocole DHCPv6 est défini dans le RFC 5007. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et les formats des messages. La mise au point de ce standard a cependant été l'objet de nombreux débats, DHCP étant un élément important dans le fonctionnement du réseau. En conséquence, la parution tardive d'un standard finalisé a entrainé une adoption lente du support et du déploiement de ce mécanisme.

Architecture du protocole

Conformément au modèle client-serveur, les échanges DHCPv6 se composent de requêtes et de réponses. Une transaction est souvent entamée à l'initiative d'un client par une requête DHCP. La fiabilité de la transaction est assurée par le client, qui répète sa requête DHCP jusqu'à recevoir une réponse ou obtenir la certitude que le serveur DHCP est indisponible.

DHCPv6 est un protocole d'application qui se sert du protocole de transport UDP. Un client envoie les requêtes sur le port 547 du serveur et recevra les réponses par le port 546. Les messages UDP seront encapsulés classiquement dans des paquets IPv6. En plus des communications point-à-point, DHCPv6 s'appuie également sur des communications multi-destination (multicast) pour la découverte des serveurs d'un site.

Le client IPv6 représente une machine candidate à une connectivité globale IPv6 et demandeur d'informations de configuration pour activer cette connectivité. Le serveur DHCP constitue un point central regroupant les paramètres de configuration. Il ne se trouve pas forcément sur le même lien que le client et dans ce cas, les échanges DHCP peuvent passer par un relais. Le serveur peut maintenir la configuration de machines situées sur plusieurs liens différents. Le client DHCP doit maintenir une connectivité directe soit avec un relais DHCP, soit avec le serveur DHCP lui-même.

Les relais sont des équipements reliés à plusieurs réseaux. Ils relaient le trafic échangé entre les serveurs et les clients. Leur action est transparente pour les clients. Les clients ont l’impression de communiquer directement avec le serveur. Ils ignorent l’existence des relais. Les interrogateurs (requestors) sont des entités spécifiques à destination des administrateurs. Ils interrogent un serveur DHCPV6 pour obtenir des informations relatives aux clients. Un administrateur peut, par exemple, interroger un serveur DHCPv6 pour obtenir des informations relatives aux baux d’un client ou à la machine qui utilise une adresse à un instant donné ou encore aux adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.

Gestion des ressources allouées

Dans la configuration DHCPv6 sans état (stateless), le client a configuré ses adresses IPv6, soit de façon autonome (fichier interface, intervention de l’administrateur, soit à partir d’informations extraites d’annonces de routeurs. Le client a besoin pour se configurer d'informations comme le serveur DNS. Ces informations transmises par DHCPv6 sont donc statiques et ne nécessitent donc pas de conserver un état dans le serveur.

Dans la configuration avec états (stateful), le serveur procède à l'allocation pour le client d'une ou plusieurs adresses IPv6. Ces adresses font l’objet d’un contrat de location temporaire. Le serveur enregistre ce contrat de location dans un registre spécial : le fichier des baux (de location) (lease file). Pour cette raison, ce type de configuration est dit avec états.

Messages

Format des messages

L'ensemble des éléments du protocole DHCPv6 est décrit dans le document (RFC 3315). A l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut changer et évoluer rapidement sans impacter les mécanismes de cet échange. Cette séparation assure au protocole une certaine stabilité et une propriété d'extensibilité. On retrouve dans la structure des unités de protocole ce découpage. Une unité de protocole DHCP suit le schéma classique des unités de protocole : un en-tête pour les informations du protocole lui-même, une charge utile pour les informations applicatives.

Dans la terminologie DHCP, une unité de protocole DHCPv6 est désignée par le terme message. Chaque message DHCP a un format d'en-tête identique. De ce point de vue, DHCP reprend les principes qui ont guidé à la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP. La motivation tient à la simplification du processus de développement du protocole.

Structure des messages échangés entre client et serveur DHCPv6

La structure des messages échangés entre client et serveur DHCPv6 est la suivante :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type-msg   |               Id-transaction                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | | Adresse du serveur | | | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                    Liste d’options                            .
.                           (variable)                          .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• L'information de commande codée sur un mot de 32 bits désigne la fonction DHCP concernée par l'échange. Cette partie contient notamment le type de message (type-msg) et l'identification de l'échange (id-transaction). Le premier champ de cette partie est toujours le champ type de message codé sur 8 bits et qui définit la fonction du message dans le protocole. Le champ transaction-ID a comme rôle comme son nom l'indique, d'identifier la transaction vis à vis du client. Il sert au client à rapprocher les réponses reçues des demandes qu'il a faites.
• L'information d'adressage sert à indiquer l'adresse IPv6 du serveur d'un échange DHCP. L'adresse du serveur contient l'adresse de l'interface utilisé par le serveur dans la transaction.
• Le champ options sert à véhiculer les informations de configurations. Cette partie est de taille variable. Son codage suit le schéma classique "TLV" à savoir le type de l'option, la longueur en octet du champ valeur qui suit et le champ valeur du paramètre. Le champ type est toujours codé sur 2 octets. Le champ longueur sur 2 octets est toujours présent, même en l'absence de valeur ou pour une valeur de longueur fixe.

Structure des messages échangés entre relais et serveur DHCPv6

La structure des messages échangés entre relais et serveur est la suivante :

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type-msg   |   hop-count   |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Link-address                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Peer-address                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     .                                                               .
     .            Options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Messages de découverte de serveur

SOLICIT / ADVERTISE

Messages de requêtes d'information de configuration

REQUEST / REPLY

Messages de gestion des ressources allouées

CONFIRM / RENEW / REBIND / RELEASE / DECLINE / RECONFIGURE / INFORMATION REQUEST

Messages de relayage

RELAY-FORW / RELAY-REPL

Contenu des messages

Types de valeurs

Le RFC 5007 définit 2 types de valeurs qui peuvent être transportée dans ces messages.

Identifiant DUID

Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP maintient une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource dépendant du serveur, celle-ci n'est pas utilisable par le serveur DHCP pour identifier un client. Le serveur identifie donc le client par un identifiant unique à usage exclusif de DHCP : le DUID (DHCP Unique IDentifier). Les clients utilisent eux les DUID pour identifier les serveurs quand et là où ils en ont besoin. Le contenu des DUID n’est pas interprété, mais uniquement comparé pour vérifier l'identité du correspondant. Le DUID concerne la station et non une de ces interfaces.

Cet identifiant est généré par la station et ne doit plus en changer dans le temps. Les DUID sont codés sur deux octets et ont une longueur inférieure à 128 octets (hors champ type). Ils peuvent être généré selon 3 méthodes :

• 1 : Link-layer address plus time
• 2 : Vendor-assigned unique ID based on Enterprise Number
• 3 : Link-layer address

Association d'identités

Une association d’identités permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Un client associe au moins une association d’identité à chacune de ses interfaces de réseau pour laquelle il requiert une adresse IPv6.

Les affectations d'adresses à un client sont gérées par le serveur avec une notion de container appelé IA (Identity Association). Une IA est définie comme une liste (pouvant être vide) d'adresses IPv6. L'idée est que chaque client a une IA par interface et que cette IA reste affectée en permanence à l'interface. Ainsi, par ce container, la gestion de la durée de vie des adresses ou la renumérotation du client s'effectue par le serveur. Cette notion simplifie le format des messages et le contrôle des adresses.

Options

Le protocole DHCPv6 transporte tous les paramètres de configuration du réseau dans des options du protocole. Il est par conséquent extensible. Pour l’étendre, il suffit de définir une nouvelle option. Chaque option est identifiée dans le paquet par un champ code, permettant l'interprétation des données transportées. Certaines options peuvent contenir une information structurée en plusieurs champs (voir Annexe 1).

Scénario d'attribution d'adresse sans relai

Scénario d'attribution d'adresse avec relai

Scénario de délégation de préfixe

Scénario de renumérotation

Conclusion

Annexe : Détail des options