Difference between revisions of "MOOC:Compagnon Act33-s7"

From Livre IPv6

Revision as of 09:08, 14 October 2015

La configuration automatique centralisée par DHCPv6

Introduction

L'autoconfiguration à états utilise un serveur pour allouer des adresses IPv6 et/ou des paramètres de configuration à des machines IPv6. Elle réduit les efforts de configuration des machines IPv6, tout comme l'autoconfiguration sans état. Elle offre, à la différence de l'autoconfiguration sans état, une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des équipements du réseau.

Les deux techniques d'autoconfiguration, avec et sans états, 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 à états.

Tout le mécanisme d'autoconfiguration à états est bâti sur le modèle client-serveur. Il utilise le protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6).

Principe

Le RFC 3315 définit le principe de fonctionnement du protocole DHCPv6. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et le format 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 qui souhaite obtenir des adresses IPv6 et/ou des paramètres de configuration du réseau initie souvent une transaction en émettant une requête DHCPv6. le client, pour éviter les avalanches de trafic, attends un temps aléatoire avant d'émettre sa première demande. 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 DHCPv6, s'il en existe ou d'abandonner sa tentative de configuration.

Le serveur DHCPv6 répond au client en lui fournissant les adresses et/ou les paramètres de configuration du réseau demandés.

Lorsque le client et le serveur se trouvent sur le même mien, les interactions directes entre client et srveur sont possibles.

Lorsque le client et le serveur ne sont pas sur le même lien, un relais intervient. Le relais intercepte le message du client et l'encapsule dans un message de relais, plus précisémment dans une option de message relayé. Le message de relais est ensuite envoyé, soit au serveur DHCPv6, soit au relais suivant.

Si le message est transmis au serveur, le relais qui effectue l'envoi est le dernier sur le chemin qui relie le client au serveur.

Si, au contraire le relais ne peut pas transmettre directement son message au serveur, il l'adresse à un autre relais. Le processus se poursuit jusqu'à ce qe le message atteigne le serveur DHCPv6.

Lorsque le serveur envoie sa réponse au client, la réponse issue du serveurest, soit envoyée directement au client, soit renvoyée au dernier relais. ce relais renvoie la réponse du client au relais précédent, et ainsi de suite jusqu'à ce que le dernier relais puisse remettre la réponse du serveur au client DHCPv6.

Pile de communication utilisée par DHCPv6

DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP.

Un client DHCPv6 envoie les requêtes depuis le port 546 et les envoie vers le port 547 du serveur ou du premier relais.

Le serveur DHCPv6 envoie ses réponses depuis son port 547 les envoie vers le port 546 du client si la remise directe est possible. Sinon le serveur envoie sa réponse au premier relais du chemin de retour, sur le port 547.

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, il fait, par exemple, appel à un serveur de diffusion.

Présentation des entités du protocole DHCPV6

Le protocole DHCPV6 pour fonctionner fait intervenir quatre entités : le client, le serveur, le relais et l'interrogateur. l'intervention de la quatrième entité, l'interrograteur est facultative.

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 ni les relais, ni le serveur ne modifieent les messages du client. Ils se contentent, en présence de relais, de les encapsuler dans une option de message de relais.

Les interrogateurs (requestors) [RFC 5007] 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 pour se configurer besoin d'informations telles que l'adresse IPv6 du serveur DNS. Ces informations transmises par DHCPv6 sont statiques. Elles 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és.

Les identificateurs de transactions permettent d'associer les réponses aux demandes correspondantes. Ils changent pour chaque transaction et sont globalement uniques.

Les associations d'identités 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 d'identités sont également transmises dans des options 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 allouer des adresses et/ou des paramètres de configuration du réseau.

Un serveur configuré pour fournir des adresses ou des paramètres de configuration du réseau aux clients annonce sa disponibilité au client DHCPv6 à l'aide d'un message ADVERTISE (champ type 2).

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 DHCPv6 choisi. Une option 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 directement 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 lui a alloué adresses et paramètres de configuration du réseau 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 lui a alloués. Le client utilise ce message à la demande explicite du serveur.

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 DHCPV6, si le serveur DHCPv6 auquel il s'est adressé pour obtenir ses adresses et paramètres de configuration du réseau ne répond pas à son message RENEW.

