MOOC:Compagnon Act33-s7
From Livre IPv6
Contents
- 1 La configuration automatique centralisée par DHCPv6
- 1.1 Introduction
- 1.2 Principe
- 1.3 Principe de fonctionnement client-serveur
- 1.4 Pile de communication utilisée par DHCPv6
- 1.5 Présentation des entités du protocole DHCPV6
- 1.6 Fonctions des Messages
- 1.7 Format des messages
- 1.8 Contenu des messages
- 1.9 Scénario d'attribution d'adresse sans relai
- 1.10 Scénario d'attribution d'adresse avec relai
- 1.11 Scénario de délégation de préfixe
- 1.12 Scénario de renumérotation
- 1.13 Conclusion
- 1.14 Annexe : Détail des options
La configuration automatique centralisée par DHCPv6
Introduction
L'autoconfiguration avec état vise à réduire les efforts de configuration des machines IPv6, tout comme l'autoconfiguration sans état d'ailleurs. A la différence de l'autoconfiguration sans état, elle offre une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration.
Les deux techniques d'autoconfiguration ne sont pas exclusives et peuvent coexister dans un même environnement.
Une machine peut, par exemple, obtenir son adresse unicast globale par autoconfiguration sans état et obtenir les informations relatives au 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. Il 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 3315. 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 du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné 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. Ces échanges utilisent une pile de communication UDP/IPv6/ réseau physique. Ils font intervenir quatre types d'entités : les client, les serveurs, les relais et les interrogateurs (requestor). Nous les présentons successivement.
Principe de fonctionnement client-serveur
Un client DHCPv6 initie souvent une transaction en émettant une requête DHCPv6. Le client assure la fiabilité de la transaction en répètant sa requête DHCPv6 jusqu'à recevoir une réponse ou être sûr que le serveur DHCP est indisponible. Dans ce cas, il peut éventuellement décider de solliciter d'autres serveurs, s'il en existe ou abandonner sa tentative de configuration.
Le serveur DHCPv6 répond au client en lui fournissant les paramètres de configuration du réseau demandés.
Pile de communication utilisée par DHCPv6
DHCPv6 est un protocole d'application. Il utilise le protocole de transport UDP.
Un client DHCPv6 envoie les requêtes depuis le port 546. Il les envoie vers le port 547 du serveur.
Le serveur DHCPv6 envoie ses réponses depuis son port 547. Il les envoie vers le port 546 du client.
Les messages UDP sont encapsulés dans des datagrammes IPv6.
En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6, se faire en point à point ou en diffusion sélective (multicast) pour la découverte des serveurs DHCPv6 d'un site.
IPv6 s'appuie ensuite sur les fonctions de diffusion, générale ou sélective, du réseau physique sous-jecent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau n'est pas diffusant, on peut, par exemple, utiliser un serveur de diffusion.
Présentation des entités du protocole DHCPV6
Le client DHCPv6 est une machine candidate à une connectivité globale IPv6. Il demande des informations de configuration du réseau à un serveur DHCPv6 pour activer cette connectivité. Il doit maintenir une connectivité directe , soit avec un relais DHCPv6, soit avec le serveur DHCPv6 (c'est-à-dire être sur le même lien). Un client ignore l'existence des relais DHCPv6. Il a l'impression de communiquer directement avec le serveur DHCPv6.
Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau. Il peut ou non se trouver sur le même lien qu'un client DHCPv6. Il gère la configuration de clients situés sur le même lien ou sur des liens différents. Lorsqu'il ne se trouve pas sur le même lien que son client, les échanges DHCP transitent par un relais DHCPv6.
Les relais DHCPv6 sont des équipements éventuellement reliés à plusieurs liens. Ils interceptent le trafic des clients DHCPv6 pour l'acheminer vers les serveurs DHCPv6, lorsque ces derniers ne se trouvent pas sur le lien du client. Leur action est transparente pour les clients.
Notez que le relais ne modifie jamais les messages du client. Il se contente de les encapsuler dans une option de message de 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 pour connaître les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.
Gestion centralisée des ressources allouées
Dans la configuration DHCPv6 sans état (stateless), le client a configuré ses adresses IPv6, soit de façon manuelle (fichier interface, intervention de l’administrateur, soit à partir d’informations extraites d’annonces de routeurs (autoconfiguration sans état). Le client a besoin pour se configurer d'informations telle que l'adresse IPv6 du serveur DNS. Ces informations transmises par DHCPv6 sont statiques. Elles et ne nécessitent donc pas de conserver un état dans le serveur.
Dans la configuration avec états (stateful), le serveur DHCPv6 alloue une ou plusieurs adresses IPv6 au client. 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.
De plus, lorsqu'un serveur redémarre, il relit son fichier de baux. Il peut alors reprendre son activité là où il l'avait laissée.
Fonctions des Messages
Cette partie présente les messages du protocole DHCPv6. Le protocole distingue deux types de messages : d’une part les messages échangés entre client et serveur, et d’autre part les messages échanges entre serveur et relais. Nous les présentons successivement dans cet ordre. en général les messages échangés transportent des identificateurs de transaction et des associations d'identité.
Les identificateurs de transactions permettent d'associer les réponses aux demandes correspondantes.
Les associations d'identité permettent aux serveur et aux clients de s'identifier mutuellement et également d'identifier les interfaces de réseau concernées par les paramètres de configuration du réseau demandés (client) ou fournis (serveur).
Les associations sont également transmises dans des optiosn du protocole DHCPv6.
Messages échangés entre client et serveur
SOLICIT / ADVERTISE Un client utilise le message SOLICIT (champ type 1) pour Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration.
Un serveur configuré pour fournir des adresses ou des paramètres de configuration aux clients utilise le message ADVERTISE (champ type 2) pour annoncer sa disponibilité au client DHCPv6.
Messages de demande d'information de configuration
REQUEST / REPLY
Un client utilise le message REQUEST (champ type 3) pour demander des adresses et/ou des paramètres de configuration au serveur choisi. Une option d'options demandées contient la liste des paramètres de configuration demandés.
Un serveur utilise le message REPLY(champ type 7) pour répondre à un message SOLICIT, REQUEST, RENEW, REBIND reçu d’un client DCHPv6.
Messages de gestion des ressources allouées
CONFIRM / RENEW / REBIND / RELEASE / DECLINE / RECONFIGURE / INFORMATION REQUEST
Un client utilise le message CONFIRM (champ type 4) pour indiquer au serveur qui a alloué adresses et paramètres de configuration que ces paramètres sont adaptés au lien auquel le client est raccordé.
Un client utilise le message RENEW (champ type 5) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
Un client utilise le message REBIND (champ type 6) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur, en cas de non réponse au message RENEW.
Un serveur utilise le message REPLY(champ type7) pour répondre à un message SOLICIT, REQUEST, RENEW ou REBIND reçu d’un client.
Un client utilise le message RELEASE (champ type 8) pour indiquer au serveur qu'il n’utilise plus (libère) des adresses IPv6.
Un client utilise le message DECLINE (champ type 9) pour signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
Un serveur utilise le message RECONFIGURE (champ type 10) pour signaler au client que le serveur a de nouveaux paramètres de configuration du réseau ou les a actualisés.
Un client utilise le message INFORMATION-REQUEST (champ type 11) pour demander au serveur des paramètres de configuration, sans demander d’adresse.
Messages échangés entre relais et serveur
RELAY-FORW / RELAY-REPL Un relais DHCPv6 utilise le message RELAY-FORW (champ type 12) pour relayer des messages vers un serveur DHCPv6. Le message du client DHCPv6 est, sans être modifié, relayé sous la forme d’une option de ce message).
Un serveur DHCPv6 utilise le message RELAY-REPL (champ type 13) pour envoyer un message à un client, via un relais,. Le relais extrait le message destiné au client contenu dans une option de ce message pour le lui remettre.
Pour en savoir plus : extension du protocole DHCPv6 [RFC 5007]
Notez qu'un mécanisme d'option de relais spécifique permet qu'un relais DHCPv6 communique des paramètres de configuration susceptibles d'intéresser un client DHCPv6 et dont il a la connaissance au serveur DHCPv6.
Le serveur DHCPv6 peut ensuite décider ou non de communiquer au client tout ou partie des es paramètres de configuration du réseau issus du relais, en fonction de la politique de l'administrateur du réseau.
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) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les messages utilisés pour la communication serveur - relais sont différents. Un message de relais contient l'information de remise du message DHCP du serveur au client. Le préfixe du lien (link-address) indique l'interface du relais par laquelle le message DHCP a été reçu ou par laquelle il doit être envoyé. L'adresse du client (peer-address) contient l'adresse de l'interface à configurer du client. Le message DHCP est encapsulé dans le message de relais sous forme d'une option.
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).
| Désignation | Code | Définition |
|---|---|---|
| OPTION_CLIENTID | 1 | Identification du client |
| OPTION_SERVERID | 2 | Identification du serveur |
| OPTION_IA_NA | 3 | Association d’identité pour les options d’adresse non temporaire |
| OPTION_IA_TA | 4 | Association d’identité pour les options d’adresse temporaire |
| OPTION_IAADDR | 5 | Adresse associée à IA_NA ou IA_TA |
| OPTION_ORO | 6 | Identifie une liste d’options dans les messages échangés entre un client |
| OPTION_PREFERENCE | 7 | Annonce la priorité du serveur DHCPv6 et comment gérer cette priorité au client. |
| OPTION_ELAPSED_TIME | 8 | Temps écoulé depuis le démarrage de la machine qui tente d’achever sa configuration. |
| OPTION_RELAY_MSG | 9 | Transporte un message DHCPv6 dans des messages relay-forw ou relay-repl |
| OPTION_AUTH | 11 | Transporte les informations d’authentification de l’identité et du contenu des messages DHCPv6. |
| OPTION_UNICAST | 12 | Permet que le serveur indique au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur |
| OPTION_STATUS_CODE | 13 | Indique le statut du message DHCPv6 qui transporte cette option. |
| OPTION_RAPID_COMMIT | 14 | Permet, dans un message solicit, à un client de demander ce mode de fonctionnement. Le serveur doit inclure cette option dans la réponse correspondante (Solicit reply) |
| OPTION_USER_CLASS | 15 | Définit la classe d’utilisateur associée à un utilisateur ou à ne application. |
| OPTION_VENDOR_CLASS | 16 | Identifie le constructeur du matériel utilisé par le client. |
| OPTION_VENDOR_OPTS | 17 | Permet que les client et serveur échangent des informations spécifiques d’un constructeur. |
| OPTION_INTERFACE_ID | 18 | Identifie l’interface de réception du message du client DHCPv6. |
| OPTION_RECONF_MSG | 19 | Indique, dans un message reconfiguration, si le client doit répondre par un message renew ou information-request. |
| OPTION_RECONF_ACCEPT | 20 | Indique annonce à un serveur si le client accepte ou refuse les messages reconfigure |
