MOOC:Compagnon Act34-s6 - Revision history

Bstevant: Bstevant moved page MOOC:Compagnon Act34 to MOOC:Compagnon Act34-s6

2021-06-15T08:17:27Z

Bstevant moved page MOOC:Compagnon Act34 to MOOC:Compagnon Act34-s6

Vlerouvillois: /* Conclusion */

2019-06-08T14:22:14Z

‎Conclusion

Vlerouvillois: /* Délégation de préfixe à états */

2019-06-08T14:20:26Z

‎Délégation de préfixe à états

Vlerouvillois: /* Options du protcole DHCPv6 */

2019-06-08T14:15:26Z

‎Options du protcole DHCPv6

Vlerouvillois: /* Structure des messages DHCPv6 */

2019-06-08T13:28:18Z

‎Structure des messages DHCPv6

Vlerouvillois: /* Extension du protocole DHCPv6 [RFC 6422] */

2019-06-08T13:19:07Z

‎Extension du protocole DHCPv6 [RFC 6422]

Vlerouvillois: /* Tableau récapitulatif des messages DHCPv6 */

2019-06-08T13:18:19Z

‎Tableau récapitulatif des messages DHCPv6

Vlerouvillois: /* Messages échangés entre relais et serveur */

2019-06-08T13:16:42Z

‎Messages échangés entre relais et serveur

Vlerouvillois: /* Fonctions des messages du protocole DHCPv6 */

2019-06-08T13:14:16Z

‎Fonctions des messages du protocole DHCPv6

Vlerouvillois: /* Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 */

2019-06-08T13:11:20Z

‎Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6

@@ Line 555: / Line 555: @@
 Lorsque les relais disposent d’informations locales, des options spécifiques des messages RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6. Les serveurs DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent alors communiquer tout ou partie de ces informations à leurs clients.
-Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options. Ainsi initialement, ni la délégation de préfixe, ni l'exclusion de préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.
+Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options. Ainsi, initialement, ni la délégation de préfixe ni l'exclusion de préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.
 <!--
 Ceci a impliqué des modifications [RFC 7550] pour clarifier ou préciser la spécification RFC 3315 de DHCPv6 et entraînera prochainement la publication d'une nouvelle version de la spécification du protocole DHCPv6.
 -->
 == Références bibliographiques ==
 <references />

@@ Line 499: / Line 499: @@
 La délégation de préfixe facilite également la renumérotation. Elle permet, par exemple,  d'allouer le préfixe qui servira à générer les nouvelles adresses IPv6.
-Les préfixes sont censés avoir une grande duré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. C'est, par exemple le cas pour la renumérotation passive présentée ci-dessous.
+Les préfixes sont censés avoir une grande duré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. C'est par exemple le cas pour la renumérotation passive présentée ci-dessous.
 ==== Renumérotation des réseaux ====
-La renummérotation peut se faire de deux façons : passive ou active.
+La renumérotation peut se faire de deux façons : passive ou active.
 ===== Renumérotation passive =====
@@ Line 514: / Line 514: @@
 Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est possible. Toutes les communications utilisant les anciennes adresses sont coupées. Elles sont, en cas de besoin, rétablies en utilisant les nouvelles adresses.
-Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines auto-configurent leurs nouvelles adresses.
+Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines autoconfigurent leurs nouvelles adresses.
 Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes d'accès au routeur demandeur et d'accès au réseau qu'il dessert.
@@ Line 521: / Line 521: @@
 Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne de l'interface qui le relie au routeur délégataire. Il utilise alors deux des options du RFC 6603.
-''(l'annexe 4 presente la structure de l'option d'association d'identités pour la délégation de préfixes).''
+''(l'annexe 4 présente la structure de l'option d'association d'identités pour la délégation de préfixes).''
 === Principe de l'allocation ===
@@ Line 538: / Line 538: @@
 Le serveur renvoie son message RELAY-REPLY au relais.
-Le relais  extrait le message ADVERTISE  de l'option "message relayé" du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans le champ Peer-Address de l'en-tête du message RELAY-REPLY (voir la figure 9).
+Le relais  extrait le message ADVERTISE  de l'option "message relayé" du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans le champ ''Peer-Address'' de l'en-tête du message RELAY-REPLY (voir la figure 9).
 <center>

@@ Line 381: / Line 381: @@
 Le serveur DHCPv6, s'il est configuré pour cela, effectue des mises à jour dynamiques sécurisées du service de noms de domaines.