Un serveur utilise le message REPLY (champ type 7) 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 DHCPv6 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. La DAD : détection d'adresses dupliquées d'IPv6 peut, par exemple, fournir cette information.

Un serveur utilise le message RECONFIGURE (champ type 10) pour signaler au client qu'il a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise en particulier si le client doit utiliser le message RENEW ou REBIND.

Un client utilise le message INFORMATION-REQUEST (champ type 11) pour demander au serveur des paramètres de configuration du réseau, sans demander d’adresse.

Messages échangés entre relais et serveur

RELAY-FORWARD / RELAY-REPLY Un relais DHCPv6 utilise le message RELAY-FORWARD (champ type 12) pour relayer des messages DHCPv6 vers un serveur DHCPv6. Le message relayé est soit le message DHCPv6 du client, soit le message RELAY-FORWARD du relais précédent (sur le chemin reliant le client au serveur DHCPv6).

Un relais ne modifie jamais le message d'un client. Le message du client DHCPv6 est relayé, sans être modifié, dans une option message relayé du message RELAY-FORWARD du premier relais rencontré sur le chemin reliant le client au serveur DHCPv6.

Un serveur DHCPv6 utilise le message RELAY-REPLY (champ type 13) pour envoyer un message à un client, via un relais.

Chaque relais qui reçoit un message RELAY-REPLY extrait le message contenu dans l'option message relayé et le réexpédie vers le client. Seul le contenu de l'option message relayé est donc transmis vers le client.

Le dernier relais extrait le message destiné au client contenu dans l'option message relayé option de ce message RELAY-REPLY pour le lui remettre. Ici encore le message du client reste inchangé.

Pour en savoir plus : extension du protocole DHCPv6 [RFC 6422]

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 connaissance, au serveur DHCPv6.

Le serveur DHCPv6 peut ensuite décider ou non, en fonction de la politique définie par l'administrateur du réseau, de communiquer au client tout ou partie des paramètres de configuration du réseau spécifiques issus du relais.

Structure des messages DHCPV6

Le document [RFC 3315] décrit l'ensemble des éléments du protocole DHCPv6. 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 la stabilité et l'extensibilité du protocole.

La structure des unités de données du protocole reprend ce découpage : un en-tête de taille fixe pour les informations du protocole lui-même et une charge utile transportées dans des champs d'option pour les informations applicatives.

Pour étendre le protocole, il suffit de définir de nouvelles options et de concevoir leur traitement, en émission et en réception.

Dans la terminologie DHCPv6, le terme message désigne une unité de protocole DHCPv6. Chaque type de message DHCPv6 (client-serveur ou relais-serveur) a un format d'en-tête identique. De ce point de vue, DHCPv6 reprend les principes de simplification du processus de développement du protocole qui ont guidé la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP.

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                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                    Liste d’options                            .
.                           (variable)                          .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La structure générale des messages échangés entre client et serveur DHCPv6 est la suivante : : un champ type, un champ identificateur de transaction, id-transaction, et une liste variable d’options.

Le champ type identifie la nature du message DHCPv6. Il est codé sur un octet.

L'identificateur de transaction identifie un échange (question-réponse). Il change pour chaque échange et est globalement unique. Il est codé sur 3 octets.

Les options de la liste transportent, soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6).

La partie liste d'options est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, les unes derrière les autres, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives.

Les options de la liste transportent les différentes informations de configuration du réseau des messages de DHCPV6 ou nécessaires à son fonctionnement.

Pour en savoir plus sur les options, reportez-vous au chapitre sur les options.

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 entre serveur et relais sont différents des messages utilisés pour la communication entre client et serveur.

Un message RELAY-FORWARD transite d'un relais, vers le serveur. Un message RELAY-REPLY transite du serveur vers le client.

