Difference between revisions of "MOOC:Compagnon Act33-s7"
From Livre IPv6
(→Délégation de préfixe à états) |
(→applications de la délégation de préfixe) |
||
| Line 962: | Line 962: | ||
|DSL to subscriber / | |DSL to subscriber / | ||
|premises / | |premises / | ||
| − | + | | | |
+------+------+ \ | +------+------+ \ | ||
| CPE | \ | | CPE | \ | ||
Revision as of 15:54, 12 June 2015
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 DHCPv6, 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 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 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 pour se configurer besoin 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. ils changent pour chaque transaction et son 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é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 demander des adresses et/ou des paramètres de configuration.
Un serveur configuré pour fournir des adresses ou des paramètres de configuration 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 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 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. 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é 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.
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. 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-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. Ici encore le message du client reste inchangé.
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 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.
Format des messages DHCPV6
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 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 serveur - relais sont différents des messages utilisés pour la communication client - serveur.
Un message de relais contient l'information de remise du message DHCPv6 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 pair(peer-address) identifie le lien auquel le client à configurer est raccordé. Le message DHCPv6 du client ou la réponse du serveur sont encapsulés dans le message de relais, dans une option de message de relais.
Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel 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. Une fois ce message de relais extrait, le relais dispose de l'adresse du pair à qui envoyer message RELAY-REPLY nouvellement extrait.
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.
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
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é de 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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.
6.4.2. 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.
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, 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 effectuer des mises à jour dynamiques du service de noms de domaine.
Options
Chaque option est identifiée dans le paquet par un champ type d'option. 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 4 + longueur de la valeur du champ longueur de l'option.
| 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 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 |
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 ALL_DHCP_And_ Relay_Agent.
Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE.
Au cas où plusieurs serveurs DHCPV6 configurés seraient disponibles, le client ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. le client émet alors un message request. Il envoie ce message à l’adresse de diffusion sélective ALL_DHCP_And_ Relay_Agent. Ainsi tous les serveurs qui ont répondu à la demande du client savent 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.
- Animation ****
Client Serveur
Solicit
---------------------------->
Advertise
<----------------------------
Request
---------------------------->
Reply
<-------------------------
La
Recherche des serveurs DHCPv6 par le client DHCPv6
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 pour expédier ce message vers le port UDP destination du serveur. 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 ALL_DHCPV6_Relay_Agents_and_Servers comme adresse IPv6 de destination.
UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à transmettre à la couche IPv6.
IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Comme notre client n’a qu’une interface, celle-ci est associée à la route par défaut. 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 empruntera 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.
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 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 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, options ( Identification du client Association d’identités pour adresse non temporaire Temps écoulé depuis l’activation du processus DHCPv6 client paramètres de configuration du réseau demandés)
Question.
Dans la capture de trame Ethernet qui précède, 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). Réponse .
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
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 ( 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)
Question.
Dans la capture de trame Ethernet qui précède, 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 ype Ethernet ?
Quelles sont les valeurs, le type et la fonction des adresses 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é par le protocole de transport ?
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
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 1). Réponse.
Emission du message REQUEST du client DHCPv6 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 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 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd ........'....... 0010 60 00 00 00 00 6a 11 01 fe 80 00 00 00 00 00 00 `....j.......... 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 6a 5f e6 .........".#.j_. 0040 03 b1 4a a1 00 01 00 0e 00 01 00 01 1c 77 78 81 ..J..........wx. 0050 08 00 27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff ..'......(...... 0060 ff ff ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f .......... ...3. 0070 a0 d1 00 00 00 00 00 00 00 bd 00 00 0e 10 00 00 ................ 0080 1c 20 00 06 00 04 00 17 00 18 00 02 00 0e 00 01 . .............. 0090 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02 ...wu:..'](k.... 00a0 00 00 ..
Indice Message DHCPv6 : type de message, identificateur de transaction ( 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)
Question. Dans la capture de trame Ethernet qui précède, 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 des adresses 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é par le protocole de transport ?
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
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) Réponse.
Emission du message REPLY 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 ac 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 ac c0 dd ..'......#.".... 0040 07 b1 4a a1 00 03 00 4a 00 00 00 01 00 00 07 d0 ..J....J........ 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 1e 00 00 41 6c 6c 20 61 64 64 72 65 73 ......All addres 0080 73 65 73 20 77 65 72 65 20 61 73 73 69 67 6e 65 ses were assigne 0090 64 2e 00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00 d..........wu:.. 00a0 27 5d 28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81 '](k.........wx. 00b0 08 00 27 9b a1 9b 00 07 00 01 07 00 17 00 10 20 ..'............ 00c0 01 0d b8 33 0f a0 d1 00 00 00 00 00 00 00 53 00 ...3..........S. 00d0 18 00 11 03 74 70 74 07 65 78 61 6d 70 6c 65 03 ....tpt.example. 00e0 63 6f 6d 00 com.
indice Message DHCPv6 REPLY, identificateur de transaction ( Association d’identités pour adresse non temporaire Adresse IPv6 Paramètres de configuration demandés Identification du serveur Identification du client Temps écoulé depuis l’activation du processus DHCPv6 client)
Question. Dans la capture de trame Ethernet qui précède, 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 des adresses 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é par le protocole de transport ?
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
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) Réponse.
Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6
Lorsque le client se trouve derrière un routeur par rapport au serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors pas allouer d’adresse correspondant au lien du client puisqu'il ignore le ou les préfixes à utiliser.
Le routeur intermédiaire entre le client et le serveur DHCPv6 doit supporter une fonction relais DHCPv6. Comme DHCPv6 est un nouveau protocole spécifique d’IPv6, il n’a pas de contrainte de compatibilité ascendante. C’est pourquoi le fonctionnement des relais DHCPv6 est différent de celui des relais DHCPv4. L'activation de la fonction relais DHCPv6 sur le routeur le transforme en relais DHCPv6. Nous ferons un abus de langage en nommant ce routeur relais DHCPV6 (nous l'avions déjà fait, mais sans le dire...).
Un relais DHCPv6 qui reçoit un message DHCPv6 d’un client l'encapsule dans un message DHCPv6 relay-forward. Le message du client est inclus dans l'option message relayé du message RELAY-FORWARD que le relais envoie au serveur. Le relais DHCPv6 envoie le message RELAY-FORWARD au serveur DHCPV6, soit en utilisant l’adresse de diffusion sélective réservée, et dans ce cas aucune configuration n'est nécessaire, soit en utilisant l’adresse unicast du serveur. Il faut, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse utilisé.
Lorsque le message DHCPv6 d’un client doit traverser plusieurs relais DHCPv6, chaque relais encapsule le message relay-forward reçu du relais précédent dans l'option message relayé de son propre message relay forward.
Chaque relais traversé identifie dans son message RELAY-FORWARD, l’interface sur laquelle il a reçu le message du client ou du relais précédent et l’interface par laquelle il réexpédie au serveur son message relay forward. Rappelons que le message du client est recopié dans l'option message relayé du premier relais DHCPv6 traversé.
Si le message traverse plusieurs relais, l'option message relayé du relais courant contient le message RELAY-FORWARD du relais précédent.
Lorsque serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPV6, il trouve dans l'en-tête de ce message l'adresse ipv6 du dernier relais. Il saura donc où envoyer son message RELAY-REPLY.
Chaque relais intermédiaire procéde de la sorte en extrayant le message RELAY-FORWARD du relais précédent.
Le chemin inverse n’est par conséquent pas difficile à calculer. Le serveur DHCPv6 peut donc ainsi faire parvenir sa réponse au client.
Client Relais Serveur
. SOLICIT
---------------------->
. Relay-forward (solicit)
----------------------------->
. Relay-reply (advertise)
<-----------------------------
. Advertise
<----------------------
. request
---------------------->
. Relay-forward (request)
----------------------------->
. Relay-reply (Reply)
<-----------------------------
. Reply
<----------------------
Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie (DAD) que l'adresse ipv6 allouée n'est pas déjà en service. Il configure alors ses interfaces de réseau. L'utilisateur qui travaille sur le client DHCPv6 peut alors accéder au réseau. Le processus DHCPv6 devient inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Le processus DHCPv6 client se réactive alors pour libérer (release) l'adresse IPv6 allouée.
Détail des messages DHCPv6
SOLICIT
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 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 91 07 .........".#.<.. 0040 01 45 32 94 00 01 00 0e 00 01 00 01 1c 77 78 81 .E2..........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, options (Identification du client Association d’identités pour adresse non temporaire Temps écoulé depuis l’activation du processus DHCPv6 client paramètres de configuration du réseau demandés)
Question.
Dans la capture de trame Ethernet qui précède, 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). Réponse .
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
RELAY-FORWARD(SOLICIT)
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 8e e4 bd 00 00 86 dd ........'....... 0010 60 00 00 00 00 6a 11 01 20 01 0d b8 33 0f a0 d1 `....j.. ...3... 0020 00 00 00 00 00 00 01 97 ff 05 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 01 00 03 02 23 02 23 00 6a 6a 54 .........#.#.jjT 0040 0c 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00 .. ...3......... 0050 01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b ............'... 0060 a1 9b 00 12 00 04 00 00 13 9c 00 09 00 34 01 45 .............4.E 0070 32 94 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00 2..........wx... 0080 27 9b a1 9b 00 03 00 0c 00 00 00 01 ff ff ff ff '............... 0090 ff ff ff ff 00 08 00 02 00 00 00 06 00 04 00 17 ................ 00a0 00 18 ..
RELAY-REPLY(ADVERTISE)
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 00 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd ........'.E..... 0010 60 00 00 00 00 eb 11 40 fe 80 00 00 00 00 00 00 `......@........ 0020 0a 00 27 ff fe 1e 45 17 20 01 0d b8 33 0f a0 d1 ..'...E. ...3... 0030 00 00 00 00 00 00 01 97 02 23 02 23 00 eb d2 3b .........#.#...; 0040 0d 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00 .. ...3......... 0050 01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b ............'... 0060 a1 9b 00 12 00 04 00 00 13 9c 00 09 00 b5 02 45 ...............E 0070 32 94 00 03 00 84 00 00 00 01 00 00 0e 10 00 00 2............... 0080 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 00 00 ...... ...3..... 0090 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 00 0d ........Q....... 00a0 00 58 00 00 31 20 61 64 64 72 65 73 73 20 67 72 .X..1 address gr 00b0 61 6e 74 65 64 2e 20 59 6f 75 20 6d 61 79 20 69 anted. You may i 00c0 6e 63 6c 75 64 65 20 49 41 41 44 44 52 20 69 6e nclude IAADDR in 00d0 20 49 41 20 6f 70 74 69 6f 6e 2c 20 69 66 20 79 IA option, if y 00e0 6f 75 20 77 61 6e 74 20 74 6f 20 70 72 6f 76 69 ou want to provi 00f0 64 65 20 61 20 68 69 6e 74 2e 00 02 00 0e 00 01 de a hint....... 0100 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 01 00 0e ...wu:..'](k.... 0110 00 01 00 01 1c 77 78 81 08 00 27 9b a1 9b 00 07 .....wx...'..... 0120 00 01 07 ...
Dans la capture de trame Ethernet qui précède, 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). Réponse .
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
ADVERTISE
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 a5 cd 3d 00 00 86 dd ........'..=.... 0010 60 00 00 00 00 bd 11 40 fe 80 00 00 00 00 00 00 `......@........ 0020 0a 00 27 ff fe a5 cd 3d fe 80 00 00 00 00 00 00 ..'....=........ 0030 0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 bd 71 be ..'......#."..q. 0040 02 45 32 94 00 03 00 84 00 00 00 01 00 00 0e 10 .E2............. 0050 00 00 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 ........ ...3... 0060 00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 ..........Q..... 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 .....
Indice.
Message DHCPv6 : type de message, identificateur de transaction ( 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)
Question.
Dans la capture de trame Ethernet qui précède, 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 ype Ethernet ?
Quelles sont les valeurs, le type et la fonction des adresses 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é par le protocole de transport ?
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
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 1). Réponse.
request
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 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd ........'....... 0010 60 00 00 00 00 6a 11 01 fe 80 00 00 00 00 00 00 `....j.......... 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 6a 80 cf .........".#.j.. 0040 03 ad 5f 37 00 01 00 0e 00 01 00 01 1c 77 78 81 .._7.........wx. 0050 08 00 27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff ..'......(...... 0060 ff ff ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f .......... ...3. 0070 a0 d2 00 00 00 00 00 00 00 ed 00 01 51 80 00 02 ............Q... 0080 a3 00 00 06 00 04 00 17 00 18 00 02 00 0e 00 01 ................ 0090 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02 ...wu:..'](k.... 00a0 00 00 ..
Relay-forward (request)
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 8e e4 bd 00 00 86 dd ........'....... 0010 60 00 00 00 00 98 11 01 20 01 0d b8 33 0f a0 d1 `....... ...3... 0020 00 00 00 00 00 00 01 97 ff 05 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 01 00 03 02 23 02 23 00 98 59 ee .........#.#..Y. 0040 0c 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00 .. ...3......... 0050 01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b ............'... 0060 a1 9b 00 12 00 04 00 00 13 9c 00 09 00 62 03 ad .............b.. 0070 5f 37 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00 _7.........wx... 0080 27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff ff ff '......(........ 0090 ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f a0 d2 ........ ...3... 00a0 00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 ..........Q..... 00b0 00 06 00 04 00 17 00 18 00 02 00 0e 00 01 00 01 ................ 00c0 1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02 00 00 .wu:..'](k......
Indice.
Message DHCPv6 : type de message, nombre de sauts, adresse du lien (côté client DHCPv6), adresse du pair, (options : identificateur d'interface, message relayé (type de message, identificateur de transaction, identificateur de client (DUID, typede DUID, type de réseau physique, adresse MAC), association d'identités pour adresse non temporaire (identificateur d'association d'identité, T1 durée de vie en mode préféré, T2 durée de vie totale, temps écoulé, paramètres de configuration du réseau demandés),
Relay-reply (Reply)
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 00 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd ........'.E.....
0010 60 00 00 00 00 b1 11 40 fe 80 00 00 00 00 00 00 `......@........
0020 0a 00 27 ff fe 1e 45 17 20 01 0d b8 33 0f a0 d1 ..'...E. ...3...
0030 00 00 00 00 00 00 01 97 02 23 02 23 00 b1 3c c5 .........#.#..<.
0040 0d 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00 .. ...3.........
0050 01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b ............'...
0060 a1 9b 00 12 00 04 00 00 13 9c 00 09 00 7b 07 ad .............{..
0070 5f 37 00 03 00 4a 00 00 00 01 00 00 0e 10 00 00 _7...J..........
0080 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 00 00 ...... ...3.....
0090 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 00 0d ........Q.......
00a0 00 1e 00 00 41 6c 6c 20 61 64 64 72 65 73 73 65 ....All addresse
00b0 73 20 77 65 72 65 20 61 73 73 69 67 6e 65 64 2e s were assigned.
00c0 00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00 27 5d .........wu:..']
00d0 28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00 (k.........wx...
00e0 27 9b a1 9b 00 07 00 01 07 '........
Reply
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 a5 cd 3d 00 00 86 dd ........'..=.... 0010 60 00 00 00 00 83 11 40 fe 80 00 00 00 00 00 00 `......@........ 0020 0a 00 27 ff fe a5 cd 3d fe 80 00 00 00 00 00 00 ..'....=........ 0030 0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 83 dc 0d ..'......#.".... 0040 07 ad 5f 37 00 03 00 4a 00 00 00 01 00 00 0e 10 .._7...J........ 0050 00 00 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 ........ ...3... 0060 00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 ..........Q..... 0070 00 0d 00 1e 00 00 41 6c 6c 20 61 64 64 72 65 73 ......All addres 0080 73 65 73 20 77 65 72 65 20 61 73 73 69 67 6e 65 ses were assigne 0090 64 2e 00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00 d..........wu:.. 00a0 27 5d 28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81 '](k.........wx. 00b0 08 00 27 9b a1 9b 00 07 00 01 07 ..'........
libération de l'adresse IPv6 par le client DHCPv6 avec présence d'un relais
Le processus d'arrêt normal du client DHCPv6 inclut la libération de l'adresse ipv6 allouée par le serveur. La figure ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais.
Client Relais Serveur
. RELEASE
---------------------->
. Relay-forward (RELEASE)
----------------------------->
. Relay-reply (REPLY)
<-----------------------------
. REPLY
<----------------------
La figure ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais;
Client Serveur
. RELEASE ---------------------->
. REPLY <---------------------
Délégation de préfixe à états
La délégation de préfixe à états fait intervenir deux routeurs. un routeur délégataire et un routeur demandeur. Elle utilise le protocole DHCPv6 pour assurer la délégation de préfixe et définit deux options : une association d'identités pour l'allocation de préfixes (IA_PD) et une option de préfixe d'association d'identités pour la délégation de préfixe (IA_PD Prefix).
Ces options permettenr au routeur délégataire de déléguer la gestion d'un ou plusieurs préfixes à un routeur demandeur.
L'association d'identités pour l'allocation de préfixes associe notamment les DUID des routeurs demandeur et délégataire et les préfixes alloués.
L'option de préfixe d'association d'identités pour la délégation de préfixe transporte un préfixe qu'un routeur délégataire a déléqué à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une
Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6
applications de la délégation de préfixe
La délégation de préfixe convient pour des situations où le routeur délégataire ignore la topologie du réseau auquel le routeur demandeur donne accès et n'a pas d'autre information à connaître que l'identité du routeur demandeur pour allouer le préfixe. c'est, par exemple, le cas du routeur d'un FAI : fournisseur d'accès Internet) (ISP : Internet service Provider) qui alloue un préfixe au routeur d'accès d'un client (CPE : customer Premise Equipment) qui relie un réseau interne au réseau du FAI. La figure ci-dessous présente un exemple où la délégation de préfixe à états est possible.
______________________ \
/ \ \
| ISP core network | \
\__________ ___________/ |
| |
+-------+-------+ |
| Aggregation | | ISP
| device | | network
| (delegating | |
| router) | |
+-------+-------+ |
| /
|DSL to subscriber /
|premises /
|
+------+------+ \
| CPE | \
| (requesting | \
| router) | |
+----+---+----+ |
| | | Subscriber
---+-------------+-----+- -+-----+-------------+--- | network
| | | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|Subscriber| |Subscriber| |Subscriber| |Subscriber| /
| PC | | PC | | PC | | PC | /
+----------+ +----------+ +----------+ +----------+ /
La délégation de préfixe facilite également la renumérotation. Les préfixes sont censés avoir une grande dirée de vie. EN cas de renumérotation, la cohabitation pendant un certain temps de l'ancien et du nouveau préfixe est fort probable.
Conclusion
Annexe 1. Structure des options du protocole DHCPv6
La structure générale des options est la suivante. Elle correspond à un codage TLV : type, longueur, valeur.
Le type ou code est un entier non signé. Il précise quelle est l’option. La longueur de l’option précise la taille en octet du champs de données de l’option. Le champs type de l'option en est exclus. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.
la portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'un association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.
La structure générale d'une option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d'identification du client
L'option d'identification du client (Client Identifier Option) transporte le DUID (DHCPv6 User Identification) du client dans les messages DHCPv6 échangés entre client et serveur.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CLIENTID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . DUID . . (variable length . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option identification du serveur (Server Identification Option)
L'option identification du serveur (Server Identification Option) transporte le DUID (DHCPv6 User Identification) du serveur dans les messages DHCPv6 échangés entre client et serveur.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SERVERID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . DUID . . (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option association d’identité pour les adresses non temporaires
L'Option association d’identité pour les adresses non temporaires (option IA_NA : Identity Association for Non Temporary Addresses) inclut les paramètres de cette association et les adresses non temporaires associées. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6.
Cette association transporte un identificateur d'IA_NA, les temporisations T1 durée de vie préférée d'une adresse et T2 durée de vie maximum d'une adresse et les options de cette association, par exemple la liste des options d'adresse spécifiques de cette association.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_NA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_NA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d'association d’identité pour les adresses temporaires
L'option d'association d’identité pour les adresses temporaires (option IA_TA : Identity Association for Temporary Addresses) inclut les paramètres de cette association et au plus une adresses temporaires associées par préfixe autorisé sur le lien du client. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6. Une option statut indique l'état de toute opération impliquant cette option.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_TA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_TA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d’adresse d'association d'identités
L'option d'adresse'association d'identités (IA Address Option) spécifie une adresse IPv6 associée à une association d'identités IA_NA ou IA_TA. Elle apparaît dans le champ d'option d'une association d'identités pour adresse non temporaire ou temporaire. Une option statut indique l'état de toute opération impliquant cette adresse.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IAADDR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IAaddr-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option de demande d’options
L'option de demande d'option (Options Request Option) identifie la liste des options demandées par le client ou fournies ou cconcernées pour le serveur.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ORO | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | requested-option-code-1 | requested-option-code-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option de priorité (du serveur)
L'option de priorité (Preference Option) indique la priorité du serveur au client.
Un client choisit le serveur de priorité la plus élevée. En cas d'égalité des priorités, il choisit le serveur de priorité la plus élevée qui lui propose la meilleure offre. Il peut ne pas choisir l'offre du serveur le plus prioritaire. Le choix repose alors sur l'adéquation de l'offre.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFERENCE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref-value | +-+-+-+-+-+-+-+-+
Option temps écoulé (depuis le début d'un échange)
L'option temps écoulé mesure le temps écoulé (Elapsed Time Option) depuis l'émission du premier message d'un échange DHCPv6 inachevé. Cette option vaut 0 dans le premier message d'un échange.
Serveurs et agents utilisent la valeur de cette option pour déterminer leur façon de traiter le message DHCPv6 correspondant. La valeur ffff en hexadécimal (0xffff) représente une durée supérieure à la plus grande durée représentable.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ELAPSED_TIME | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | elapsed-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option message relayé
L'option message relayé (RELAY Message Option) contient le message DHCPv6 relayé dans un message RELAY-FORWARD ou RELAY-REPLY.
Le message relayé, dans le cas d'un message qui transite du client vers le serveur, est soit le message DHCPv6 du client (premier relais), soit le message RELAY-FORWARD du relais précédent (du deuxième relais au dernier).
Le message relayé dans le cas d'un message qui transite du serveur vers le client est, soit le message REPLY du serveur (premier relais), soit le message RELAY-REPLY du relais précédent (du deuxième relais au dernier).
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RELAY_MSG | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . DHCP-relay-message . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d’authentification
L'option d'authentification (Authetication Option) transporte une information d'authentification. Cette information authentifie l'identité de l'émetteur et l'intégrité du message DHCPv6. Cette option fournit un environnement qui prend en compte différents protocoles d'authentification, ce qui permettra d'en prendre en compte de nouveaux.
Cette option décrit donc le protocole d'authentification utilisé, la méthode de protection contre le rejeu, l'algorithme de génération du condensé (MAC : Message Authentification Code) qui authentifie le message, et bien entendu la valeur du condensé (128 bits, pa exemple).
Rappel : le principe de l'authentification consiste à calculer un condensé de taille fixe qui ne dépend que de l'information prise en compte (le message DHCPv6, par exemple) en utilisant un algorithme tel que deux informations différentes produisent très probablement des condensés différents. La comparaison des condensés reçu et calculé par le récepteur permet de décider si les données reçues sont ou ne sont pas acceptables. Si ces condensés sont ientiques, l'information est acceptable. Elle ne l'est pas sinon.
La sécurisation des échanges DHCPv6 entre serveurs et relais adjacents utilise IPsec.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_AUTH | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | protocol | algorithm | RDM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | replay detection (64 bits) +-+-+-+-+-+-+-+-+ | | auth-info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . authentication information . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d’utilisation de l'adresse individuelle du serveur
L'option d'utilisation de l'adresse individuelle du serveur (Server Unicast Option), qu'émet un serveur, autorise le client DHCPv6 qui reçoit cette option à échanger avec le serveur en utilisant son adresse individuelle au lieu de l'adresse de diffusion sélective All_DHCP_Relay_Agents_and_Servers address.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_UNICAST | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option de code d’état
L'option code d'état Status Code Option) renvoie une indication d'état relative au message DHCPv6 ou à l'option dans laquelle cette option apparaît. L'omission du code d'état dans un message ou dans une option où son utilisation est possible signifie succès (success).
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_STATUS_CODE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | status-code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . status-message . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L'annexe 2 présente les valeurs des différents codes d'état.
Option de Validation rapide
L'option de validation rapide (Rapid Commit Option) indique l'utilisation d'un échange à deux messages pour l'allocation d'adresses ipv6.
Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.
Un serveur doit inclure cete option le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RAPID_COMMIT | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option classe d'utilisateur
L'option classe d'utilisateur (User Class Option)identifie un type ou une classe d'utilisateurs ou d'applications qu'ils représentent. La partie données de cette option contient plusieurs champs non interprétés (Opaque) par DHCPV6. Ces champs représentent la classe d'utilisateur à laquelle appartient le client.
Un serveur choisit les informations de configuration du client en fonction de la classe identifiée par l'option.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . user-class-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La structure de la partie données de cette option peut apparaître plusieurs fois. Elle est la suivante :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Option de classe de constructeur
L'option de classe de constructeur (Vendor Class Option)identifie le constructeur du matériel qui supporte le client DHCPv6. Le numéro d'entreprise identifie le constructeur.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-class-data . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les paramètres définissant la classe du constructeur se suivent les uns les autres dans le champ de données de classe de constructeur. Chaque paramètre est codé en format LV. DHCPv6 n'interprète pas la valeur (opaque) de ces paramètres.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | vendor-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Option d'information spécifique d'un constructeur
L'option d'information spécifique d'un constructeur (Vendor-specific Information Option) permet que les clients et serveurs DHCPv6 échangent des informations spécifiques d'un constructeur. Le numéro d'entreprise identifie le constructeur.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_OPTS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La spécification des données échangées dépend du constructeur. Chacune de ces options de données est codée en format TLV. Le constructeur définit leur code. Plusieurs options de données peuvent se succéder dans le champ de données de l'optiond'information spécifique d'un constructeur.
La structure de l'option de donnée spécifique d'un constructeur 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d'identification d'interface
L'option d'identification d'interface (Interface-Id Option)identifie sur un relais, l'interface de réception du message d'un client.
Un relais qui reçoit un message incluant une option d'identification d'interface relaie le message reçu sur l'interface identifiée dans l'option.
Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option es spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cete information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_INTERFACE_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . interface-id . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option de message de reconfiguration
L'option de message de reconfiguration (Reconfigure Message Option)présente dans un message de reconfiguration issue d'un serveur indique au client s'il doit répondre à l'aide d'un message RENEW ou INFORMATION-REQUEST.Cette option est spécifique du message de reconfiguration.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RECONF_MSG | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | +-+-+-+-+-+-+-+-+
option d'acceptation de reconfiguration
L'option d'acceptation de reconfiguration (Reconfigure Accept Option) annonce au serveur que le client accepte les messages de reconfiguration.
Un serveur utilise cette option pour dire au client s'il doit ou non accepter les messages de reconfiguration. L'absence de cette option indique le refux d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messsages de reconfiguration.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RECONF_ACCEPT | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
extension du protocole DHCPv6 : options spécifiques des relais
Dans certains cas les relais DHCPv6 connaissent des informations qui seraient utiles aux clients DHCPv6.
Le protocole DHCPv6 est étendu (RFC 6422) pour que les relais puissent inclure une option RSSO : RELAY-SUPPLIED OPTIONS OPTION dans les messages RELAY-FORW adressés au serveur DHCPv6.
L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORW adressés au serveur DHCPv6 contient alors toutes les options correspondant à des paramètres que le relais souhaite porter à la connaissance du client. Cette possibilité n’est effective que pour des paramètres classés RSOO.
Le serveur DHCPv6 qui reçoit un message RELAY-FORW contenant une option RSSO enregistre les option classées RSOO fournies par le relais DHCPv6. Il peut ensuite transmettre ces informations aux clients en ajoutant les options de classe RSOO qu’il accepte de transmette au client.
Notez que le relais transmet ces paramètres spécifiques de relais au serveur. Le serveur décide ensuite de transmettre tout ou partie de ces informations au client, éventuellement en fonction de la politique définie par l'administrateur du réseau.
Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un client.
La structure de cette option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RSOO (66) | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | options ... +-+-+-+-+-+-+-+-+-+-+-+
Pour en savoir plus lisez le RFC 6422.
Annexe 2. Codes d’état du protocole DHCPv6
Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 3315.
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCPV6_Relay_Agents_and_Servers
address.