-=== Options du protcole DHCPv6===
+=== Options du protocole DHCPv6===
 Chaque option est codée en format TLV : type, longueur, valeur ; à savoir :
-* le type de l'option : Un champ <tt>type d'option</tt> 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ées en plusieurs champs (voir Annexe 1 : options du protocole DHCPv6) ;
+* le type de l'option : un champ <tt>type d'option</tt> 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ées en plusieurs champs (voir annexe 1 : options du protocole DHCPv6) ;
 * la longueur, en octets, du champ <tt>valeur du paramètre</tt> qui suit ;
 * le champ <tt>valeur du paramètre de configuration</tt>.
@@ Line 446: / Line 446: @@
 |<tt>OPTION_RAPID_COMMIT</tt>
 ||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'').
+||Permet à un client, dans un message SOLICIT, 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'').
 |-
 |<tt>OPTION_USER_CLASS</tt>

@@ Line 258: / Line 258: @@
 == Structure des messages DHCPv6 ==
-Le document RFC 8415 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 donc changer et évoluer rapidement, sans impacter les mécanismes de cet échange. Cette séparation assure la stabilité et l'extensibilité du protocole.
+Le document RFC 8415 décrit l'ensemble des éléments du protocole DHCPv6. À 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 donc 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ée 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. Les options utilisables par DHCPv6 sont référencées dans un registre maintenu par l'IANA<ref>IANA. Protocol Registries [http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Dynamic Host Configuration Protocol for IPv6 (DHCPv6)]</ref>.
-Dans la terminologie DHCPv6, le terme message désigne une unité de données du 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.
+Dans la terminologie DHCPv6, le terme "message" désigne une unité de données du 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.
 === Structure des messages émis par les serveurs et clients DHCPv6 ===
@@ Line 274: / Line 274: @@
 <tt>Type-msg</tt> : le champ <tt>type de message</tt> identifie la nature du message DHCPv6. Il est codé sur un octet.
-<tt>Id-transaction</tt> : l'identificateur de transaction identifie un échange (question/réponse). Il est spécifique aux messages participant à une transaction, et est globalement unique. Il permet d'associer les réponses aux requêtes correspondantes. En effet la couche transport UDP ne garantit pas le sequencement des réponses, lorsque plusieus requêtes successives ont été émises à destination d'un serveur. Il est codé sur 3 octets.
+<tt>Id-transaction</tt> : l'identificateur de transaction identifie un échange (question/réponse). Il est spécifique aux messages participant à une transaction, et est globalement unique. Il permet d'associer les réponses aux requêtes correspondantes. En effet, la couche transport UDP ne garantit pas le séquencement des réponses lorsque plusieurs requêtes successives ont été émises à destination d'un serveur. Il est codé sur 3 octets.
-<tt>Option list</tt> : la liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, selon la sémantique du message, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent, soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.
+<tt>Option list</tt> : la liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, selon la sémantique du message, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.
 Pour en savoir plus sur les options, reportez-vous à l’annexe 1 ''Options du protocole DHCPv6'' de cette activité.
@@ Line 291: / Line 291: @@
 <tt>Type-msg</tt> : le type du message identifie le type du message DHCPv6.
-<tt>Hop-count</tt> : le nombre de sauts 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.
+<tt>Hop-count</tt> : le nombre de sauts 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.
 <!--
 <tt>Link-address</tt> : l'adresse locale au lien désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).
-<tt>Peer-address</tt> : l'adresse du pair 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.
+<tt>Peer-address</tt> : l'adresse du pair 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.
 -->