Le type du message identifie le type du message DHCPv6. Le nombre de sauts (hop-count) identifie, soit le nombre de relais déjà traversés pour atteindre le serveur, soit le nombre de relais restant à traverser pour atteindre le client.

L'adresse locale au lien (link-address désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).

L'adresse du pair(peer-address) est une adresse globale ou locale au site. Elle identifie, pour chaque relais, l'interface du relais, côté client. pour le dernier relais dans le cas du transit d'un message du serveur vers le client, cette adresse identifie l'interface du relais derrière laquelle se trouve le client.

Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel de ces relais s'adresser pour répondre à un client donné. Chacun des relais, lorsqu'il faut en traverser plusieurs pour atteindre le client, sait à qui transmettre le message de relais contenu dans l'option de message de relais du message RELAY-REPLY reçu. Ce message contient l'adresse locale au lien du relais suivant ou, pour le dernier relais, l'adresse locale au lien du client. Le dernier relais peut donc envoyer au client la réponse du serveur.

Le tableau ci-dessous résume le nom, le type l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.

Message DHCPv6	Type	Emetteur	Fonction
SOLICIT	1	Client	Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration
ADVERTISE	2	Serveur	Annoncer la disponibilité du serveur DHCPv6
REQUEST	3	Client	Demander des adresses et/ou des paramètres de configuration au serveur choisi.
CONFIRM	4	Client	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é.
RENEW	5	Client	Prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
REBIND	6	Client	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
REPLY	7	Serveur	Répondre à un message Solicit, Request, Renew, Rebind reçu d’un client
RELEASE	8	Client	Indiquer au serveur que le client n’utilise plus des adressesipv6.
DECLINE	9	Client	Signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
RECONFIGURE	10	Serveur	Signaler au client que le serveur a de nouveaux paramètres ou les a actualisés.
INFORMATION-REQUEST	11	Client	Demander au serveur des paramètres de configuration, sans demander d’adresse.
RELAY-FORW	12	Relai	Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6 est placé dans une option de ce message.
RELAY-REPL	13	Serveur	Envoyer un message à un relais, depuis un serveur. Le relais extrait le message destiné au client contenu dans ce message pour le lui remettre.

Message DHCPv6 RELAY-FORWARD

Le champ type de ce message vaut 12. Le nombre de saut indique le nombre de relais traversés par ce message pour atteindre le serveur. L’adresse de lien (link-address) d’un message RELAY-FORWARD est une adresse globale ou une adresse locale au site que le serveur utilise pour identifier le lien où se trouve le client (adresse du relais côté client). C'est l'adresse du relais, du côté du client.

L’adresse du pair Peer-address est l’adresse IPv6 de l'interface depuis laquelle le relais a envoyé le message au serveur. C'est l'adresse du relais du côté du serveur. La liste d’option de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais. Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.

Message DHCPv6 RELAY-REPLY

Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur. Le champ type de ce message vaut 13. Le nombre de saut indique le nombre de relais que ce message traversera pour atteindre le client. Les adresses du lien et du pair sont recopiées du message RELAY-FORWARD précédent. La liste d’options doit obligatoirement contenir une option de message relayé (Relay Message option). Cette option transporte la réponse du serveur DHCPv6 destinée au client DHCPv6.

Types de valeurs

Le RFC 3315 définit 2 types de valeurs qui peuvent être transportée dans ces messages. [ je ne comprends pas ce titre B. Joachim je propose de supprimer cette partie.]

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 gère 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).

Chaque station génère son identifiant. Cet identifiant doit être permanent et avoir une grande durée de vie. Une station peut, par exemple et à un instant donné, générer un DUID à partir de l'adresse MAC d'une de ses cartes réseau. Elle le conservera alors son identifiant, même en cas de remplacement ultérieur de cette carte réseau.

Les clients utilisent les DUID pour identifier les serveurs quand et là où ils en ont besoin, par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 et/ou des paramètres de configurationdu réseau.

Le contenu des DUID n’est pas interprété, mais uniquement utilisé pour des comparaisons pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ces interfaces.

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 : combinaison d'une adresse et d'une horodate, dérivée d'un numéro de construteur ou d'un numéro unique affecté par un construceur, ou enfin, dérivée de l'adresse MAC d'une interface de réseau.

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

Le type de DUID est codé sur 2 octets. Un nombre variable d’octets suit et constitue l’identificateur. La longueur maximale d’un identificateur est 128 octets.

Le DUID est lui même une structure de donnée qui selon le mode de construction, contient des types de valeur différents.

DUID construit à partir de l'adresse physique + horodate (1)(DUID-LLT)

Le champs type (2 octets) vaut 1. Deux octets contiennent le type de réseau physique. H’horodate est codée sur 4 octets, puis vient l’adresse physique. La longueur de l’adresse physique (adresse MAC) varie.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               1              |     hardware type (16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                 time (32 bits)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.              link-layer address (variable length)             .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le choix de l’interface est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui à servi à le générer.

Ce type de DUID est recommandé pour les ordinateurs de bureau, les ordinateurs portables, ou plus généralement pour tout équipement doté d'une mémoire non volatile où l’écriture est possible.

Une interface d’administration doit permettre, sur chacun de ces équipements, que l’administrateur gère les conflits éventuels.

DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN)

Un constructeur affecte ce type d’identificateur à un équipement. Ce DUID combine le numéro unique affecté à l’entreprise avec un identificateur de longueur variable, unique pour l’entreprise et défini par elle. Cet identificateur est généralement un entier non signé codé sur 32 bits. La structure du message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               2               |       enterprise-number       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd)     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
.                       identifier                              .
.                     (variable length)                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.

DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN)