-<tt>Link-address</tt> : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
+<tt>Link-address</tt> : l'adresse de lien est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
-<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu ''(elle est extraite de l'adresse source du paquet du message reçu)''. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client, ''(elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY)''.
+<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.
 Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel des 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 RELAY-REPLY reçu. Le champ <tt>Peer-address</tt> de 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.
@@ Line 317: / Line 317: @@
 <tt>Link-address</tt> : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
-<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu ''(elle est extraite de l'adresse source du paquet du message reçu)''. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client, ''(elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY)''.
+<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.
 <tt>Option list</tt> : la liste d’options de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais.
@@ Line 341: / Line 341: @@
 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 comme identifiant, même en cas de remplacement ultérieur de cette carte réseau.
-Les clients utilisent les DUID pour identifier les serveurs quand 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 configuration du réseau.
+Les clients utilisent les DUID pour identifier les serveurs quand ils en ont besoin ; par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 ou des paramètres de configuration du réseau.
-Le contenu des DUID n’est pas interprété, mais uniquement utilisé pour des comparaisons ou pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.
+Le contenu des DUID n’est pas interprété mais uniquement utilisé pour des comparaisons ou pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.
-Le RFC 8415 définit 3 types d’identificateurs unique DHCPv6 (DUID). Les DUID peuvent, donc, être générés selon 3 méthodes, repérés par le champ  <tt>type de DUID</tt> dont les valeurs respectives sont :
+Le RFC 8415 définit trois types d’identificateurs uniques DHCPv6 (DUID). Les DUID peuvent donc être générés selon trois méthodes, repérées par le champ  <tt>type de DUID</tt> dont les valeurs respectives sont :
-* <tt>1</tt> : '''''DUID-LLT''''' ''(Link-Layer address plus Time)'' resultant de la combinaison d'une adresse physique et d'une horodate ;
+* <tt>1</tt> : '''''DUID-LLT''''' ''(Link-Layer address plus Time)'' résultant de la combinaison d'une adresse physique et d'une horodate ;
 * <tt>2</tt> : '''''DUID-EN''''' ''(Vendor-assigned unique ID based on Enterprise Number)'' dérivé d'un numéro de constructeur ou d'un numéro unique affecté par un constructeur ;
 * <tt>3</tt> : '''''DUID-LL''''' ''(Link-Layer address)'' dérivé de l'adresse MAC d'une interface de réseau.

@@ Line 252: / Line 252: @@
 === 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.
+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.

← Older revision	Revision as of 08:17, 15 June 2021
(No difference)

@@ Line 198: / Line 198: @@
 || 3
 || Client
-|| Demander des adresses et/ou des paramètres de configuration au serveur choisi.
+|| Demander des adresses ou des paramètres de configuration au serveur choisi.
 |-
 | '''CONFIRM'''
@@ Line 223: / Line 223: @@
 || 8
 || Client
 || Indiquer au serveur que le client n'utilise plus des adresses IPv6.
 |-style="background:silver"
 | '''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'''

@@ Line 176: / Line 176: @@
 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 REPLY destiné au client et contenu dans l'option "message relayé" de ce message RELAY-REPLY pour le lui remettre. Ici encore, le message du client reste inchangé.
 === Tableau récapitulatif des messages DHCPv6 ===

@@ Line 130: / Line 130: @@
 == Fonctions des messages du protocole DHCPv6 ==
-Cette partie introduit les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur, et d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.
+Cette partie introduit les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur et, d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.
 En général, les messages échangés transportent des identificateurs de transactions et des associations d'identités. Les serveurs DHCPv6 utilisent les identificateurs de transactions pour associer leurs réponses aux demandes correspondantes des clients. L'identificateur de transaction change pour chaque transaction et est globalement unique pour une transaction donnée. Mais les messages associés à une transaction se distinguent notamment par le champ <tt>Type</tt> de l'en-tête DHCPv6.
@@ Line 138: / Line 138: @@
 === Messages échangés entre client et serveur ===
-Un client utilise le message SOLICIT (champ <tt>Type</tt> = 1) pour localiser les serveurs configurés pour allouer des adresses et/ou des paramètres de configuration du réseau.
+Un client utilise le message SOLICIT (champ <tt>Type</tt> = 1) pour localiser les serveurs configurés pour allouer des adresses 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 <tt>Type</tt> = 2).
-Un client utilise ensuite le message REQUEST (champ <tt>Type</tt> = 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 qu’il demande.
+Un client utilise ensuite le message REQUEST (champ <tt>Type</tt> = 3) pour demander des adresses ou des paramètres de configuration au serveur DHCPv6 choisi. Une option ''options demandées'' contient la liste des paramètres de configuration qu’il demande.
 Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message SOLICIT ou REQUEST reçu d’un client DCHPv6.

@@ Line 87: / Line 87: @@
 == Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==
-Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le (ou les) préfixe(s) à y utiliser.
+Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le ou les préfixes à y 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...)''. Notez que, pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.
+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...). Notez que, pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.
 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 ensuite 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 individuelle (unicast) du serveur DHCPv6. L'administrateur du réseau doit, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse, individuelle ou diffusion sélective, utilisé.
@@ Line 97: / Line 97: @@
 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 (adresse globale ou locale au lien) 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’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.
+Chaque relais traversé identifie (adresse globale ou locale au lien), 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’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.
 Notez que le message du client est recopié dans l'option "message relayé" du message RELAY-FORWARD 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.