Un constructeur affecte ce type d’identificateur à un équipement. Ce DUID combine le numéro unique affecté à l’entreprise avec un identificateur de longueur variable et unique pour l’entreprise. Cet identificateur est généralement d’un entier non signé codé sur 32 bits. La structure du message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               3               |    hardware type (16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.              link-layer address (variable length)             .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.

Ce format est recommandé pour les équipements dépourvus de mémoire de stockage et qui ont une interface de réseau connectée en permanence au réseau (une imprimante réseau, par exemple).

Association d'identités

Une association d’identités IA (Identity Association) permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Ces informations sont enregistrées dans des options de l'association.

Un client associe au moins une association d’identités à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.

Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du réseau IPv6 (voir le principe de la renumérotation).

Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées : T1 et T2. T1 représente la durée de vie de l‘adresse dans l’état préféré. T2 représente la durée de validité de l’adresse IPv6.

Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 : des adresses non temporaitres et des adresses temporaires.

Allocation des adresses non temporaires

Le serveur choisit les adresses d’un client en fonction du lien du client, du DUID du client, et des options fournies par le client et des informations fournies par le relais DHCPv6.

Les adresses allouées font l'objet d'une écriture dans le fichier des baux.

Allocation des adresses temporaires

DHCPv6 gère les adresses temporaires comme les adresses non temporaires. Une association d’identités pour adresse temporaire ne contient au plus qu’une seule adresse temporaire.

Ici encore, l'allocation d'adresse fait l'objet d'un écriture dans le fichier des baux. (à vérifier)

Le serveur DHCPv6, s'il est configuré pour cela effectue des mises à jour dynamiques du service de noms de domaine.

Options

Un champ type d'option identifie chaque option d'un paquet DHCPv6. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurée en plusieurs champs (voir Annexe 1).

Chaque option est codée en format TLV : Type, Longueur, Valeur, à savoir, le type de l'option, la longueur en octet du champ valeur de l'option qui suit et le champ valeur du paramètre de configuration.

Le champ type de l'option est toujours codé sur 2 octets. Le champ longueur est codé sur 2 octets. Il est toujours présent, même en l'absence de valeur ou pour une information de longueur fixe. Il exclut le champ type de l'option.

La longueur totale en octet d'une option est donc souvent 4 + longueur de la valeur du champ longueur de l'option. Elle peut être plus importante si l'en-tête de l'option inclut des informations de taille fixe.

**Options de DHCPv6**
Désignation	Code	Définition
`OPTION_CLIENTID`	1	Identification du client
`OPTION_SERVERID`	2	Identification du serveur
`OPTION_IA_NA`	3	Association d’identités pour les options d’adresse non temporaire
`OPTION_IA_TA`	4	Association d’identités 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 au client la priorité du serveur DHCPv6 et comment gérer cette priorité.
`OPTION_ELAPSED_TIME`	8	Temps écoulé depuis le démarrage d'un échange pour la machine qui tente d’achever sa configuration.
`OPTION_RELAY_MSG`	9	Transporte un message DHCPv6 relayé 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 au serveur d'indiquer au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur pour échanger aavec lui.
`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 pour réaliser des échanges en deux temps au lieu de quatre. 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 à une 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 à un serveur si le client accepte ou refuse les messages reconfigure ou annonce à un client qu'il peut ou non accepter les messages reconfigure.

Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais

Un client relié au même lien que le serveur DHCPv6, utilise le message DHCPv6 SOLICIT pour découvrir les serveurs configurés pour lui fournir des adresses IPv6 ou des paramètres de configuration du réseau. Comme a priori ce client ignore l'adresse ipv6 du serveur, le client DHCPv6 envoie toujours (c'est le mode de fonctionnement par défaut) ce message à l’adresse de diffusion sélective IPv6 ALL_DHCP_And_ Relay_Agent.

Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE.

Le client, si plusieurs serveurs DHCPV6 sont disponibles, ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. Il émet alors un message request destiné au serveur sélectionné. Il envoie ce message à l’adresse de diffusion sélective ALL_DHCP_And_ Relay_Agent.

Tous les serveurs qui ont répondu à la demande du client savent ainsi si leur offre a ou non été retenue. Le serveur dont l'offre à été retenue, et lui seul, renvoie un message REPLY au client.

La figure ci-dessous résume les messages DHCPv6 échangés dans ce cas.

Client					Serveur
                     Solicit 
        ----------------------------> 
                    Advertise
        <----------------------------
                     Request
        ---------------------------->
                      Reply
        <----------------------------

Recherche des serveurs DHCPv6 par le client : fonctionnement de la pile de communication

Le client DHCPv6 demande au serveur une adresse IPv6 et un certain nombre de paramètres de configuration du réseau. Il fabrique donc un message DHCPv6 SOLICIT. Il émet ensuite ce message DHCPv6 SOLICIT pour découvrir les serveurs DHCPv6 disponible.

Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 (546) pour expédier ce message vers le port UDP destination du serveur (547). Comme à ce stade le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de diffusion sélective (multicast) réservée pau protocole DHCPv6, ALL_DHCPV6_Relay_Agents_and_Servers comme adresse IPv6 de destination.

UDP ne gère pas les adresses IPv6. Il transmet donc simplement à la couche IPv6 l’adresse IPv6 de destination du message UDP à transmettre.

IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Si,notre client n’a qu’une interface, celle-ci est associée à la route par défaut. Sinon, le client envoie le message depuis l'interface de réseau associée à la route par défaut. L'adresse IPv6 source utilisée dans le datagramme IPv6 est l'adresse locale au lien de cette interface.

Notez que l'administrateur du réseau définit l'interface de réseau à utiliser par défaut. Il peut effectuer cette configuration au niveau d'une image disque ou encore au niveau d'un fichier de configuration du client DHCPv6.

L’adresse de destination est une adresse de diffusion sélective. Elle n’est associée à aucune route spécifique. Le trafic destiné à ce groupe emprunte la route par défaut. L’adresse IPv6 source utilisée ici est donc celle de cette interface.

IPv6 demande ensuite à Ethernet d’expédier ce datagramme. L’adresse IPv6 de diffusion sélective de destination est ensuite associée à l’adresse Ethernet de diffusion sélective spécifique d’IPv6. Ceci permet d’utiliser, au niveau Ethernet, la diffusion sélective et de ne pas recourir, sur le lien, à la diffusion générale, ce qui dérangerait un nombre potentiellement considérable de machines sur un réseau IPv6.

Le client DHCPv6 envoie donc la trame Ethernet sur le lien, vers le serveur DHCPv6.

La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale correspond, en fait, à la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.

Notez également que si les mots de passe transitent en clair sur le réseau, leur valeur s'affiche directement dans cette colonne !

0000  00 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd   ........'.......
0010  60 00 00 00 00 3c 11 01 fe 80 00 00 00 00 00 00   `....<..........
0020  0a 00 27 ff fe 9b a1 9b ff 02 00 00 00 00 00 00   ..'.............
0030  00 00 00 00 00 01 00 02 02 22 02 23 00 3c 6e ef   .........".#.<n.
0040  01 4d 54 a4 00 01 00 0e 00 01 00 01 1c 77 78 81   .MT..........wx.
0050  08 00 27 9b a1 9b 00 03 00 0c 00 00 00 01 ff ff   ..'.............
0060  ff ff ff ff ff ff 00 08 00 02 00 00 00 06 00 04   ................
0070  00 17 00 18                                       ....

Indice. Au niveau DHCPv6, la structure du message est la suivante : type de message, identificateur de transaction, liste d'options ( Identification du client Association d’identités pour adresse non temporaire Temps écoulé depuis lle démarrage de l'échange DHCPv6 paramètres de configuration du réseau demandés)

Question.

Dans la capture de trame Ethernet qui précède et our chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs.

Notez que vous pouvez vous aider d’un analyseur de protocole.

Quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ?

Quelles sont la valeur et la signification du champ type Ethernet ?

Quelles sont les valeurs, le type et la fonction de chacun des champs du protocole transporté par Ethernet ?

Quel est le protocole transporté par le protocole précédent ?

Quelles sont les valeurs des informations importantes pour interpréter les messages transportés par le protocole de transport ?

Quels sont enfin le protocole, le message, la valeur et la signification de chacun des champs de ce protocole ?

A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0).

Emission du message ADVERTISE du serveur DHCPv6 vers le client DHCPv6

La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.

0000  00 04 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd   ........'.E.....
0010  60 00 00 00 00 e6 11 40 fe 80 00 00 00 00 00 00   `......@........
0020  0a 00 27 ff fe 1e 45 17 fe 80 00 00 00 00 00 00   ..'...E.........
0030  0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 e6 1f e4   ..'......#."....
0040  02 4d 54 a4 00 03 00 84 00 00 00 01 00 00 07 d0   .MT.............
0050  00 00 0b b8 00 05 00 18 20 01 0d b8 33 0f a0 d1   ........ ...3...
0060  00 00 00 00 00 00 00 bd 00 00 0e 10 00 00 1c 20   ............... 
0070  00 0d 00 58 00 00 31 20 61 64 64 72 65 73 73 20   ...X..1 address 
0080  67 72 61 6e 74 65 64 2e 20 59 6f 75 20 6d 61 79   granted. You may
0090  20 69 6e 63 6c 75 64 65 20 49 41 41 44 44 52 20    include IAADDR 
00a0  69 6e 20 49 41 20 6f 70 74 69 6f 6e 2c 20 69 66   in IA option, if
00b0  20 79 6f 75 20 77 61 6e 74 20 74 6f 20 70 72 6f    you want to pro
00c0  76 69 64 65 20 61 20 68 69 6e 74 2e 00 02 00 0e   vide a hint.....
00d0  00 01 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 01   .....wu:..'](k..
00e0  00 0e 00 01 00 01 1c 77 78 81 08 00 27 9b a1 9b   .......wx...'...
00f0  00 07 00 01 07 00 17 00 10 20 01 0d b8 33 0f a0   ......... ...3..
0100  d1 00 00 00 00 00 00 00 53 00 18 00 11 03 74 70   ........S.....tp
0110  74 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00         t.example.com.

Indice.

Message DHCPv6 : type de message, identificateur de transaction, liste d'options( Association d’identités pour adresse non temporaire Adresse IP statut Identification du serveur Identification du client Priorité du serveur Paramètres de configuration du réseau)