http://livre.g6.asso.fr/api.php?action=feedcontributions&feedformat=atom&user=JlandruLivre IPv6 - User contributions [en]2026-05-24T23:42:28ZUser contributionsMediaWiki 1.25.2http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act21-s7&diff=20619MOOC:Compagnon Act21-s72024-11-06T14:24:48Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
<br />
= Activité 21: L’en-tête IPv6 =<br />
<!-- = Activité 21: Le format de l’en-tête IPv6 = --><br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau. Il est composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme, utilisé dans l'Internet, impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.<br />
<br />
L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP : <br />
* une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;<br />
* l'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.<br />
<br />
== Format de l'en-tête du datagramme IPv6 ==<br />
Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.<br />
<br />
<br />
<center><br />
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]<br />
</center><br />
<br />
== Signification des champs de l'en-tête ==<br />
<br />
=== Version ===<br />
Le champ <tt>Version</tt> est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].<br />
<br />
=== Classe de trafic (''Traffic Class'') ===<br />
Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].<br />
<br />
Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (''Differentiated Services Code Point'') contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit ''au mieux'' (ou ''best effort''). Les deux derniers bits du champ, notés ECN (''Explicit congestion Notification''), servent aux routeurs à rapporter un risque de congestion [RFC 8311].<br />
<center><br />
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]<br />
</center><br />
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|annexe 1]] décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.<br />
<br />
=== Identificateur de flux (''Flow Label'') ===<br />
Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. L'utilisation de ce champ est spécifiée par le RFC 6437.<br />
<br />
Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission. <br />
<br />
Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les autres informations. <br />
<br />
Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires. <br />
<br />
{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}<br />
<br />
À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.<br />
<br />
=== Longueur de la charge du paquet (''Payload Length'') ===<br />
<br />
Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge du paquet, autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer la taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de "proche en proche" avec l'option ''jumbogramme'' définie par le RFC 2675. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".<br />
<br />
=== En-tête suivant (''Next Header'')===<br />
Ce champ identifie le prochain en-tête de protocole se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau ''Valeurs du champ en-tête suivant pour IPv6'').<br />
<br />
<center><br />
{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br />
</center><br />
<br />
=== Nombre maximal de sauts (''Hop Limit'') ===<br />
<br />
Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud source du paquet et, ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.<br />
Ce champ est à la base de l'outil <tt>traceroute</tt> pour identifier la suite des routeurs traversés jusqu'à une destination.<br />
<br />
La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br />
<br />
La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.<br />
<br />
=== Adresses source et destination ===<br />
Ces adresses sont renseignées par le nœud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre un nœud de l'Internet en donnant comme adresse source une adresse ''lien-local''. Le choix de l'adresse source est spécifié dans le RFC 6724.<br />
<br />
L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.<br />
<br />
=== Extensions à l'en-tête IPv6 ===<br />
L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité. <br />
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.<br />
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.<br />
<br />
Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ <tt>En-tête suivant</tt> (''Next Header'') de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans une activité ultérieure de ce cours.<br />
<br />
<center><br />
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]<br />
</center><br />
<br />
== Evolution de l'en-tête depuis IPv4 ==<br />
<br />
Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage<ref>Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.</ref>, reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.<br />
<br />
L'en-tête ne contient plus de contrôle d'erreur (''checksum''), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ <tt>durée de vie</tt>. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP. <br />
<br />
La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (<tt>Identification, Drapeau, Place du fragment</tt>) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (''Path MTU'') évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.<br />
<br />
Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ <tt>Internet Header Length</tt>), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.<br />
<br />
== Conclusion ==<br />
<br />
Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole IPv4 : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif est d'avoir un traitement simple et donc rapide de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le ''checksum'' ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Pour aller plus loin ==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
* RFC 791 Internet protocol (IPv4)<br />
* RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+<br />
* RFC 2205 Resource ReSerVation Protocol (RSVP)<br />
* RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [http://www.bortzmeyer.org/2474.html Analyse]<br />
* RFC 2675 IPv6 Jumbograms<br />
* RFC 6040 Tunnelling of Explicit Congestion Notification<br />
* RFC 6437 IPv6 Flow Label Specification<br />
* RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br />
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]<br />
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br />
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html Analyse]<br />
<br />
<!--<br />
Vous pouvez approfondir vos connaissances en consultant les documents suivants :<br />
*RFC 1190 : Experimental Internet Stream Protocol Version 2 (ST-II)<br />
*RFC 2492 : IPv6 over ATM Networks (cf page 2)<br />
*RFC 2597 : An Expedited Forwarding PHB<br />
*RFC 2598 : Assured Forwarding PHB Group<br />
*RFC 4594 : Configuration Guidelines for DiffServ Service Classes <br />
*RFC 5865 : A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br />
*RFC 6438 : Flow Label for Tunnel ECMP/LAG (cf page-4)<br />
*RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br />
*RFC 6282 : Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks<br />
*RFC 6775 : Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)<br />
--><br />
<br />
== Annexe 1: la gestion de la qualité de service ==<br />
<br />
L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (''Service Level Agreement'') avec son fournisseur d’accès. <br />
<br />
L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en ''Best Effort'' même si certains sont plus ''Best'' que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi. <br />
<br />
Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur. <br />
<br />
<br />
Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseignée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre le traitement différencié. Le format de ce champ est rappelé en figure 2.<br />
<br />
Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (''Differential Service Code Point''). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet <tt>Traffic Class</tt>, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :<br />
<br />
<center><br />
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]<br />
</center><br />
<br />
Pour l'instant, deux types de comportement sont standardisés :<br />
<br />
* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.<br />
* Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).<br />
<br />
* Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).<br />
<br />
* Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].<br />
<br />
=== Références bibliographiques ===<br />
* RFC 2597 Assured Forwarding PHB Group<br />
* RFC 3246 An Expedited Forwarding PHB<br />
* RFC 4594 Configuration Guidelines for DiffServ Service Classes<br />
* RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br />
<br />
== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==<br />
<br />
Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br />
<br />
De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc. <br />
<br />
Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.<br />
<br />
Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.<br />
<br />
L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br />
<br />
== Principe des extensions IPv6==<br />
<br />
Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).<br />
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.<br />
<br />
Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.<br />
<br />
'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''<br />
<br />
Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.<br />
<br />
== Le champ ''Next Header'' ==<br />
<br />
<center><br />
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]<br />
</center><br />
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :<br />
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br />
</center><br />
<br />
== Intégration des extensions d’en-tête dans le paquet IPv6==<br />
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée : <br />
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br />
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br />
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br />
<br />
<br />
La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6. <br />
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.<br />
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports. <br />
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6). <br />
<br />
<center><br />
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br />
</center><br />
<br />
== Quelques exemples ==<br />
<br />
=== Fragmentation ===<br />
<br />
Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.<br />
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br />
<br />
La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.<br />
<br />
Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.<br />
<br />
=== Extensions d'authentification (AH) et de confidentialité (ESP) ===<br />
<br />
L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.<br />
<br />
Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.<br />
<br />
<br />
L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.<br />
<br />
Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.<br />
<br />
=== Segment Routing Header (SRH) ===<br />
<br />
Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.<br />
<br />
<br />
<br />
<center><br />
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br />
</center><br />
<br />
<br />
L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.<br />
<br />
Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.<br />
<br />
<br />
<br />
<center><br />
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]<br />
</center><br />
<br />
<br />
<br />
Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.<br />
<br />
<br />
<center><br />
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]<br />
</center><br />
<br />
L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.<br />
<br />
Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Pour aller plus loin==<br />
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
<br />
* RFC 4302 : IP Authentication Header<br />
* RFC 4303 : IP Encapsulating Security Payload (ESP)<br />
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br />
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br />
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br />
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br />
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]<br />
* RFC 9673 : IPv6 Hop-by-Hop Options Processing Procedures [http://www.bortzmeyer.org/9673.html Analyse]</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20617MOOC:Compagnon Act13-s72024-09-14T08:14:32Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe <tt>2001:db8::/32</tt> est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe <tt>2001:db8::/32</tt> réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : <tt>192.0.2.0/24</tt> (TEST-NET-1), <tt>198.51.100.0/24</tt> (TEST-NET-2) et <tt>203.0.113.0/24</tt> (TEST-NET-3). Le RFC 9637 étend la plage des adresses documentaires au préfixe <tt>3fff::/20</tt> pour faciliter la documentation d'architectures complexes ou étendues nécessitant des hiérarchies de préfixes multiples. "l'ancien préfixe <tt>2001:db8::/32</tt> reste réservé et valable donc pas besoin de modifier les documentations existantes".}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* '''Le préfixe <tt>3fff::/20</tt>''' réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') '''étend la plage d'adressage documentaire''' afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
* RFC 9637 Expanding the IPv6 Documentation Space [http://www.bortzmeyer.org/9637.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20616MOOC:Compagnon Act13-s72024-09-14T08:12:48Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe <tt>2001:db8::/32</tt> est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe <tt>2001:db8::/32</tt> réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : <tt>192.0.2.0/24</tt> (TEST-NET-1), <tt>198.51.100.0/24</tt> (TEST-NET-2) et <tt>203.0.113.0/24</tt> (TEST-NET-3). Le RFC 9637 étend la plage des adresses documentaires au préfixe <tt>3fff::/20</tt> pour faciliter la documentation d'architectures complexes ou étendues nécessitant des hiérarchies de préfixes multiples. "l'ancien préfixe <tt>2001:db8::/32</tt> reste réservé et valable donc pas besCompagnon_Act01-foin de modifier les documentations existantes".}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* '''Le préfixe <tt>3fff::/20</tt>''' réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') '''étend la plage d'adressage documentaire''' afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
* RFC 9637 Expanding the IPv6 Documentation Space [http://www.bortzmeyer.org/9637.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20615MOOC:Compagnon Act13-s72024-09-13T19:05:40Z<p>Jlandru: /* Pour aller plus loin */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe <tt>2001:db8::/32</tt> est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe <tt>2001:db8::/32</tt> réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : <tt>192.0.2.0/24</tt> (TEST-NET-1), <tt>198.51.100.0/24</tt> (TEST-NET-2) et <tt>203.0.113.0/24</tt> (TEST-NET-3). Le RFC 9637 étend la plage des adresses documentaires au préfixe 3fff::/20 pour faciliter la documentation d'architectures complexes ou étendues nécessitant des hiérarchies de préfixes multiples. "l'ancien préfixe <tt>2001:db8::/32</tt> reste réservé et valable donc pas besoin de modifier les documentations existantes".}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') étend la plage d'adressage documentaire afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
* RFC 9637 Expanding the IPv6 Documentation Space [http://www.bortzmeyer.org/9637.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20614MOOC:Compagnon Act13-s72024-09-13T19:03:26Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe <tt>2001:db8::/32</tt> est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe <tt>2001:db8::/32</tt> réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : <tt>192.0.2.0/24</tt> (TEST-NET-1), <tt>198.51.100.0/24</tt> (TEST-NET-2) et <tt>203.0.113.0/24</tt> (TEST-NET-3). Le RFC 9637 étend la plage des adresses documentaires au préfixe 3fff::/20 pour faciliter la documentation d'architectures complexes ou étendues nécessitant des hiérarchies de préfixes multiples. "l'ancien préfixe <tt>2001:db8::/32</tt> reste réservé et valable donc pas besoin de modifier les documentations existantes".}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') étend la plage d'adressage documentaire afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20613MOOC:Compagnon Act13-s72024-09-13T18:59:26Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3). Le RFC 9637 étend la plage des adresses documentaires au préfixe 3fff::/20 pour faciliter la documentation d'architectures complexes ou étendues nécessitant des hiérarchies de préfixes multiples. "l'ancien préfixe 2001:db8::/32 reste réservé et valable donc pas besoin de modifier les documentations existantes" }}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') étend la plage d'adressage documentaire afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20612MOOC:Compagnon Act13-s72024-09-13T17:50:02Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') étend la plage d'adressage documentaire afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hiérarchies de préfixes multiples. Le préfixe documentaire précédent <tt>2001:db8::/32</tt> reste réservé et valable il n'est donc pas nécessaire de modifier les documentations existantes.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20611MOOC:Compagnon Act13-s72024-09-13T17:46:20Z<p>Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637 (''Expanding the IPv6 Documentation Space'') étend la plage d'adressage documentaire afin de faciliter les descriptions et documentations d'architectures étendues ou complexes nécessitant des hierarchies de préfixes multiples.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20610MOOC:Compagnon Act13-s72024-09-13T17:41:29Z<p>Jlandru: /* Activité 13 : Familles d'adresses IPv6 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
* Le préfixe <tt>3fff::/20</tt> réservé par le RFC 9637<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (<i>multicast</i>) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (<i>broadcast</i>). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br />
<br />
En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre <i>multicast</i> de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (<i>Duplicate Address Detection</i>) suivie d'une trame à destination de <tt>ff02::16</tt> annonçant la nouvelle adresse de <i>multicast</i> sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de <i>multicast</i> sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br />
<br />
Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act04-f&diff=20609MOOC:Compagnon Act04-f2024-04-24T13:33:44Z<p>Jlandru: /* Activité 04 : Pourquoi IPv6 ? */</p>
<hr />
<div>__NOTOC__<br />
<!-- {{Decouverte}} --><br />
<br />
<!--<br />
{{TODO|Reprendre les paragraphes IPv6 de [[MOOC:Compagnon_Act03]] et des éléments historiques de [[La_standardisation_d'IPv6]]}}<br />
--><br />
<br />
= Activité 04 : Pourquoi IPv6 ? =<br />
<br />
== Motivations ==<br />
<br />
Le problème de pénurie des adresses Internet est principalement dû à l'explosion de la demande qui dépasse largement la capacité d'adressage IPv4. Ce problème qui est devenu critique ces dernières années, milite pour l’adoption rapide d’IPv6. En effet, il faut aujourd'hui un grand espace d'adressage pour adresser tous les appareils connectés et par la suite, les futurs objets connectés issus des applications IoT. Dépasser la pénurie d'adresses, c'est aussi ouvrir la voie à de nouveaux services, à de nouveaux acteurs innovants, c'est créer de nouveaux marchés pour de nouveaux besoins. Le passage à IPv6 devient une nécessité car, en attribuant une adresse à chaque nœud du réseau, la connectivité en IPv6 retrouve les principes qui ont fait le succès du fonctionnement de l'Internet.<br />
<!-- et notamment celui du "bout-en-bout". --><br />
<br />
La technologie de l'infrastructure de communication retrouve sa simplicité originelle. Il n'est pas soutenable que la croissance du réseau s'effectue avec une complexité croissante comme avec IPv4. Tout ceci est bien connu et cette évolution est qualifiée par "non passage au facteur d'échelle" (''not scalable''). Ainsi, avec cette simplicité retrouvée, de nouveaux champs d'application s'ouvrent à l'Internet en IPv6. Le [RFC 7368] en donne une illustration avec la domotique. <br />
<br />
En plus de la simplicité retrouvée, IPv6 apporte de nouvelles fonctionnalités, comme la configuration automatique d'un réseau. En IPv4, chaque équipement doit se voir attribuer une adresse et obtenir sa configuration depuis un serveur qui reste à gérer. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leurs adresses automatiquement. Ce qui est très intéressant lorsque le réseau comporte un grand parc de machines. <br />
<br />
<br />
Nous allons introduire les points clés de la nouvelle version du protocole d'interconnexion IP : le protocole IPv6. Nous expliquerons pourquoi il y a beaucoup plus d'adresses et comment le protocole IP a été simplifié et modernisé. Les deux protocoles étant différents, le passage d'IPv4 à IPv6 a fait l'objet de scénarios spécifiés dans des RFC. Un grand nombre d'équipements et de services reposent toujours sur IPv4 et une cohabitation s'est installée pour encore de nombreuses années. Néanmoins, IPv6 est un passage obligé pour l'Internet du 21<sup>e</sup> siècle.<br />
<br />
== IPv6 : une nouvelle version d'IP ==<br />
<br />
Depuis le premier RFC sur IPv6 publié en décembre 1995, la version IPv6 a quitté les laboratoires. L'étape de standardisation des protocoles de base de IPv6 (''core specs'') est achevée depuis le début des années 2000.<br />
La nouvelle version d'IP reprend ses principes fondateurs : encapsulation des données dans des paquets, adresses source et destination dans l'en-tête, transfert en mode datagramme, routage paquet par paquet. <br />
<br />
Le réseau utilise des équipements intermédiaires simples et transparentes aux données transférées. Il n'effectue aucune reprise sur erreurs et tout le contrôle est reporté sur les extrémités dans d'autres protocoles. L'adressage est toujours hiérarchique mais de nouveaux niveaux sont ajoutés à la demande.<br />
<br />
Deux points clés permettent à IPv6 de résoudre les problèmes que nous avons évoqués dans les activités précédentes :<br />
<br />
* IPv6 offre une adresse plus longue qui passe de 32 bits à 128 bits. Cette capacité immense va résoudre la pénurie à très long terme ;<br />
* les concepteurs d'IPv6 ont voulu moderniser le protocole par la même occasion pour prendre en compte de nouveaux besoins qui n'avaient pas été envisagés dans les années 70-80. <br />
<br />
Par exemple, il n'avait pas été imaginé le développement de la diffusion de chaînes de télévision sur Internet. Dans IPv6, la diffusion à un groupe de récepteurs, le ''multicast'', a été défini dès le départ.<br />
<br />
=== Un système d'adressage avec une capacité immense ===<br />
<br />
L'espace d'adressage IPv6 a une capacité immense. Une adresse IPv6 est longue de 128 bits (16 octets), contre 32 bits pour IPv4. On dispose ainsi d'environ 3,4 × 10<sup>38</sup> adresses (soit plus de 340 sextillions). Pour reprendre l'image usuelle, on aurait plus de 667 millions d'adresses IPv6 par millimètre carré de surface terrestre.<br />
<br />
La notation d'une adresse IPv6 se fait maintenant en hexadécimal, codé sur 16 bits. Une adresse IPv6 est alors représenté par 8 mots de 2 octets séparés par un ":", comme le montre l'exemple de la figure 2.<br />
<br />
<center><br />
[[Image:04-fig1.png|500px|thumb|center|Figure 1 : Exemple d'adresse IPv6 notée en héxadécimal.]]<br />
</center><br />
<br />
Le format de l'adresse est hiérarchique avec de multiples niveaux. L'opérateur dispose d'un bloc d'adresses plus long qui lui donne plus de liberté pour allouer des sous-blocs. On peut découper par exemple l'adresse en 4 champs qui sont :<br />
* le préfixe FAI ;<br />
* le préfixe de réseau ;<br />
* le préfixe de sous-réseau ;<br />
* et l'adresse hôte. <br />
<br />
<center><br />
[[Image:04-fig2.png|500px|thumb|center|Figure 2 : Format de l'adresse IPv6.]]<br />
</center><br />
<br />
<br />
<br />
En IPv6, l'auto-configuration d'adresse permet à un hôte d'utiliser son adresse physique ou MAC pour créer son adresse réseau. Pour réaliser la transition en douceur, il est aussi possible de dériver l'adresse IPv6 de l'adresse IPv4. De nouvelles fonctionnalités définissent des adresses génériques pour, par exemple, trouver immédiatement le serveur DNS sur un réseau, ou n'importe quel autre service.<br />
<br />
=== Une simplification des fonctions d’IP ===<br />
<br />
La conception d'IPv6 est aussi l'occasion de dépoussiérer le protocole. Fort de l'expérience acquise avec IPv4, certaines fonctions d'IP on été redéfinies et optimisées, d'autres ont été supprimées.<br />
<br />
Ainsi, la protection des erreurs du paquet IPv4 par un ''checksum'' est finalement inutile puisque déjà réalisée au niveau liaison ; le champ ''checksum'' n'est plus présent dans l'en-tête IPv6.<br />
<br />
La fonction de fragmentation d’un paquet par le routeur a été elle aussi supprimée. Cette fonction a pour but d’adapter la taille du paquet à celle de la trame du réseau suivant. Cela signifie que lorsque le routeur veut envoyer un paquet qui est plus grand que la taille de la trame, il doit fragmenter ce paquet et ainsi l’envoyer dans plusieurs trames consécutives. Les différents fragments sont identifiés pour permettre en réception de reconstituer le paquet initial. La fragmentation a de multiples inconvénients qui sont l’accroissement du temps de traitement du paquet par le routeur, une probabilité plus importante de perte de paquets puisque un seul frgment perdu entraîne la perte de tout le paquet et enfin, en réception, la mémorisation des fragments, leur éventuel remise en ordre avant la livraison à la couche supérieure. Pour éviter la fragmentation par les routeurs, le protocole IPv6 préconise d'apprendre la taille minimale de paquet supportée '''sur tout le chemin''' et ainsi, d'envoyer des paquets de la bonne taille. Les trois champs de l’en-tête dédiés à cette fonction ont donc été supprimés.<br />
<br />
Un inconvénient d'IPv4 est qu'il n'y a aucune relation entre les adresses de niveau réseau et de niveau liaison. Or l'adresse physique est nécessaire pour transmettre la trame qui contient le paquet. Avec IPv4, il faut donc chercher et récupérer cette adresse physique avant d'encapsuler le paquet dans la trame. Pour éviter cette recherche, IPv6 fournit l'auto-configuration d'adresse réseau à partir de l'adresse physique.<br />
<br />
Le protocole IPv4 ayant été conçu il y a 40 ans, de nouveaux usages sont apparus qu'il a fallu ajouter de manière artificielle. Dans IPv6, il sera possible d'ajouter de nouvelles fonctionnalités assez facilement grâce aux extensions d'en-tête.<br />
<br />
== De IPv4 à IPv6 ==<br />
<br />
=== Une transition pas si simple ===<br />
<br />
IPv4 et IPv6 sont des protocoles différents : les adresses ainsi que le format des paquets n'ont pas la même structure. De fait, les deux technologies vont cohabiter sur Internet, chacune dans un plan d'adressage différent. Ceci a pour conséquence que la communication entre un hôte IPv4 et un hôte IPv6 ne peut pas se faire directement. Pour connecter tous les utilisateurs de manière transparente, les routeurs et les hôtes devront avoir une connectivité IPv4 et IPv6. On parle de double pile. Les équipements disposent alors à la fois d'une adresse IPv4 et d'une adresse IPv6.<br />
<br />
<center><br />
[[Image:04-fig3.png|500px|thumb|center|Figure 3 : Scénario de transition IPv6 avec routeurs double pile.]]<br />
</center><br />
<br />
<br />
Lorsqu'une des connectivités est manquante, il est possible de recourir à des solution de tunnels. Un tunnel permet à deux hôtes IPv4 de communiquer au travers d'un réseau IPv6, ou inversement. Cependant, il faut noter que le recours à un mécanisme de tunnels est complexe et nuit aux performances. <br />
<br />
D'autres scénarios de transition ont été étudiés et sont spécifiés dans plusieurs RFC.<br />
<br />
=== Une cohabitation forcée ===<br />
<br />
Le premier standard IPv6 date de 1995 et a été amélioré et complété durant une dizaine d'années. Depuis, la transition vers IPv6 n'est toujours pas finie alors même que les opérateurs ont quasiment tous épuisé leurs adresses IPv4.<br />
<br />
En France, dans son baromètre annuel de la transition vers IPv6 <ref>Baromètre annuel de la transition vers IPv6 en France (Nov. 2021) [https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html]</ref>, l'ARCEP pointe les nombreux freins au déploiement généralisé d'IPV6 (voir figure.4). Les causes sont multiples car cette transition nécessite des compétences techniques et des ressources adaptées. C'est un vrai projet. Et ce rapport met en évidence le rôle joué dans cette transition par les multiples acteurs de l'Internet : fournisseurs d'accès, hébergeurs de contenus, opérateurs mobiles, équipementiers, services DNS, réseau de transit et terminaux. <br />
<br />
<center><br />
[[Image:04-fig4-b.png|500px|thumb|center|Figure 4 : Etat de la transition vers IPv6 selon les acteurs [ARCEP].]]<br />
</center><br />
<br />
La figure 4, tirée du rapport de l'ARCEP, montre l'état d'avancement de la transition IPV6 au niveau des différents acteurs de l'Internet. Les équipementiers (ou fabricants de routeurs), les systèmes d'exploitation et les terminaux ont achevé leur mise en conformité avec les standards d'IPv6. Pour d'autres acteurs, comme les opérateurs, l'adoption d'IPv6 est plus longue. Carton rouge aux hébergeurs dont l'adoption d'IPv6 reste encore assez faible.<br />
Sur le plan international, la situation est aussi différente selon les pays. Les Etats-unis, le Canada et quelques pays d'Europe ont largement déployé IPv6. Cependant, en majorité, les pays sont encore très faiblement impliqués comme le montre la figure 5.<br />
<br />
<center><br />
[[Image:04-fig5.png|500px|thumb|center|Figure 5 : Carte de l'adoption d'IPv6 par CISCO.]]<br />
</center><br />
<br />
<br />
En 2022, l'usage d'IPv6 vu par les serveurs de Google est proche de 40 %. La figure 6 montre l'évolution des usages<ref>Google. Statistics. [http://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption IPv6 Adoption]</ref>. Cette courbe montre un quasi-doublement de l'adoption d'IPv6 tous les ans depuis 2010.<br />
Les utilisateurs de Google peuvent émettre des requêtes en IPv6 s'ils ont un accès IPv6 offert par leur fournisseur d'accès à Internet. En aout 2016, aux USA, IPv6 représente plus de la moitié du trafic mobile vers Facebook<ref>Col P. (2016) ZDNet. [http://www.zdnet.fr/actualites/ipv6-represente-plus-de-la-moitie-du-trafic-mobile-vers-facebook-aux-usa-39840834.htm IPv6 représente plus de la moitié du trafic mobile vers Facebook aux USA]</ref>.<br />
<center><br />
[[Image:Google-2022.png|500px|thumb|center|Figure 6 : Évolution du pourcentage de requêtes reçues en IPv6 par Google en 2022.]]<br />
</center><br />
<br />
La figure 7<ref>RIPE NCC. [http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_RIPE_NCC;s=FR;s=DE;s=GB;s=US;s=JP IPv6 Enabled Networks]</ref> montre le pourcentage des organisations annonçant un préfixe IPv6. L'Europe, de manière générale, est active dans le déploiement d'IPv6 et la Belgique en particulier <ref>Cole, P. (2016). ZDnet. [http://www.zdnet.fr/actualites/la-belgique-championne-du-monde-d-ipv6-bien-loin-devant-la-france-39839252.htm La Belgique championne du monde d'IPv6, bien loin devant la France !]</ref>. Pour suivre l'évolution de l'adoption d'IPv6, la page web de ''world ipv6 launch'' référence les mesures faites par différents opérateurs<ref>World IPv6 Launch [http://www.worldipv6launch.org/measurements/ IPv6 Measurements]</ref>.<br />
<br />
<br />
<center><br />
[[Image:Ipv6-usable-2022.png|500px|thumb|center|Figure 7 : Évolution du pourcentage d'organisations annonçant au moins un préfixe IPv6 par région.]]<br />
</center><br />
<br />
== IPv6 : un passage obligé ==<br />
<br />
Restons optimistes cependant car les nouveaux services ou les nouveaux usages se tournent de plus en plus vers IPv6 car ils ne trouvent pas dans IPv4 les solutions techniques nécessaires à leur développement.<br />
<br />
Les distributeurs de contenus qui déploient une infrastructure de caches répartis sur tout l'Internet ont besoin de beaucoup de flexibilité, de beaucoup de bande passante et d'une latence faible. Les nouveaux réseaux d'accès sont de plus en plus en IPv6. Enfin, l'Internet des objets, les villes intelligentes ou les réseaux de véhicules ne peuvent se développer qu'en IPv6.<br />
<br />
L'adoption d'IPv6 est aussi une question de formation. Le protocole IPv6 n'est plus au stade expérimental ; il est indispensable pour un fonctionnement normal de l'Internet. Nous entendons par "normal", un fonctionnement respectant les principes fondateurs de l'Internet, dont celui du "bout-en-bout". Si les principes de ces deux versions d'IP sont très similaires, IPv4 adopte de plus en plus des principes non conventionnels pour continuer à fonctionner. <br />
<br />
L'apprentissage du fonctionnement de l'Internet doit se faire de nos jours principalement avec IPv6, et accessoirement avec IPv4. Il faut rendre banale la nouvelle version du protocole IP. <br />
Dans un article<ref>Huston, G. (2011). Cisco Internet Protocol Journal, Vol. 14, No. 1, pp. 14-21, March. [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-1/ipj_14-1.pdf Transitional Myths]</ref>, Geof Huston dresse une liste de fausses assertions et de rumeurs pour justifier de ne pas commencer le travail de migration vers IPv6. Si ces fausses assertions circulent, elles démontrent à quel point le besoin de formation et d'information sur la situation de l'Internet est nécessaire. Nous espérons que ce cours contribuera à combler ce manque.<br />
<br />
== Conclusion ==<br />
<br />
Pour conclure, l'heure de la pénurie d'adresses IPv4 a sonné depuis quelques années et IPv6 est un passage obligé pour développer les nouveaux usages et simplifier le fonctionnement du réseau. IPv6 est le protocole de l’Internet du 21<sup>e</sup> siècle. Il est incontournable. L'IoT (''Internet of Things'') et les nouveaux usages seront les moteurs de son déploiement massif dans les dix prochaines années. Comme il modernise effectivement IPv4, il nécessite une étude approfondie de ses mécanismes de fonctionnement pour faciliter son appropriation par l'ensemble des acteurs impliqués dans un monde de plus en plus numérique.<br />
<br />
IPv6 permet de retrouver les principes qui ont fait le succès de l'Internet comme, notamment, une connectivité simplifiée. Il est admis aujourd'hui qu'IPv6 est indispensable pour le développement des services innovants.<br />
<br />
== Références bibliographiques ==<br />
<br />
<references /><br />
<br />
== Pour aller plus loin ==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 9547: Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022 [https://www.bortzmeyer.org/9547.html]<br />
<br />
<br />
----</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act04-f&diff=20608MOOC:Compagnon Act04-f2024-04-24T13:30:29Z<p>Jlandru: /* Activité 04 : Pourquoi IPv6 ? */</p>
<hr />
<div>__NOTOC__<br />
<!-- {{Decouverte}} --><br />
<br />
<!--<br />
{{TODO|Reprendre les paragraphes IPv6 de [[MOOC:Compagnon_Act03]] et des éléments historiques de [[La_standardisation_d'IPv6]]}}<br />
--><br />
<br />
= Activité 04 : Pourquoi IPv6 ? =<br />
<br />
== Motivations ==<br />
<br />
Le problème de pénurie des adresses Internet est principalement dû à l'explosion de la demande qui dépasse largement la capacité d'adressage IPv4. Ce problème qui est devenu critique ces dernières années, milite pour l’adoption rapide d’IPv6. En effet, il faut aujourd'hui un grand espace d'adressage pour adresser tous les appareils connectés et par la suite, les futurs objets connectés issus des applications IoT. Dépasser la pénurie d'adresses, c'est aussi ouvrir la voie à de nouveaux services, à de nouveaux acteurs innovants, c'est créer de nouveaux marchés pour de nouveaux besoins. Le passage à IPv6 devient une nécessité car, en attribuant une adresse à chaque nœud du réseau, la connectivité en IPv6 retrouve les principes qui ont fait le succès du fonctionnement de l'Internet.<br />
<!-- et notamment celui du "bout-en-bout". --><br />
<br />
La technologie de l'infrastructure de communication retrouve sa simplicité originelle. Il n'est pas soutenable que la croissance du réseau s'effectue avec une complexité croissante comme avec IPv4. Tout ceci est bien connu et cette évolution est qualifiée par "non passage au facteur d'échelle" (''not scalable''). Ainsi, avec cette simplicité retrouvée, de nouveaux champs d'application s'ouvrent à l'Internet en IPv6. Le [RFC 7368] en donne une illustration avec la domotique. <br />
<br />
En plus de la simplicité retrouvée, IPv6 apporte de nouvelles fonctionnalités, comme la configuration automatique d'un réseau. En IPv4, chaque équipement doit se voir attribuer une adresse et obtenir sa configuration depuis un serveur qui reste à gérer. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leurs adresses automatiquement. Ce qui est très intéressant lorsque le réseau comporte un grand parc de machines. <br />
<br />
<br />
Nous allons introduire les points clés de la nouvelle version du protocole d'interconnexion IP : le protocole IPv6. Nous expliquerons pourquoi il y a beaucoup plus d'adresses et comment le protocole IP a été simplifié et modernisé. Les deux protocoles étant différents, le passage d'IPv4 à IPv6 a fait l'objet de scénarios spécifiés dans des RFC. Un grand nombre d'équipements et de services reposent toujours sur IPv4 et une cohabitation s'est installée pour encore de nombreuses années. Néanmoins, IPv6 est un passage obligé pour l'Internet du 21<sup>e</sup> siècle.<br />
<br />
== IPv6 : une nouvelle version d'IP ==<br />
<br />
Depuis le premier RFC sur IPv6 publié en décembre 1995, la version IPv6 a quitté les laboratoires. L'étape de standardisation des protocoles de base de IPv6 (''core specs'') est achevée depuis le début des années 2000.<br />
La nouvelle version d'IP reprend ses principes fondateurs : encapsulation des données dans des paquets, adresses source et destination dans l'en-tête, transfert en mode datagramme, routage paquet par paquet. <br />
<br />
Le réseau utilise des équipements intermédiaires simples et transparentes aux données transférées. Il n'effectue aucune reprise sur erreurs et tout le contrôle est reporté sur les extrémités dans d'autres protocoles. L'adressage est toujours hiérarchique mais de nouveaux niveaux sont ajoutés à la demande.<br />
<br />
Deux points clés permettent à IPv6 de résoudre les problèmes que nous avons évoqués dans les activités précédentes :<br />
<br />
* IPv6 offre une adresse plus longue qui passe de 32 bits à 128 bits. Cette capacité immense va résoudre la pénurie à très long terme ;<br />
* les concepteurs d'IPv6 ont voulu moderniser le protocole par la même occasion pour prendre en compte de nouveaux besoins qui n'avaient pas été envisagés dans les années 70-80. <br />
<br />
Par exemple, il n'avait pas été imaginé le développement de la diffusion de chaînes de télévision sur Internet. Dans IPv6, la diffusion à un groupe de récepteurs, le ''multicast'', a été défini dès le départ.<br />
<br />
=== Un système d'adressage avec une capacité immense ===<br />
<br />
L'espace d'adressage IPv6 a une capacité immense. Une adresse IPv6 est longue de 128 bits (16 octets), contre 32 bits pour IPv4. On dispose ainsi d'environ 3,4 × 10<sup>38</sup> adresses (soit plus de 340 sextillions). Pour reprendre l'image usuelle, on aurait plus de 667 millions d'adresses IPv6 par millimètre carré de surface terrestre.<br />
<br />
La notation d'une adresse IPv6 se fait maintenant en hexadécimal, codé sur 16 bits. Une adresse IPv6 est alors représenté par 8 mots de 2 octets séparés par un ":", comme le montre l'exemple de la figure 2.<br />
<br />
<center><br />
[[Image:04-fig1.png|500px|thumb|center|Figure 1 : Exemple d'adresse IPv6 notée en héxadécimal.]]<br />
</center><br />
<br />
Le format de l'adresse est hiérarchique avec de multiples niveaux. L'opérateur dispose d'un bloc d'adresses plus long qui lui donne plus de liberté pour allouer des sous-blocs. On peut découper par exemple l'adresse en 4 champs qui sont :<br />
* le préfixe FAI ;<br />
* le préfixe de réseau ;<br />
* le préfixe de sous-réseau ;<br />
* et l'adresse hôte. <br />
<br />
<center><br />
[[Image:04-fig2.png|500px|thumb|center|Figure 2 : Format de l'adresse IPv6.]]<br />
</center><br />
<br />
<br />
<br />
En IPv6, l'auto-configuration d'adresse permet à un hôte d'utiliser son adresse physique ou MAC pour créer son adresse réseau. Pour réaliser la transition en douceur, il est aussi possible de dériver l'adresse IPv6 de l'adresse IPv4. De nouvelles fonctionnalités définissent des adresses génériques pour, par exemple, trouver immédiatement le serveur DNS sur un réseau, ou n'importe quel autre service.<br />
<br />
=== Une simplification des fonctions d’IP ===<br />
<br />
La conception d'IPv6 est aussi l'occasion de dépoussiérer le protocole. Fort de l'expérience acquise avec IPv4, certaines fonctions d'IP on été redéfinies et optimisées, d'autres ont été supprimées.<br />
<br />
Ainsi, la protection des erreurs du paquet IPv4 par un ''checksum'' est finalement inutile puisque déjà réalisée au niveau liaison ; le champ ''checksum'' n'est plus présent dans l'en-tête IPv6.<br />
<br />
La fonction de fragmentation d’un paquet par le routeur a été elle aussi supprimée. Cette fonction a pour but d’adapter la taille du paquet à celle de la trame du réseau suivant. Cela signifie que lorsque le routeur veut envoyer un paquet qui est plus grand que la taille de la trame, il doit fragmenter ce paquet et ainsi l’envoyer dans plusieurs trames consécutives. Les différents fragments sont identifiés pour permettre en réception de reconstituer le paquet initial. La fragmentation a de multiples inconvénients qui sont l’accroissement du temps de traitement du paquet par le routeur, une probabilité plus importante de perte de paquets puisque un seul frgment perdu entraîne la perte de tout le paquet et enfin, en réception, la mémorisation des fragments, leur éventuel remise en ordre avant la livraison à la couche supérieure. Pour éviter la fragmentation par les routeurs, le protocole IPv6 préconise d'apprendre la taille minimale de paquet supportée '''sur tout le chemin''' et ainsi, d'envoyer des paquets de la bonne taille. Les trois champs de l’en-tête dédiés à cette fonction ont donc été supprimés.<br />
<br />
Un inconvénient d'IPv4 est qu'il n'y a aucune relation entre les adresses de niveau réseau et de niveau liaison. Or l'adresse physique est nécessaire pour transmettre la trame qui contient le paquet. Avec IPv4, il faut donc chercher et récupérer cette adresse physique avant d'encapsuler le paquet dans la trame. Pour éviter cette recherche, IPv6 fournit l'auto-configuration d'adresse réseau à partir de l'adresse physique.<br />
<br />
Le protocole IPv4 ayant été conçu il y a 40 ans, de nouveaux usages sont apparus qu'il a fallu ajouter de manière artificielle. Dans IPv6, il sera possible d'ajouter de nouvelles fonctionnalités assez facilement grâce aux extensions d'en-tête.<br />
<br />
== De IPv4 à IPv6 ==<br />
<br />
=== Une transition pas si simple ===<br />
<br />
IPv4 et IPv6 sont des protocoles différents : les adresses ainsi que le format des paquets n'ont pas la même structure. De fait, les deux technologies vont cohabiter sur Internet, chacune dans un plan d'adressage différent. Ceci a pour conséquence que la communication entre un hôte IPv4 et un hôte IPv6 ne peut pas se faire directement. Pour connecter tous les utilisateurs de manière transparente, les routeurs et les hôtes devront avoir une connectivité IPv4 et IPv6. On parle de double pile. Les équipements disposent alors à la fois d'une adresse IPv4 et d'une adresse IPv6.<br />
<br />
<center><br />
[[Image:04-fig3.png|500px|thumb|center|Figure 3 : Scénario de transition IPv6 avec routeurs double pile.]]<br />
</center><br />
<br />
<br />
Lorsqu'une des connectivités est manquante, il est possible de recourir à des solution de tunnels. Un tunnel permet à deux hôtes IPv4 de communiquer au travers d'un réseau IPv6, ou inversement. Cependant, il faut noter que le recours à un mécanisme de tunnels est complexe et nuit aux performances. <br />
<br />
D'autres scénarios de transition ont été étudiés et sont spécifiés dans plusieurs RFC.<br />
<br />
=== Une cohabitation forcée ===<br />
<br />
Le premier standard IPv6 date de 1995 et a été amélioré et complété durant une dizaine d'années. Depuis, la transition vers IPv6 n'est toujours pas finie alors même que les opérateurs ont quasiment tous épuisé leurs adresses IPv4.<br />
<br />
En France, dans son baromètre annuel de la transition vers IPv6 <ref>Baromètre annuel de la transition vers IPv6 en France (Nov. 2021) [https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html]</ref>, l'ARCEP pointe les nombreux freins au déploiement généralisé d'IPV6 (voir figure.4). Les causes sont multiples car cette transition nécessite des compétences techniques et des ressources adaptées. C'est un vrai projet. Et ce rapport met en évidence le rôle joué dans cette transition par les multiples acteurs de l'Internet : fournisseurs d'accès, hébergeurs de contenus, opérateurs mobiles, équipementiers, services DNS, réseau de transit et terminaux. <br />
<br />
<center><br />
[[Image:04-fig4-b.png|500px|thumb|center|Figure 4 : Etat de la transition vers IPv6 selon les acteurs [ARCEP].]]<br />
</center><br />
<br />
La figure 4, tirée du rapport de l'ARCEP, montre l'état d'avancement de la transition IPV6 au niveau des différents acteurs de l'Internet. Les équipementiers (ou fabricants de routeurs), les systèmes d'exploitation et les terminaux ont achevé leur mise en conformité avec les standards d'IPv6. Pour d'autres acteurs, comme les opérateurs, l'adoption d'IPv6 est plus longue. Carton rouge aux hébergeurs dont l'adoption d'IPv6 reste encore assez faible.<br />
Sur le plan international, la situation est aussi différente selon les pays. Les Etats-unis, le Canada et quelques pays d'Europe ont largement déployé IPv6. Cependant, en majorité, les pays sont encore très faiblement impliqués comme le montre la figure 5.<br />
<br />
<center><br />
[[Image:04-fig5.png|500px|thumb|center|Figure 5 : Carte de l'adoption d'IPv6 par CISCO.]]<br />
</center><br />
<br />
<br />
En 2022, l'usage d'IPv6 vu par les serveurs de Google est proche de 40 %. La figure 6 montre l'évolution des usages<ref>Google. Statistics. [http://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption IPv6 Adoption]</ref>. Cette courbe montre un quasi-doublement de l'adoption d'IPv6 tous les ans depuis 2010.<br />
Les utilisateurs de Google peuvent émettre des requêtes en IPv6 s'ils ont un accès IPv6 offert par leur fournisseur d'accès à Internet. En aout 2016, aux USA, IPv6 représente plus de la moitié du trafic mobile vers Facebook<ref>Col P. (2016) ZDNet. [http://www.zdnet.fr/actualites/ipv6-represente-plus-de-la-moitie-du-trafic-mobile-vers-facebook-aux-usa-39840834.htm IPv6 représente plus de la moitié du trafic mobile vers Facebook aux USA]</ref>.<br />
<center><br />
[[Image:Google-2022.png|500px|thumb|center|Figure 6 : Évolution du pourcentage de requêtes reçues en IPv6 par Google en 2022.]]<br />
</center><br />
<br />
La figure 7<ref>RIPE NCC. [http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_RIPE_NCC;s=FR;s=DE;s=GB;s=US;s=JP IPv6 Enabled Networks]</ref> montre le pourcentage des organisations annonçant un préfixe IPv6. L'Europe, de manière générale, est active dans le déploiement d'IPv6 et la Belgique en particulier <ref>Cole, P. (2016). ZDnet. [http://www.zdnet.fr/actualites/la-belgique-championne-du-monde-d-ipv6-bien-loin-devant-la-france-39839252.htm La Belgique championne du monde d'IPv6, bien loin devant la France !]</ref>. Pour suivre l'évolution de l'adoption d'IPv6, la page web de ''world ipv6 launch'' référence les mesures faites par différents opérateurs<ref>World IPv6 Launch [http://www.worldipv6launch.org/measurements/ IPv6 Measurements]</ref>.<br />
<br />
<br />
<center><br />
[[Image:Ipv6-usable-2022.png|500px|thumb|center|Figure 7 : Évolution du pourcentage d'organisations annonçant au moins un préfixe IPv6 par région.]]<br />
</center><br />
<br />
== IPv6 : un passage obligé ==<br />
<br />
Restons optimistes cependant car les nouveaux services ou les nouveaux usages se tournent de plus en plus vers IPv6 car ils ne trouvent pas dans IPv4 les solutions techniques nécessaires à leur développement.<br />
<br />
Les distributeurs de contenus qui déploient une infrastructure de caches répartis sur tout l'Internet ont besoin de beaucoup de flexibilité, de beaucoup de bande passante et d'une latence faible. Les nouveaux réseaux d'accès sont de plus en plus en IPv6. Enfin, l'Internet des objets, les villes intelligentes ou les réseaux de véhicules ne peuvent se développer qu'en IPv6.<br />
<br />
L'adoption d'IPv6 est aussi une question de formation. Le protocole IPv6 n'est plus au stade expérimental ; il est indispensable pour un fonctionnement normal de l'Internet. Nous entendons par "normal", un fonctionnement respectant les principes fondateurs de l'Internet, dont celui du "bout-en-bout". Si les principes de ces deux versions d'IP sont très similaires, IPv4 adopte de plus en plus des principes non conventionnels pour continuer à fonctionner. <br />
<br />
L'apprentissage du fonctionnement de l'Internet doit se faire de nos jours principalement avec IPv6, et accessoirement avec IPv4. Il faut rendre banale la nouvelle version du protocole IP. <br />
Dans un article<ref>Huston, G. (2011). Cisco Internet Protocol Journal, Vol. 14, No. 1, pp. 14-21, March. [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-1/ipj_14-1.pdf Transitional Myths]</ref>, Geof Huston dresse une liste de fausses assertions et de rumeurs pour justifier de ne pas commencer le travail de migration vers IPv6. Si ces fausses assertions circulent, elles démontrent à quel point le besoin de formation et d'information sur la situation de l'Internet est nécessaire. Nous espérons que ce cours contribuera à combler ce manque.<br />
<br />
== Conclusion ==<br />
<br />
Pour conclure, l'heure de la pénurie d'adresses IPv4 a sonné depuis quelques années et IPv6 est un passage obligé pour développer les nouveaux usages et simplifier le fonctionnement du réseau. IPv6 est le protocole de l’Internet du 21<sup>e</sup> siècle. Il est incontournable. L'IoT (''Internet of Things'') et les nouveaux usages seront les moteurs de son déploiement massif dans les dix prochaines années. Comme il modernise effectivement IPv4, il nécessite une étude approfondie de ses mécanismes de fonctionnement pour faciliter son appropriation par l'ensemble des acteurs impliqués dans un monde de plus en plus numérique.<br />
<br />
IPv6 permet de retrouver les principes qui ont fait le succès de l'Internet comme, notamment, une connectivité simplifiée. Il est admis aujourd'hui qu'IPv6 est indispensable pour le développement des services innovants.<br />
<br />
== Pour aller plus loin ==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 9547: Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022 [https://www.bortzmeyer.org/9547.html]<br />
<br />
<br />
----</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20595MOOC:Compagnon Act13-s72024-03-04T13:29:12Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20594MOOC:Compagnon Act13-s72024-03-04T13:27:30Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers</tt>). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20593MOOC:Compagnon Act13-s72024-03-04T13:27:12Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (<tt>MLDv2-capable-routers<tt>). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20592MOOC:Compagnon Act13-s72024-03-04T13:26:33Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse <tt>ff02::16</tt>) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20591MOOC:Compagnon Act13-s72024-03-04T13:25:52Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20590MOOC:Compagnon Act13-s72024-03-04T13:15:53Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateursethernet diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 au registre multicast de l'IANA de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20589MOOC:Compagnon Act13-s72024-03-04T13:14:44Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 au registre multicast de l'IANA de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541 ,<ref>IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]</ref>, <ref>Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]</ref>, <ref>MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]</ref>.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20588MOOC:Compagnon Act13-s72024-03-04T13:04:23Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 au registre multicast de l'IANA de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.<br />
Pour aller plus loin sur le sujet diverses ressources et illustrations vous sont accessibles : RFC 4541, </ref>.<br />
IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping].</ref>. }}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20587MOOC:Compagnon Act13-s72024-03-04T12:52:21Z<p>Jlandru: /* Pour aller plus loin */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 au registre multicast de l'IANA de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20586MOOC:Compagnon Act13-s72024-03-04T12:48:42Z<p>Jlandru: /* Correspondance avec les adresses de multicast de niveau 2 */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- = Activité 13 : Les adresses unicast = --><br />
= Activité 13 : Familles d'adresses IPv6 =<br />
<!-- {{Decouverte}} --><br />
== Introduction ==<br />
Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br />
Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br />
<br />
== Types d'adresses ==<br />
IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br />
{{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br />
<br />
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : <br><br />
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br><br />
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;<br><br />
** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br />
<center><br />
[[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br />
</center><br />
<br />
* Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &quot;général&quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br />
<center> <br />
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br />
</center><br />
<br />
* Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &quot;plus proche&quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br />
<center><br />
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br />
</center><br />
<br />
== Identification des types d'adresses ==<br />
Le type d'une adresse IPv6 est identifié par ses bits de poids<br />
fort.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="40%" align="center" | '''Type''' <br />
! scope="col" width="30%" align="center" | '''Préfixe binaire d'identification'''<br />
! scope="col" width="30%" align="center" | '''Notation IPv6'''<br />
<br />
|- style="background:silver"<br />
| Non spécifié || <tt>00...0</tt> || <tt>::/128</tt><br />
<br />
|-<br />
| Adresse de bouclage (Loopback) || <tt>00...1</tt> || <tt>::1/128</tt><br />
<br />
|- style="background:silver"<br />
| Multicast || <tt>1111 1111</tt> || <tt>ff00::/8</tt><br />
<br />
|-<br />
| Unicast lien local || <tt>1111 1110 10</tt> || <tt>fe80::/10</tt><br />
<br />
|- style="background:silver"<br />
| Unique Local Unicast Address (ULA) || <tt>1111 1101</tt> || <tt>fd00::/8</tt><br />
<br />
|-<br />
| Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || <tt>001</tt> || <tt>2000::/3</tt> <br>(soit toute adresse commençant par 2 ou 3)<br />
<br />
|}<br />
</center><br />
Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br />
<br />
<center><br />
{|<br />
!Préfixe IPv6!!Allouer!!Référence <br />
|-style="background:silver"<br />
|<tt>0000::/8</tt>|| Réservé pour la transition et loopback ||RFC 4291 <br />
|-<br />
|<tt>0100::/8</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0200::/7</tt>||Réservé (ex NSAP)||RFC 4048 <br />
|-<br />
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 4291<br />
|-style="background:silver"<br />
|<tt>0800::/5</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>1000::/4</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>2000::/3</tt>||Unicast Global||RFC 4291 <br />
|-<br />
|<tt>4000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>6000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>8000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>a000::/3</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>c000::/3</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>e000::/4</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>f000::/5</tt>||Réservé||RFC 4291<br />
|-style="background:silver"<br />
|<tt>f800::/6</tt>||Réservé||RFC 4291<br />
|-<br />
|<tt>fc00::/7</tt>||Unique Local Unicast||RFC 4193<br />
|-style="background:silver"<br />
|<tt>fe00::/9</tt> ||Réservé||RFC 4291<br />
|-<br />
|<tt>fe80::/10</tt>||Lien-local||RFC 4291<br />
|-style="background:silver"<br />
|<tt>fec0::/10</tt>||Réservé||RFC 3879<br />
|-<br />
|<tt>ff00::/8</tt>||Multicast||RFC 4291<br />
|}<br />
</center><br />
Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br />
<br />
Les adresses anycast ne sont pas distinguées des adresses unicast<br />
de quelque portée (globale, locale, lien) que ce soit.<br />
<br />
== L'adressage unicast ==<br />
=== Structure de l'adresse unicast ===<br />
Le plan d'adressage agrégé actuellement en vigueur est défini<br />
dans le RFC 3587. Il s'inspire des recommandations de la politique<br />
d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br />
RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br />
bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br />
<br />
Les adresses IPv6 peuvent être agrégées avec des préfixes de<br />
longueur quelconque, de manière similaire aux mécanismes mis en<br />
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br />
d'IPv4.<br />
<br />
Un nœud peut avoir une connaissance minimale de la structuration<br />
interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br />
Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br />
de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br />
comme un simple mot binaire de 128 bits, sans aucune structure<br />
particulière telle que présentée dans la figure 4.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br />
</center><br />
Un premier niveau de hiérarchisation découpe l'adresse en deux<br />
parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br />
pour acheminer le paquet à travers le réseau, et un identifiant<br />
d'interface qui sera utilisé sur le dernier saut pour remettre le<br />
paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br />
</center><br />
<br />
=== Différents types d'adresse unicast ===<br />
==== L'adresse non spécifiée ====<br />
L'adresse <tt>0:0:0:0:0:0:0:0</tt> ou <tt>::/128</tt> est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br />
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br />
comme adresse source par les paquets d'initialisation lors de<br />
l'auto-configuration d'une station. Elle ne doit jamais être<br />
utilisée comme adresse de destination d'un paquet.<br />
<br />
==== L'adresse de bouclage (loopback) ==== <br />
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée<br />
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br />
d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br />
lui-même. Elle ne doit jamais être affectée à une interface. Elle<br />
est considérée comme ayant une étendue de type "lien-local" et doit<br />
être vue comme une adresse unicast de "lien-local" de l'interface<br />
virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br />
utilisée comme adresse source ou destination d'un paquet circulant<br />
sur le réseau ou, plus exactement, un paquet circulant hors de la<br />
machine. Un paquet reçu sur une interface avec une telle adresse de<br />
destination doit être détruit.<br />
<br />
==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br />
Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br />
Les adresses unicast globales sont issues du plan d'adressage agrégé,<br />
proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire <tt>0b0010</tt><ref> Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]</ref>, soit<br />
<tt>2000::/3</tt> en notation<br />
IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br />
une adresse unicast globale.<br />
<br />
Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br />
RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br />
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br />
<br />
* une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br />
* une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br />
* un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br />
</center> <br />
À part le préfixe <tt>2002::/16</tt> qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12<ref name="assign" >IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]</ref> qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br />
<br />
Il est maintenant admis que le préfixe attribué par un opérateur<br />
à ses clients peut également être un /56. En effet, si l'on garde<br />
l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br />
que l'on intègre les réseaux domotiques, les opérateurs peuvent<br />
justifier d'un besoin important d'adresses que les autorités<br />
régionales ne peuvent leur refuser.<br />
<br />
'''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br />
{{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br />
<br />
* Le préfixe <tt>2002::/16</tt> est réservé au mécanisme d'intégration dit "tunnel 6to4" ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br />
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br />
* Le préfixe <tt>2001:5::/32</tt> est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br />
* Le préfixe <tt>2001:10::/28</tt> réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br />
* Le préfixe <tt>2001:20::/28</tt> réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br />
* Le préfixe <tt>2001:1::1/128</tt> adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br />
* Le préfixe <tt>3ffe::/16</tt> était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br />
<br />
Le plan agrégé <tt>2000::/3</tt> a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (<tt>2000::/3</tt>) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br />
<br />
La plage <tt>2001::/16</tt> du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA<ref name="assign" />.<br />
<br />
La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br />
<center><br />
[[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br />
</center><br />
<br />
==== Les adresses unicast locales ====<br />
Il y a deux types d'adresse unicast qui sont utilisées localement :<br />
<br />
* les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (''Link Local Address'') ;<br />
* les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br />
<br />
===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br />
<br />
Les adresses "lien-local", sont des adresses dont l'étendue de<br />
validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br />
Les adresses "lien-local" sont analogues aux adresses APIPA<ref>Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]</ref> (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br />
<br />
Les adresses "lien-local" sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse "lien-local" entre deux liens différents est autorisée.<br />
<br />
Ces adresses sont "non routables". Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type "lien-local".<br />
<br />
La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br />
<br />
La figure 8 représente le préfixe d'identification qui est <tt>fe80::/10</tt>. L'adresse "lien-local" a le format suivant : préfixe <tt>fe80::/64</tt> accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses "lien-local" ne sortent jamais du réseau où elles sont utilisées.<br />
<center> <br />
[[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]<br><br />
</center><br />
<br><br />
<br />
'''''Nota :''' Une adresse "lien-local" (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &quot;%&quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br />
<br />
===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br />
<br />
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br />
<br />
Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br />
La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br />
<br />
Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br />
<br />
* Prefix (7 bits) : <tt>fc00::/7</tt> préfixe identifiant les adresses IPv6 locales (ULA) ;<br />
* L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe <tt>fd00::/8</tt>) ;<br />
* Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br />
* Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br />
* Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br />
<br />
<center><br />
[[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br />
</center><br />
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme <tt>10.0.0.0/8</tt>) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br />
<br />
Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br />
<br />
Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, <tt>fc00::/7</tt>, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br />
<br />
Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br />
<br />
* préfixe globalement unique (très forte probabilité d'unicité) ;<br />
* un préfixe bien connu <tt>fc00::/7</tt> facilitant le filtrage aux frontières du site ;<br />
* limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br />
* indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br />
* indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br />
* en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br />
<br />
L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br />
<br />
Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br />
<br />
# prendre l'heure courante dans le format 64 bits du protocole NTP ;<br />
# prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br />
# concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br />
# calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br />
# prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br />
# préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8<sup>e</sup> bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br />
<br />
L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br />
<br />
Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.<br />
<br />
<!--<br />
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br />
<br />
===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br />
Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br />
<br />
===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br />
L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère ":"<br />
Ainsi l'adresse IPv4 '''<tt>192.168.10.5</tt>''' sera notée '''<tt>c0a8:a05</tt>''' dans l'adresse IPv6.<br />
<br />
Exemples : <br />
* <tt>2002:'''c0a8:a05''':624:5054:1ff1fe12:3456</tt><br />
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt><br />
<br />
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande, ...). Cependant elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (log système) de la machine. Dans ce cas si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.<br />
<br />
===== Les adresses IPv4 imbriquées historiques =====<br />
Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<br />
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.<br />
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un noeud supportant uniquement IPv4.<br />
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0::xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un noeud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.<br />
<br />
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis à vis du calcul du checksum intégrant le pseudo entête ''(cf sequence 3)''.<br />
<br />
Les longs préfixe nuls de ces adresses les rendent difficilement routables. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utiliséees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br />
<br />
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br />
Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br />
<br />
Le RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br />
<br />
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br />
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|32| prefix '''|v4(32) | u |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|40| prefix '''|v4(24) | u |(8)|''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|48| prefix '''|v4(16) | u | (16) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|56| prefix '''|(8)| u | v4(24) |''' suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|64| prefix '''| u |''' v4(32) | suffix |<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
|96| prefix '''| v4(32) |'''<br />
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br />
<br />
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br />
<br />
''''' Note :''''' '' Le préfixe réservé'' '''''<tt>64:ff9b::/96</tt>''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br />
<br />
===== Les adresses pour les extrémités de tunneliers =====<br />
<br />
====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br />
6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''<tt>2002::/16</tt>''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''<tt>192.88.99.1</tt>''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''<tt>2002:c058:6301::/48</tt>'''.<br />
<br />
Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br />
<br />
6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br />
<br />
====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br />
6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br />
<br />
Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (<tt>2002 ::/16</tt>) était quant à lui partagé entre tous FAI.<br />
<br />
Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br />
et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br />
<br />
| n bits '''| o bits |''' m bits | 128-n-o-m bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| 6rd prefix '''| Ipv4 address |''' subnet ID | interface ID |<br />
+---------------+--------------+-----------+------------------------+<br />
|<== 6rd delegated prefix ==>| <br />
<br />
<br />
* 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br />
* 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br />
* 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br />
* 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br />
* IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br />
<br />
====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br />
ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br />
<br />
| 64 bits | (IID) 64 bits |<br />
+---------------+--------------+-----------+------------------------+<br />
| IPv6 prefix | subnet ID '''| 0:5efe:xxxx:xxxx |'''<br />
+---------------+--------------+-----------+------------------------+<br />
'''| 0:5efe:a.b.c.d |'''<br />
<br />
* L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br />
* Auquel est accolé le code réservé 0xfe,<br />
* Suivi de l'adresse IPv4 de l'interface.<br />
<br />
--><br />
<br />
=== Portée de l'adresse unicast ===<br />
<br />
On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa "routabilité". <br />
<br />
Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'"adresses publiques", sont ainsi routables à l'échelle du réseau public mondial Internet.<br />
<br />
Inversement, la portée des adresses locales (ULA couramment dénommées "adresses privées") sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br />
<br />
Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont "confinés" au lien et ne permettent qu'une communication avec le voisinage direct.<br />
<br />
L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br />
<br />
== L'adressage multicast ==<br />
Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br />
<br />
Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br />
<br />
=== Structure de l'adresse multicast ===<br />
Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
<br />
Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br />
<br />
Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br />
<br />
=== Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br />
==== diffusion restreinte : tous les nœuds du lien ====<br />
L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" <tt>ff01::1</tt> et "lien local" <tt>ff02::1</tt>. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br />
<br />
==== diffusion restreinte : tous les routeurs du lien ====<br />
Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" <tt>ff01::2</tt>, "lien local" <tt>ff02::2</tt> et "site local" <tt>ff05::2</tt>. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br />
<br />
==== diffusion restreinte : l'adresse multicast sollicité ====<br />
Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".<br />
<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
<br />
Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> et l'ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt> sur l'interface eth0<br />
<br />
cos:~$ ip -6 addr show eth0<br />
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
altname enp1s0<br />
inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br />
valid_lft forever preferred_lft forever<br />
<br />
La commande <tt>ip -6 maddr show eth0</tt> affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse <tt>ff01::1</tt> (toutes les interfaces de l'hôte), l'addresse <tt>ff02::1</tt> (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité <tt>ff02::1:ff'''1d:534c'''</tt> et <tt>ff02::1:ff'''00:0'''</tt> construites en concaténant le préfixe réservé <tt>ff02::1:ff</tt> aux trois derniers octets des IID respectivement de l'adresse LLA <tt>fe80::5054:ff:fe'''1d:534c'''/64</tt> ainsi que de l'adresse ULA <tt>fd7e:1ec0:3111:80:5:0:4'''00:0'''/64</tt>.<br />
<br />
cos:~$ ip -6 maddr show eth0<br />
2: eth0<br />
inet6 ff02::1:ff'''00:0'''<br />
inet6 ff02::1:ff'''1d:534c'''<br />
inet6 ff02::1<br />
inet6 ff01::1<br />
<br />
== conclusion ==<br />
<br />
Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<br />
<br />
== Références bibliographiques ==<br />
<references/><br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 1546 Host Anycasting Service <br />
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br />
* RFC 3587 IPv6 Global Unicast Address Format<br />
* RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br />
* RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br />
* RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br />
* RFC 4048 RFC 1888 Is Obsolete<br />
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br />
* RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br />
* RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br />
* RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br />
* RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br />
* RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br />
* RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br />
* RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br />
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br />
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br />
* RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br />
<br />
<br />
<br />
= Annexe : Le multicast en IPv6 =<br />
== Introduction ==<br />
Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990<ref>Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]</ref>.<br />
Multicast IP est présenté en détail par cet article de Cisco <ref> Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].</ref>. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br />
Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast<ref>Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]</ref> uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br />
<br />
== Communication multicast ==<br />
Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br />
De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br />
<br />
Le service de communication multicast se rend selon 2 modèles :<br />
<br />
* le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br />
* le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br />
<br />
Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br />
* choix de l'adresse multicast pour la session ;<br />
* description et annonce de la session multicast à tous les participants ;<br />
* gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br />
* construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br />
<br />
Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br />
<br />
== Formats des adresses multicast IPv6 ==<br />
Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br />
<br />
=== Format général ===<br />
Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''"Structure de l'adresse multicast"'']]<br />
<!--Les adresses multicast IPv6 sont dérivées du préfixe <tt>ff00::/8</tt>. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br />
</center><br />
<br />
Le champ <tt>drapeaux</tt> (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ <tt>drapeaux</tt>, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br />
<br />
* le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br />
* le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br />
* le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br />
* le bit de poids fort du champ <tt>drapeaux</tt> n'est pas encore attribué.<br />
<br />
Le champ <tt>étendue</tt> (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ <tt>durée de vie</tt> (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br />
<br />
* 0 - reserved <br />
* 1 - node-local<br />
* 2 - link-local<br />
* 3 - realm-local<br />
* 4 - admin-local<br />
* 5 - site-local<br />
* 8 - organisation-local<br />
* e - global<br />
* f - reserved<br />
--><br />
<br />
== Adresses multicast IPv6 permanentes ==<br />
Une adresse multicast IPv6 avec le bit T du champ <tt>drapeaux</tt> à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br />
</center><br />
<br />
Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>ff00::/12</tt>.<br />
<br />
Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br />
<br />
* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br />
* des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br />
<br />
Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br />
<br />
<center> <br />
{|<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::101</tt> ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br />
|-<br />
|<tt>ff02::101</tt> || Tous les serveurs NTP du même lien que l'émetteur ;<br />
|- style="background:silver" <br />
|<tt>ff05::101</tt> || Tous les serveurs NTP du même site que l'émetteur ;<br />
|-<br />
|<tt>ff0e::101</tt> || Tous les serveurs NTP de l'Internet.<br />
|} <br />
</center><br />
<br />
Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre<ref> IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]</ref> de l'ensemble des adresses multicast réservées.<br />
<br />
<br />
* L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : <tt>ff0x:0:0:0:0:0:0:0</tt> avec x variant de '0' à 'f'.<br />
* Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type "déni de service" par bombardement massif en diffusion).<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de mutlicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::1</tt> || Toutes les interfaces du nœud ;<br />
|-<br />
| <tt>ff02::1</tt> || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br />
|}<br />
</center><br />
<br />
* Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution "bis", pour limiter les attaques en "déni de service").<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="75%"<br />
! Adresse de multicast || Population concernée<br />
|- style="background:silver" <br />
|<tt>ff01::2</tt> || Tous les routeurs du nœud ;<br />
|- <br />
|<tt>ff02::2</tt> || Tous les routeurs du lien ;<br />
|- style="background:silver" <br />
|<tt>ff05::2</tt> || Tous les routeurs du site.<br />
|}<br />
</center><br />
<br />
== Adresses multicast IPv6 temporaires ==<br />
Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br />
bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br />
Exemple : l'adresse multicast site-local <tt>ff15::999</tt> sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br />
Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br />
<br />
=== Adresses multicast temporaires générales ===<br />
Ce sont des adresses avec tous les bits du champ <tt>drapeaux</tt> à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br />
</center><br />
<br />
=== Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br />
Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br />
</center><br />
<br />
* <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.<br />
* <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br />
* <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe.<br />
<br />
Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660</tt>, et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>ff3x:20:2001:660::a34b:c56d</tt> ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br />
Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br />
<br />
=== Adresses multicast ''Embedded-RP'' ===<br />
Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br />
</center><br />
<br />
Ainsi, pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3007:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :<br />
<br />
* <tt>res</tt> (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br />
* <tt>RPad</tt> : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br />
* <tt>Plen</tt> (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal).<br />
* <tt>prefix</tt> (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt><br />
* <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".<br />
<br />
Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>ff7x:340:2001:660:3007:125:a1b2:c3d4</tt> ; '''''a1b2:c3d4''''' étant le<br />
group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br />
portée (''scope'').<br />
<br />
=== Les adresses multicast SSM ===<br />
Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>ff3x::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>ff3x::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0. La figure 6 représente ce format.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br />
</center><br />
<br />
<!-- reporté dans l'activité - n'a plus sa place dans cette annexe --><br />
<!--<br />
== Les adresses "multicast sollicité" ==<br />
L'adresse de "multicast sollicité" (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse <tt>ff02::1</tt> (tous les équipements sur le lien), l'utilisation des adresses de "multicast sollicité" permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br />
<br />
L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé <tt>ff02::1:ff00:0 /104</tt> aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br />
<br />
Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de "multicast sollicité" et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de "multicast sollicité" pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br />
<br />
Plusieurs équipements sur le lien peuvent avoir la même adresse de "multicast sollicité". Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de "multicast sollicité" peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse "unicast globale" si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse "multicast sollicité".]]<br />
</center><br />
--><br />
<br />
== Correspondance avec les adresses de multicast de niveau 2 ==<br />
{{HorsTexte|Le multicast sur la commutation ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs diffusent les trames de multidiffusion (mutlicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de "l'IGMP / MLD snooping". Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derriere lesquels se trouvent des abonnés aux groupes de multidifussion.<br />
<br />
En IPv6 le groupe identifié 16 au registre multicast de l'IANA de portée locale (adresse ff02::16) est le groupe des routeurs MLDv2 (MLDv2-capable-routers). Lors de séance de TP, vous pourrez constater, à l'aide d'une capture wireshark, qu'à l'initialisation d'une adresse à une interface d'un noeud une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utllisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au noeud.}}<br />
Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br />
<br />
Par exemple, à l'adresse multicast IPv6 <tt>ff0e:30:2001:660:3001:4002:ae45:2C56</tt> correspondra l'adresse MAC <tt>33-33-AE-45-2C-56</tt>. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ <tt>group-ID</tt> à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br />
<br />
<center><br />
[[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br />
</center><br />
<br />
== Récapitulatif des types d'adresses multicast ==<br />
Le tableau suivant récapitule les préfixes associés aux<br />
différents types d'adresses multicast décrit précédemment.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="80%"<br />
|- align="center"<br />
<br />
! scope="col" width="30%" align="center" | '''Préfixe'''<br />
! scope="col" width="70%" align="center" | '''Usage'''<br />
|- style="background:silver"<br />
|<tt>ff0'''x'''::/16</tt> || Adresses IPv6 multicast permanentes ;<br />
|-<br />
|<tt>ff1'''x'''::/16</tt> || Adresses IPv6 multicast temporaires générales ;<br />
|- style="background:silver"<br />
|<tt>ff3'''x'''::/16</tt> || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br />
|-<br />
|<tt>ff3'''x'''::/96</tt> || Adresses SSM (temporaires) ;<br />
|- style="background:silver"<br />
|<tt>ff7'''x'''::/16</tt> || Adresses IPv6 multicast &quot;Embedded-RP&quot; (temporaires) ;<br />
|-<br />
|<tt>ff02::1:ff00:0/104</tt> ||Adresses de "multicast sollicité" (préfixe prédéfini, portée limitée au lien).<br />
|- <br />
|} <br />
</center><br />
(<tt>'''x'''</tt> : une des valeurs valides de la portée (''scope''))<br />
<br />
== Conclusion ==<br />
Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer : <br />
<br />
* RFC 2375 IPv6 Multicast Address Assignments<br />
* RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br />
* RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br />
* RFC 3569 An Overview of Source-Specific Multicast (SSM)<br />
* RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br />
* RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br />
* RFC 7346 IPv6 Multicast Address Scopes</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20578MOOC:Manuel Apprenant2024-01-10T16:26:19Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' '''''Dans le cas de Windows 11''''' ''il peut également être nécessaire de désactiver la variable d'environnement <tt>hypervisorlaunchtype</tt> à l'aide de la commande : <tt>bcdedit /set hypervisorlaunchtype off</tt><br />
(pour plus de détails voir : <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>).''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20577MOOC:Manuel Apprenant2024-01-10T16:24:22Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' ''Dans le cas de Windows 11 il peut également être nécessaire de désactiver la variable d'environnement <tt>hypervisorlaunchtype</tt> à l'aide de la commande : <tt>bcdedit /set hypervisorlaunchtype off</tt><br />
(pour plus de détails voir : <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>).''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20576MOOC:Manuel Apprenant2024-01-10T15:49:24Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' ''Dans le cas de VMWare-player il peut également être nécessaire de désactiver la variable d'environnement <tt>hypervisorlaunchtype</tt> à l'aide de la commande : <tt>bcdedit /set hypervisorlaunchtype off</tt><br />
(pour plus de détails voir : <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>).''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20575MOOC:Manuel Apprenant2024-01-10T15:47:48Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' ''Dans le cas de VMWare-player il peut également être nécessaire de désactiver la variable d'environnement <tt>hypervisorlaunchtype</tt> à l'aide de la commande : <tt>bcdedit /set hypervisorlaunchtype off</tt><br />
(pour plus de détails voir : <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>.''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20574MOOC:Manuel Apprenant2024-01-10T15:18:52Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' ''Dans le cas de VMWare player il peut également être nécessaire de désactiver la variable d'environnement <tt>hypervisorlaunchtype</tt> à l'aide de la commande : <tt>bcdedit /set hypervisorlaunchtype off</tt><br />
(pour plus de détails, voir <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>.''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20573MOOC:Manuel Apprenant2024-01-10T15:14:32Z<p>Jlandru: /* Etape 2 de l'installation */</p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
''' Nota : ''' ''Dans le cas de VMWare player il peut également être nécessaire de désactiver la variable d'environnement `hypervisorlaunchtype` à l'aide de la commande : `bcdedit /set hypervisorlaunchtype off`<br />
(voir <ref>Résoudre Virtualized Intel VT-x/EPT ou AMD-R/RVI is not supported on this plateform sur VMWare [https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/ https://www.malekal.com/resoudre-virtualized-intel-vt-x-ept-ou-amd-r-rvi-is-not-supported-on-this-plataform-vmware/]</ref>.''<br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20554MOOC:Manuel Apprenant2023-01-26T22:05:36Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt>$vmname</tt> au nom de votre VM ;<br />
VBoxManage modifyvm $vmname --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20553MOOC:Manuel Apprenant2023-01-26T09:19:55Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt><vm-name></tt> au nom de votre VM ;<br />
VBoxManage modifyvm <vm-name> --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20552MOOC:Manuel Apprenant2023-01-26T09:18:20Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |406px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt><vm-name></tt> au nom de votre VM ;<br />
VBoxManage modifyvm <vm-name> --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 11) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20551MOOC:Manuel Apprenant2023-01-26T09:17:17Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__ <br />
= Introduction =<br />
Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br />
* l'installation de la plateforme ;<br />
* l'outil GNS3 ;<br />
* le déroulement d'une activité pratique ;<br />
* l'utilisation des outils liés aux activités ;<br />
* les commandes utilisées pour les activités.<br />
<br />
= Prise en main de la plateforme des activités pratiques =<br />
<br />
Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br />
<br />
== Pourquoi utiliser GNS3 ? ==<br />
<br />
Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' <ref>GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]</ref> qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br />
<center><br />
[[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br />
</center><br />
Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br />
Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br />
<br />
== Contexte d'exécution des Travaux Pratiques ==<br />
Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox<ref>Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [</ref> (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 "Objectif IPv6" sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC "Objectif IPv6" sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br />
<br />
'''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br />
* ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation <ref group="note">Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. </ref> ;''<br />
* ''RAM 2 Go (recommandé 4 Go) ;''<br />
* ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br />
* ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br />
* ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br />
'''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br />
<br />
=== Note ===<br />
<br />
<references group="note" /><br />
<br />
== Installation de la plateforme ==<br />
<br />
=== Validation préalable des extensions matérielles à la virtualisation ===<br />
Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br />
<br />
'''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du "firmware" (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br />
<br />
En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br />
<center><br />
[[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox "extensions de virtualisation indisponibles]]<br />
</center><br />
<br />
Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br />
* soit directement dans l'affichage de l'onglet ''"performances"'' du ''"gestionnaire de tâches"''<br />
<center><br />
[[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 "Gestionnaire de tâches > performances > Virtualisation activée" ]]<br />
</center><br />
* soit directement en ligne de commande, à l'aide de la commande '''''<tt>systeminfo</tt>''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br />
<center><br />
[[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' > Virtualisation activée" ]]<br />
</center><br />
* alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br />
<center><br />
[[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' >extensions VMX/SVM activées" ]]<br />
</center><br />
Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre <tt>VMX</tt>, ''(respectivement <tt>SVM</tt> si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br />
<br />
=== Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br />
<br />
Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br />
<br />
Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br />
<br />
Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br />
<br />
Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''"Setup"'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br />
<br />
Au besoin, il peut être utile de consulter les références suivantes : <br />
* '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]<ref>Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]</ref><br />
<br />
* '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]<ref> Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]</ref><br />
<br />
* [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] <ref>[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]</ref><br />
<br />
Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br />
<br />
=== Copies d'écran type ===<br />
<center><br />
[[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS "configuration CPU" ]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS "Activation du mode VTx"]]<br />
</center><br />
<br />
<center><br />
[[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS "sortie et sauvegarde du réglage"]]<br />
</center><br />
<br />
Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br />
<br />
=== Étape 1 de l'installation ===<br />
<br />
Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br />
<br />
<!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --><br />
[https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br />
<br />
Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, "double-cliquez" sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le "pack" d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br />
<br />
''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br />
<br />
=== Etape 2 de l'installation ===<br />
<br />
''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br />
<br />
L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« > Installer GNS3 > Comment procéder ? »'' de la séquence de "Bienvenue" du MOOC "Objectif IPv6".<br />
<br />
Le fichier image (au format ''<tt>.ova</tt>'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''<tt>.ova</tt>'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br />
* si besoin, renommez la machine ainsi : "MoocIPv6-S6" ; <br />
* en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br />
* vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br />
* les autres réglages par défaut devraient convenir.<br />
Une fois que le répertoire de travail est fixé, vous pouvez valider "l'import".<br />
<br />
''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br />
<br />
''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br />
<br />
''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version >= 2004 de Windows 10 <ref>Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]</ref>.''<br />
<br />
''Il convient, également, de désactiver la fonctionnalité "Sandbox" ou "Bac à sable Windows", qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br />
<br />
''Pour le vérifier afficher les fonctionnalités Windows : ''<br />
<br />
''Touche Windows+R ou commande Exécuter : optionalfeatures''<br />
<br />
''Vérifiez que les fonctionnalités "Bac à sable Windows" et "HyperV" sont bien décochées, comme ci dessous:''<br />
<center><br />
[[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |406px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br />
</center><br />
<br />
Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br />
* dans l'onglet ''« Général > De base »'', le système d'exploitation invité est bien "Ubuntu-64bit" ;<br />
* dans l'onglet ''« Général > Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br />
* sur l'onglet ''« Système > Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br />
* sur l'onglet ''« Système > Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br />
* '''sur ce même onglet''' '''''« Système > Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''<tt>Active VT-x/AMD-V imbriqué</tt>''''' '''est bien activée !'''<br />
{{HorsTexte|Paramètre "Activer VT-x/AMD-V imbriqué" grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option "Activer VT-x/AMD-V imbriqué" soit grisée et ne peut être activée<ref>Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].</ref>. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br />
<br />
a) assurez vous que la VM soit stoppée ;<br />
<br />
b) dans un terminal de commande exécutez la commande suivante en ajustant "<tt><vm-name></tt> au nom de votre VM ;<br />
VBoxManage modifyvm <vm-name> --nested-hw-virt on<br />
<br />
c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br />
* '''sur l'onglet''' '''''« Système > Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''<tt>KVM</tt>''''' qui sera utile dans notre contexte ;<br />
* dans l'onglet ''« Affichage > Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''<tt>VMSVGA</tt>'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br />
* onglet ''« Stockage »'' : on laisse en l'état ;<br />
* '''onglet''' '''''« Réseau > Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''<tt>NAT</tt>''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br />
* enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br />
<br />
Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br />
<center><br />
[[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br />
</center><br />
<br />
L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br />
<!--<br />
Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br />
--><br />
<br />
= Utilisation de GNS3 =<br />
<br />
Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme "Réseau IPv6" utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br />
<br />
L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br />
<center><br />
[[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br />
</center><br />
* Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br />
<br />
*Sur la figure 11, à droite de l'espace de travail, la fenêtre "Liste des équipements" (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br />
<br />
*Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''"triangle vert"'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 10). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br />
<br />
*Le bouton ''">_"'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br />
<br />
'''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de <tt>login</tt> comme représentée par la figure 12.''<br />
<center><br />
[[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br />
</center><br />
*Le bouton intitulé ''"a b c"'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br />
<br />
Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]<ref>tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]</ref>.<br />
<br />
= Déroulement d'une activité pratique =<br />
<br />
== Démarrage d'une activité ==<br />
<br />
Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br />
<br />
Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br />
<center><br />
[[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br />
</center><br />
Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br />
<br />
Les instantanés ou ''"snapshots"'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br />
<br />
Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br />
<br />
'''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br />
<br />
== Mise en pause et reprise ==<br />
<br />
Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br />
<br />
Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en "pause" (menu ''Machine > pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br />
<br />
<!--<br />
Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br />
<br />
Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br />
--><br />
Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br />
<br />
== Retour arrière ==<br />
<br />
Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br />
<br />
= Interface de commandes des équipements de la plateforme =<br />
<br />
== Console / Ligne de commande ==<br />
<br />
L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode "ligne de commande" avec cet équipement.<br />
<br />
L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 ("''Console connect to all devices''"). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br />
<br />
Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question ("clic droit" sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br />
<br />
Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de "l'invite du système" afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont <tt>ifconfig</tt> validés par la touche "Entrée" pour exécuter la commande.<br />
<br />
Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br />
* copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br />
* coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br />
<br />
== Edition de fichier ==<br />
<br />
Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode "texte". Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers <tt>nano</tt> :<br />
<br />
root@PC-x::cx:~$ '''nano -w <nom du fichier>'''<br />
<br />
Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches <CTRL-O> (touches "Ctrl" et lettre 'o' simultanément) permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur.<br />
<br />
'''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur <tt>nano</tt> sont rappelées dans le bas de l'écran de la console.''<br />
<br />
== Capture de trames réseau ==<br />
<br />
La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br />
<br />
=== Démarrer une capture de trames réseau ===<br />
<br />
Pour lancer une capture, allez dans la fenêtre '''"Topology Summary"''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''"Start capture"'''. <br />
<br />
La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br />
<center><br />
[[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br />
</center><br />
Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br />
<br />
=== Arrêter une capture réseau ===<br />
<br />
L'arrêt des captures est possible depuis la fenêtre "Topology Summary" (voir la figure 10) en choisissant '''"Stop all captures"'''.<br />
<br />
'''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br />
<br />
= Synthèse des commandes des systèmes =<br />
<br />
== A propos des modes VyOS ==<br />
<br />
VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 10). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br />
<br />
'''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br />
login: '''vyos'''<br />
password: '''vyos'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos:~$ <br />
<br />
Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br />
<br />
'''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''vtysh'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos# <br />
<br />
Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br />
La sortie de ce mode s'effectue par la commande '''exit'''.<br />
<br />
'''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br />
vyos@vyos:~$ '''configure'''<br />
<br />
L'invite de commande dans ce mode est :<br />
vyos@vyos# <br />
<br />
Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br />
<br />
== Commandes pour les paramètres des interfaces réseau ==<br />
<br />
'''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br />
<br />
'''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est "apprenant" et il n'y a pas de mot de passe.''<br />
<br />
'''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br />
<br />
=== Visualiser la configuration IPv6 des interfaces réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig'''<br />
root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br />
root@PC-x::cx:~$ '''ip -6'''<br />
<br />
VyOS (Mode Utilisateur)<br />
vyos@vyos:~$ '''show interfaces detail'''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''show interface'''<br />
<br />
=== Activer une interface réseau ===<br />
<br />
Il convient de remplacer le motif <tt>''interface''</tt> par le nom de l'interface réseau de l'équipement.<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br />
<br />
VyOS (Mode Quagga)<br />
Il faut passer en mode configuration par cette commande: <br />
vyos# '''configure terminal'''<br />
vyos(config)# <br />
Puis en configuration d'interface par la commande <tt>''interface''</tt>:<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no shutdown'''<br />
vyos(config-if)# '''exit'''<br />
vyos(config)#<br />
<br />
La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br />
vyos(config-if)# '''end'''<br />
vyos#<br />
La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br />
vyos(config-if)# '''do show interface'''<br />
<br />
=== Ajouter une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
=== Enlever une adresse IPv6 à une interface réseau ===<br />
<br />
Linux :<br />
root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br />
<br />
VyOS (Mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''interface ''interface'' '''<br />
vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br />
vyos(config-if)# '''exit'''<br />
<br />
== Commandes propres à la table de routage ==<br />
<br />
=== Visualiser la table de routage IPv6 ===<br />
<br />
Linux <br />
root@PC-x::cx:~$ '''route -A inet6'''<br />
root@PC-x::cx:~$ '''ip -6 route'''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''show ipv6 route'''<br />
<br />
=== Ajouter une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br />
root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br />
L'interface est optionnelle.<br />
<br />
=== Enlever une route IPv6 ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br />
<br />
== Autres commandes utiles pour IPv6 ==<br />
<br />
=== Tester la connectivité vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br />
'''^C''' (CTRL+C) pour stopper le test<br />
<br />
Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br />
root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br />
<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
=== Visualiser le chemin vers une autre machine ===<br />
<br />
Linux<br />
root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br />
<br />
VyOS (mode Quagga)<br />
vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br />
<br />
= Références URLographiques =<br />
<references/></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=File:Windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png&diff=20550File:Windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png2023-01-26T09:09:22Z<p>Jlandru: Windows 10 : Hyper-V and Sandbox check box</p>
<hr />
<div>Windows 10 : Hyper-V and Sandbox check box</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act46&diff=20549MOOC:Compagnon Act462023-01-17T11:02:01Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
= Activité 46: Faites inter-opérer des applications IPv6 et IPv4=<br />
<br />
Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :<br />
* un Internet en IPv4 encore prépondérant du fait de ses services ;<br />
* un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.<br />
<br />
L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours. <br />
<br />
Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.<br />
<br />
La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :<br />
* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;<br />
* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;<br />
* un routeur R2 en IPv4 : c'est un noeud représentant l'Internet en IPv4 ;<br />
* un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;<br />
* un serveur web IPv4. Ce service sera hébergé sur le noeud SRV-3 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.<br />
<br />
<!--<center><br />
[[image:46-etape0.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center> --><br />
<center><br />
[[image:MoocSession5_act46_topology_20190628.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center><br />
<br />
= Etape 0 : Situation initiale =<br />
<br />
Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.<br />
<!--<br />
Dans la phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Il reste à démarrer les services. Les services hébergés sur PC2 sont le DNS, pour la résolution de noms, et le web. <br />
--><br />
<!--<br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur PC2 les services applicatifs de nommage DNS (<tt>named -c /usr/local/etc/bind/named.conf</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
--><br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur SRV-3 les services applicatifs de nommage DNS (<tt>/usr/sbin/named -u bind</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
<br />
'''Note :''' pour vous loguer sur les stations PC-1, PC-2 et SRV-3, l'identifiant est '''root''' et il n'y a pas de mot de passe (tapez sur 'retour chariot' (''return'' ou Entrée) quand le mot de passe est demandé).<br />
<!--<br />
Activez le service de web sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo nginx'''<br />
<br />
Activez le service de nommage sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo named -c /usr/local/etc/bind/named.conf'''<br />
--><br />
<br />
Pour tester la configuration, il faut d'abord valider le DNS en interrogeant le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
'''''Nota : ''''' ''Dans le cadre de ce TP, les machines PC-1, PC-2, R1, R2 et SRV-3 ont respectivement été enregistrées pc1, pc2, r1, r2 et srv dans le domaine DNS .tp hebergé sur la machine SRV-3.''<br />
<br />
La commande <tt>dig</tt> est disponible sur PC-2. L'adresse du serveur de noms à utiliser dans la commande <tt>dig</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. :<br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp'''<br />
Pour un affichage plus concis vous pouvez ajouter le paramètre <tt>+short</tt><br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp +short'''<br />
<br />
Vous pouvez également vérifier que la résolution de noms fonctionne depuis R1 (en mode utilisateur) à l'aide de la commande <tt>host</tt>. Pour vous connecter en mode utilisateur sur R1 :<br />
<br />
'''''Nota :''''' ''Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).''<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'adresse du serveur de noms à utiliser dans la commande <tt>host</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. La syntaxe de la commande devient alors, sur R1 :<br />
vyos@r1:~$ '''host srv.tp 192.0.3.3'''<br />
<!--<br />
Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2.<br />
--><br />
Vérifiez ensuite le bon fonctionnement du service web de SRV-3 depuis R1, à l'aide de la commande <tt>curl</tt> : <br />
vyos@r1:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Si vous le souhaitez, vous pouvez recommencer la vérification depuis R2. <br />
<br />
Pour cela il vous faut d'abord faire pointer le client DNS de R2 vers SRV-3 en renseignant le fichier de configuration <tt>/etc/resolv.conf</tt>. Passez d’abord en mode ''root'', puis créer le fichier fichier du client DNS, à l'aide de la commande <tt>echo</tt> et en redirigeant la sortie standard vers le fichier à créer.<br />
r2 login: '''vyos'''<br />
Password: <br />
Linux r2 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''echo "nameserver 192.0.3.3" > /etc/resolv.conf'''<br />
root@r2:/home/vyos# '''exit'''<br />
exit<br />
<br />
Vous pouvez ensuite procéder aux tests de la même manière que sur R1.<br />
<br />
vyos@r2:~$ '''host srv.tp'''<br />
vyos@r2:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
La problématique qu'il reste à résoudre se pose dans les termes suivants : comment PC1, qui est en ''IPv6-only'', peut-il accéder au service web <tt>srv.tp</tt> qui est en ''IPv4-only'' ?<br />
<br />
= Etape 1 : Configuration de NAT64/DNS64 =<br />
Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. <br />
<!--Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud en double pile R1.--><br />
La fonction de relais dns auxiliaire DNS64 est maintenant intégrée dans les versions récentes de la pile logicielle DNS Bind9. Elle sera donc assurée par le service de nommage DNS porté par SRV-3. La fonction de traduction NAT64, quant à elle, sera placée sur le nœud en double pile R1.<br />
<br />
Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être 'avec état' ou 'sans état'.<br />
<br />
Le NAT64 que nous allons déployer sur notre plateforme est un traducteur 'sans état'. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction.<br />
Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode 'sans état'. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052.<br />
Ainsi, lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination, adresse qu'il aura apprise en recevant la requête. Comme la traduction d'adresse s'effectue 'sans état', ceci implique que l'adresse IPv4 du client a été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose, parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc, d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 ''IPv4-translatable'' en plus de son adresse IPv6 unicast routable.<br />
<br />
Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64. <br />
Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br />
Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.<br />
<br />
<!--<center><br />
[[Image:46-fig2.png|300px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_dns64_20190628.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_dns64_20210408.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center><br />
<br />
== Allocation d'adresses ==<br />
<br />
Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.<br />
La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.<br />
<!--<center><br />
[[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_step_1_20190628.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_step_1_20210408.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center><br />
<br />
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.<br />
<!--<br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! @ IPv4<br />
! @ IPv6<br />
|-<br />
! rowspan="2" | PC1<br />
| <br />
|<tt> fd75:e4d9:cb77:1::3</tt><br />
|-<br />
| <tt>192.0.3.3</tt><br />
| <tt>fd75:e4d9:cb77:64::192.0.3.3</tt><br />
|- <br />
! rowspan="3" | R1<br />
| <tt>192.0.3.1</tt> <br />
| <tt>fd75:e4d9:cb77:64::192.0.3.1</tt><br />
|-<br />
| <br />
| <tt>fd75:e4d9:cb77:1::1</tt> <br />
|-<br />
| <tt>192.0.2.130</tt><br />
|<br />
|-<br />
! rowspan="2" | R2<br />
| <tt>192.0.2.129</tt><br />
| <br />
|-<br />
| <tt>192.0.2.2</tt><br />
| <br />
|-<br />
! rowspan="1" | PC2<br />
| <tt>192.0.2.1</tt><br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
--><br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! Interface<br />
! @ IPv4<br />
! @ IPv6<br />
|- style="background:silver"<br />
! rowspan="2" | PC-1 <br />
|eth0<br />
|<br />
| '''<tt> fd75:e4d9:cb77:1::c1</tt>'''<br />
|- style="background:silver"<br />
|eth0<br />
| ''<tt>192.0.1.1</tt>''<br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.1</tt>'''<br />
|- <br />
! rowspan="3" | R1<br />
| eth0<br />
|<br />
| '''<tt>fd75:e4d9:cb77:1::1</tt>'''<br />
|-<br />
| eth0<br />
| ''<tt>192.0.1.254/24</tt>'' <br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.254</tt>'''<br />
|-<br />
| eth1<br />
| '''<tt>192.0.0.1/30</tt>'''<br />
|<br />
|- style="background:silver"<br />
! rowspan="3" | R2<br />
| eth1<br />
| '''<tt>192.0.0.2/30</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth0<br />
| '''<tt>192.0.2.254/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth3<br />
| '''<tt>192.0.3.254/24</tt>'''<br />
|<br />
|-<br />
! rowspan="1" | PC-2<br />
| eth0<br />
| '''<tt>192.0.2.2/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
! rowspan="1" | SRV-3<br />
| eth0<br />
| '''<tt>192.0.3.3/24</tt>'''<br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
<br />
Il est à noter que bien que PC-1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 (''IPv4-translatable'') qui sera attribuée à l'interface réseau de PC1. De ce fait, PC-1 aura bien 2 adresses unicast IPv6 routables : une utilisée pour les communications avec des noeuds IPv6 (SID positionné à <tt>1</tt>) et une autre utilisée pour les communications avec des noeuds IPv4 (SID positionné à <tt>64</tt>). L'algorithme du choix de l'adresse source, lorsqu'il a plusieurs adresses IPv6, est défini par le RFC 6724.<br />
Lorsque PC-1 envoie une requête à SRV-3, il utilise, sur le réseau IPv6, comme adresse source : <tt>fd75:e4d9:cb77:64::192.0.1.1</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:101</tt>), et comme adresse de destination : <tt>fd75:e4d9:cb77:64::192.0.3.3</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:303</tt>). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source <tt>192.0.1.1</tt> et destination <tt>192.0.3.3</tt>.<br />
<br />
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.<br />
<br />
== Configuration de PC1 ==<br />
<br />
<!-- Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :<br />
apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:1::3/64'''<br />
--><br />
Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.<br />
root@PC-1~# '''ifconfig eth0'''<br />
Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien. <br />
<!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' --><br />
root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''<br />
Vérifiez votre saisie en affichant de nouveau les adresses de l'interface eth0.<br />
<br />
root@PC-1~# '''ip addr show eth0'''<br />
'''''Nota :''''' ''La notation canonique de la nouvelle adresse que vous venez d'attribuer à l'interface affiche l'adresse IPv4 en hexadécimal avec l'IID <tt>::c000:101</tt>''<br />
<br />
Ensuite, il faudrait théoriquement indiquer une route au préfixe NSP réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC-1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement distinct du routeur. Elle pourrait être positionnée par la commande : <br />
<br />
<tt> route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1</tt><br />
<br />
Dans notre cas, PC-1 n'a pas besoin de route spécifique pour le préfixe NSP IPv6 de traduction puisque la passerelle de traduction NAT64 est elle-même hébergée sur le routeur par défaut pour PC-1.<br />
<br />
<!--<br />
Enfin, renseignez le serveur de noms qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS qui sera configuré par la suite sur R1. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> qui ne contiendra qu'une seule ligne. Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap''). L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
--><br />
Enfin, configurez le client DNS (''resolver'') de PC-1 en renseignant le serveur récursif de proximité qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS récursif qui sera configuré par la suite sur R1 afin de relayer les requêtes vers SRV-3. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> de PC-1 qui ne contiendra qu'une seule ligne.<br />
<br />
'''''Nota :''''' ''Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap'').''<br />
<br />
L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
root@PC-1:~# '''nano -w /etc/resolv.conf'''<br />
et saisissez la ligne ci-dessous avant de sauvegarder le fichier à l'aide de la commande <CTRL+o>, puis de sortir de l'éditeur par <CTRL+x> :<br />
'''nameserver fd75:e4d9:cb77:1::1'''<br />
Vérifiez vote saisie en affichant le contenu du fichier à l'aide de la commande <tt>cat</tt><br />
root@PC-1:~# '''cat /etc/resolv.conf'''<br />
<br />
== Mise en oeuvre du DNS64 sur SRV-3 ==<br />
<br />
<!--<br />
== Mise en oeuvre du DNS64 sur R1 ==<br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel '''TOTD''' (''Trick Or Treat Daemon'') peut également être utilisé pour cet usage. '''TOTD''' est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).<br />
Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. La configuration de NAT64/DNS64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans un mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt> :<br />
vyos@vyos~$ '''exit'''<br />
Pour vous reconnecter en mode ''root'' sur R1 :<br />
login: '''root''' <br />
Password: '''root'''<br />
L'invite de commande dans ce mode est :<br />
root@vyos:~#<br />
Avant de démarrer le service DNS auxiliaire, complétez le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1, éditez le fichier de configuration de '''TOTD''' :<br />
root@vyos:~# '''nano -w /etc/totd.conf'''<br />
pour localiser et renseigner les informations suivantes dans le fichier :<br />
forwarder '''192.0.2.1''' # IPv4 address for name server<br />
prefix '''fd75:e4d9:cb77:64::''' # /96 by default<br />
port '''53'''<br />
<br />
Le ''forwarder'' correspond à l'adresse IPv4 du serveur DNS général. La ligne ''prefix'' indique dans notre cas le NSP qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (''IPv4-converted'').<br />
<br />
Démarrez le logiciel :<br />
root@vyos:~# '''/etc/init.d/totd start'''<br />
<br />
Vérifiez que TOTD ne s'est pas arrêté, en consultant la fin du journal système à l'aide de la commande : <br />
root@vyos:~# '''tail /var/log/messages'''<br />
Vous pouvez également vérifier la présence du processus 'daemon totd' à l'aide de la commande :<br />
root@vyos:~# '''ps -edf | grep totd'''<br />
'''Note :''' le symbole <tt>|</tt> (pipe Unix) est obtenu en appuyant simultanément sur les touches 'Alt Gr' et '6' du clavier azerty de votre PC ou Shift + Alt + L (appui simultané sur les 3 touches) de votre Mac.<br />
<br />
Nous allons vérifier que le serveur DNS contient les bons enregistrements pour les noeuds de cette plateforme. A savoir que PC2 contient bien l'adresse <tt>192.0.2.1</tt>. Aussi ouvrir une session sur PC2 et consulter le fichier <tt>/etc/bind/db.tp</tt><br />
apprenant@MOOCIPv6:~$ '''less /etc/bind/db.tp'''<br />
pour sortir de l'afficheur taper 'q'. Pour faire des modifications ou des ajouts, utiliser votre éditeur de texte. Pour recharger la base de données du serveur dns sur PC2:<br />
apprenant@MOOCIPv6:~$ '''sudo /etc/init.d/bind reload'''<br />
<br />
Vérifier que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande: <tt>{tail /var/log/syslog}</tt>.<br />
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande <tt>/etc/init.d/bind restart</tt>.<br />
--><br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64, tel qu'il est illustré à la figure 2. Sur notre plateforme, c'est le serveur SRV-3 qui supporte à la fois le service DNS et la fonction de DNS64 auxilliaire.<br />
Nous allons passer en revue sa configuration avant de tester son fonctionnement.<br />
Observons le contenu de la base de données du serveur en consultant le fichier ''<tt>/etc/bind/db.tp</tt> à l'aide de la commande <tt>cat</tt><br />
root@SRV-3:/# '''cat /etc/bind/db.tp'''<br />
On constate que certaines ressources sont référencées à la fois en IPv6 et en IPv4 avec des RR (''Resource Record'') de type AAAA et A et d'autres uniquement en IPv4 sous forme de RR de type A.<br />
<br />
Les options de démarrage du serveurs sont fixées dans le fichier ''<tt>/etc/bind/named.conf.options</tt>''<br />
root@SRV-3:/# '''cat /etc/bind/named.conf.options'''<br />
'''Nota''' ''Dans ce fichier, les commentaires sont préfixés par <tt>//</tt> (''double caractères diviseur'').''<br />
<br />
A la fin du fichier vous trouverez les clauses de configuration de la fonction DNS64.<br />
Quel est le préfixe choisi pour la translation ? Pour quels clients cette fonction est elle activée ?<br />
<br />
Avant de procéder aux tests, nous devons activer la fonction de relais récursif DNS de proximité de R1 pour que les requêtes des clients sur le sous réseau Net1 soient relayées vers le serveur DNS SRV-3, en enchaînant les commandes suivantes<br />
vyos@r1$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set service dns forwarding cache-size 0'''<br />
vyos@r1# '''set service dns forwarding listen-address fd75:e4d9:cb77:1::1'''<br />
vyos@r1# '''set service dns forwarding name-server 192.0.3.3'''<br />
vyos@r1# '''commit;save'''<br />
vyos@r1#<br />
<br />
Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC-1. Sur PC-1, demandez l'adresse IPv4 de <tt>srv.tp</tt> de la manière suivante :<br />
root@PC-1:~# '''dig srv.tp +short'''<br />
puis l'adresse IPv6 :<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Observez le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal <tt>c000:303</tt>). L'adresse IPv4 occupe les 32 bits de poids faible (à droite) de l'adresse IPv6 affichée.<br />
<br />
Vous pouvez analyser les échanges en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface <tt>eth0</tt> et sur l'interface <tt>eth1</tt> de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de <tt>srv.tp</tt> en une adresse IPv6 initiée par PC-1.<br />
<!--Ainsi, par l'affichage des messages ''DNS standard query'' et ''DNS standard response'' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.--><br />
<br />
== Mise en oeuvre de NAT64 sur R1==<br />
<br />
'''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''Simple, no fuss NAT64 for Linux'') est une mise en oeuvre libre sous Linux du RFC 6145, la version 'sans état' du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS64 auxiliaire que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.<br />
<br />
'''TAYGA''' est installé sur un routeur en double pile, à savoir R1. Nous allons vérifier en premier lieu que R1 satisfait bien cette condition. La configuration de NAT64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans le mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt>. Pour cela, entrez la commande suivante :<br />
vyos@r1:~# '''exit'''<br />
exit<br />
vyos@r1:~$ '''exit'''<br />
logout<br />
<br />
Welcome to VyOS - r1 ttyS0<br />
Pour vous connecter en mode ''VyOS'' sur R1 :<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright. <br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Pour passer en mode ''root'' sur R1 :<br />
vyos@r1:~$ '''sudo su'''<br />
root@r1:/home/vyos# '''sh interfaces'''<br />
Vous pouvez observer que l'interface <tt>eth0</tt> est bien configurée avec une adresse IPv6 routable et que l'interface <tt>eth1</tt> est configurée avec une adresse IPv4. Ce noeud a bien la capacité de communiquer avec les 2 versions du protocole IP. C'est donc bien un noeud en double pile.<br />
<!--<br />
Il faut que le R1 soit configuré en routeur à savoir que le relayage des paquets soit activé. Ceci s'indique par les drapeaux système:<br />
<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv6/conf/all/forwarding '''<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv4/ip_forward''<br />
<br />
Nous allons commencer par configurer les interfaces réseaux de R1, l'interface <tt>eth0</tt> avec les informations liées à IPv6 et <tt>eth1</tt> à IPv4. Nous allons faire cette configuration toujours en mode root.<br />
<br />
root@vyos~# '''ifconfig eth0 inet6 add fd75:e4d9:cb77:1::1/64'''<br />
root@vyos~# '''ifconfig eth1 192.0.2.130/25'''<br />
<br />
Ensuite il reste à indiquer les routes statiques :<br />
root@vyos~# '''ip route add 192.0.2.0/25 via 192.0.2.129 dev eth1'''<br />
R1 vient d'être configuré en double pile. <br />
<br />
Il reste à configurer le logiciel '''TAYGA''' sur R1 :<br />
--><br />
<br />
La configuration de '''TAYGA''' commence par l'édition de son fichier de configuration<tt>/etc/tayga.conf</tt>. Le fichier ayant été pré-configuré, nous allons nous contenter de vérifier que les paramètres correspondent bien à notre architecture en affichant son contenu à l'aide de la commande <tt>cat</tt>. Aidez vous de votre souris et de l'ascenceur dans la partie droite de la fenêtre pour la navigation. :<br />
root@r1:/home/vyos# '''cat /etc/tayga.conf'''<br />
...<br />
'''tun-device nat64''' # device name for nat64<br />
...<br />
ipv4-addr '''192.0.1.254''' # IPv4 address that TAYGA will use<br />
...<br />
prefix '''fd75:e4d9:cb77:64::/96''' # NSP<br />
...<br />
'''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.<br />
<!--<br />
Configurez les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.2.131/25 dev nat64''' #IPv4 nat64 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::2/64 dev nat64''' #IPv6 nat64 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.3.0/24 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0''' # route to pc1<br />
--><br />
<br />
Configurez l'interface interne logique <tt>nat64</tt> et les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.0.1 dev nat64''' # IPv4 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64''' # IPv6 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64''' # route to IPv6 nodes (nodes with IPv4-tranlsatable address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64''' # global route to IPv4 nodes (nodes with IPv4-converted address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1<br />
'''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''<br />
<br />
'''''Nota 2 :''''' ''Pour les deux commandes d'affectation d'une adresse IPv4 et d'une adresse IPv6 à l'interface interne logique nat64 : <tt>ip addr add 192.0.0.1 dev nat64</tt> et <tt>ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64</tt>'' '''''il ne faut pas indiquer de longueur de préfixe !''''' ''sinon l'interface nat64 prendra la priorité sur l'interface eth1 et l'interface eth0 dans la table de routage pour ces préfixes respectifs et la fonction NAT64 ne fonctionnera pas.''<br />
<br />
Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :<br />
vyos@r2:~$ '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''ip route 192.0.1.0/24 192.0.0.1'''<br />
r2(config)# '''end'''<br />
r2#<br />
<br />
192.0.1.0/24 représente le réseau IPv4 fictif qui est inclus dans l'infrastructure IPv6.<br />
<br />
Démarrez '''TAYGA''' sur '''R1''' :<br />
root@r1:/home/vyos# '''tayga'''<br />
<br />
Le service est maintenant opérationnel. Pour le valider, faites un simple test de connectivité ping depuis PC-1 :<br />
root@PC-1:~# '''ping6 -c 5 srv.tp'''<br />
<br />
Maintenant, testez que le client IPv6 (sur PC-1) accède bien au service web (sur SRV-3) :<br />
root@PC-1:~# '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Relancez ces deux dernières commandes en observant parallèlement avec wireshark les captures des flux de part et d'autre du traducteur '''TAYGA''' ''(lancez parallèlement les captures wireshark sur les liens des interfaces <tt>eth0</tt> et <tt>eth1</tt> de R1)''. Quelles sont les versions du protocoles IP, quelles sont les adresses source et destination des paquets ?<br />
<br />
= Etape 2 : Connectivité IPv6 par tunnel =<br />
Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel. <br />
Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.<br />
Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extrémités du tunnel sont indiqués par la figure 4. --><br />
<br />
<!--<center><br />
[[Image:46-fig4-v2.png|450px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession5_act46_step_2_20190630.png|600px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center><br />
<br />
Avant de passer à la configuration du tunnel, revenez en mode utilisateur sur les routeurs. Sur R1 :<br />
root@r1:/home/vyos# '''exit'''<br />
exit<br />
vyos@r1:~$ <br />
<br />
sur R2: <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
<br />
Pour rappel, l'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :<br />
* La première commande consiste à passer en mode administrateur par <tt>configure</tt>.<br />
* La commande <tt>set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64'</tt> crée une interface de tunnel configuré, dénommée <tt>tun0</tt>. Cette interface est identifiée par une adresse IP. Le tunnel est un lien et, en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.<br />
* Le mode d'encapsulation pour le tunnel est spécifié par la commande <tt>set interfaces tunnel tun0 encapsulation 'sit' </tt>. Le mode SIT (''Simple Internet Transition'') indique une méthode d'encapsulation d'IPv6 dans IPv4.<br />
* La commande <tt>set interfaces tunnel tun0 local-ip '192.0.0.1' </tt> précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.<br />
* La commande <tt>set interfaces tunnel tun0 remote-ip '192.0.0.2' </tt> précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi, un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.<br />
* La commande <tt>set interfaces tunnel tun0 mtu '1480' </tt> précise la taille de la MTU (''Maximum Transmission Unit'') appliquée sur ce tunnel. Par défaut, tous les liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisé qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur laquelle repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit, un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête compris). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins les 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc, pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi, moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.<br />
* Enfin, la commande <tt>commit</tt> valide la séquence des commandes en mode administrateur pour revenir en mode utilisateur.<br />
Dans leur ensemble, les commandes à exécuter sont les suivantes :<br />
vyos@r1:~$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::1/64'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 local-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 remote-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r1# '''commit'''<br />
[edit]<br />
vyos@r1#<br />
<br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r1# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r1# '''show interface'''<br />
<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r1# '''show ipv6 route'''<br />
<br />
Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.<br />
<br />
vyos@r2:~$ '''configure'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::2/64'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 local-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 remote-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r2# '''commit'''<br />
[edit]<br />
vyos@r2# <br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r2# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''show interface'''<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r2# '''show ipv6 route'''<br />
<br />
Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :<br />
<br />
r1# '''ping ipv6 fd75:e4d9:cb77:fff::2'''<br />
<br />
Nota : l'arrêt de la commande <tt>ping</tt> s'effectue par un 'Ctrl + C' (appui simultané sur les touches Ctrl et C).<br />
<br />
Sur une des interfaces Ethernet entre R1 et R2, lancez une capture wireshark pour observer les paquets qui vont transiter par le tunnel. <br />
<br />
Recommencez le test de connectivité depuis PC-1.<br />
<br />
root@PC1:~# '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
<br />
<!--Oups ! cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 a bien une route par défaut :<br />
<br />
apprenant@MOOCIPv6:~$ '''route -A inet6'''<br />
<br />
Qu'en est-il de la route de la réponse à la requête du ping ? Regardez la table de routage sur R2 (en mode Quagga) :<br />
<br />
vyos@vyos:~$ '''vtysh'''<br />
vyos# '''show ipv6 route'''<br />
<br />
R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale, à savoir la route par défaut. En effet, on peut considérer que l'Internet v6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :<br />
<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ::/0 tun0'''<br />
vyos(config)# '''exit'''<br />
Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2<br />
vyos# '''show ipv6 route'''<br />
Recommencez le test de connectivité depuis PC1.<br />
<br />
apprenant@MOOCIPv6:~$ '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
--><br />
Cela fonctionne, la connectivité IPv6 a bien été étendue jusqu'au routeur R2.<br />
<br />
Si vous avez lancé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 encapsulés dans des paquets IPv6, eux-mêmes encapsulés dans des paquets IPv4. Observez les différentes encapsulations : <tt>[Ethernet[IPv4[IPv6[ICMPv6]]]]</tt>. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs, quel est le numéro de protocole utilisé dans l'en-tête IPv4 pour identifier un contenu IPv6 ? <br />
<br />
On constate sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>-I</tt> (''Interface'') de la commande Ping6 en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC1:~# '''ping6 -c 5 -I fd75:e4d9:cb77:1::c1 fd75:e4d9:cb77:fff::2'''<br />
Cela fonctionne également. Observez le changement d'adresse source des paquets émis par PC-1 sur la capture.<br />
<br />
Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.<br />
<br />
= Etape 3 : Configurer un reverse proxy web sur R2 =<br />
Dans cette dernière étape, la base des clients en IPv6 est devenue conséquente. Une connectivité IPv6 arrive jusqu'au réseau du serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'applicatif web soit compatible avec IPv6, surtout s'il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.<br />
<br />
Nous avons vu, dans l'étape 1, qu'un client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible, notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. <br />
Une autre solution existe dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative dite ALG (''Application Layer Gateway''). <br />
<br />
Dans cette étape, nous allons mettre en oeuvre un ''reverse proxy'' web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.<br />
<br />
<!--Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion : <br />
login: '''root'''<br />
password: '''root'''<br />
--><br />
Sur le routeur R2, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt>, ensuite <tt>sudo su</tt>. L'affichage des interfaces, permet de s'assurer de nouveau de la connectivité IPv6 de R2 par son interface <tt>tun0</tt> : <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''sh interfaces'''<br />
<!--<br />
Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive<br />
...<br />
pid /run/nginx.pid<br />
...<br />
par<br />
...<br />
'''pid /var/run/nginx.pid'''<br />
...<br />
à l'aide de l'éditeur nano.<br />
root@vyos:~# '''nano -w /etc/nginx/nginx.conf'''<br />
--><br />
<br />
Vérifiez la configuration "reverse proxy IPv6" de R2 en consultant le fichier <tt>/etc/nginx/sites-available/default</tt> à l'aide de la commande <tt>less</tt>.<br />
<br />
'''''Rappel :''''' ''La commande <tt>less</tt> vous permet d'afficher, sans l'éditer, le contenu d'un fichier texte en naviguant simplement avec les touches de direction du curseur. Pour quitter l'affichage du fichier, appuyez simplement sur la touche 'q' qui signifie "quit". ''<br />
root@r2:/home/vyos# '''less /etc/nginx/sites-available/default'''<br />
<br />
Verifiez d'abord que le serveur reverse-proxy sera bien en écoute sur ses interfaces ipv6 en consultant la clause '''listen''' <br />
...<br />
server {<br />
'''listen [::]:80 default_server;'''<br />
...<br />
Vérifiez ensuite sa configration en mode "reverse-proxy" vers l'adresse du serveur SRV-3 en consultant la clause '''location'''<br />
<br />
...<br />
'''location / {'''<br />
''' proxy_pass http://192.0.3.3/;'''<br />
'''}'''<br />
...<br />
<br />
<!--<br />
'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.<br />
<br />
L'appel de l'éditeur s'effectue par la commande :<br />
root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''<br />
--><br />
Redémarrez le serveur nginx :<br />
root@r2:/home/vyos# '''service nginx restart'''<br />
<br />
Vérifiez l'état du service<br />
root@r2:/home/vyos# '''service nginx status'''<br />
<br />
Le service de DNS doit maintenant identifier le ''reverse proxy'' comme le serveur web en IPv6. Pour cela, sur '''SRV-3''', modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy en ajoutant un <tt>RR AAAA</tt> à la valeur <tt>fd75:e4d9:cb77:fff::2</tt> <br />
<br />
root@SRV-3:/# '''nano -w /etc/bind/db.tp'''<br />
...<br />
srv IN A 192.0.3.3<br />
'''IN AAAA fd75:e4d9:cb77:fff::2'''<br />
;<br />
<br />
Relancez le serveur <tt>named</tt>. Pour cela, validez d'abord votre nouvelle configuration à l'aide de la commande <tt> named-checkconf -z</tt>. Si tout est correct, relancez le service à l'aide de la commande <tt>service bind9 restart</tt>:<br />
<br />
root@SRV-3:/# '''named-checkconf -z'''<br />
...<br />
root@SRV-3:/# '''service bind9 restart'''<br />
...<br />
[ ok ] Starting domain name service...: bind9.<br />
Verifiez l'état du service<br />
root@SRV-3:/# '''service bind9 status''' <br />
Sur le relais DNS de R1, afin de réinitialiser le cache DNS, rédemarrez le service <tt>pdns-recursor</tt>. Sinon les réponses des reqêtes de PC-1 concernant SRV-3 pourraient continuer à être basée sur l'adresse traduisible <tt>fd75:e4d9:cb77:64:c000:303</tt> de SRV-3 mémorisée dans le cache DNS du relais R1. Sur R1 en mode ''root''<br />
r1# '''exit'''<br />
[edit]<br />
vyos@r1# '''sudo su'''<br />
root@r1:/home/vyos# '''service pdns-recursor restart'''<br />
<br />
Sur le client IPv6 PC-1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy <tt>fd75:e4d9:cb77:fff::2</tt>.<br />
<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et SRV-3.<br />
<br />
root@PC-1:~# '''curl -6 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Dans les fenêtres de capture, vous pouvez vérifier que :<br />
* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;<br />
* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;<br />
* après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?<br />
<br />
On constate, de nouveau sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>--interface</tt> de la commande <tt>curl</tt> en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC-1:~# '''curl -6 --interface fd75:e4d9:cb77:1::c1 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
= Conclusion =<br />
<br />
Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement (et uniquement !?) en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'. <br />
<br />
Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.<br />
<br />
=Pour aller plus loin=<br />
<references /></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act46&diff=20548MOOC:Compagnon Act462023-01-17T10:56:22Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
= Activité 46: Faites inter-opérer des applications IPv6 et IPv4=<br />
<br />
Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :<br />
* un Internet en IPv4 encore prépondérant du fait de ses services ;<br />
* un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.<br />
<br />
L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours. <br />
<br />
Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.<br />
<br />
La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :<br />
* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;<br />
* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;<br />
* un routeur R2 en IPv4 : c'est un noeud représentant l'Internet en IPv4 ;<br />
* un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;<br />
* un serveur web IPv4. Ce service sera hébergé sur le noeud SRV-3 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.<br />
<br />
<!--<center><br />
[[image:46-etape0.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center> --><br />
<center><br />
[[image:MoocSession5_act46_topology_20190628.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center><br />
<br />
= Etape 0 : Situation initiale =<br />
<br />
Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.<br />
<!--<br />
Dans la phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Il reste à démarrer les services. Les services hébergés sur PC2 sont le DNS, pour la résolution de noms, et le web. <br />
--><br />
<!--<br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur PC2 les services applicatifs de nommage DNS (<tt>named -c /usr/local/etc/bind/named.conf</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
--><br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur SRV-3 les services applicatifs de nommage DNS (<tt>/usr/sbin/named -u bind</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
<br />
'''Note :''' pour vous loguer sur les stations PC-1, PC-2 et SRV-3, l'identifiant est '''root''' et il n'y a pas de mot de passe (tapez sur 'retour chariot' (''return'' ou Entrée) quand le mot de passe est demandé).<br />
<!--<br />
Activez le service de web sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo nginx'''<br />
<br />
Activez le service de nommage sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo named -c /usr/local/etc/bind/named.conf'''<br />
--><br />
<br />
Pour tester la configuration, il faut d'abord valider le DNS en interrogeant le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
'''''Nota : ''''' ''Dans le cadre de ce TP, les machines PC-1, PC-2, R1, R2 et SRV-3 ont respectivement été enregistrées pc1, pc2, r1, r2 et srv dans le domaine DNS .tp hebergé sur la machine SRV-3.''<br />
<br />
La commande <tt>dig</tt> est disponible sur PC-2. L'adresse du serveur de noms à utiliser dans la commande <tt>dig</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. :<br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp'''<br />
Pour un affichage plus concis vous pouvez ajouter le paramètre <tt>+short</tt><br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp +short'''<br />
<br />
Vous pouvez également vérifier que la résolution de noms fonctionne depuis R1 (en mode utilisateur) à l'aide de la commande <tt>host</tt>. Pour vous connecter en mode utilisateur sur R1 :<br />
<br />
'''''Nota :''''' ''Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).''<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'adresse du serveur de noms à utiliser dans la commande <tt>host</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. La syntaxe de la commande devient alors, sur R1 :<br />
vyos@r1:~$ '''host srv.tp 192.0.3.3'''<br />
<!--<br />
Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2.<br />
--><br />
Vérifiez ensuite le bon fonctionnement du service web de SRV-3 depuis R1, à l'aide de la commande <tt>curl</tt> : <br />
vyos@r1:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Si vous le souhaitez, vous pouvez recommencer la vérification depuis R2. <br />
<br />
Pour cela il vous faut d'abord faire pointer le client DNS de R2 vers SRV-3 en renseignant le fichier de configuration <tt>/etc/resolv.conf</tt>. Passez d’abord en mode ''root'', puis créer le fichier fichier du client DNS, à l'aide de la commande <tt>echo</tt> et en redirigeant la sortie standard vers le fichier à créer.<br />
r2 login: '''vyos'''<br />
Password: <br />
Linux r2 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''echo "nameserver 192.0.3.3" > /etc/resolv.conf'''<br />
root@r2:/home/vyos# '''exit'''<br />
exit<br />
<br />
Vous pouvez ensuite procéder aux tests de la même manière que sur R1.<br />
<br />
vyos@r2:~$ '''host srv.tp'''<br />
vyos@r2:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
La problématique qu'il reste à résoudre se pose dans les termes suivants : comment PC1, qui est en ''IPv6-only'', peut-il accéder au service web <tt>srv.tp</tt> qui est en ''IPv4-only'' ?<br />
<br />
= Etape 1 : Configuration de NAT64/DNS64 =<br />
Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. <br />
<!--Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud en double pile R1.--><br />
La fonction de relais dns auxiliaire DNS64 est maintenant intégrée dans les versions récentes de la pile logicielle DNS Bind9. Elle sera donc assurée par le service de nommage DNS porté par SRV-3. La fonction de traduction NAT64, quant à elle, sera placée sur le nœud en double pile R1.<br />
<br />
Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être 'avec état' ou 'sans état'.<br />
<br />
Le NAT64 que nous allons déployer sur notre plateforme est un traducteur 'sans état'. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction.<br />
Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode 'sans état'. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052.<br />
Ainsi, lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination, adresse qu'il aura apprise en recevant la requête. Comme la traduction d'adresse s'effectue 'sans état', ceci implique que l'adresse IPv4 du client a été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose, parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc, d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 ''IPv4-translatable'' en plus de son adresse IPv6 unicast routable.<br />
<br />
Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64. <br />
Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br />
Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.<br />
<br />
<!--<center><br />
[[Image:46-fig2.png|300px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_dns64_20190628.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_dns64_20210408.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center><br />
<br />
== Allocation d'adresses ==<br />
<br />
Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.<br />
La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.<br />
<!--<center><br />
[[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_step_1_20190628.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_step_1_20210408.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center><br />
<br />
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.<br />
<!--<br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! @ IPv4<br />
! @ IPv6<br />
|-<br />
! rowspan="2" | PC1<br />
| <br />
|<tt> fd75:e4d9:cb77:1::3</tt><br />
|-<br />
| <tt>192.0.3.3</tt><br />
| <tt>fd75:e4d9:cb77:64::192.0.3.3</tt><br />
|- <br />
! rowspan="3" | R1<br />
| <tt>192.0.3.1</tt> <br />
| <tt>fd75:e4d9:cb77:64::192.0.3.1</tt><br />
|-<br />
| <br />
| <tt>fd75:e4d9:cb77:1::1</tt> <br />
|-<br />
| <tt>192.0.2.130</tt><br />
|<br />
|-<br />
! rowspan="2" | R2<br />
| <tt>192.0.2.129</tt><br />
| <br />
|-<br />
| <tt>192.0.2.2</tt><br />
| <br />
|-<br />
! rowspan="1" | PC2<br />
| <tt>192.0.2.1</tt><br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
--><br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! Interface<br />
! @ IPv4<br />
! @ IPv6<br />
|- style="background:silver"<br />
! rowspan="2" | PC-1 <br />
|eth0<br />
|<br />
| '''<tt> fd75:e4d9:cb77:1::c1</tt>'''<br />
|- style="background:silver"<br />
|eth0<br />
| ''<tt>192.0.1.1</tt>''<br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.1</tt>'''<br />
|- <br />
! rowspan="3" | R1<br />
| eth0<br />
|<br />
| '''<tt>fd75:e4d9:cb77:1::1</tt>'''<br />
|-<br />
| eth0<br />
| ''<tt>192.0.1.254/24</tt>'' <br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.254</tt>'''<br />
|-<br />
| eth1<br />
| '''<tt>192.0.0.1/30</tt>'''<br />
|<br />
|- style="background:silver"<br />
! rowspan="3" | R2<br />
| eth1<br />
| '''<tt>192.0.0.2/30</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth0<br />
| '''<tt>192.0.2.254/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth3<br />
| '''<tt>192.0.3.254/24</tt>'''<br />
|<br />
|-<br />
! rowspan="1" | PC-2<br />
| eth0<br />
| '''<tt>192.0.2.2/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
! rowspan="1" | SRV-3<br />
| eth0<br />
| '''<tt>192.0.3.3/24</tt>'''<br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
<br />
Il est à noter que bien que PC-1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 (''IPv4-translatable'') qui sera attribuée à l'interface réseau de PC1. De ce fait, PC-1 aura bien 2 adresses unicast IPv6 routables : une utilisée pour les communications avec des noeuds IPv6 (SID positionné à <tt>1</tt>) et une autre utilisée pour les communications avec des noeuds IPv4 (SID positionné à <tt>64</tt>). L'algorithme du choix de l'adresse source, lorsqu'il a plusieurs adresses IPv6, est défini par le RFC 6724.<br />
Lorsque PC-1 envoie une requête à SRV-3, il utilise, sur le réseau IPv6, comme adresse source : <tt>fd75:e4d9:cb77:64::192.0.1.1</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:101</tt>), et comme adresse de destination : <tt>fd75:e4d9:cb77:64::192.0.3.3</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:303</tt>). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source <tt>192.0.1.1</tt> et destination <tt>192.0.3.3</tt>.<br />
<br />
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.<br />
<br />
== Configuration de PC1 ==<br />
<br />
<!-- Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :<br />
apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:1::3/64'''<br />
--><br />
Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.<br />
root@PC-1~# '''ifconfig eth0'''<br />
Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien. <br />
<!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' --><br />
root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''<br />
Vérifiez votre saisie en affichant de nouveau les adresses de l'interface eth0.<br />
<br />
root@PC-1~# '''ip addr show eth0'''<br />
'''''Nota :''''' ''La notation canonique de la nouvelle adresse que vous venez d'attribuer à l'interface affiche l'adresse IPv4 en hexadécimal avec l'IID <tt>::c000:101</tt>''<br />
<br />
Ensuite, il faudrait théoriquement indiquer une route au préfixe NSP réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC-1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement distinct du routeur. Elle pourrait être positionnée par la commande : <br />
<br />
<tt> route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1</tt><br />
<br />
Dans notre cas, PC-1 n'a pas besoin de route spécifique pour le préfixe NSP IPv6 de traduction puisque la passerelle de traduction NAT64 est elle-même hébergée sur le routeur par défaut pour PC-1.<br />
<br />
<!--<br />
Enfin, renseignez le serveur de noms qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS qui sera configuré par la suite sur R1. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> qui ne contiendra qu'une seule ligne. Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap''). L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
--><br />
Enfin, configurez le client DNS (''resolver'') de PC-1 en renseignant le serveur récursif de proximité qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS récursif qui sera configuré par la suite sur R1 afin de relayer les requêtes vers SRV-3. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> de PC-1 qui ne contiendra qu'une seule ligne.<br />
<br />
'''''Nota :''''' ''Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap'').''<br />
<br />
L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
root@PC-1:~# '''nano -w /etc/resolv.conf'''<br />
et saisissez la ligne ci-dessous avant de sauvegarder le fichier à l'aide de la commande <CTRL+o>, puis de sortir de l'éditeur par <CTRL+x> :<br />
'''nameserver fd75:e4d9:cb77:1::1'''<br />
Vérifiez vote saisie en affichant le contenu du fichier à l'aide de la commande <tt>cat</tt><br />
root@PC-1:~# '''cat /etc/resolv.conf'''<br />
<br />
== Mise en oeuvre du DNS64 sur SRV-3 ==<br />
<br />
<!--<br />
== Mise en oeuvre du DNS64 sur R1 ==<br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel '''TOTD''' (''Trick Or Treat Daemon'') peut également être utilisé pour cet usage. '''TOTD''' est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).<br />
Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. La configuration de NAT64/DNS64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans un mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt> :<br />
vyos@vyos~$ '''exit'''<br />
Pour vous reconnecter en mode ''root'' sur R1 :<br />
login: '''root''' <br />
Password: '''root'''<br />
L'invite de commande dans ce mode est :<br />
root@vyos:~#<br />
Avant de démarrer le service DNS auxiliaire, complétez le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1, éditez le fichier de configuration de '''TOTD''' :<br />
root@vyos:~# '''nano -w /etc/totd.conf'''<br />
pour localiser et renseigner les informations suivantes dans le fichier :<br />
forwarder '''192.0.2.1''' # IPv4 address for name server<br />
prefix '''fd75:e4d9:cb77:64::''' # /96 by default<br />
port '''53'''<br />
<br />
Le ''forwarder'' correspond à l'adresse IPv4 du serveur DNS général. La ligne ''prefix'' indique dans notre cas le NSP qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (''IPv4-converted'').<br />
<br />
Démarrez le logiciel :<br />
root@vyos:~# '''/etc/init.d/totd start'''<br />
<br />
Vérifiez que TOTD ne s'est pas arrêté, en consultant la fin du journal système à l'aide de la commande : <br />
root@vyos:~# '''tail /var/log/messages'''<br />
Vous pouvez également vérifier la présence du processus 'daemon totd' à l'aide de la commande :<br />
root@vyos:~# '''ps -edf | grep totd'''<br />
'''Note :''' le symbole <tt>|</tt> (pipe Unix) est obtenu en appuyant simultanément sur les touches 'Alt Gr' et '6' du clavier azerty de votre PC ou Shift + Alt + L (appui simultané sur les 3 touches) de votre Mac.<br />
<br />
Nous allons vérifier que le serveur DNS contient les bons enregistrements pour les noeuds de cette plateforme. A savoir que PC2 contient bien l'adresse <tt>192.0.2.1</tt>. Aussi ouvrir une session sur PC2 et consulter le fichier <tt>/etc/bind/db.tp</tt><br />
apprenant@MOOCIPv6:~$ '''less /etc/bind/db.tp'''<br />
pour sortir de l'afficheur taper 'q'. Pour faire des modifications ou des ajouts, utiliser votre éditeur de texte. Pour recharger la base de données du serveur dns sur PC2:<br />
apprenant@MOOCIPv6:~$ '''sudo /etc/init.d/bind reload'''<br />
<br />
Vérifier que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande: <tt>{tail /var/log/syslog}</tt>.<br />
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande <tt>/etc/init.d/bind restart</tt>.<br />
--><br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64, tel qu'il est illustré à la figure 2. Sur notre plateforme, c'est le serveur SRV-3 qui supporte à la fois le service DNS et la fonction de DNS64 auxilliaire.<br />
Nous allons passer en revue sa configuration avant de tester son fonctionnement.<br />
Observons le contenu de la base de données du serveur en consultant le fichier ''<tt>/etc/bind/db.tp</tt> à l'aide de la commande <tt>cat</tt><br />
root@SRV-3:/# '''cat /etc/bind/db.tp'''<br />
On constate que certaines ressources sont référencées à la fois en IPv6 et en IPv4 avec des RR (''Resource Record'') de type AAAA et A et d'autres uniquement en IPv4 sous forme de RR de type A.<br />
<br />
Les options de démarrage du serveurs sont fixées dans le fichier ''<tt>/etc/bind/named.conf.options</tt>''<br />
root@SRV-3:/# '''cat /etc/bind/named.conf.options'''<br />
'''Nota''' ''Dans ce fichier, les commentaires sont préfixés par <tt>//</tt> (''double caractères diviseur'').''<br />
<br />
A la fin du fichier vous trouverez les clauses de configuration de la fonction DNS64.<br />
Quel est le préfixe choisi pour la translation ? Pour quels clients cette fonction est elle activée ?<br />
<br />
Avant de procéder aux tests, nous devons activer la fonction de relais récursif DNS de proximité de R1 pour que les requêtes des clients sur le sous réseau Net1 soient relayées vers le serveur DNS SRV-3, en enchaînant les commandes suivantes<br />
vyos@r1$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set service dns forwarding cache-size 0'''<br />
vyos@r1# '''set service dns forwarding listen-address fd75:e4d9:cb77:1::1'''<br />
vyos@r1# '''set service dns forwarding name-server 192.0.3.3'''<br />
vyos@r1# '''commit;save'''<br />
vyos@r1#<br />
<br />
Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC-1. Sur PC-1, demandez l'adresse IPv4 de <tt>srv.tp</tt> de la manière suivante :<br />
root@PC-1:~# '''dig srv.tp +short'''<br />
puis l'adresse IPv6 :<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Observez le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal <tt>c000:303</tt>). L'adresse IPv4 occupe les 32 bits de poids faible (à droite) de l'adresse IPv6 affichée.<br />
<br />
Vous pouvez analyser les échanges en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface <tt>eth0</tt> et sur l'interface <tt>eth1</tt> de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de <tt>srv.tp</tt> en une adresse IPv6 initiée par PC-1.<br />
<!--Ainsi, par l'affichage des messages ''DNS standard query'' et ''DNS standard response'' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.--><br />
<br />
== Mise en oeuvre de NAT64 sur R1==<br />
<br />
'''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''Simple, no fuss NAT64 for Linux'') est une mise en oeuvre libre sous Linux du RFC 6145, la version 'sans état' du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS64 auxiliaire que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.<br />
<br />
'''TAYGA''' est installé sur un routeur en double pile, à savoir R1. Nous allons vérifier en premier lieu que R1 satisfait bien cette condition. La configuration de NAT64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans le mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt>. Pour cela, entrez la commande suivante :<br />
vyos@r1:~# '''exit'''<br />
exit<br />
vyos@r1:~$ '''exit'''<br />
logout<br />
<br />
Welcome to VyOS - r1 ttyS0<br />
Pour vous connecter en mode ''VyOS'' sur R1 :<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright. <br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Pour passer en mode ''root'' sur R1 :<br />
vyos@r1:~$ '''sudo su'''<br />
root@r1:/home/vyos# '''sh interfaces'''<br />
Vous pouvez observer que l'interface <tt>eth0</tt> est bien configurée avec une adresse IPv6 routable et que l'interface <tt>eth1</tt> est configurée avec une adresse IPv4. Ce noeud a bien la capacité de communiquer avec les 2 versions du protocole IP. C'est donc bien un noeud en double pile.<br />
<!--<br />
Il faut que le R1 soit configuré en routeur à savoir que le relayage des paquets soit activé. Ceci s'indique par les drapeaux système:<br />
<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv6/conf/all/forwarding '''<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv4/ip_forward''<br />
<br />
Nous allons commencer par configurer les interfaces réseaux de R1, l'interface <tt>eth0</tt> avec les informations liées à IPv6 et <tt>eth1</tt> à IPv4. Nous allons faire cette configuration toujours en mode root.<br />
<br />
root@vyos~# '''ifconfig eth0 inet6 add fd75:e4d9:cb77:1::1/64'''<br />
root@vyos~# '''ifconfig eth1 192.0.2.130/25'''<br />
<br />
Ensuite il reste à indiquer les routes statiques :<br />
root@vyos~# '''ip route add 192.0.2.0/25 via 192.0.2.129 dev eth1'''<br />
R1 vient d'être configuré en double pile. <br />
<br />
Il reste à configurer le logiciel '''TAYGA''' sur R1 :<br />
--><br />
<br />
La configuration de '''TAYGA''' commence par l'édition de son fichier de configuration<tt>/etc/tayga.conf</tt>. Le fichier ayant été pré-configuré, nous allons nous contenter de vérifier que les paramètres correspondent bien à notre architecture en affichant son contenu à l'aide de la commande <tt>cat</tt>. Aidez vous de votre souris et de l'ascenceur dans la partie droite de la fenêtre pour la navigation. :<br />
root@r1:/home/vyos# '''cat /etc/tayga.conf'''<br />
...<br />
'''tun-device nat64''' # device name for nat64<br />
...<br />
ipv4-addr '''192.0.1.254''' # IPv4 address that TAYGA will use<br />
...<br />
prefix '''fd75:e4d9:cb77:64::/96''' # NSP<br />
...<br />
'''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.<br />
<!--<br />
Configurez les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.2.131/25 dev nat64''' #IPv4 nat64 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::2/64 dev nat64''' #IPv6 nat64 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.3.0/24 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0''' # route to pc1<br />
--><br />
<br />
Configurez l'interface interne logique <tt>nat64</tt> et les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.0.1 dev nat64''' # IPv4 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64''' # IPv6 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64''' # route to IPv6 nodes (nodes with IPv4-tranlsatable address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64''' # global route to IPv4 nodes (nodes with IPv4-converted address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1<br />
'''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''<br />
<br />
'''''Nota 2 :''''' ''Pour les deux commandes d'affectation d'une adresse IPv4 et d'une adresse IPv6 à l'interface interne logique nat64 : <tt>ip addr add 192.0.0.1 dev nat64</tt> et <tt>ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64</tt>'' '''''il ne faut pas indiquer de longueur de préfixe !''''' ''sinon l'interface nat64 prendra la priorité sur l'interface eth1 et l'interface eth0 dans la table de routage pour ces préfixes respectifs et la fonction NAT64 ne fonctionnera pas.''<br />
<br />
Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :<br />
vyos@r2:~$ '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''ip route 192.0.1.0/24 192.0.0.1'''<br />
r2(config)# '''end'''<br />
r2#<br />
<br />
192.0.1.0/24 représente le réseau IPv4 fictif qui est inclus dans l'infrastructure IPv6.<br />
<br />
Démarrez '''TAYGA''' sur '''R1''' :<br />
root@r1:/home/vyos# '''tayga'''<br />
<br />
Le service est maintenant opérationnel. Pour le valider, faites un simple test de connectivité ping depuis PC-1 :<br />
root@PC-1:~# '''ping6 -c 5 srv.tp'''<br />
<br />
Maintenant, testez que le client IPv6 (sur PC-1) accède bien au service web (sur SRV-3) :<br />
root@PC-1:~# '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Relancez ces deux dernières commandes en observant parallèlement avec wireshark les captures des flux de part et d'autre du traducteur '''TAYGA''' ''(lancez parallèlement les captures wireshark sur les liens des interfaces <tt>eth0</tt> et <tt>eth1</tt> de R1)''. Quelles sont les versions du protocoles IP, quelles sont les adresses source et destination des paquets ?<br />
<br />
= Etape 2 : Connectivité IPv6 par tunnel =<br />
Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel. <br />
Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.<br />
Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extrémités du tunnel sont indiqués par la figure 4. --><br />
<br />
<!--<center><br />
[[Image:46-fig4-v2.png|450px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession5_act46_step_2_20190630.png|600px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center><br />
<br />
Avant de passer à la configuration du tunnel, revenez en mode utilisateur sur les routeurs. Sur R1 :<br />
root@r1:/home/vyos# '''exit'''<br />
exit<br />
vyos@r1:~$ <br />
<br />
sur R2: <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
<br />
Pour rappel, l'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :<br />
* La première commande consiste à passer en mode administrateur par <tt>configure</tt>.<br />
* La commande <tt>set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64'</tt> crée une interface de tunnel configuré, dénommée <tt>tun0</tt>. Cette interface est identifiée par une adresse IP. Le tunnel est un lien et, en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.<br />
* Le mode d'encapsulation pour le tunnel est spécifié par la commande <tt>set interfaces tunnel tun0 encapsulation 'sit' </tt>. Le mode SIT (''Simple Internet Transition'') indique une méthode d'encapsulation d'IPv6 dans IPv4.<br />
* La commande <tt>set interfaces tunnel tun0 local-ip '192.0.0.1' </tt> précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.<br />
* La commande <tt>set interfaces tunnel tun0 remote-ip '192.0.0.2' </tt> précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi, un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.<br />
* La commande <tt>set interfaces tunnel tun0 mtu '1480' </tt> précise la taille de la MTU (''Maximum Transmission Unit'') appliquée sur ce tunnel. Par défaut, tous les liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisé qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur laquelle repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit, un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête compris). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins les 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc, pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi, moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.<br />
* Enfin, la commande <tt>commit</tt> valide la séquence des commandes en mode administrateur pour revenir en mode utilisateur.<br />
Dans leur ensemble, les commandes à exécuter sont les suivantes :<br />
vyos@r1:~$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::1/64'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 local-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 remote-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r1# '''commit'''<br />
[edit]<br />
vyos@r1#<br />
<br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r1# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r1.tp# '''show interface'''<br />
<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r1.tp# '''show ipv6 route'''<br />
<br />
Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.<br />
<br />
vyos@r2:~$ '''configure'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::2/64'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 local-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 remote-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r2# '''commit'''<br />
[edit]<br />
vyos@r2# <br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r2# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2.tp# '''show interface'''<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r2.tp# '''show ipv6 route'''<br />
<br />
Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :<br />
<br />
r1# '''ping ipv6 fd75:e4d9:cb77:fff::2'''<br />
<br />
Nota : l'arrêt de la commande <tt>ping</tt> s'effectue par un 'Ctrl + C' (appui simultané sur les touches Ctrl et C).<br />
<br />
Sur une des interfaces Ethernet entre R1 et R2, lancez une capture wireshark pour observer les paquets qui vont transiter par le tunnel. <br />
<br />
Recommencez le test de connectivité depuis PC-1.<br />
<br />
root@PC1:~# '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
<br />
<!--Oups ! cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 a bien une route par défaut :<br />
<br />
apprenant@MOOCIPv6:~$ '''route -A inet6'''<br />
<br />
Qu'en est-il de la route de la réponse à la requête du ping ? Regardez la table de routage sur R2 (en mode Quagga) :<br />
<br />
vyos@vyos:~$ '''vtysh'''<br />
vyos# '''show ipv6 route'''<br />
<br />
R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale, à savoir la route par défaut. En effet, on peut considérer que l'Internet v6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :<br />
<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ::/0 tun0'''<br />
vyos(config)# '''exit'''<br />
Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2<br />
vyos# '''show ipv6 route'''<br />
Recommencez le test de connectivité depuis PC1.<br />
<br />
apprenant@MOOCIPv6:~$ '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
--><br />
Cela fonctionne, la connectivité IPv6 a bien été étendue jusqu'au routeur R2.<br />
<br />
Si vous avez lancé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 encapsulés dans des paquets IPv6, eux-mêmes encapsulés dans des paquets IPv4. Observez les différentes encapsulations : <tt>[Ethernet[IPv4[IPv6[ICMPv6]]]]</tt>. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs, quel est le numéro de protocole utilisé dans l'en-tête IPv4 pour identifier un contenu IPv6 ? <br />
<br />
On constate sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>-I</tt> (''Interface'') de la commande Ping6 en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC1:~# '''ping6 -c 5 -I fd75:e4d9:cb77:1::c1 fd75:e4d9:cb77:fff::2'''<br />
Cela fonctionne également. Observez le changement d'adresse source des paquets émis par PC-1 sur la capture.<br />
<br />
Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.<br />
<br />
= Etape 3 : Configurer un reverse proxy web sur R2 =<br />
Dans cette dernière étape, la base des clients en IPv6 est devenue conséquente. Une connectivité IPv6 arrive jusqu'au réseau du serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'applicatif web soit compatible avec IPv6, surtout s'il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.<br />
<br />
Nous avons vu, dans l'étape 1, qu'un client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible, notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. <br />
Une autre solution existe dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative dite ALG (''Application Layer Gateway''). <br />
<br />
Dans cette étape, nous allons mettre en oeuvre un ''reverse proxy'' web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.<br />
<br />
<!--Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion : <br />
login: '''root'''<br />
password: '''root'''<br />
--><br />
Sur le routeur R2, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt>, ensuite <tt>sudo su</tt>. L'affichage des interfaces, permet de s'assurer de nouveau de la connectivité IPv6 de R2 par son interface <tt>tun0</tt> : <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''sh interfaces'''<br />
<!--<br />
Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive<br />
...<br />
pid /run/nginx.pid<br />
...<br />
par<br />
...<br />
'''pid /var/run/nginx.pid'''<br />
...<br />
à l'aide de l'éditeur nano.<br />
root@vyos:~# '''nano -w /etc/nginx/nginx.conf'''<br />
--><br />
<br />
Vérifiez la configuration "reverse proxy IPv6" de R2 en consultant le fichier <tt>/etc/nginx/sites-available/default</tt> à l'aide de la commande <tt>less</tt>.<br />
<br />
'''''Rappel :''''' ''La commande <tt>less</tt> vous permet d'afficher, sans l'éditer, le contenu d'un fichier texte en naviguant simplement avec les touches de direction du curseur. Pour quitter l'affichage du fichier, appuyez simplement sur la touche 'q' qui signifie "quit". ''<br />
root@r2:/home/vyos# '''less /etc/nginx/sites-available/default'''<br />
<br />
Verifiez d'abord que le serveur reverse-proxy sera bien en écoute sur ses interfaces ipv6 en consultant la clause '''listen''' <br />
...<br />
server {<br />
'''listen [::]:80 default_server;'''<br />
...<br />
Vérifiez ensuite sa configration en mode "reverse-proxy" vers l'adresse du serveur SRV-3 en consultant la clause '''location'''<br />
<br />
...<br />
'''location / {'''<br />
''' proxy_pass http://192.0.3.3/;'''<br />
'''}'''<br />
...<br />
<br />
<!--<br />
'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.<br />
<br />
L'appel de l'éditeur s'effectue par la commande :<br />
root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''<br />
--><br />
Redémarrez le serveur nginx :<br />
root@r2:/home/vyos# '''service nginx restart'''<br />
<br />
Vérifiez l'état du service<br />
root@r2:/home/vyos# '''service nginx status'''<br />
<br />
Le service de DNS doit maintenant identifier le ''reverse proxy'' comme le serveur web en IPv6. Pour cela, sur '''SRV-3''', modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy en ajoutant un <tt>RR AAAA</tt> à la valeur <tt>fd75:e4d9:cb77:fff::2</tt> <br />
<br />
root@SRV-3:/# '''nano -w /etc/bind/db.tp'''<br />
...<br />
srv IN A 192.0.3.3<br />
'''IN AAAA fd75:e4d9:cb77:fff::2'''<br />
;<br />
<br />
Relancez le serveur <tt>named</tt>. Pour cela, validez d'abord votre nouvelle configuration à l'aide de la commande <tt> named-checkconf -z</tt>. Si tout est correct, relancez le service à l'aide de la commande <tt>service bind9 restart</tt>:<br />
<br />
root@SRV-3:/# '''named-checkconf -z'''<br />
...<br />
root@SRV-3:/# '''service bind9 restart'''<br />
...<br />
[ ok ] Starting domain name service...: bind9.<br />
Verifiez l'état du service<br />
root@SRV-3:/# '''service bind9 status''' <br />
Sur le relais DNS de R1, afin de réinitialiser le cache DNS, rédemarrez le service <tt>pdns-recursor</tt>. Sinon les réponses des reqêtes de PC-1 concernant SRV-3 pourraient continuer à être basée sur l'adresse traduisible <tt>fd75:e4d9:cb77:64:c000:303</tt> de SRV-3 mémorisée dans le cache DNS du relais R1. Sur R1 en mode ''root''<br />
r1# '''exit'''<br />
[edit]<br />
vyos@r1# '''sudo su'''<br />
root@r1:/home/vyos# '''service pdns-recursor restart'''<br />
<br />
Sur le client IPv6 PC-1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy <tt>fd75:e4d9:cb77:fff::2</tt>.<br />
<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et SRV-3.<br />
<br />
root@PC-1:~# '''curl -6 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Dans les fenêtres de capture, vous pouvez vérifier que :<br />
* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;<br />
* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;<br />
* après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?<br />
<br />
On constate, de nouveau sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>--interface</tt> de la commande <tt>curl</tt> en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC-1:~# '''curl -6 --interface fd75:e4d9:cb77:1::c1 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
= Conclusion =<br />
<br />
Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement (et uniquement !?) en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'. <br />
<br />
Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.<br />
<br />
=Pour aller plus loin=<br />
<references /></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act46&diff=20547MOOC:Compagnon Act462023-01-17T10:54:48Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
= Activité 46: Faites inter-opérer des applications IPv6 et IPv4=<br />
<br />
Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :<br />
* un Internet en IPv4 encore prépondérant du fait de ses services ;<br />
* un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.<br />
<br />
L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours. <br />
<br />
Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.<br />
<br />
La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :<br />
* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;<br />
* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;<br />
* un routeur R2 en IPv4 : c'est un noeud représentant l'Internet en IPv4 ;<br />
* un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;<br />
* un serveur web IPv4. Ce service sera hébergé sur le noeud SRV-3 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.<br />
<br />
<!--<center><br />
[[image:46-etape0.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center> --><br />
<center><br />
[[image:MoocSession5_act46_topology_20190628.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center><br />
<br />
= Etape 0 : Situation initiale =<br />
<br />
Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.<br />
<!--<br />
Dans la phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Il reste à démarrer les services. Les services hébergés sur PC2 sont le DNS, pour la résolution de noms, et le web. <br />
--><br />
<!--<br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur PC2 les services applicatifs de nommage DNS (<tt>named -c /usr/local/etc/bind/named.conf</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
--><br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur SRV-3 les services applicatifs de nommage DNS (<tt>/usr/sbin/named -u bind</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
<br />
'''Note :''' pour vous loguer sur les stations PC-1, PC-2 et SRV-3, l'identifiant est '''root''' et il n'y a pas de mot de passe (tapez sur 'retour chariot' (''return'' ou Entrée) quand le mot de passe est demandé).<br />
<!--<br />
Activez le service de web sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo nginx'''<br />
<br />
Activez le service de nommage sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo named -c /usr/local/etc/bind/named.conf'''<br />
--><br />
<br />
Pour tester la configuration, il faut d'abord valider le DNS en interrogeant le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
'''''Nota : ''''' ''Dans le cadre de ce TP, les machines PC-1, PC-2, R1, R2 et SRV-3 ont respectivement été enregistrées pc1, pc2, r1, r2 et srv dans le domaine DNS .tp hebergé sur la machine SRV-3.''<br />
<br />
La commande <tt>dig</tt> est disponible sur PC-2. L'adresse du serveur de noms à utiliser dans la commande <tt>dig</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. :<br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp'''<br />
Pour un affichage plus concis vous pouvez ajouter le paramètre <tt>+short</tt><br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp +short'''<br />
<br />
Vous pouvez également vérifier que la résolution de noms fonctionne depuis R1 (en mode utilisateur) à l'aide de la commande <tt>host</tt>. Pour vous connecter en mode utilisateur sur R1 :<br />
<br />
'''''Nota :''''' ''Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).''<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'adresse du serveur de noms à utiliser dans la commande <tt>host</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. La syntaxe de la commande devient alors, sur R1 :<br />
vyos@r1:~$ '''host srv.tp 192.0.3.3'''<br />
<!--<br />
Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2.<br />
--><br />
Vérifiez ensuite le bon fonctionnement du service web de SRV-3 depuis R1, à l'aide de la commande <tt>curl</tt> : <br />
vyos@r1:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Si vous le souhaitez, vous pouvez recommencer la vérification depuis R2. <br />
<br />
Pour cela il vous faut d'abord faire pointer le client DNS de R2 vers SRV-3 en renseignant le fichier de configuration <tt>/etc/resolv.conf</tt>. Passez d’abord en mode ''root'', puis créer le fichier fichier du client DNS, à l'aide de la commande <tt>echo</tt> et en redirigeant la sortie standard vers le fichier à créer.<br />
r2 login: '''vyos'''<br />
Password: <br />
Linux r2 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''echo "nameserver 192.0.3.3" > /etc/resolv.conf'''<br />
root@r2:/home/vyos# '''exit'''<br />
exit<br />
<br />
Vous pouvez ensuite procéder aux tests de la même manière que sur R1.<br />
<br />
vyos@r2:~$ '''host srv.tp'''<br />
vyos@r2:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
La problématique qu'il reste à résoudre se pose dans les termes suivants : comment PC1, qui est en ''IPv6-only'', peut-il accéder au service web <tt>srv.tp</tt> qui est en ''IPv4-only'' ?<br />
<br />
= Etape 1 : Configuration de NAT64/DNS64 =<br />
Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. <br />
<!--Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud en double pile R1.--><br />
La fonction de relais dns auxiliaire DNS64 est maintenant intégrée dans les versions récentes de la pile logicielle DNS Bind9. Elle sera donc assurée par le service de nommage DNS porté par SRV-3. La fonction de traduction NAT64, quant à elle, sera placée sur le nœud en double pile R1.<br />
<br />
Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être 'avec état' ou 'sans état'.<br />
<br />
Le NAT64 que nous allons déployer sur notre plateforme est un traducteur 'sans état'. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction.<br />
Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode 'sans état'. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052.<br />
Ainsi, lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination, adresse qu'il aura apprise en recevant la requête. Comme la traduction d'adresse s'effectue 'sans état', ceci implique que l'adresse IPv4 du client a été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose, parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc, d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 ''IPv4-translatable'' en plus de son adresse IPv6 unicast routable.<br />
<br />
Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64. <br />
Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br />
Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.<br />
<br />
<!--<center><br />
[[Image:46-fig2.png|300px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_dns64_20190628.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_dns64_20210408.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center><br />
<br />
== Allocation d'adresses ==<br />
<br />
Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.<br />
La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.<br />
<!--<center><br />
[[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_step_1_20190628.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_step_1_20210408.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center><br />
<br />
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.<br />
<!--<br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! @ IPv4<br />
! @ IPv6<br />
|-<br />
! rowspan="2" | PC1<br />
| <br />
|<tt> fd75:e4d9:cb77:1::3</tt><br />
|-<br />
| <tt>192.0.3.3</tt><br />
| <tt>fd75:e4d9:cb77:64::192.0.3.3</tt><br />
|- <br />
! rowspan="3" | R1<br />
| <tt>192.0.3.1</tt> <br />
| <tt>fd75:e4d9:cb77:64::192.0.3.1</tt><br />
|-<br />
| <br />
| <tt>fd75:e4d9:cb77:1::1</tt> <br />
|-<br />
| <tt>192.0.2.130</tt><br />
|<br />
|-<br />
! rowspan="2" | R2<br />
| <tt>192.0.2.129</tt><br />
| <br />
|-<br />
| <tt>192.0.2.2</tt><br />
| <br />
|-<br />
! rowspan="1" | PC2<br />
| <tt>192.0.2.1</tt><br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
--><br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! Interface<br />
! @ IPv4<br />
! @ IPv6<br />
|- style="background:silver"<br />
! rowspan="2" | PC-1 <br />
|eth0<br />
|<br />
| '''<tt> fd75:e4d9:cb77:1::c1</tt>'''<br />
|- style="background:silver"<br />
|eth0<br />
| ''<tt>192.0.1.1</tt>''<br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.1</tt>'''<br />
|- <br />
! rowspan="3" | R1<br />
| eth0<br />
|<br />
| '''<tt>fd75:e4d9:cb77:1::1</tt>'''<br />
|-<br />
| eth0<br />
| ''<tt>192.0.1.254/24</tt>'' <br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.254</tt>'''<br />
|-<br />
| eth1<br />
| '''<tt>192.0.0.1/30</tt>'''<br />
|<br />
|- style="background:silver"<br />
! rowspan="3" | R2<br />
| eth1<br />
| '''<tt>192.0.0.2/30</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth0<br />
| '''<tt>192.0.2.254/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth3<br />
| '''<tt>192.0.3.254/24</tt>'''<br />
|<br />
|-<br />
! rowspan="1" | PC-2<br />
| eth0<br />
| '''<tt>192.0.2.2/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
! rowspan="1" | SRV-3<br />
| eth0<br />
| '''<tt>192.0.3.3/24</tt>'''<br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
<br />
Il est à noter que bien que PC-1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 (''IPv4-translatable'') qui sera attribuée à l'interface réseau de PC1. De ce fait, PC-1 aura bien 2 adresses unicast IPv6 routables : une utilisée pour les communications avec des noeuds IPv6 (SID positionné à <tt>1</tt>) et une autre utilisée pour les communications avec des noeuds IPv4 (SID positionné à <tt>64</tt>). L'algorithme du choix de l'adresse source, lorsqu'il a plusieurs adresses IPv6, est défini par le RFC 6724.<br />
Lorsque PC-1 envoie une requête à SRV-3, il utilise, sur le réseau IPv6, comme adresse source : <tt>fd75:e4d9:cb77:64::192.0.1.1</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:101</tt>), et comme adresse de destination : <tt>fd75:e4d9:cb77:64::192.0.3.3</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:303</tt>). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source <tt>192.0.1.1</tt> et destination <tt>192.0.3.3</tt>.<br />
<br />
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.<br />
<br />
== Configuration de PC1 ==<br />
<br />
<!-- Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :<br />
apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:1::3/64'''<br />
--><br />
Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.<br />
root@PC-1~# '''ifconfig eth0'''<br />
Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien. <br />
<!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' --><br />
root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''<br />
Vérifiez votre saisie en affichant de nouveau les adresses de l'interface eth0.<br />
<br />
root@PC-1~# '''ip addr show eth0'''<br />
'''''Nota :''''' ''La notation canonique de la nouvelle adresse que vous venez d'attribuer à l'interface affiche l'adresse IPv4 en hexadécimal avec l'IID <tt>::c000:101</tt>''<br />
<br />
Ensuite, il faudrait théoriquement indiquer une route au préfixe NSP réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC-1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement distinct du routeur. Elle pourrait être positionnée par la commande : <br />
<br />
<tt> route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1</tt><br />
<br />
Dans notre cas, PC-1 n'a pas besoin de route spécifique pour le préfixe NSP IPv6 de traduction puisque la passerelle de traduction NAT64 est elle-même hébergée sur le routeur par défaut pour PC-1.<br />
<br />
<!--<br />
Enfin, renseignez le serveur de noms qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS qui sera configuré par la suite sur R1. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> qui ne contiendra qu'une seule ligne. Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap''). L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
--><br />
Enfin, configurez le client DNS (''resolver'') de PC-1 en renseignant le serveur récursif de proximité qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS récursif qui sera configuré par la suite sur R1 afin de relayer les requêtes vers SRV-3. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> de PC-1 qui ne contiendra qu'une seule ligne.<br />
<br />
'''''Nota :''''' ''Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap'').''<br />
<br />
L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
root@PC-1:~# '''nano -w /etc/resolv.conf'''<br />
et saisissez la ligne ci-dessous avant de sauvegarder le fichier à l'aide de la commande <CTRL+o>, puis de sortir de l'éditeur par <CTRL+x> :<br />
'''nameserver fd75:e4d9:cb77:1::1'''<br />
Vérifiez vote saisie en affichant le contenu du fichier à l'aide de la commande <tt>cat</tt><br />
root@PC-1:~# '''cat /etc/resolv.conf'''<br />
<br />
== Mise en oeuvre du DNS64 sur SRV-3 ==<br />
<br />
<!--<br />
== Mise en oeuvre du DNS64 sur R1 ==<br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel '''TOTD''' (''Trick Or Treat Daemon'') peut également être utilisé pour cet usage. '''TOTD''' est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).<br />
Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. La configuration de NAT64/DNS64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans un mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt> :<br />
vyos@vyos~$ '''exit'''<br />
Pour vous reconnecter en mode ''root'' sur R1 :<br />
login: '''root''' <br />
Password: '''root'''<br />
L'invite de commande dans ce mode est :<br />
root@vyos:~#<br />
Avant de démarrer le service DNS auxiliaire, complétez le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1, éditez le fichier de configuration de '''TOTD''' :<br />
root@vyos:~# '''nano -w /etc/totd.conf'''<br />
pour localiser et renseigner les informations suivantes dans le fichier :<br />
forwarder '''192.0.2.1''' # IPv4 address for name server<br />
prefix '''fd75:e4d9:cb77:64::''' # /96 by default<br />
port '''53'''<br />
<br />
Le ''forwarder'' correspond à l'adresse IPv4 du serveur DNS général. La ligne ''prefix'' indique dans notre cas le NSP qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (''IPv4-converted'').<br />
<br />
Démarrez le logiciel :<br />
root@vyos:~# '''/etc/init.d/totd start'''<br />
<br />
Vérifiez que TOTD ne s'est pas arrêté, en consultant la fin du journal système à l'aide de la commande : <br />
root@vyos:~# '''tail /var/log/messages'''<br />
Vous pouvez également vérifier la présence du processus 'daemon totd' à l'aide de la commande :<br />
root@vyos:~# '''ps -edf | grep totd'''<br />
'''Note :''' le symbole <tt>|</tt> (pipe Unix) est obtenu en appuyant simultanément sur les touches 'Alt Gr' et '6' du clavier azerty de votre PC ou Shift + Alt + L (appui simultané sur les 3 touches) de votre Mac.<br />
<br />
Nous allons vérifier que le serveur DNS contient les bons enregistrements pour les noeuds de cette plateforme. A savoir que PC2 contient bien l'adresse <tt>192.0.2.1</tt>. Aussi ouvrir une session sur PC2 et consulter le fichier <tt>/etc/bind/db.tp</tt><br />
apprenant@MOOCIPv6:~$ '''less /etc/bind/db.tp'''<br />
pour sortir de l'afficheur taper 'q'. Pour faire des modifications ou des ajouts, utiliser votre éditeur de texte. Pour recharger la base de données du serveur dns sur PC2:<br />
apprenant@MOOCIPv6:~$ '''sudo /etc/init.d/bind reload'''<br />
<br />
Vérifier que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande: <tt>{tail /var/log/syslog}</tt>.<br />
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande <tt>/etc/init.d/bind restart</tt>.<br />
--><br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64, tel qu'il est illustré à la figure 2. Sur notre plateforme, c'est le serveur SRV-3 qui supporte à la fois le service DNS et la fonction de DNS64 auxilliaire.<br />
Nous allons passer en revue sa configuration avant de tester son fonctionnement.<br />
Observons le contenu de la base de données du serveur en consultant le fichier ''<tt>/etc/bind/db.tp</tt> à l'aide de la commande <tt>cat</tt><br />
root@SRV-3:/# '''cat /etc/bind/db.tp'''<br />
On constate que certaines ressources sont référencées à la fois en IPv6 et en IPv4 avec des RR (''Resource Record'') de type AAAA et A et d'autres uniquement en IPv4 sous forme de RR de type A.<br />
<br />
Les options de démarrage du serveurs sont fixées dans le fichier ''<tt>/etc/bind/named.conf.options</tt>''<br />
root@SRV-3:/# '''cat /etc/bind/named.conf.options'''<br />
'''Nota''' ''Dans ce fichier, les commentaires sont préfixés par <tt>//</tt> (''double caractères diviseur'').''<br />
<br />
A la fin du fichier vous trouverez les clauses de configuration de la fonction DNS64.<br />
Quel est le préfixe choisi pour la translation ? Pour quels clients cette fonction est elle activée ?<br />
<br />
Avant de procéder aux tests, nous devons activer la fonction de relais récursif DNS de proximité de R1 pour que les requêtes des clients sur le sous réseau Net1 soient relayées vers le serveur DNS SRV-3, en enchaînant les commandes suivantes<br />
vyos@r1$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set service dns forwarding cache-size 0'''<br />
vyos@r1# '''set service dns forwarding listen-address fd75:e4d9:cb77:1::1'''<br />
vyos@r1# '''set service dns forwarding name-server 192.0.3.3'''<br />
vyos@r1# '''commit;save'''<br />
vyos@r1#<br />
<br />
Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC-1. Sur PC-1, demandez l'adresse IPv4 de <tt>srv.tp</tt> de la manière suivante :<br />
root@PC-1:~# '''dig srv.tp +short'''<br />
puis l'adresse IPv6 :<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Observez le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal <tt>c000:303</tt>). L'adresse IPv4 occupe les 32 bits de poids faible (à droite) de l'adresse IPv6 affichée.<br />
<br />
Vous pouvez analyser les échanges en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface <tt>eth0</tt> et sur l'interface <tt>eth1</tt> de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de <tt>srv.tp</tt> en une adresse IPv6 initiée par PC-1.<br />
<!--Ainsi, par l'affichage des messages ''DNS standard query'' et ''DNS standard response'' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.--><br />
<br />
== Mise en oeuvre de NAT64 sur R1==<br />
<br />
'''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''Simple, no fuss NAT64 for Linux'') est une mise en oeuvre libre sous Linux du RFC 6145, la version 'sans état' du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS64 auxiliaire que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.<br />
<br />
'''TAYGA''' est installé sur un routeur en double pile, à savoir R1. Nous allons vérifier en premier lieu que R1 satisfait bien cette condition. La configuration de NAT64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans le mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt>. Pour cela, entrez la commande suivante :<br />
vyos@r1:~# '''exit'''<br />
exit<br />
vyos@r1:~$ '''exit'''<br />
logout<br />
<br />
Welcome to VyOS - r1 ttyS0<br />
Pour vous connecter en mode ''VyOS'' sur R1 :<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright. <br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Pour passer en mode ''root'' sur R1 :<br />
vyos@r1:~$ '''sudo su'''<br />
root@r1:/home/vyos# '''sh interfaces'''<br />
Vous pouvez observer que l'interface <tt>eth0</tt> est bien configurée avec une adresse IPv6 routable et que l'interface <tt>eth1</tt> est configurée avec une adresse IPv4. Ce noeud a bien la capacité de communiquer avec les 2 versions du protocole IP. C'est donc bien un noeud en double pile.<br />
<!--<br />
Il faut que le R1 soit configuré en routeur à savoir que le relayage des paquets soit activé. Ceci s'indique par les drapeaux système:<br />
<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv6/conf/all/forwarding '''<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv4/ip_forward''<br />
<br />
Nous allons commencer par configurer les interfaces réseaux de R1, l'interface <tt>eth0</tt> avec les informations liées à IPv6 et <tt>eth1</tt> à IPv4. Nous allons faire cette configuration toujours en mode root.<br />
<br />
root@vyos~# '''ifconfig eth0 inet6 add fd75:e4d9:cb77:1::1/64'''<br />
root@vyos~# '''ifconfig eth1 192.0.2.130/25'''<br />
<br />
Ensuite il reste à indiquer les routes statiques :<br />
root@vyos~# '''ip route add 192.0.2.0/25 via 192.0.2.129 dev eth1'''<br />
R1 vient d'être configuré en double pile. <br />
<br />
Il reste à configurer le logiciel '''TAYGA''' sur R1 :<br />
--><br />
<br />
La configuration de '''TAYGA''' commence par l'édition de son fichier de configuration<tt>/etc/tayga.conf</tt>. Le fichier ayant été pré-configuré, nous allons nous contenter de vérifier que les paramètres correspondent bien à notre architecture en affichant son contenu à l'aide de la commande <tt>cat</tt>. Aidez vous de votre souris et de l'ascenceur dans la partie droite de la fenêtre pour la navigation. :<br />
root@r1:/home/vyos# '''cat /etc/tayga.conf'''<br />
...<br />
'''tun-device nat64''' # device name for nat64<br />
...<br />
ipv4-addr '''192.0.1.254''' # IPv4 address that TAYGA will use<br />
...<br />
prefix '''fd75:e4d9:cb77:64::/96''' # NSP<br />
...<br />
'''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.<br />
<!--<br />
Configurez les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.2.131/25 dev nat64''' #IPv4 nat64 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::2/64 dev nat64''' #IPv6 nat64 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.3.0/24 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0''' # route to pc1<br />
--><br />
<br />
Configurez l'interface interne logique <tt>nat64</tt> et les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.0.1 dev nat64''' # IPv4 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64''' # IPv6 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64''' # route to IPv6 nodes (nodes with IPv4-tranlsatable address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64''' # global route to IPv4 nodes (nodes with IPv4-converted address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1<br />
'''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''<br />
<br />
'''''Nota 2 :''''' ''Pour les deux commandes d'affectation d'une adresse IPv4 et d'une adresse IPv6 à l'interface interne logique nat64 : <tt>ip addr add 192.0.0.1 dev nat64</tt> et <tt>ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64</tt>'' '''''il ne faut pas indiquer de longueur de préfixe !''''' ''sinon l'interface nat64 prendra la priorité sur l'interface eth1 et l'interface eth0 dans la table de routage pour ces préfixes respectifs et la fonction NAT64 ne fonctionnera pas.''<br />
<br />
Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :<br />
vyos@r2:~$ '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''ip route 192.0.1.0/24 192.0.0.1'''<br />
r2(config)# '''end'''<br />
r2#<br />
<br />
192.0.1.0/24 représente le réseau IPv4 fictif qui est inclus dans l'infrastructure IPv6.<br />
<br />
Démarrez '''TAYGA''' sur '''R1''' :<br />
root@r1:/home/vyos# '''tayga'''<br />
<br />
Le service est maintenant opérationnel. Pour le valider, faites un simple test de connectivité ping depuis PC-1 :<br />
root@PC-1:~# '''ping6 -c 5 srv.tp'''<br />
<br />
Maintenant, testez que le client IPv6 (sur PC-1) accède bien au service web (sur SRV-3) :<br />
root@PC-1:~# '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Relancez ces deux dernières commandes en observant parallèlement avec wireshark les captures des flux de part et d'autre du traducteur '''TAYGA''' ''(lancez parallèlement les captures wireshark sur les liens des interfaces <tt>eth0</tt> et <tt>eth1</tt> de R1)''. Quelles sont les versions du protocoles IP, quelles sont les adresses source et destination des paquets ?<br />
<br />
= Etape 2 : Connectivité IPv6 par tunnel =<br />
Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel. <br />
Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.<br />
Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extrémités du tunnel sont indiqués par la figure 4. --><br />
<br />
<!--<center><br />
[[Image:46-fig4-v2.png|450px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession5_act46_step_2_20190630.png|600px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center><br />
<br />
Avant de passer à la configuration du tunnel, revenez en mode utilisateur sur les routeurs. Sur R1 :<br />
root@r1:/home/vyos# '''exit'''<br />
exit<br />
vyos@r1:~$ <br />
<br />
sur R2: <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
<br />
Pour rappel, l'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :<br />
* La première commande consiste à passer en mode administrateur par <tt>configure</tt>.<br />
* La commande <tt>set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64'</tt> crée une interface de tunnel configuré, dénommée <tt>tun0</tt>. Cette interface est identifiée par une adresse IP. Le tunnel est un lien et, en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.<br />
* Le mode d'encapsulation pour le tunnel est spécifié par la commande <tt>set interfaces tunnel tun0 encapsulation 'sit' </tt>. Le mode SIT (''Simple Internet Transition'') indique une méthode d'encapsulation d'IPv6 dans IPv4.<br />
* La commande <tt>set interfaces tunnel tun0 local-ip '192.0.0.1' </tt> précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.<br />
* La commande <tt>set interfaces tunnel tun0 remote-ip '192.0.0.2' </tt> précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi, un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.<br />
* La commande <tt>set interfaces tunnel tun0 mtu '1480' </tt> précise la taille de la MTU (''Maximum Transmission Unit'') appliquée sur ce tunnel. Par défaut, tous les liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisé qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur laquelle repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit, un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête compris). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins les 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc, pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi, moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.<br />
* Enfin, la commande <tt>commit</tt> valide la séquence des commandes en mode administrateur pour revenir en mode utilisateur.<br />
Dans leur ensemble, les commandes à exécuter sont les suivantes :<br />
vyos@r1:~$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::1/64'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 local-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 remote-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r1# '''commit'''<br />
[edit]<br />
vyos@r1#<br />
<br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r1# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r1.tp# '''show interface'''<br />
<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r1.tp# '''show ipv6 route'''<br />
<br />
Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.<br />
<br />
vyos@r2:~$ '''configure'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::2/64'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 local-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 remote-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r2# '''commit'''<br />
[edit]<br />
vyos@r2# <br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r2# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''show interface'''<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r2# '''show ipv6 route'''<br />
<br />
Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :<br />
<br />
r1# '''ping ipv6 fd75:e4d9:cb77:fff::2'''<br />
<br />
Nota : l'arrêt de la commande <tt>ping</tt> s'effectue par un 'Ctrl + C' (appui simultané sur les touches Ctrl et C).<br />
<br />
Sur une des interfaces Ethernet entre R1 et R2, lancez une capture wireshark pour observer les paquets qui vont transiter par le tunnel. <br />
<br />
Recommencez le test de connectivité depuis PC-1.<br />
<br />
root@PC1:~# '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
<br />
<!--Oups ! cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 a bien une route par défaut :<br />
<br />
apprenant@MOOCIPv6:~$ '''route -A inet6'''<br />
<br />
Qu'en est-il de la route de la réponse à la requête du ping ? Regardez la table de routage sur R2 (en mode Quagga) :<br />
<br />
vyos@vyos:~$ '''vtysh'''<br />
vyos# '''show ipv6 route'''<br />
<br />
R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale, à savoir la route par défaut. En effet, on peut considérer que l'Internet v6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :<br />
<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ::/0 tun0'''<br />
vyos(config)# '''exit'''<br />
Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2<br />
vyos# '''show ipv6 route'''<br />
Recommencez le test de connectivité depuis PC1.<br />
<br />
apprenant@MOOCIPv6:~$ '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
--><br />
Cela fonctionne, la connectivité IPv6 a bien été étendue jusqu'au routeur R2.<br />
<br />
Si vous avez lancé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 encapsulés dans des paquets IPv6, eux-mêmes encapsulés dans des paquets IPv4. Observez les différentes encapsulations : <tt>[Ethernet[IPv4[IPv6[ICMPv6]]]]</tt>. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs, quel est le numéro de protocole utilisé dans l'en-tête IPv4 pour identifier un contenu IPv6 ? <br />
<br />
On constate sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>-I</tt> (''Interface'') de la commande Ping6 en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC1:~# '''ping6 -c 5 -I fd75:e4d9:cb77:1::c1 fd75:e4d9:cb77:fff::2'''<br />
Cela fonctionne également. Observez le changement d'adresse source des paquets émis par PC-1 sur la capture.<br />
<br />
Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.<br />
<br />
= Etape 3 : Configurer un reverse proxy web sur R2 =<br />
Dans cette dernière étape, la base des clients en IPv6 est devenue conséquente. Une connectivité IPv6 arrive jusqu'au réseau du serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'applicatif web soit compatible avec IPv6, surtout s'il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.<br />
<br />
Nous avons vu, dans l'étape 1, qu'un client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible, notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. <br />
Une autre solution existe dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative dite ALG (''Application Layer Gateway''). <br />
<br />
Dans cette étape, nous allons mettre en oeuvre un ''reverse proxy'' web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.<br />
<br />
<!--Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion : <br />
login: '''root'''<br />
password: '''root'''<br />
--><br />
Sur le routeur R2, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt>, ensuite <tt>sudo su</tt>. L'affichage des interfaces, permet de s'assurer de nouveau de la connectivité IPv6 de R2 par son interface <tt>tun0</tt> : <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''sh interfaces'''<br />
<!--<br />
Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive<br />
...<br />
pid /run/nginx.pid<br />
...<br />
par<br />
...<br />
'''pid /var/run/nginx.pid'''<br />
...<br />
à l'aide de l'éditeur nano.<br />
root@vyos:~# '''nano -w /etc/nginx/nginx.conf'''<br />
--><br />
<br />
Vérifiez la configuration "reverse proxy IPv6" de R2 en consultant le fichier <tt>/etc/nginx/sites-available/default</tt> à l'aide de la commande <tt>less</tt>.<br />
<br />
'''''Rappel :''''' ''La commande <tt>less</tt> vous permet d'afficher, sans l'éditer, le contenu d'un fichier texte en naviguant simplement avec les touches de direction du curseur. Pour quitter l'affichage du fichier, appuyez simplement sur la touche 'q' qui signifie "quit". ''<br />
root@r2:/home/vyos# '''less /etc/nginx/sites-available/default'''<br />
<br />
Verifiez d'abord que le serveur reverse-proxy sera bien en écoute sur ses interfaces ipv6 en consultant la clause '''listen''' <br />
...<br />
server {<br />
'''listen [::]:80 default_server;'''<br />
...<br />
Vérifiez ensuite sa configration en mode "reverse-proxy" vers l'adresse du serveur SRV-3 en consultant la clause '''location'''<br />
<br />
...<br />
'''location / {'''<br />
''' proxy_pass http://192.0.3.3/;'''<br />
'''}'''<br />
...<br />
<br />
<!--<br />
'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.<br />
<br />
L'appel de l'éditeur s'effectue par la commande :<br />
root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''<br />
--><br />
Redémarrez le serveur nginx :<br />
root@r2:/home/vyos# '''service nginx restart'''<br />
<br />
Vérifiez l'état du service<br />
root@r2:/home/vyos# '''service nginx status'''<br />
<br />
Le service de DNS doit maintenant identifier le ''reverse proxy'' comme le serveur web en IPv6. Pour cela, sur '''SRV-3''', modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy en ajoutant un <tt>RR AAAA</tt> à la valeur <tt>fd75:e4d9:cb77:fff::2</tt> <br />
<br />
root@SRV-3:/# '''nano -w /etc/bind/db.tp'''<br />
...<br />
srv IN A 192.0.3.3<br />
'''IN AAAA fd75:e4d9:cb77:fff::2'''<br />
;<br />
<br />
Relancez le serveur <tt>named</tt>. Pour cela, validez d'abord votre nouvelle configuration à l'aide de la commande <tt> named-checkconf -z</tt>. Si tout est correct, relancez le service à l'aide de la commande <tt>service bind9 restart</tt>:<br />
<br />
root@SRV-3:/# '''named-checkconf -z'''<br />
...<br />
root@SRV-3:/# '''service bind9 restart'''<br />
...<br />
[ ok ] Starting domain name service...: bind9.<br />
Verifiez l'état du service<br />
root@SRV-3:/# '''service bind9 status''' <br />
Sur le relais DNS de R1, afin de réinitialiser le cache DNS, rédemarrez le service <tt>pdns-recursor</tt>. Sinon les réponses des reqêtes de PC-1 concernant SRV-3 pourraient continuer à être basée sur l'adresse traduisible <tt>fd75:e4d9:cb77:64:c000:303</tt> de SRV-3 mémorisée dans le cache DNS du relais R1. Sur R1 en mode ''root''<br />
r1# '''exit'''<br />
[edit]<br />
vyos@r1# '''sudo su'''<br />
root@r1:/home/vyos# '''service pdns-recursor restart'''<br />
<br />
Sur le client IPv6 PC-1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy <tt>fd75:e4d9:cb77:fff::2</tt>.<br />
<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et SRV-3.<br />
<br />
root@PC-1:~# '''curl -6 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Dans les fenêtres de capture, vous pouvez vérifier que :<br />
* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;<br />
* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;<br />
* après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?<br />
<br />
On constate, de nouveau sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>--interface</tt> de la commande <tt>curl</tt> en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC-1:~# '''curl -6 --interface fd75:e4d9:cb77:1::c1 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
= Conclusion =<br />
<br />
Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement (et uniquement !?) en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'. <br />
<br />
Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.<br />
<br />
=Pour aller plus loin=<br />
<references /></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act46&diff=20546MOOC:Compagnon Act462023-01-17T10:38:23Z<p>Jlandru: /* Etape 2 : Connectivité IPv6 par tunnel */</p>
<hr />
<div>__NOTOC__<br />
= Activité 46: Faites inter-opérer des applications IPv6 et IPv4=<br />
<br />
Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :<br />
* un Internet en IPv4 encore prépondérant du fait de ses services ;<br />
* un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.<br />
<br />
L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours. <br />
<br />
Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.<br />
<br />
La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :<br />
* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;<br />
* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;<br />
* un routeur R2 en IPv4 : c'est un noeud représentant l'Internet en IPv4 ;<br />
* un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;<br />
* un serveur web IPv4. Ce service sera hébergé sur le noeud SRV-3 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.<br />
<br />
<!--<center><br />
[[image:46-etape0.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center> --><br />
<center><br />
[[image:MoocSession5_act46_topology_20190628.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center><br />
<br />
= Etape 0 : Situation initiale =<br />
<br />
Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.<br />
<!--<br />
Dans la phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Il reste à démarrer les services. Les services hébergés sur PC2 sont le DNS, pour la résolution de noms, et le web. <br />
--><br />
<!--<br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur PC2 les services applicatifs de nommage DNS (<tt>named -c /usr/local/etc/bind/named.conf</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
--><br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur SRV-3 les services applicatifs de nommage DNS (<tt>/usr/sbin/named -u bind</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
<br />
'''Note :''' pour vous loguer sur les stations PC-1, PC-2 et SRV-3, l'identifiant est '''root''' et il n'y a pas de mot de passe (tapez sur 'retour chariot' (''return'' ou Entrée) quand le mot de passe est demandé).<br />
<!--<br />
Activez le service de web sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo nginx'''<br />
<br />
Activez le service de nommage sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo named -c /usr/local/etc/bind/named.conf'''<br />
--><br />
<br />
Pour tester la configuration, il faut d'abord valider le DNS en interrogeant le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
'''''Nota : ''''' ''Dans le cadre de ce TP, les machines PC-1, PC-2, R1, R2 et SRV-3 ont respectivement été enregistrées pc1, pc2, r1, r2 et srv dans le domaine DNS .tp hebergé sur la machine SRV-3.''<br />
<br />
La commande <tt>dig</tt> est disponible sur PC-2. L'adresse du serveur de noms à utiliser dans la commande <tt>dig</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. :<br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp'''<br />
Pour un affichage plus concis vous pouvez ajouter le paramètre <tt>+short</tt><br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp +short'''<br />
<br />
Vous pouvez également vérifier que la résolution de noms fonctionne depuis R1 (en mode utilisateur) à l'aide de la commande <tt>host</tt>. Pour vous connecter en mode utilisateur sur R1 :<br />
<br />
'''''Nota :''''' ''Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).''<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'adresse du serveur de noms à utiliser dans la commande <tt>host</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. La syntaxe de la commande devient alors, sur R1 :<br />
vyos@r1:~$ '''host srv.tp 192.0.3.3'''<br />
<!--<br />
Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2.<br />
--><br />
Vérifiez ensuite le bon fonctionnement du service web de SRV-3 depuis R1, à l'aide de la commande <tt>curl</tt> : <br />
vyos@r1:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Si vous le souhaitez, vous pouvez recommencer la vérification depuis R2. <br />
<br />
Pour cela il vous faut d'abord faire pointer le client DNS de R2 vers SRV-3 en renseignant le fichier de configuration <tt>/etc/resolv.conf</tt>. Passez d’abord en mode ''root'', puis créer le fichier fichier du client DNS, à l'aide de la commande <tt>echo</tt> et en redirigeant la sortie standard vers le fichier à créer.<br />
r2 login: '''vyos'''<br />
Password: <br />
Linux r2 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''echo "nameserver 192.0.3.3" > /etc/resolv.conf'''<br />
root@r2:/home/vyos# '''exit'''<br />
exit<br />
<br />
Vous pouvez ensuite procéder aux tests de la même manière que sur R1.<br />
<br />
vyos@r2:~$ '''host srv.tp'''<br />
vyos@r2:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
La problématique qu'il reste à résoudre se pose dans les termes suivants : comment PC1, qui est en ''IPv6-only'', peut-il accéder au service web <tt>srv.tp</tt> qui est en ''IPv4-only'' ?<br />
<br />
= Etape 1 : Configuration de NAT64/DNS64 =<br />
Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. <br />
<!--Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud en double pile R1.--><br />
La fonction de relais dns auxiliaire DNS64 est maintenant intégrée dans les versions récentes de la pile logicielle DNS Bind9. Elle sera donc assurée par le service de nommage DNS porté par SRV-3. La fonction de traduction NAT64, quant à elle, sera placée sur le nœud en double pile R1.<br />
<br />
Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être 'avec état' ou 'sans état'.<br />
<br />
Le NAT64 que nous allons déployer sur notre plateforme est un traducteur 'sans état'. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction.<br />
Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode 'sans état'. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052.<br />
Ainsi, lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination, adresse qu'il aura apprise en recevant la requête. Comme la traduction d'adresse s'effectue 'sans état', ceci implique que l'adresse IPv4 du client a été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose, parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc, d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 ''IPv4-translatable'' en plus de son adresse IPv6 unicast routable.<br />
<br />
Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64. <br />
Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br />
Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.<br />
<br />
<!--<center><br />
[[Image:46-fig2.png|300px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_dns64_20190628.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_dns64_20210408.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center><br />
<br />
== Allocation d'adresses ==<br />
<br />
Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.<br />
La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.<br />
<!--<center><br />
[[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_step_1_20190628.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_step_1_20210408.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center><br />
<br />
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.<br />
<!--<br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! @ IPv4<br />
! @ IPv6<br />
|-<br />
! rowspan="2" | PC1<br />
| <br />
|<tt> fd75:e4d9:cb77:1::3</tt><br />
|-<br />
| <tt>192.0.3.3</tt><br />
| <tt>fd75:e4d9:cb77:64::192.0.3.3</tt><br />
|- <br />
! rowspan="3" | R1<br />
| <tt>192.0.3.1</tt> <br />
| <tt>fd75:e4d9:cb77:64::192.0.3.1</tt><br />
|-<br />
| <br />
| <tt>fd75:e4d9:cb77:1::1</tt> <br />
|-<br />
| <tt>192.0.2.130</tt><br />
|<br />
|-<br />
! rowspan="2" | R2<br />
| <tt>192.0.2.129</tt><br />
| <br />
|-<br />
| <tt>192.0.2.2</tt><br />
| <br />
|-<br />
! rowspan="1" | PC2<br />
| <tt>192.0.2.1</tt><br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
--><br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! Interface<br />
! @ IPv4<br />
! @ IPv6<br />
|- style="background:silver"<br />
! rowspan="2" | PC-1 <br />
|eth0<br />
|<br />
| '''<tt> fd75:e4d9:cb77:1::c1</tt>'''<br />
|- style="background:silver"<br />
|eth0<br />
| ''<tt>192.0.1.1</tt>''<br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.1</tt>'''<br />
|- <br />
! rowspan="3" | R1<br />
| eth0<br />
|<br />
| '''<tt>fd75:e4d9:cb77:1::1</tt>'''<br />
|-<br />
| eth0<br />
| ''<tt>192.0.1.254/24</tt>'' <br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.254</tt>'''<br />
|-<br />
| eth1<br />
| '''<tt>192.0.0.1/30</tt>'''<br />
|<br />
|- style="background:silver"<br />
! rowspan="3" | R2<br />
| eth1<br />
| '''<tt>192.0.0.2/30</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth0<br />
| '''<tt>192.0.2.254/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth3<br />
| '''<tt>192.0.3.254/24</tt>'''<br />
|<br />
|-<br />
! rowspan="1" | PC-2<br />
| eth0<br />
| '''<tt>192.0.2.2/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
! rowspan="1" | SRV-3<br />
| eth0<br />
| '''<tt>192.0.3.3/24</tt>'''<br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
<br />
Il est à noter que bien que PC-1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 (''IPv4-translatable'') qui sera attribuée à l'interface réseau de PC1. De ce fait, PC-1 aura bien 2 adresses unicast IPv6 routables : une utilisée pour les communications avec des noeuds IPv6 (SID positionné à <tt>1</tt>) et une autre utilisée pour les communications avec des noeuds IPv4 (SID positionné à <tt>64</tt>). L'algorithme du choix de l'adresse source, lorsqu'il a plusieurs adresses IPv6, est défini par le RFC 6724.<br />
Lorsque PC-1 envoie une requête à SRV-3, il utilise, sur le réseau IPv6, comme adresse source : <tt>fd75:e4d9:cb77:64::192.0.1.1</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:101</tt>), et comme adresse de destination : <tt>fd75:e4d9:cb77:64::192.0.3.3</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:303</tt>). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source <tt>192.0.1.1</tt> et destination <tt>192.0.3.3</tt>.<br />
<br />
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.<br />
<br />
== Configuration de PC1 ==<br />
<br />
<!-- Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :<br />
apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:1::3/64'''<br />
--><br />
Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.<br />
root@PC-1~# '''ifconfig eth0'''<br />
Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien. <br />
<!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' --><br />
root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''<br />
Vérifiez votre saisie en affichant de nouveau les adresses de l'interface eth0.<br />
<br />
root@PC-1~# '''ip addr show eth0'''<br />
'''''Nota :''''' ''La notation canonique de la nouvelle adresse que vous venez d'attribuer à l'interface affiche l'adresse IPv4 en hexadécimal avec l'IID <tt>::c000:101</tt>''<br />
<br />
Ensuite, il faudrait théoriquement indiquer une route au préfixe NSP réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC-1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement distinct du routeur. Elle pourrait être positionnée par la commande : <br />
<br />
<tt> route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1</tt><br />
<br />
Dans notre cas, PC-1 n'a pas besoin de route spécifique pour le préfixe NSP IPv6 de traduction puisque la passerelle de traduction NAT64 est elle-même hébergée sur le routeur par défaut pour PC-1.<br />
<br />
<!--<br />
Enfin, renseignez le serveur de noms qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS qui sera configuré par la suite sur R1. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> qui ne contiendra qu'une seule ligne. Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap''). L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
--><br />
Enfin, configurez le client DNS (''resolver'') de PC-1 en renseignant le serveur récursif de proximité qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS récursif qui sera configuré par la suite sur R1 afin de relayer les requêtes vers SRV-3. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> de PC-1 qui ne contiendra qu'une seule ligne.<br />
<br />
'''''Nota :''''' ''Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap'').''<br />
<br />
L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
root@PC-1:~# '''nano -w /etc/resolv.conf'''<br />
et saisissez la ligne ci-dessous avant de sauvegarder le fichier à l'aide de la commande <CTRL+o>, puis de sortir de l'éditeur par <CTRL+x> :<br />
'''nameserver fd75:e4d9:cb77:1::1'''<br />
Vérifiez vote saisie en affichant le contenu du fichier à l'aide de la commande <tt>cat</tt><br />
root@PC-1:~# '''cat /etc/resolv.conf'''<br />
<br />
== Mise en oeuvre du DNS64 sur SRV-3 ==<br />
<br />
<!--<br />
== Mise en oeuvre du DNS64 sur R1 ==<br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel '''TOTD''' (''Trick Or Treat Daemon'') peut également être utilisé pour cet usage. '''TOTD''' est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).<br />
Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. La configuration de NAT64/DNS64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans un mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt> :<br />
vyos@vyos~$ '''exit'''<br />
Pour vous reconnecter en mode ''root'' sur R1 :<br />
login: '''root''' <br />
Password: '''root'''<br />
L'invite de commande dans ce mode est :<br />
root@vyos:~#<br />
Avant de démarrer le service DNS auxiliaire, complétez le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1, éditez le fichier de configuration de '''TOTD''' :<br />
root@vyos:~# '''nano -w /etc/totd.conf'''<br />
pour localiser et renseigner les informations suivantes dans le fichier :<br />
forwarder '''192.0.2.1''' # IPv4 address for name server<br />
prefix '''fd75:e4d9:cb77:64::''' # /96 by default<br />
port '''53'''<br />
<br />
Le ''forwarder'' correspond à l'adresse IPv4 du serveur DNS général. La ligne ''prefix'' indique dans notre cas le NSP qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (''IPv4-converted'').<br />
<br />
Démarrez le logiciel :<br />
root@vyos:~# '''/etc/init.d/totd start'''<br />
<br />
Vérifiez que TOTD ne s'est pas arrêté, en consultant la fin du journal système à l'aide de la commande : <br />
root@vyos:~# '''tail /var/log/messages'''<br />
Vous pouvez également vérifier la présence du processus 'daemon totd' à l'aide de la commande :<br />
root@vyos:~# '''ps -edf | grep totd'''<br />
'''Note :''' le symbole <tt>|</tt> (pipe Unix) est obtenu en appuyant simultanément sur les touches 'Alt Gr' et '6' du clavier azerty de votre PC ou Shift + Alt + L (appui simultané sur les 3 touches) de votre Mac.<br />
<br />
Nous allons vérifier que le serveur DNS contient les bons enregistrements pour les noeuds de cette plateforme. A savoir que PC2 contient bien l'adresse <tt>192.0.2.1</tt>. Aussi ouvrir une session sur PC2 et consulter le fichier <tt>/etc/bind/db.tp</tt><br />
apprenant@MOOCIPv6:~$ '''less /etc/bind/db.tp'''<br />
pour sortir de l'afficheur taper 'q'. Pour faire des modifications ou des ajouts, utiliser votre éditeur de texte. Pour recharger la base de données du serveur dns sur PC2:<br />
apprenant@MOOCIPv6:~$ '''sudo /etc/init.d/bind reload'''<br />
<br />
Vérifier que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande: <tt>{tail /var/log/syslog}</tt>.<br />
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande <tt>/etc/init.d/bind restart</tt>.<br />
--><br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64, tel qu'il est illustré à la figure 2. Sur notre plateforme, c'est le serveur SRV-3 qui supporte à la fois le service DNS et la fonction de DNS64 auxilliaire.<br />
Nous allons passer en revue sa configuration avant de tester son fonctionnement.<br />
Observons le contenu de la base de données du serveur en consultant le fichier ''<tt>/etc/bind/db.tp</tt> à l'aide de la commande <tt>cat</tt><br />
root@SRV-3:/# '''cat /etc/bind/db.tp'''<br />
On constate que certaines ressources sont référencées à la fois en IPv6 et en IPv4 avec des RR (''Resource Record'') de type AAAA et A et d'autres uniquement en IPv4 sous forme de RR de type A.<br />
<br />
Les options de démarrage du serveurs sont fixées dans le fichier ''<tt>/etc/bind/named.conf.options</tt>''<br />
root@SRV-3:/# '''cat /etc/bind/named.conf.options'''<br />
'''Nota''' ''Dans ce fichier, les commentaires sont préfixés par <tt>//</tt> (''double caractères diviseur'').''<br />
<br />
A la fin du fichier vous trouverez les clauses de configuration de la fonction DNS64.<br />
Quel est le préfixe choisi pour la translation ? Pour quels clients cette fonction est elle activée ?<br />
<br />
Avant de procéder aux tests, nous devons activer la fonction de relais récursif DNS de proximité de R1 pour que les requêtes des clients sur le sous réseau Net1 soient relayées vers le serveur DNS SRV-3, en enchaînant les commandes suivantes<br />
vyos@r1$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set service dns forwarding cache-size 0'''<br />
vyos@r1# '''set service dns forwarding listen-address fd75:e4d9:cb77:1::1'''<br />
vyos@r1# '''set service dns forwarding name-server 192.0.3.3'''<br />
vyos@r1# '''commit;save'''<br />
vyos@r1#<br />
<br />
Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC-1. Sur PC-1, demandez l'adresse IPv4 de <tt>srv.tp</tt> de la manière suivante :<br />
root@PC-1:~# '''dig srv.tp +short'''<br />
puis l'adresse IPv6 :<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Observez le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal <tt>c000:303</tt>). L'adresse IPv4 occupe les 32 bits de poids faible (à droite) de l'adresse IPv6 affichée.<br />
<br />
Vous pouvez analyser les échanges en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface <tt>eth0</tt> et sur l'interface <tt>eth1</tt> de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de <tt>srv.tp</tt> en une adresse IPv6 initiée par PC-1.<br />
<!--Ainsi, par l'affichage des messages ''DNS standard query'' et ''DNS standard response'' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.--><br />
<br />
== Mise en oeuvre de NAT64 sur R1==<br />
<br />
'''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''Simple, no fuss NAT64 for Linux'') est une mise en oeuvre libre sous Linux du RFC 6145, la version 'sans état' du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS64 auxiliaire que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.<br />
<br />
'''TAYGA''' est installé sur un routeur en double pile, à savoir R1. Nous allons vérifier en premier lieu que R1 satisfait bien cette condition. La configuration de NAT64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans le mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt>. Pour cela, entrez la commande suivante :<br />
vyos@r1:~# '''exit'''<br />
exit<br />
vyos@r1:~$ '''exit'''<br />
logout<br />
<br />
Welcome to VyOS - r1 ttyS0<br />
Pour vous connecter en mode ''VyOS'' sur R1 :<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright. <br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Pour passer en mode ''root'' sur R1 :<br />
vyos@r1:~$ '''sudo su'''<br />
root@r1:/home/vyos# '''sh interfaces'''<br />
Vous pouvez observer que l'interface <tt>eth0</tt> est bien configurée avec une adresse IPv6 routable et que l'interface <tt>eth1</tt> est configurée avec une adresse IPv4. Ce noeud a bien la capacité de communiquer avec les 2 versions du protocole IP. C'est donc bien un noeud en double pile.<br />
<!--<br />
Il faut que le R1 soit configuré en routeur à savoir que le relayage des paquets soit activé. Ceci s'indique par les drapeaux système:<br />
<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv6/conf/all/forwarding '''<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv4/ip_forward''<br />
<br />
Nous allons commencer par configurer les interfaces réseaux de R1, l'interface <tt>eth0</tt> avec les informations liées à IPv6 et <tt>eth1</tt> à IPv4. Nous allons faire cette configuration toujours en mode root.<br />
<br />
root@vyos~# '''ifconfig eth0 inet6 add fd75:e4d9:cb77:1::1/64'''<br />
root@vyos~# '''ifconfig eth1 192.0.2.130/25'''<br />
<br />
Ensuite il reste à indiquer les routes statiques :<br />
root@vyos~# '''ip route add 192.0.2.0/25 via 192.0.2.129 dev eth1'''<br />
R1 vient d'être configuré en double pile. <br />
<br />
Il reste à configurer le logiciel '''TAYGA''' sur R1 :<br />
--><br />
<br />
La configuration de '''TAYGA''' commence par l'édition de son fichier de configuration<tt>/etc/tayga.conf</tt>. Le fichier ayant été pré-configuré, nous allons nous contenter de vérifier que les paramètres correspondent bien à notre architecture en affichant son contenu à l'aide de la commande <tt>cat</tt>. Aidez vous de votre souris et de l'ascenceur dans la partie droite de la fenêtre pour la navigation. :<br />
root@r1:/home/vyos# '''cat /etc/tayga.conf'''<br />
...<br />
'''tun-device nat64''' # device name for nat64<br />
...<br />
ipv4-addr '''192.0.1.254''' # IPv4 address that TAYGA will use<br />
...<br />
prefix '''fd75:e4d9:cb77:64::/96''' # NSP<br />
...<br />
'''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.<br />
<!--<br />
Configurez les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.2.131/25 dev nat64''' #IPv4 nat64 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::2/64 dev nat64''' #IPv6 nat64 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.3.0/24 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0''' # route to pc1<br />
--><br />
<br />
Configurez l'interface interne logique <tt>nat64</tt> et les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.0.1 dev nat64''' # IPv4 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64''' # IPv6 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64''' # route to IPv6 nodes (nodes with IPv4-tranlsatable address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64''' # global route to IPv4 nodes (nodes with IPv4-converted address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1<br />
'''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''<br />
<br />
'''''Nota 2 :''''' ''Pour les deux commandes d'affectation d'une adresse IPv4 et d'une adresse IPv6 à l'interface interne logique nat64 : <tt>ip addr add 192.0.0.1 dev nat64</tt> et <tt>ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64</tt>'' '''''il ne faut pas indiquer de longueur de préfixe !''''' ''sinon l'interface nat64 prendra la priorité sur l'interface eth1 et l'interface eth0 dans la table de routage pour ces préfixes respectifs et la fonction NAT64 ne fonctionnera pas.''<br />
<br />
Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :<br />
vyos@r2:~$ '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''ip route 192.0.1.0/24 192.0.0.1'''<br />
r2(config)# '''end'''<br />
r2#<br />
<br />
192.0.1.0/24 représente le réseau IPv4 fictif qui est inclus dans l'infrastructure IPv6.<br />
<br />
Démarrez '''TAYGA''' sur '''R1''' :<br />
root@r1:/home/vyos# '''tayga'''<br />
<br />
Le service est maintenant opérationnel. Pour le valider, faites un simple test de connectivité ping depuis PC-1 :<br />
root@PC-1:~# '''ping6 -c 5 srv.tp'''<br />
<br />
Maintenant, testez que le client IPv6 (sur PC-1) accède bien au service web (sur SRV-3) :<br />
root@PC-1:~# '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Relancez ces deux dernières commandes en observant parallèlement avec wireshark les captures des flux de part et d'autre du traducteur '''TAYGA''' ''(lancez parallèlement les captures wireshark sur les liens des interfaces <tt>eth0</tt> et <tt>eth1</tt> de R1)''. Quelles sont les versions du protocoles IP, quelles sont les adresses source et destination des paquets ?<br />
<br />
= Etape 2 : Connectivité IPv6 par tunnel =<br />
Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel. <br />
Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.<br />
Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extrémités du tunnel sont indiqués par la figure 4. --><br />
<br />
<!--<center><br />
[[Image:46-fig4-v2.png|450px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession5_act46_step_2_20190630.png|600px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center><br />
<br />
Avant de passer à la configuration du tunnel, revenez en mode utilisateur sur les routeurs. Sur R1 :<br />
root@r1:/home/vyos# '''exit'''<br />
exit<br />
vyos@r1:~$ <br />
<br />
sur R2: <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
<br />
Pour rappel, l'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :<br />
* La première commande consiste à passer en mode administrateur par <tt>configure</tt>.<br />
* La commande <tt>set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64'</tt> crée une interface de tunnel configuré, dénommée <tt>tun0</tt>. Cette interface est identifiée par une adresse IP. Le tunnel est un lien et, en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.<br />
* Le mode d'encapsulation pour le tunnel est spécifié par la commande <tt>set interfaces tunnel tun0 encapsulation 'sit' </tt>. Le mode SIT (''Simple Internet Transition'') indique une méthode d'encapsulation d'IPv6 dans IPv4.<br />
* La commande <tt>set interfaces tunnel tun0 local-ip '192.0.0.1' </tt> précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.<br />
* La commande <tt>set interfaces tunnel tun0 remote-ip '192.0.0.2' </tt> précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi, un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.<br />
* La commande <tt>set interfaces tunnel tun0 mtu '1480' </tt> précise la taille de la MTU (''Maximum Transmission Unit'') appliquée sur ce tunnel. Par défaut, tous les liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisé qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur laquelle repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit, un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête compris). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins les 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc, pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi, moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.<br />
* Enfin, la commande <tt>commit</tt> valide la séquence des commandes en mode administrateur pour revenir en mode utilisateur.<br />
Dans leur ensemble, les commandes à exécuter sont les suivantes :<br />
vyos@r1:~$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::1/64'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 local-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 remote-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r1# '''commit'''<br />
[edit]<br />
vyos@r1#<br />
<br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r1# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r1# '''show interface'''<br />
<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r1# '''show ipv6 route'''<br />
<br />
Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.<br />
<br />
vyos@r2:~$ '''configure'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::2/64'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 local-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 remote-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r2# '''commit'''<br />
[edit]<br />
vyos@r2# <br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r2# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''show interface'''<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r2# '''show ipv6 route'''<br />
<br />
Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :<br />
<br />
r1# '''ping ipv6 fd75:e4d9:cb77:fff::2'''<br />
<br />
Nota : l'arrêt de la commande <tt>ping</tt> s'effectue par un 'Ctrl + C' (appui simultané sur les touches Ctrl et C).<br />
<br />
Sur une des interfaces Ethernet entre R1 et R2, lancez une capture wireshark pour observer les paquets qui vont transiter par le tunnel. <br />
<br />
Recommencez le test de connectivité depuis PC-1.<br />
<br />
root@PC1:~# '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
<br />
<!--Oups ! cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 a bien une route par défaut :<br />
<br />
apprenant@MOOCIPv6:~$ '''route -A inet6'''<br />
<br />
Qu'en est-il de la route de la réponse à la requête du ping ? Regardez la table de routage sur R2 (en mode Quagga) :<br />
<br />
vyos@vyos:~$ '''vtysh'''<br />
vyos# '''show ipv6 route'''<br />
<br />
R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale, à savoir la route par défaut. En effet, on peut considérer que l'Internet v6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :<br />
<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ::/0 tun0'''<br />
vyos(config)# '''exit'''<br />
Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2<br />
vyos# '''show ipv6 route'''<br />
Recommencez le test de connectivité depuis PC1.<br />
<br />
apprenant@MOOCIPv6:~$ '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
--><br />
Cela fonctionne, la connectivité IPv6 a bien été étendue jusqu'au routeur R2.<br />
<br />
Si vous avez lancé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 encapsulés dans des paquets IPv6, eux-mêmes encapsulés dans des paquets IPv4. Observez les différentes encapsulations : <tt>[Ethernet[IPv4[IPv6[ICMPv6]]]]</tt>. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs, quel est le numéro de protocole utilisé dans l'en-tête IPv4 pour identifier un contenu IPv6 ? <br />
<br />
On constate sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>-I</tt> (''Interface'') de la commande Ping6 en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC1:~# '''ping6 -c 5 -I fd75:e4d9:cb77:1::c1 fd75:e4d9:cb77:fff::2'''<br />
Cela fonctionne également. Observez le changement d'adresse source des paquets émis par PC-1 sur la capture.<br />
<br />
Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.<br />
<br />
= Etape 3 : Configurer un reverse proxy web sur R2 =<br />
Dans cette dernière étape, la base des clients en IPv6 est devenue conséquente. Une connectivité IPv6 arrive jusqu'au réseau du serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'applicatif web soit compatible avec IPv6, surtout s'il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.<br />
<br />
Nous avons vu, dans l'étape 1, qu'un client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible, notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. <br />
Une autre solution existe dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative dite ALG (''Application Layer Gateway''). <br />
<br />
Dans cette étape, nous allons mettre en oeuvre un ''reverse proxy'' web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.<br />
<br />
<!--Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion : <br />
login: '''root'''<br />
password: '''root'''<br />
--><br />
Sur le routeur R2, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt>, ensuite <tt>sudo su</tt>. L'affichage des interfaces, permet de s'assurer de nouveau de la connectivité IPv6 de R2 par son interface <tt>tun0</tt> : <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''sh interfaces'''<br />
<!--<br />
Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive<br />
...<br />
pid /run/nginx.pid<br />
...<br />
par<br />
...<br />
'''pid /var/run/nginx.pid'''<br />
...<br />
à l'aide de l'éditeur nano.<br />
root@vyos:~# '''nano -w /etc/nginx/nginx.conf'''<br />
--><br />
<br />
Vérifiez la configuration "reverse proxy IPv6" de R2 en consultant le fichier <tt>/etc/nginx/sites-available/default</tt> à l'aide de la commande <tt>less</tt>.<br />
<br />
'''''Rappel :''''' ''La commande <tt>less</tt> vous permet d'afficher, sans l'éditer, le contenu d'un fichier texte en naviguant simplement avec les touches de direction du curseur. Pour quitter l'affichage du fichier, appuyez simplement sur la touche 'q' qui signifie "quit". ''<br />
root@r2:/home/vyos# '''less /etc/nginx/sites-available/default'''<br />
<br />
Verifiez d'abord que le serveur reverse-proxy sera bien en écoute sur ses interfaces ipv6 en consultant la clause '''listen''' <br />
...<br />
server {<br />
'''listen [::]:80 default_server;'''<br />
...<br />
Vérifiez ensuite sa configration en mode "reverse-proxy" vers l'adresse du serveur SRV-3 en consultant la clause '''location'''<br />
<br />
...<br />
'''location / {'''<br />
''' proxy_pass http://192.0.3.3/;'''<br />
'''}'''<br />
...<br />
<br />
<!--<br />
'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.<br />
<br />
L'appel de l'éditeur s'effectue par la commande :<br />
root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''<br />
--><br />
Redémarrez le serveur nginx :<br />
root@r2:/home/vyos# '''service nginx restart'''<br />
<br />
Vérifiez l'état du service<br />
root@r2:/home/vyos# '''service nginx status'''<br />
<br />
Le service de DNS doit maintenant identifier le ''reverse proxy'' comme le serveur web en IPv6. Pour cela, sur '''SRV-3''', modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy en ajoutant un <tt>RR AAAA</tt> à la valeur <tt>fd75:e4d9:cb77:fff::2</tt> <br />
<br />
root@SRV-3:/# '''nano -w /etc/bind/db.tp'''<br />
...<br />
srv IN A 192.0.3.3<br />
'''IN AAAA fd75:e4d9:cb77:fff::2'''<br />
;<br />
<br />
Relancez le serveur <tt>named</tt>. Pour cela, validez d'abord votre nouvelle configuration à l'aide de la commande <tt> named-checkconf -z</tt>. Si tout est correct, relancez le service à l'aide de la commande <tt>service bind9 restart</tt>:<br />
<br />
root@SRV-3:/# '''named-checkconf -z'''<br />
...<br />
root@SRV-3:/# '''service bind9 restart'''<br />
...<br />
[ ok ] Starting domain name service...: bind9.<br />
Verifiez l'état du service<br />
root@SRV-3:/# '''service bind9 status''' <br />
Sur le relais DNS de R1, afin de réinitialiser le cache DNS, rédemarrez le service <tt>pdns-recursor</tt>. Sinon les réponses des reqêtes de PC-1 concernant SRV-3 pourraient continuer à être basée sur l'adresse traduisible <tt>fd75:e4d9:cb77:64:c000:303</tt> de SRV-3 mémorisée dans le cache DNS du relais R1. Sur R1 en mode ''root''<br />
r1# '''exit'''<br />
[edit]<br />
vyos@r1# '''sudo su'''<br />
root@r1:/home/vyos# '''service pdns-recursor restart'''<br />
<br />
Sur le client IPv6 PC-1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy <tt>fd75:e4d9:cb77:fff::2</tt>.<br />
<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et SRV-3.<br />
<br />
root@PC-1:~# '''curl -6 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Dans les fenêtres de capture, vous pouvez vérifier que :<br />
* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;<br />
* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;<br />
* après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?<br />
<br />
On constate, de nouveau sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>--interface</tt> de la commande <tt>curl</tt> en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC-1:~# '''curl -6 --interface fd75:e4d9:cb77:1::c1 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
= Conclusion =<br />
<br />
Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement (et uniquement !?) en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'. <br />
<br />
Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.<br />
<br />
=Pour aller plus loin=<br />
<references /></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act46&diff=20545MOOC:Compagnon Act462023-01-17T10:37:50Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
= Activité 46: Faites inter-opérer des applications IPv6 et IPv4=<br />
<br />
Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :<br />
* un Internet en IPv4 encore prépondérant du fait de ses services ;<br />
* un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.<br />
<br />
L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours. <br />
<br />
Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.<br />
<br />
La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :<br />
* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;<br />
* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;<br />
* un routeur R2 en IPv4 : c'est un noeud représentant l'Internet en IPv4 ;<br />
* un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;<br />
* un serveur web IPv4. Ce service sera hébergé sur le noeud SRV-3 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.<br />
<br />
<!--<center><br />
[[image:46-etape0.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center> --><br />
<center><br />
[[image:MoocSession5_act46_topology_20190628.png|500px|thumb|center|Figure 1 : Plateforme de l'activité.]]<br />
</center><br />
<br />
= Etape 0 : Situation initiale =<br />
<br />
Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.<br />
<!--<br />
Dans la phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Il reste à démarrer les services. Les services hébergés sur PC2 sont le DNS, pour la résolution de noms, et le web. <br />
--><br />
<!--<br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur PC2 les services applicatifs de nommage DNS (<tt>named -c /usr/local/etc/bind/named.conf</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
--><br />
Pour cette phase initiale, l'infrastructure de communication de la plateforme est opérationnelle. Sur SRV-3 les services applicatifs de nommage DNS (<tt>/usr/sbin/named -u bind</tt>) et web (<tt>nginx</tt>) ont été automatiquement lancés au démarrage de la machine.<br />
<br />
'''Note :''' pour vous loguer sur les stations PC-1, PC-2 et SRV-3, l'identifiant est '''root''' et il n'y a pas de mot de passe (tapez sur 'retour chariot' (''return'' ou Entrée) quand le mot de passe est demandé).<br />
<!--<br />
Activez le service de web sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo nginx'''<br />
<br />
Activez le service de nommage sur PC2 : <br />
apprenant@MOOCIPv6:~$ '''sudo named -c /usr/local/etc/bind/named.conf'''<br />
--><br />
<br />
Pour tester la configuration, il faut d'abord valider le DNS en interrogeant le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
'''''Nota : ''''' ''Dans le cadre de ce TP, les machines PC-1, PC-2, R1, R2 et SRV-3 ont respectivement été enregistrées pc1, pc2, r1, r2 et srv dans le domaine DNS .tp hebergé sur la machine SRV-3.''<br />
<br />
La commande <tt>dig</tt> est disponible sur PC-2. L'adresse du serveur de noms à utiliser dans la commande <tt>dig</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. :<br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp'''<br />
Pour un affichage plus concis vous pouvez ajouter le paramètre <tt>+short</tt><br />
root@PC-2:~# '''dig @192.0.3.3 -t A srv.tp +short'''<br />
<br />
Vous pouvez également vérifier que la résolution de noms fonctionne depuis R1 (en mode utilisateur) à l'aide de la commande <tt>host</tt>. Pour vous connecter en mode utilisateur sur R1 :<br />
<br />
'''''Nota :''''' ''Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).''<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'adresse du serveur de noms à utiliser dans la commande <tt>host</tt> est l'adresse de SRV-3, soit <tt>192.0.3.3</tt>. La syntaxe de la commande devient alors, sur R1 :<br />
vyos@r1:~$ '''host srv.tp 192.0.3.3'''<br />
<!--<br />
Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2.<br />
--><br />
Vérifiez ensuite le bon fonctionnement du service web de SRV-3 depuis R1, à l'aide de la commande <tt>curl</tt> : <br />
vyos@r1:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Si vous le souhaitez, vous pouvez recommencer la vérification depuis R2. <br />
<br />
Pour cela il vous faut d'abord faire pointer le client DNS de R2 vers SRV-3 en renseignant le fichier de configuration <tt>/etc/resolv.conf</tt>. Passez d’abord en mode ''root'', puis créer le fichier fichier du client DNS, à l'aide de la commande <tt>echo</tt> et en redirigeant la sortie standard vers le fichier à créer.<br />
r2 login: '''vyos'''<br />
Password: <br />
Linux r2 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright.<br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''echo "nameserver 192.0.3.3" > /etc/resolv.conf'''<br />
root@r2:/home/vyos# '''exit'''<br />
exit<br />
<br />
Vous pouvez ensuite procéder aux tests de la même manière que sur R1.<br />
<br />
vyos@r2:~$ '''host srv.tp'''<br />
vyos@r2:~$ '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
La problématique qu'il reste à résoudre se pose dans les termes suivants : comment PC1, qui est en ''IPv6-only'', peut-il accéder au service web <tt>srv.tp</tt> qui est en ''IPv4-only'' ?<br />
<br />
= Etape 1 : Configuration de NAT64/DNS64 =<br />
Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. <br />
<!--Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud en double pile R1.--><br />
La fonction de relais dns auxiliaire DNS64 est maintenant intégrée dans les versions récentes de la pile logicielle DNS Bind9. Elle sera donc assurée par le service de nommage DNS porté par SRV-3. La fonction de traduction NAT64, quant à elle, sera placée sur le nœud en double pile R1.<br />
<br />
Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être 'avec état' ou 'sans état'.<br />
<br />
Le NAT64 que nous allons déployer sur notre plateforme est un traducteur 'sans état'. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction.<br />
Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode 'sans état'. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052.<br />
Ainsi, lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination, adresse qu'il aura apprise en recevant la requête. Comme la traduction d'adresse s'effectue 'sans état', ceci implique que l'adresse IPv4 du client a été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose, parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc, d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 ''IPv4-translatable'' en plus de son adresse IPv6 unicast routable.<br />
<br />
Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64. <br />
Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br />
Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.<br />
<br />
<!--<center><br />
[[Image:46-fig2.png|300px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_dns64_20190628.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_dns64_20210408.png|600px|thumb|center|Figure 2 : Opérations du DNS64.]]<br />
</center><br />
<br />
== Allocation d'adresses ==<br />
<br />
Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.<br />
La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.<br />
<!--<center><br />
[[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<!-- <center><br />
[[Image:MoocSession5_act46_step_1_20190628.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession6_act46_step_1_20210408.png|600px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]<br />
</center><br />
<br />
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.<br />
<!--<br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! @ IPv4<br />
! @ IPv6<br />
|-<br />
! rowspan="2" | PC1<br />
| <br />
|<tt> fd75:e4d9:cb77:1::3</tt><br />
|-<br />
| <tt>192.0.3.3</tt><br />
| <tt>fd75:e4d9:cb77:64::192.0.3.3</tt><br />
|- <br />
! rowspan="3" | R1<br />
| <tt>192.0.3.1</tt> <br />
| <tt>fd75:e4d9:cb77:64::192.0.3.1</tt><br />
|-<br />
| <br />
| <tt>fd75:e4d9:cb77:1::1</tt> <br />
|-<br />
| <tt>192.0.2.130</tt><br />
|<br />
|-<br />
! rowspan="2" | R2<br />
| <tt>192.0.2.129</tt><br />
| <br />
|-<br />
| <tt>192.0.2.2</tt><br />
| <br />
|-<br />
! rowspan="1" | PC2<br />
| <tt>192.0.2.1</tt><br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
--><br />
<center><br />
{| border="1" cellpadding="5" cellspacing="0"<br />
! Noeuds<br />
! Interface<br />
! @ IPv4<br />
! @ IPv6<br />
|- style="background:silver"<br />
! rowspan="2" | PC-1 <br />
|eth0<br />
|<br />
| '''<tt> fd75:e4d9:cb77:1::c1</tt>'''<br />
|- style="background:silver"<br />
|eth0<br />
| ''<tt>192.0.1.1</tt>''<br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.1</tt>'''<br />
|- <br />
! rowspan="3" | R1<br />
| eth0<br />
|<br />
| '''<tt>fd75:e4d9:cb77:1::1</tt>'''<br />
|-<br />
| eth0<br />
| ''<tt>192.0.1.254/24</tt>'' <br />
| '''<tt>fd75:e4d9:cb77:64::192.0.1.254</tt>'''<br />
|-<br />
| eth1<br />
| '''<tt>192.0.0.1/30</tt>'''<br />
|<br />
|- style="background:silver"<br />
! rowspan="3" | R2<br />
| eth1<br />
| '''<tt>192.0.0.2/30</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth0<br />
| '''<tt>192.0.2.254/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
| eth3<br />
| '''<tt>192.0.3.254/24</tt>'''<br />
|<br />
|-<br />
! rowspan="1" | PC-2<br />
| eth0<br />
| '''<tt>192.0.2.2/24</tt>'''<br />
| <br />
|- style="background:silver"<br />
! rowspan="1" | SRV-3<br />
| eth0<br />
| '''<tt>192.0.3.3/24</tt>'''<br />
| <br />
|}<br />
Tableau 1 : Allocation des adresses.<br />
</center><br />
<br />
Il est à noter que bien que PC-1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 (''IPv4-translatable'') qui sera attribuée à l'interface réseau de PC1. De ce fait, PC-1 aura bien 2 adresses unicast IPv6 routables : une utilisée pour les communications avec des noeuds IPv6 (SID positionné à <tt>1</tt>) et une autre utilisée pour les communications avec des noeuds IPv4 (SID positionné à <tt>64</tt>). L'algorithme du choix de l'adresse source, lorsqu'il a plusieurs adresses IPv6, est défini par le RFC 6724.<br />
Lorsque PC-1 envoie une requête à SRV-3, il utilise, sur le réseau IPv6, comme adresse source : <tt>fd75:e4d9:cb77:64::192.0.1.1</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:101</tt>), et comme adresse de destination : <tt>fd75:e4d9:cb77:64::192.0.3.3</tt> (soit en hexadécimal <tt>fd75:e4d9:cb77:64::c000:303</tt>). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source <tt>192.0.1.1</tt> et destination <tt>192.0.3.3</tt>.<br />
<br />
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.<br />
<br />
== Configuration de PC1 ==<br />
<br />
<!-- Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :<br />
apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:1::3/64'''<br />
--><br />
Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.<br />
root@PC-1~# '''ifconfig eth0'''<br />
Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien. <br />
<!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' --><br />
root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''<br />
Vérifiez votre saisie en affichant de nouveau les adresses de l'interface eth0.<br />
<br />
root@PC-1~# '''ip addr show eth0'''<br />
'''''Nota :''''' ''La notation canonique de la nouvelle adresse que vous venez d'attribuer à l'interface affiche l'adresse IPv4 en hexadécimal avec l'IID <tt>::c000:101</tt>''<br />
<br />
Ensuite, il faudrait théoriquement indiquer une route au préfixe NSP réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC-1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement distinct du routeur. Elle pourrait être positionnée par la commande : <br />
<br />
<tt> route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1</tt><br />
<br />
Dans notre cas, PC-1 n'a pas besoin de route spécifique pour le préfixe NSP IPv6 de traduction puisque la passerelle de traduction NAT64 est elle-même hébergée sur le routeur par défaut pour PC-1.<br />
<br />
<!--<br />
Enfin, renseignez le serveur de noms qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS qui sera configuré par la suite sur R1. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> qui ne contiendra qu'une seule ligne. Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap''). L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
--><br />
Enfin, configurez le client DNS (''resolver'') de PC-1 en renseignant le serveur récursif de proximité qui sera utilisé au niveau du réseau IPv6 : il s'agit du relais DNS récursif qui sera configuré par la suite sur R1 afin de relayer les requêtes vers SRV-3. L'adresse de R1 est indiquée dans le fichier <tt>/etc/resolv.conf</tt> de PC-1 qui ne contiendra qu'une seule ligne.<br />
<br />
'''''Nota :''''' ''Pour éviter que la seule ligne puisse être découpée (par l'insertion d'un retour à la ligne) par l'éditeur, l'éditeur de texte <tt>nano</tt> sera appelé avec l'option <tt>-w</tt> (''no wrap'').''<br />
<br />
L'appel de l'éditeur sur PC-1 est donc le suivant :<br />
root@PC-1:~# '''nano -w /etc/resolv.conf'''<br />
et saisissez la ligne ci-dessous avant de sauvegarder le fichier à l'aide de la commande <CTRL+o>, puis de sortir de l'éditeur par <CTRL+x> :<br />
'''nameserver fd75:e4d9:cb77:1::1'''<br />
Vérifiez vote saisie en affichant le contenu du fichier à l'aide de la commande <tt>cat</tt><br />
root@PC-1:~# '''cat /etc/resolv.conf'''<br />
<br />
== Mise en oeuvre du DNS64 sur SRV-3 ==<br />
<br />
<!--<br />
== Mise en oeuvre du DNS64 sur R1 ==<br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel '''TOTD''' (''Trick Or Treat Daemon'') peut également être utilisé pour cet usage. '''TOTD''' est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).<br />
Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. La configuration de NAT64/DNS64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans un mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt> :<br />
vyos@vyos~$ '''exit'''<br />
Pour vous reconnecter en mode ''root'' sur R1 :<br />
login: '''root''' <br />
Password: '''root'''<br />
L'invite de commande dans ce mode est :<br />
root@vyos:~#<br />
Avant de démarrer le service DNS auxiliaire, complétez le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1, éditez le fichier de configuration de '''TOTD''' :<br />
root@vyos:~# '''nano -w /etc/totd.conf'''<br />
pour localiser et renseigner les informations suivantes dans le fichier :<br />
forwarder '''192.0.2.1''' # IPv4 address for name server<br />
prefix '''fd75:e4d9:cb77:64::''' # /96 by default<br />
port '''53'''<br />
<br />
Le ''forwarder'' correspond à l'adresse IPv4 du serveur DNS général. La ligne ''prefix'' indique dans notre cas le NSP qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (''IPv4-converted'').<br />
<br />
Démarrez le logiciel :<br />
root@vyos:~# '''/etc/init.d/totd start'''<br />
<br />
Vérifiez que TOTD ne s'est pas arrêté, en consultant la fin du journal système à l'aide de la commande : <br />
root@vyos:~# '''tail /var/log/messages'''<br />
Vous pouvez également vérifier la présence du processus 'daemon totd' à l'aide de la commande :<br />
root@vyos:~# '''ps -edf | grep totd'''<br />
'''Note :''' le symbole <tt>|</tt> (pipe Unix) est obtenu en appuyant simultanément sur les touches 'Alt Gr' et '6' du clavier azerty de votre PC ou Shift + Alt + L (appui simultané sur les 3 touches) de votre Mac.<br />
<br />
Nous allons vérifier que le serveur DNS contient les bons enregistrements pour les noeuds de cette plateforme. A savoir que PC2 contient bien l'adresse <tt>192.0.2.1</tt>. Aussi ouvrir une session sur PC2 et consulter le fichier <tt>/etc/bind/db.tp</tt><br />
apprenant@MOOCIPv6:~$ '''less /etc/bind/db.tp'''<br />
pour sortir de l'afficheur taper 'q'. Pour faire des modifications ou des ajouts, utiliser votre éditeur de texte. Pour recharger la base de données du serveur dns sur PC2:<br />
apprenant@MOOCIPv6:~$ '''sudo /etc/init.d/bind reload'''<br />
<br />
Vérifier que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande: <tt>{tail /var/log/syslog}</tt>.<br />
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande <tt>/etc/init.d/bind restart</tt>.<br />
--><br />
Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64, tel qu'il est illustré à la figure 2. Sur notre plateforme, c'est le serveur SRV-3 qui supporte à la fois le service DNS et la fonction de DNS64 auxilliaire.<br />
Nous allons passer en revue sa configuration avant de tester son fonctionnement.<br />
Observons le contenu de la base de données du serveur en consultant le fichier ''<tt>/etc/bind/db.tp</tt> à l'aide de la commande <tt>cat</tt><br />
root@SRV-3:/# '''cat /etc/bind/db.tp'''<br />
On constate que certaines ressources sont référencées à la fois en IPv6 et en IPv4 avec des RR (''Resource Record'') de type AAAA et A et d'autres uniquement en IPv4 sous forme de RR de type A.<br />
<br />
Les options de démarrage du serveurs sont fixées dans le fichier ''<tt>/etc/bind/named.conf.options</tt>''<br />
root@SRV-3:/# '''cat /etc/bind/named.conf.options'''<br />
'''Nota''' ''Dans ce fichier, les commentaires sont préfixés par <tt>//</tt> (''double caractères diviseur'').''<br />
<br />
A la fin du fichier vous trouverez les clauses de configuration de la fonction DNS64.<br />
Quel est le préfixe choisi pour la translation ? Pour quels clients cette fonction est elle activée ?<br />
<br />
Avant de procéder aux tests, nous devons activer la fonction de relais récursif DNS de proximité de R1 pour que les requêtes des clients sur le sous réseau Net1 soient relayées vers le serveur DNS SRV-3, en enchaînant les commandes suivantes<br />
vyos@r1$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set service dns forwarding cache-size 0'''<br />
vyos@r1# '''set service dns forwarding listen-address fd75:e4d9:cb77:1::1'''<br />
vyos@r1# '''set service dns forwarding name-server 192.0.3.3'''<br />
vyos@r1# '''commit;save'''<br />
vyos@r1#<br />
<br />
Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC-1. Sur PC-1, demandez l'adresse IPv4 de <tt>srv.tp</tt> de la manière suivante :<br />
root@PC-1:~# '''dig srv.tp +short'''<br />
puis l'adresse IPv6 :<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Observez le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal <tt>c000:303</tt>). L'adresse IPv4 occupe les 32 bits de poids faible (à droite) de l'adresse IPv6 affichée.<br />
<br />
Vous pouvez analyser les échanges en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface <tt>eth0</tt> et sur l'interface <tt>eth1</tt> de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de <tt>srv.tp</tt> en une adresse IPv6 initiée par PC-1.<br />
<!--Ainsi, par l'affichage des messages ''DNS standard query'' et ''DNS standard response'' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.--><br />
<br />
== Mise en oeuvre de NAT64 sur R1==<br />
<br />
'''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''Simple, no fuss NAT64 for Linux'') est une mise en oeuvre libre sous Linux du RFC 6145, la version 'sans état' du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS64 auxiliaire que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.<br />
<br />
'''TAYGA''' est installé sur un routeur en double pile, à savoir R1. Nous allons vérifier en premier lieu que R1 satisfait bien cette condition. La configuration de NAT64 sur R1 s'effectue en mode ''root''. Le mode ''root'' va nous servir à entrer des commandes Unix. Si une session est ouverte dans le mode non ''root'' sur le routeur, il faut la quitter par la commande <tt>exit</tt>. Pour cela, entrez la commande suivante :<br />
vyos@r1:~# '''exit'''<br />
exit<br />
vyos@r1:~$ '''exit'''<br />
logout<br />
<br />
Welcome to VyOS - r1 ttyS0<br />
Pour vous connecter en mode ''VyOS'' sur R1 :<br />
r1 login: '''vyos'''<br />
Password: <br />
Linux r1 4.19.28-amd64-vyos #1 SMP Mon Mar 11 16:03:26 CET 2019 x86_64<br />
<br />
The programs included with the Debian GNU/Linux system are free software;<br />
the exact distribution terms for each program are described in the<br />
individual files in /usr/share/doc/*/copyright. <br />
<br />
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br />
permitted by applicable law.<br />
vyos@r1:~$<br />
L'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Pour passer en mode ''root'' sur R1 :<br />
vyos@r1:~$ '''sudo su'''<br />
root@r1:/home/vyos# '''sh interfaces'''<br />
Vous pouvez observer que l'interface <tt>eth0</tt> est bien configurée avec une adresse IPv6 routable et que l'interface <tt>eth1</tt> est configurée avec une adresse IPv4. Ce noeud a bien la capacité de communiquer avec les 2 versions du protocole IP. C'est donc bien un noeud en double pile.<br />
<!--<br />
Il faut que le R1 soit configuré en routeur à savoir que le relayage des paquets soit activé. Ceci s'indique par les drapeaux système:<br />
<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv6/conf/all/forwarding '''<br />
root@vyos~# '''echo 1 > /proc/sys/net/ipv4/ip_forward''<br />
<br />
Nous allons commencer par configurer les interfaces réseaux de R1, l'interface <tt>eth0</tt> avec les informations liées à IPv6 et <tt>eth1</tt> à IPv4. Nous allons faire cette configuration toujours en mode root.<br />
<br />
root@vyos~# '''ifconfig eth0 inet6 add fd75:e4d9:cb77:1::1/64'''<br />
root@vyos~# '''ifconfig eth1 192.0.2.130/25'''<br />
<br />
Ensuite il reste à indiquer les routes statiques :<br />
root@vyos~# '''ip route add 192.0.2.0/25 via 192.0.2.129 dev eth1'''<br />
R1 vient d'être configuré en double pile. <br />
<br />
Il reste à configurer le logiciel '''TAYGA''' sur R1 :<br />
--><br />
<br />
La configuration de '''TAYGA''' commence par l'édition de son fichier de configuration<tt>/etc/tayga.conf</tt>. Le fichier ayant été pré-configuré, nous allons nous contenter de vérifier que les paramètres correspondent bien à notre architecture en affichant son contenu à l'aide de la commande <tt>cat</tt>. Aidez vous de votre souris et de l'ascenceur dans la partie droite de la fenêtre pour la navigation. :<br />
root@r1:/home/vyos# '''cat /etc/tayga.conf'''<br />
...<br />
'''tun-device nat64''' # device name for nat64<br />
...<br />
ipv4-addr '''192.0.1.254''' # IPv4 address that TAYGA will use<br />
...<br />
prefix '''fd75:e4d9:cb77:64::/96''' # NSP<br />
...<br />
'''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.<br />
<!--<br />
Configurez les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.2.131/25 dev nat64''' #IPv4 nat64 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::2/64 dev nat64''' #IPv6 nat64 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.3.0/24 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0''' # route to pc1<br />
--><br />
<br />
Configurez l'interface interne logique <tt>nat64</tt> et les routes pour TAYGA sur R1 :<br />
root@r1:/home/vyos# '''tayga --mktun''' # create nat64 device<br />
root@r1:/home/vyos# '''ip link set nat64 up''' # activate nat64 device<br />
root@r1:/home/vyos# '''ip addr add 192.0.0.1 dev nat64''' # IPv4 router address<br />
root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64''' # IPv6 router address<br />
root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64''' # route to IPv6 nodes (nodes with IPv4-tranlsatable address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64''' # global route to IPv4 nodes (nodes with IPv4-converted address)<br />
root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1<br />
'''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''<br />
<br />
'''''Nota 2 :''''' ''Pour les deux commandes d'affectation d'une adresse IPv4 et d'une adresse IPv6 à l'interface interne logique nat64 : <tt>ip addr add 192.0.0.1 dev nat64</tt> et <tt>ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64</tt>'' '''''il ne faut pas indiquer de longueur de préfixe !''''' ''sinon l'interface nat64 prendra la priorité sur l'interface eth1 et l'interface eth0 dans la table de routage pour ces préfixes respectifs et la fonction NAT64 ne fonctionnera pas.''<br />
<br />
Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :<br />
vyos@r2:~$ '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''ip route 192.0.1.0/24 192.0.0.1'''<br />
r2(config)# '''end'''<br />
r2#<br />
<br />
192.0.1.0/24 représente le réseau IPv4 fictif qui est inclus dans l'infrastructure IPv6.<br />
<br />
Démarrez '''TAYGA''' sur '''R1''' :<br />
root@r1:/home/vyos# '''tayga'''<br />
<br />
Le service est maintenant opérationnel. Pour le valider, faites un simple test de connectivité ping depuis PC-1 :<br />
root@PC-1:~# '''ping6 -c 5 srv.tp'''<br />
<br />
Maintenant, testez que le client IPv6 (sur PC-1) accède bien au service web (sur SRV-3) :<br />
root@PC-1:~# '''curl http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Relancez ces deux dernières commandes en observant parallèlement avec wireshark les captures des flux de part et d'autre du traducteur '''TAYGA''' ''(lancez parallèlement les captures wireshark sur les liens des interfaces <tt>eth0</tt> et <tt>eth1</tt> de R1)''. Quelles sont les versions du protocoles IP, quelles sont les adresses source et destination des paquets ?<br />
<br />
= Etape 2 : Connectivité IPv6 par tunnel =<br />
Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel. <br />
Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.<br />
Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extremités du tunnel sont indiqués par la figure 4. --><br />
<br />
<!--<center><br />
[[Image:46-fig4-v2.png|450px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center> --><br />
<center><br />
[[Image:MoocSession5_act46_step_2_20190630.png|600px|thumb|center|Figure 4 : Connectivité par tunnel.]]<br />
</center><br />
<br />
Avant de passer à la configuration du tunnel, revenez en mode utilisateur sur les routeurs. Sur R1 :<br />
root@r1:/home/vyos# '''exit'''<br />
exit<br />
vyos@r1:~$ <br />
<br />
sur R2: <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
<br />
Pour rappel, l'invite de commande dans ce mode est :<br />
vyos@r1:~$<br />
Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :<br />
* La première commande consiste à passer en mode administrateur par <tt>configure</tt>.<br />
* La commande <tt>set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64'</tt> crée une interface de tunnel configuré, dénommée <tt>tun0</tt>. Cette interface est identifiée par une adresse IP. Le tunnel est un lien et, en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.<br />
* Le mode d'encapsulation pour le tunnel est spécifié par la commande <tt>set interfaces tunnel tun0 encapsulation 'sit' </tt>. Le mode SIT (''Simple Internet Transition'') indique une méthode d'encapsulation d'IPv6 dans IPv4.<br />
* La commande <tt>set interfaces tunnel tun0 local-ip '192.0.0.1' </tt> précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.<br />
* La commande <tt>set interfaces tunnel tun0 remote-ip '192.0.0.2' </tt> précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi, un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.<br />
* La commande <tt>set interfaces tunnel tun0 mtu '1480' </tt> précise la taille de la MTU (''Maximum Transmission Unit'') appliquée sur ce tunnel. Par défaut, tous les liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisé qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur laquelle repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit, un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête compris). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins les 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc, pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi, moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.<br />
* Enfin, la commande <tt>commit</tt> valide la séquence des commandes en mode administrateur pour revenir en mode utilisateur.<br />
Dans leur ensemble, les commandes à exécuter sont les suivantes :<br />
vyos@r1:~$ '''configure'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::1/64'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 local-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 remote-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r1# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r1# '''commit'''<br />
[edit]<br />
vyos@r1#<br />
<br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r1# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r1# '''show interface'''<br />
<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r1# '''show ipv6 route'''<br />
<br />
Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.<br />
<br />
vyos@r2:~$ '''configure'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 address fd75:e4d9:cb77:fff::2/64'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 encapsulation sit'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 local-ip 192.0.0.2'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 remote-ip 192.0.0.1'''<br />
[edit]<br />
vyos@r2# '''set interfaces tunnel tun0 mtu 1480'''<br />
[edit]<br />
vyos@r2# '''commit'''<br />
[edit]<br />
vyos@r2# <br />
Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga) :<br />
<br />
vyos@r2# '''vtysh'''<br />
<br />
Hello, this is FRRouting (version 7.0).<br />
Copyright 1996-2005 Kunihiro Ishiguro, et al.<br />
<br />
r2# '''show interface'''<br />
<br />
Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.<br />
Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :<br />
<br />
r2# '''show ipv6 route'''<br />
<br />
Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :<br />
<br />
r1# '''ping ipv6 fd75:e4d9:cb77:fff::2'''<br />
<br />
Nota : l'arrêt de la commande <tt>ping</tt> s'effectue par un 'Ctrl + C' (appui simultané sur les touches Ctrl et C).<br />
<br />
Sur une des interfaces Ethernet entre R1 et R2, lancez une capture wireshark pour observer les paquets qui vont transiter par le tunnel. <br />
<br />
Recommencez le test de connectivité depuis PC-1.<br />
<br />
root@PC1:~# '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
<br />
<!--Oups ! cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 a bien une route par défaut :<br />
<br />
apprenant@MOOCIPv6:~$ '''route -A inet6'''<br />
<br />
Qu'en est-il de la route de la réponse à la requête du ping ? Regardez la table de routage sur R2 (en mode Quagga) :<br />
<br />
vyos@vyos:~$ '''vtysh'''<br />
vyos# '''show ipv6 route'''<br />
<br />
R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale, à savoir la route par défaut. En effet, on peut considérer que l'Internet v6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :<br />
<br />
vyos# '''configure terminal'''<br />
vyos(config)# '''ipv6 route ::/0 tun0'''<br />
vyos(config)# '''exit'''<br />
Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2<br />
vyos# '''show ipv6 route'''<br />
Recommencez le test de connectivité depuis PC1.<br />
<br />
apprenant@MOOCIPv6:~$ '''ping6 -c 5 fd75:e4d9:cb77:fff::2'''<br />
--><br />
Cela fonctionne, la connectivité IPv6 a bien été étendue jusqu'au routeur R2.<br />
<br />
Si vous avez lancé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 encapsulés dans des paquets IPv6, eux-mêmes encapsulés dans des paquets IPv4. Observez les différentes encapsulations : <tt>[Ethernet[IPv4[IPv6[ICMPv6]]]]</tt>. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs, quel est le numéro de protocole utilisé dans l'en-tête IPv4 pour identifier un contenu IPv6 ? <br />
<br />
On constate sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>-I</tt> (''Interface'') de la commande Ping6 en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC1:~# '''ping6 -c 5 -I fd75:e4d9:cb77:1::c1 fd75:e4d9:cb77:fff::2'''<br />
Cela fonctionne également. Observez le changement d'adresse source des paquets émis par PC-1 sur la capture.<br />
<br />
Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.<br />
<br />
= Etape 3 : Configurer un reverse proxy web sur R2 =<br />
Dans cette dernière étape, la base des clients en IPv6 est devenue conséquente. Une connectivité IPv6 arrive jusqu'au réseau du serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'applicatif web soit compatible avec IPv6, surtout s'il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.<br />
<br />
Nous avons vu, dans l'étape 1, qu'un client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible, notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. <br />
Une autre solution existe dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative dite ALG (''Application Layer Gateway''). <br />
<br />
Dans cette étape, nous allons mettre en oeuvre un ''reverse proxy'' web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.<br />
<br />
<!--Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion : <br />
login: '''root'''<br />
password: '''root'''<br />
--><br />
Sur le routeur R2, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt>, ensuite <tt>sudo su</tt>. L'affichage des interfaces, permet de s'assurer de nouveau de la connectivité IPv6 de R2 par son interface <tt>tun0</tt> : <br />
r2# '''exit'''<br />
vyos@r2:~$<br />
vyos@r2:~$ '''sudo su'''<br />
root@r2:/home/vyos# '''sh interfaces'''<br />
<!--<br />
Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive<br />
...<br />
pid /run/nginx.pid<br />
...<br />
par<br />
...<br />
'''pid /var/run/nginx.pid'''<br />
...<br />
à l'aide de l'éditeur nano.<br />
root@vyos:~# '''nano -w /etc/nginx/nginx.conf'''<br />
--><br />
<br />
Vérifiez la configuration "reverse proxy IPv6" de R2 en consultant le fichier <tt>/etc/nginx/sites-available/default</tt> à l'aide de la commande <tt>less</tt>.<br />
<br />
'''''Rappel :''''' ''La commande <tt>less</tt> vous permet d'afficher, sans l'éditer, le contenu d'un fichier texte en naviguant simplement avec les touches de direction du curseur. Pour quitter l'affichage du fichier, appuyez simplement sur la touche 'q' qui signifie "quit". ''<br />
root@r2:/home/vyos# '''less /etc/nginx/sites-available/default'''<br />
<br />
Verifiez d'abord que le serveur reverse-proxy sera bien en écoute sur ses interfaces ipv6 en consultant la clause '''listen''' <br />
...<br />
server {<br />
'''listen [::]:80 default_server;'''<br />
...<br />
Vérifiez ensuite sa configration en mode "reverse-proxy" vers l'adresse du serveur SRV-3 en consultant la clause '''location'''<br />
<br />
...<br />
'''location / {'''<br />
''' proxy_pass http://192.0.3.3/;'''<br />
'''}'''<br />
...<br />
<br />
<!--<br />
'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.<br />
<br />
L'appel de l'éditeur s'effectue par la commande :<br />
root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''<br />
--><br />
Redémarrez le serveur nginx :<br />
root@r2:/home/vyos# '''service nginx restart'''<br />
<br />
Vérifiez l'état du service<br />
root@r2:/home/vyos# '''service nginx status'''<br />
<br />
Le service de DNS doit maintenant identifier le ''reverse proxy'' comme le serveur web en IPv6. Pour cela, sur '''SRV-3''', modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy en ajoutant un <tt>RR AAAA</tt> à la valeur <tt>fd75:e4d9:cb77:fff::2</tt> <br />
<br />
root@SRV-3:/# '''nano -w /etc/bind/db.tp'''<br />
...<br />
srv IN A 192.0.3.3<br />
'''IN AAAA fd75:e4d9:cb77:fff::2'''<br />
;<br />
<br />
Relancez le serveur <tt>named</tt>. Pour cela, validez d'abord votre nouvelle configuration à l'aide de la commande <tt> named-checkconf -z</tt>. Si tout est correct, relancez le service à l'aide de la commande <tt>service bind9 restart</tt>:<br />
<br />
root@SRV-3:/# '''named-checkconf -z'''<br />
...<br />
root@SRV-3:/# '''service bind9 restart'''<br />
...<br />
[ ok ] Starting domain name service...: bind9.<br />
Verifiez l'état du service<br />
root@SRV-3:/# '''service bind9 status''' <br />
Sur le relais DNS de R1, afin de réinitialiser le cache DNS, rédemarrez le service <tt>pdns-recursor</tt>. Sinon les réponses des reqêtes de PC-1 concernant SRV-3 pourraient continuer à être basée sur l'adresse traduisible <tt>fd75:e4d9:cb77:64:c000:303</tt> de SRV-3 mémorisée dans le cache DNS du relais R1. Sur R1 en mode ''root''<br />
r1# '''exit'''<br />
[edit]<br />
vyos@r1# '''sudo su'''<br />
root@r1:/home/vyos# '''service pdns-recursor restart'''<br />
<br />
Sur le client IPv6 PC-1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy <tt>fd75:e4d9:cb77:fff::2</tt>.<br />
<br />
root@PC-1:~# '''dig -t AAAA srv.tp +short'''<br />
<br />
Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et SRV-3.<br />
<br />
root@PC-1:~# '''curl -6 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
Dans les fenêtres de capture, vous pouvez vérifier que :<br />
* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;<br />
* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;<br />
* après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?<br />
<br />
On constate, de nouveau sur la capture, que PC-1 a utilisé son adresse traduisible <tt>fd75:e4d9:cb77:64::c000:101</tt> comme adresse source. Cela fonctionne-t-il également avec l'autre adresse routable, <tt>fd75:e4d9:cb77:1::c1</tt> de son interface <tt>eth0</tt> ?<br />
<br />
Pour forcer l'adresse source utilisez le paramètre <tt>--interface</tt> de la commande <tt>curl</tt> en forçant sa valeur à l'adresse source souhaitée.<br />
root@PC-1:~# '''curl -6 --interface fd75:e4d9:cb77:1::c1 http://srv.tp'''<br />
''Un contenu brut HTML doit s'afficher''<br />
<br />
= Conclusion =<br />
<br />
Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement (et uniquement !?) en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'. <br />
<br />
Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.<br />
<br />
=Pour aller plus loin=<br />
<references /></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act36&diff=20544MOOC:Compagnon Act362023-01-16T17:04:14Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
=Activité 36: Configurez votre premier réseau en IPv6 =<br />
__NOTOC__<br />
L'objectif de cette activité pratique est de mettre en œuvre un réseau IPv6 d'une façon proche de l'opérationnel. Nous présenterons comment configurer les routeurs mais aussi les hôtes en s'appuyant sur l'auto-configuration. Les mécanismes de configuration automatique des paramètres réseau vise à simplifier les tâches de l'administrateur et améliorer l'expérience de l'utilisateur. Vous allez, dans cette activité, configurer un réseau pour mettre en œuvre : <br />
* l'auto-configuration sans état,<br />
* l'auto-configuration avec état par le protocole DHCPv6,<br />
* un service de noms afin d'associer un nom à certaines adresses IPv6.<br />
<br />
Comme le montre la figure 1, la topologie du réseau que vous allez utiliser est identique à l'activité pratique de la séquence 1 et 2. Les 3 réseaux seront considérés de la façon suivante : <br />
* le lien Net 0 composé des nœuds R1 - R2 est un sous-réseau d'infrastructure. Les mécanismes d'auto-configuration ne s'y appliquent pas ;<br />
* le lien Net 1 composé de R1 - PC-1 forme un sous-réseau destiné à recevoir des hôtes ayant un rôle de client. Le protocole de configuration automatique sans état est utilisé.<br />
* le lien Net 2 composé de R2 - PC-2 forme lui aussi un sous-réseau destiné à recevoir des hôtes mais avec un rôle de serveur. Le protocole de configuration automatique utilisé ici sera avec état.<br />
* le lien Net 3 composé R2 - SRV-3 forme lui aussi un sous réseau destiné à recevoir des hôtes mais avec un rôle de serveur. Le protocole de configuration sans état est utilisé.<br />
<br />
Le plan d'adressage utilisé pour ces réseaux reprend le préfixe <tt>fd75:e4d9:cb77::/48</tt> <br />
* le préfixe <tt>fd75:e4d9:cb77::/64</tt> est utilisé pour le sous-réseau d'infrastructure ;<br />
* le préfixe <tt>fd75:e4d9:cb77:1::/64</tt> est utilisé pour le sous-réseau Net 1 ;<br />
* le préfixe <tt>fd75:e4d9:cb77:2::/64</tt> est utilisé pour le sous-réseau Net 2 ;<br />
* le préfixe <tt>fd75:e4d9:cb77:3::/64</tt> est utilisé pour le sous-réseau Net 3.<br />
Imprégnez-vous de ce plan d'adressage, utilisant des adresses ULA (''Unique Local Address''). Nous allons le mettre progressivement en oeuvre dans cette plateforme.<br />
<center><br />
[[image:MoocSession5_act36_topolo_20190605.png|thumb|center|400px| Figure 1: Plan d'adressage utilisé.]]<br />
</center><br />
<br />
Vous allez, dans une première étape, configurer le sous réseau d'infrastructure puis dans une seconde étape, configurer le sous-réseau de distribution Net1 en déployant l'auto-configuration sans état. La troisième étape consistera à déployer le protocole DHCPv6 sur le sous-réseau Net2. Enfin la quatrième et dernière étape, va nous amener à activer le serveur DNS. L'information de la disponibilité du service de nommage sera distribuée sur les différents sous-réseaux en utilisant DHCPv6.<br />
Dans cette activité, des captures des échanges seront effectuées pour illustrer les mécanismes de configuration présentés dans cette séquence. Prenez donc le temps d'étudier les messages et leur contenu.<br />
<br />
Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible dans l'onglet documentation du cours Objectif IPv6 du site de FUN. <br />
<br />
== Etape 0: Création des liens ==<br />
<br />
Double cliquer sur le lien intitulé "moocipv6.gns3"<!-- (icône symbolisé par un caméléon)-->, présent dans la partie haute du bureau de votre machine virtuelle.<br />
<br />
Vous devez restaurer le Snapshot ''(Activité-36)'' depuis '''''Edit > Manage snapshots''''' ce qui rechargera les configurations initiales des équipements.<br />
<br />
Attendre que la fenêtre <tt>moocipv6-GNS3</tt> apparaisse à l'écran comme présentée par la figure 2. Double cliquer sur la barre de titre de cette fenêtre pour qu'elle occupe la totalité de votre écran. Si besoin, vous pouvez ensuite recentrer l'image de la topologie dans la fenêtre centrale avec les boutons ascenseurs horizontal et vertical.<br />
<br />
=== Liens physiques à supprimer ===<br />
<!--<br />
Pour commencer, vous devez effacer les liaisons entre les commutateurs SW1 à SW3 et les équipements PC-1, PC-2, R1 et R2 afin que le réseau de la plateforme ressemble à la fin à la figure 2. Ensuite, nous allons les reconstruire pas à pas. C'est seulement une fois les connexions physiques effectuées, que vous pourrez commencer les travaux de configuration.<br />
--><br />
<br />
Pour commencer, vous devez effacer les liaisons entre les noeuds PC-1 - R1, R1 - R2 et R2 - PC-2, afin que le réseau de la plateforme ressemble à la fin à la figure 2. Ensuite, nous allons les reconstruire pas à pas. C'est seulement une fois les connexions physiques effectuées, que vous pourrez commencer les travaux de configuration.<br />
<br />
Avant tout, il est possible d'afficher les numéros des interfaces des équipements représentés sur la maquette. Appuyer sur le bouton carré '''"a b c" ''' situé juste en dessous du menu déroulant Device. <br />
<br />
Vous pouvez maintenant placer votre pointeur sur chacun des liens connectés, sur chacun des commutateurs. Si vous avez bien sélectionné le lien, il doit être en surbrillance. Vous pouvez faire un clic droit et choisir '''"delete"'''.<br />
<br />
<center><br />
[[image:MoocSession5 act36 link nc 20190605.png |thumb|center|600px|Figure 2: Topologie initiale.]]<br />
</center><br />
<br />
Si malencontreusement, vous appuyez sur "start capture", placez-vous sur la fenêtre "topology Summary" en haut à droite. Appuyer sur le + d'un switch, choisir une interface et, avec le clic droit, choisir "stop all captures".<br />
<br />
Une fois que vous avez effacé les 3 liens, nous pouvons commencer à construire correctement notre réseau.<br />
<br />
=== Liens physiques à réaliser ===<br />
<br />
Vous devez sélectionner l'outil ''"add a link"'' (câble en S avec une prise) situé sur le coté gauche, en bas. Une fois sélectionné, une croix rouge vous rappelle qu'il faudra le désélectionner une fois que vous aurez fini la création des liens, sinon toute autre action est inhibée.<br />
* PC1 - R1 : cliquer sur PC-1, puis sur Ethernet0, et glisser-déposer votre souris vers R1, puis sur Ethernet0: un lien apparait sur la figure.<br />
* R1 - R2 : cliquer sur R1, puis sur Ethernet1, et glisser-déposer votre souris vers R2. Choisir alors le port Ethernet1: un lien apparait sur la figure. <br />
* R2 - PC2 : cliquer sur R2, puis sur Ethernet0, et glisser-déposer votre souris vers PC2, choisir alors le port eth0 : un lien apparait sur la figure. <br />
<center><br />
[[image:MoocSession5_act36_link_act_20190605.png|thumb|center|400px|Figure 3: Topologie du réseau mise en place.]]<br />
</center><br />
<br />
Pour '''vérifier''' si l'affectation des interfaces est '''conforme à la configuration initiale présentée à la figure 1''' :<br />
* appuyer sur le bouton carré '''"a b c" ''' situé juste en dessous du menu déroulant ''Node'' ; <br />
<!--* soit vous appuyer sur le bouton ''"Show/Hide Interface Labels"'', situé sous le menu déroulant ''Device'' ;--><br />
* soit vous immobilisez votre pointeur de souris sur un composant réseau, et un panneau décrit la liste des liens en place.<br />
<br />
===Activation des équipements===<br />
<br />
Si tout est correct, vous pouvez activer les équipements du réseau dans GNS3, à l'aide du bouton triangulaire vert démarrer ''"Start/Resume all devices"''.<br />
<br />
Dans la fenêtre centrale les témoins verts des liens indiquent que les équipements démarrent, et sur la droite la fenêtre ''"Topology Summary"'' montre aussi les témoins verts des équipements réseaux.<br />
<br />
Lorsque tous les noeuds sont actifs, il faut cliquer sur le bouton ''"Console connect to all devices"'' symbolisé par >_ situé à gauche du bouton triangulaire vert, juste en dessous du menu déroulant ''"Node"''. Ainsi vous aller faire apparaitre les consoles de contrôle pour les routeurs et pour les hôtes comme le montre la figure 4.<br />
<br />
Les consoles de contrôle dites CLI (''Command Line Interface'') affichent le démarrage des différents équipements réseaux. Notons que le démarrage des PC est plus rapide que celui des routeurs (le temps de démarrage dépendant des capacités de votre machine: compter quelques minutes). Comptez entre trois et dix minutes, parfois plus. Une fois que tous les noeuds ont leur console avec l'invite pour se connecter comme le montre la figure 4, votre plateforme de réseau est dorénavant opérationnelle.<br />
<center><br />
[[image:MoocSession5_act36_topology_cli_20190604.png|thumb|center|600px|Figure 4: Ecran GNS3 avec les interfaces CLI.]]<br />
</center><br />
<br />
===Arrêt/Pause de GNS3===<br />
<br />
Au besoin vous pouvez aussi figer l'exécution des équipements avec le bouton Pause ''"Suspend all nodes"'', voire arrêter les équipements avec le bouton Stop ''"Stop all nodes"''. <br />
<br />
L'état des équipements est sauvegardé en quittant. Pour quitter proprement GNS3, faire <tt>CTRL+Q</tt> ou faire, avec le menu déroulant ''File'' et l'action ''Quit''.<br />
<br />
== Etape 1 : Configuration manuelle des routeurs R1 et R2 ==<br />
Nous allons détailler la démarche de configuration d'un routeur. Nous prendrons l'exemple sur le routeur R1.<br />
<br />
===Activation des interfaces ===<br />
Pour vous loguer sur les routeurs R1 et R2, les identifiant/mot de passe sont '''vyos'''/'''vyos'''. (Aucun affichage de caractère n'est produit lorsqu'on entre le mot de passe).<br />
Passez en mode Quagga VyOS ainsi :<br />
vyos@r1:～$ '''vtysh'''<br />
Vérifiez l'état des interfaces. <br />
Rappel: la tabulation aide à la terminer automatiquement la saisie des commandes.<br />
r1# '''show interface'''<br />
Passez en mode de configuration<br />
r1# '''configure terminal'''<br />
Puis activez l'interface eth0 et eth1.<br />
r1(config)# '''interface eth0'''<br />
r1(config-if)# '''no shutdown'''<br />
r1(config-if)# '''exit'''<br />
r1(config)# '''interface eth1'''<br />
r1(config-if)# '''no shutdown'''<br />
r1(config-if)# '''do show interface'''<br />
r1(config-if)# '''end'''<br />
r1# <br />
Vérifiez l'état des interfaces.<br />
r1# '''show interface'''<br />
Vérifiez les informations détaillées des interfaces. Pour cela quitter le mode configuration:<br />
r1# '''exit'''<br />
r1@vyos:～$ '''show interface detail'''<br />
'''Avant de passer à la suite, vous devez reprendre la même séquence sur R2.'''<br />
<br />
===Configuration des interfaces avec une adresse routable ULA ===<br />
Configurez les adresses routables des interfaces du routeur '''R1''':<br />
vyos@r1:～$ '''vtysh'''<br />
r1# '''configure terminal'''<br />
r1(config)# '''interface eth0'''<br />
r1(config-if)# '''ipv6 address fd75:e4d9:cb77:0001::1/64'''<br />
r1(config-if)# '''exit'''<br />
r1(config)# '''int eth1'''<br />
r1(config-if)# '''ipv6 address fd75:e4d9:cb77:0000::1/64'''<br />
r1(config-if)# '''exit'''<br />
r1(config)# '''exit'''<br />
Vérifiez votre saisie en affichant la configuration des interfaces.<br />
r1# '''show interface'''<br />
<br />
Nous l'avons vu dans l'activité de la séquence 2, les routeurs doivent connaitre les routes pour joindre les sous-réseaux. Il faut donc compléter la table de routage de chaque routeur.<br />
<br />
===Ajout des routes ===<br />
<br />
Configuration du routage sur R1 : ajout d'une route vers Net 2.<br />
r1# '''configure terminal'''<br />
r1(config)# '''ipv6 route fd75:e4d9:cb77:0002::/64 fd75:e4d9:cb77:0000::2 eth1''' <br />
r1(config)# '''do show ipv6 route'''<br />
r1(config)# '''exit'''<br />
r1# <br />
Une route statique vers le réseau Net 2 doit être visible maintenant.<br />
<br />
Nous venons de terminer la configuration du routeur R1. Il faut faire de nouveau la même chose pour le routeur R2 à savoir: activer les interfaces, configurer les interfaces avec une adresse ULA et ajouter les routes.<br />
Ce travail de configuration est similaire à celui de R1 mais en retenant l'adresse ULA des interfaces de R2 et la route pour atteindre Net 1.<br />
<br />
Nous vous laissons répétez l'opération de configuration sur R2.<br />
<br />
vyos@r2~$ '''vtysh'''<br />
r2# '''configure terminal'''<br />
r2(config)# '''interface eth0'''<br />
r2(config-if)# '''ipv6 address fd75:e4d9:cb77:0002::2/64'''<br />
r2(config-if)# '''exit'''<br />
r2(config)# '''int eth1'''<br />
r2(config-if)# '''ipv6 address fd75:e4d9:cb77:0000::2/64'''<br />
r2(config-if)# '''end'''<br />
<br />
Configuration du routage sur R2 : ajout d'une route vers Net 1.<br />
r2# '''configure terminal'''<br />
r2(config)# '''ipv6 route fd75:e4d9:cb77:0001::/64 fd75:e4d9:cb77:0000::1 eth1'''<br />
r2(config)# '''do show ipv6 route'''<br />
r2(config)# '''exit'''<br />
r2# <br />
Une route statique vers le réseau Net 1 doit être visible maintenant.<br />
<br />
=== Vérification de la connectivité ===<br />
Nous allons maintenant vérifier que ce qui vient d'être fait fonctionne sans erreur. Pour cela nous allons effectuer des tests de connectivité entre les différentes interfaces des routeurs. Pour les communications à remises indirectes, nous vérifions également la route suivie. <br />
<br />
* R1 - R2; Depuis le routeur R1, essayez de joindre R2:<br />
r1# '''ping ipv6 fd75:e4d9:cb77:0000::2'''<br />
Stopper le ping par appui simultané des touches ''Ctrl+C''<br />
* R1 - Net 2; Depuis le routeur R1, essayez de joindre l'interface eth0 de R2:<br />
r1# '''ping ipv6 fd75:e4d9:cb77:2::2'''<br />
Stopper le ping par appui simultané des touches ''Ctrl+C''<br />
r1# '''traceroute ipv6 fd75:e4d9:cb77:2::2'''<br />
* R2 - Net 1; Depuis le routeur R2, essayez de joindre l'interface eth0 de R1:<br />
r2# '''ping ipv6 fd75:e4d9:cb77:1::1'''<br />
Stopper le ping par appui simultané des touches ''Ctrl+C''<br />
r2# '''traceroute ipv6 fd75:e4d9:cb77:1::1'''<br />
<!-- {{HorsTexte|Note|Si vous rencontrez des problèmes sur les configurations de cette étape et vous n'arrivez pas à valider les configurations, vous pouvez étudier une configuration fonctionnelle en démarrant la plateforme par l'icône ayant le nom de l'étape suivante disponible dans le dossier '''TP3''' sur le bureau de la machine virtuelle. Vous pourrez ensuite commencer l'étape suivante à partir de cette configuration. Afin de ne pas surcharger votre machine virtuelle, il est conseillé de ne pas démarrer la plateforme de l'étape suivante sans avoir au préalable stoppé la plateforme en cours d'utilisation.}}<br />
--><br />
En l'absence d'erreur, le réseau d'infrastructure est maintenant opérationnel. Dans le cas contraire les adresses allouées et la longueur de leur préfixe sont à vérifier de même que les tables de routage.<br />
<br />
=== Arrêt/Pause du simulateur ===<br />
Au besoin vous pouvez aussi figer l'exécution des équipements avec le bouton Pause ''"Suspend All devices"'', voire arrêter les équipements avec le bouton Stop ''"Stop All devices"''. <br />
<br />
L'état des équipements est sauvegardé en quittant. Pour quitter proprement GNS3, faire <tt>CTRL+Q</tt> ou faire, avec le menu déroulant ''File'' et l'action ''Quit''.<br />
<br />
== Etape 2 : Auto-configuration sans état pour PC-1 ==<br />
<br />
=== Vérifier la configuration initiale du réseau ===<br />
<br />
Sur '''R1''', vérifier que l'interface <tt>eth0</tt> est '''activée'''.<br />
r1# '''exit'''<br />
vyos@r1:~$ '''show interface detail'''<br />
Les interfaces <tt>eth0</tt> et <tt>eth1</tt> doivent être activées et configurées.<br />
<br />
Sur '''PC-1''', vérifier que l'interface <tt>eth0</tt> de PC-1 est '''désactivée'''<br />
root@PC-1::c1:~$ '''ifconfig'''<br />
Seule l'interface <tt>lo</tt> doit s'afficher. Dans le cas contraire vous pouvez désactiver l'interface eth0 puis revérfier<br />
root@PC-1::c1:~$ '''ifconfig eth0 down'''<br />
root@PC-1::c1:~$ '''ifconfig'''<br />
Lancer alors la capture réseau sur le réseau R1 - PC1.<br />
# Séléctionner le lien PC-1 - R1 (il doit apparaître surligné) puis faire un clic-droit.<br />
# Choisir dans le menu '''Start capture'''.<br />
# L'outil de capture réseau doit s'afficher.<br />
<br />
=== Configurer les annonces de routeur sur R1 ===<br />
<br />
La configuration automatique '''sans état''' est contrôlée par la diffusion, sur le réseau, des messages d'annonce de routeur (''Routeur Advertisement'' ou RA). Le routeur de ce réseau étant R1, c'est à lui de diffuser ces messages. Vous allez maintenant activer la diffusion des messages d'annonce sur l'interface <tt>eth0</tt> du routeur R1.<br />
<br />
vyos@r1:～$ '''vtysh'''<br />
r1# '''configure terminal'''<br />
r1(config)# '''interface eth0'''<br />
r1(config-if)# '''no ipv6 nd suppress-ra'''<br />
r1(config-if)# '''ipv6 nd prefix fd75:e4d9:cb77:1::/64'''<br />
r1(config-if)# '''ipv6 nd ra-interval 30'''<br />
r1(config-if)# '''exit'''<br />
r1(config)# '''exit'''<br />
r1#<br />
<br />
La commande <tt>no ipv6 nd suppress-ra</tt> est en fait la négation d'une configuration par défaut de VyOS qui désactive la diffusion des annonces de routeur. La commande suivante <tt>ipv6 nd prefix fd75:e4d9:cb77:1::/64</tt> permet de préciser à VyOS le préfixe à diffuser dans ces messages. Ce préfixe va permettre aux stations qui se connectent sur le réseau de connaitre le préfixe à utiliser pour configurer leurs adresses.<br />
<br />
Dans le cadre de ce TP, afin de pouvoir observer les annonces dans le captures wireshark, nous outrepassons la valeur par défaut de la période d'annonces, pour la fixer à 30 secondes à l'aide de la commande <tt>ipv6 nd ra-interval 30</tt><br />
<br />
Dans l'outil de capture réseau, vérifier la diffusion périodique des annonces de routeur sur le réseau. <!--Quelle est la période de diffusion de ces messages ?--><br />
<br />
Analyser dans l'outil de capture le contenu des messages d'annonce de routeur pour identifier : <br />
* la source du message ;<br />
* la destination du message ;<br />
* le protocole utilisé pour le transport des annonces au dessus d'IPv6 ;<br />
* la valeur de la durée de validité de l'annonce ;<br />
* le préfixe annoncé sur le réseau ;<br />
* la valeur des durées de préférence et de validité du préfixe.<br />
<br />
=== Connecter PC-1 au réseau ===<br />
<br />
Sur '''PC-1''', activer l'interface <tt>eth0</tt> pour simuler la connexion d'une nouvelle station au réseau.<br />
root@PC-1::c1:~# '''ifconfig eth0 up'''<br />
<br />
Observez maintenant la configuration réseau de l'interface <tt>eth0</tt> et celle de la table de routage IPv6.<br />
root@PC-1::c1:~# '''ifconfig'''<br />
root@PC-1::c1:~# '''route -A inet6'''<br />
Quelles sont les configurations que PC-1 a pu automatiquement effectuer grâce à la configuration sans état ?<br />
<br />
Quelles sont les adresses IPv6 de l'interface eth0 de PC-1 ? Que constatez vous pour la valeur de l'identifiant d"interface (IID] de ces adresses ?<br />
<br />
Dans l'outil de capture, analysez les échanges entre '''R1''' et '''PC-1''' pour identifier :<br />
* les messages envoyés par PC-1 pour solliciter la configuration '''sans état''' ;<br />
* les messages envoyés par R1 en réponse à ces sollicitations ;<br />
* les messages envoyés par PC-1 pour valider ses paramètres réseau configurés automatiquement.<br />
<br />
Valider la configuration en testant l'accessibilité de '''R1''' et '''R2''' depuis '''PC-1'''.<br />
root@PC-1::c1:~# '''ping6 -c 5 fd75:e4d9:cb77:1::1'''<br />
root@PC-1::c1:~# '''ping6 -c 5 fd75:e4d9:cb77::1''' <br />
root@PC-1::c1:~# '''ping6 -c 5 fd75:e4d9:cb77::2'''<br />
<br />
== Etape 3 : Auto-configuration ''avec état'' pour PC-2 ==<br />
<br />
Vous allez maintenant mettre en oeuvre la configuration automatique '''avec état''' sur le sous-réseau R2 - PC2. À l'instar de la configuration automatique '''sans état''', ce mode de configuration permet de centraliser les paramètres réseau sur un équipement administré et d'automatiser leur mise en oeuvre sur la station se connectant au réseau.<br />
<br />
La configuration '''avec état''' permet par contre, à l'administrateur, de mieux contrôler les adresses configurées par cette méthode. Il va ainsi pouvoir indiquer explicitement quelles adresses seront attribuées aux interfaces. Les adresses configurées au moment de la connexion sont donc stables, prévisibles et connues avant la première connexion de la station. <br />
<br />
Dans cette étape, vous allez utiliser ce mode de configuration pour SRV-3, qui va tenir lieu dans la suite de serveur de noms. L'adresse d'un tel serveur étant par la suite à configurer sur les autres machines de la plateforme, la stabilité de cette adresse est donc fortement recommandée.<br />
<br />
Les fonctions du protocole DHCPv6 seront réparties sur le réseau de la manière suivante : <br />
* le serveur DHCPv6 sera déployé sur '''SRV-3''';<br />
* le client DHCPv6 sera déployé sur '''PC-2''';<br />
* un relai DHCPv6 devra être activé sur '''R2'''.<br />
<br />
<center><br />
[[Image:MoocSession5_act36_autoconf1_20190605.png|400px|thumb|center|Figure 5: Localisation du client et du serveur DHCPv6.]]<br />
</center><br />
<br />
=== Configurer le serveur DHCPv6 sur SRV-3===<br />
<br />
Le serveur DHCPv6 a la possibilité d'attribuer les adresses selon 2 modes : <br />
* Statique : les adresses sont fixées au préalable par machine en fonction de leur DUID ;<br />
* Dynamique : l'adresse à attribuer est choisie à la première requête dans une plage d'adresses définie par l'administrateur. L'attribution sera ensuite enregistrée pour les prochaines demandes.<br />
C'est le second mode d'attribution que vous allez mettre en oeuvre pour configurer le serveur DHCPv6.<br />
<br />
<!--<br />
La plage d'adresses disponibles pour l'attribution dynamique va s'étendre sur les 16 adresses possibles sur le préfixe <tt>fd75:e4d9:cb77:2::c0/124</tt>. La première adresse disponible sera donc <tt>fd75:e4d9:cb77:2::c0</tt>, la dernière <tt>fd75:e4d9:cb77:2::cf</tt>.<br />
--><br />
La plage d'adresses disponibles pour l'attribution dynamique va s'étendre sur les 10 adresses possibles, la première adresse disponible sera donc <tt>fd75:e4d9:cb77:2::20</tt>, la dernière <tt>fd75:e4d9:cb77:2::29</tt>.<br />
<br />
Sur SRV-3 la configuration du paquet isc-dhcpv6-server est déjà appliquée ainsi:<br />
root@SRV-3::c3: $ '''cat /etc/dhcp/dhcpd6.conf'''<br />
Relancer ce service isc-dhcpv6-server avant de poursuivre.<br />
root@SRV-3::c3: $ '''service isc-dhcp-server6 restart'''<br />
<br />
Lancer la capture sur le réseau R2 - PC2.<br />
<br />
La configuration automatique '''avec état''' nécessite toujours la diffusion des annonces de routeur, ne serait-ce que pour annoncer l'adresse du routeur par défaut. Il faut donc activer sur '''R2''' les annonces de routeurs. Ces messages vont de plus présenter 2 drapeaux (''flags'') spécifiques à l'auto-configuration '''avec état''' : <br />
<br />
r2# '''configure terminal'''<br />
r2(config)# '''interface eth0'''<br />
r2(config-if)# '''no ipv6 nd suppress-ra'''<br />
r2(config-if)# '''ipv6 nd prefix fd75:e4d9:cb77:2::/64 no-autoconfig'''<br />
r2(config-if)# '''ipv6 nd managed-config-flag'''<br />
r2(config-if)# '''end'''<br />
r2#<br />
<br />
La commande <tt>ipv6 nd prefix</tt> présente l'option <tt>no-autoconfig</tt> pour interdire aux stations se connectant de configurer leurs adresses à partir de ce préfixe. La commande <tt>ipv6 nd managed-config-flag</tt> va permettre d'indiquer aux stations que la configuration automatique '''avec état''' est disponible sur ce réseau.<br />
<br />
=== Connecter PC-2 au réseau ===<br />
<br />
Desactiver puis réactiver l'interface <tt>eth0</tt> de '''PC-2'''. <br />
root@PC-2::c2:~$ '''ifconfig eth0 down'''<br />
root@PC-2::c2:~$ '''ifconfig eth0 up'''<br />
<br />
Dans la capture, vérifier le contenu des messages d'annonce de routeur, notamment pour le message d'annonce du préfixe que les drapeaux ("Managed address configuration" est à "1" et "Autonomous address-configurationflag(A) de l'option préfixe est à "0") qui ont été positionnés par la configuration précédente.<br />
<br />
Vérifier la configuration réseau de '''PC-2'''.<br />
root@PC-2::c2:~$ '''ifconfig'''<br />
root@PC-2::c2:~$ '''route -A inet6'''<br />
<br />
Analyser les échanges entre '''R2''' et '''PC-2''' dans l'outil de capture réseau. Expliquer les différences avec les échanges entre '''R1''' et '''PC-1'''.<br />
<br />
'''PC-2''' n'a pas encore configuré d'adresse IPv6 routable car le message d'annonce de routeur interdit la configuration automatique '''sans état'''. Le drapeau annonçant la configuration automatique '''avec état''' est censé indiquer à '''PC-2''' d'initier une requête DHCPv6. Or, dans le système Linux, celle-ci doit encore être lancée manuellement.<br />
<br />
Lancer le client DHCPv6 sur '''PC-2'''.<br />
root@PC-2::c2:~$ '''dhclient -6 eth0'''<br />
<br />
Oupps, la commande ne rend pas la main. Stoppez la par l'appui simultané des touche ''CTRL+C''<br />
<br />
Vérifier la configuration réseau de '''PC-2'''.<br />
root@PC-2::c2:~$ '''ifconfig'''<br />
<!-- root@PC-2::c2:~$ '''route -A inet6''' --><br />
<br />
PC-2 n'a qu'une adresse locale de lien (LLA), il n'a toujours pas d'adresse routable basée sur le préfixe ULA de son réseau. Que se passe-t-il ?<br />
<br />
Analyser les échanges entre '''R2''' et '''PC-2''' dans l'outil de capture réseau.<br />
<br />
Quels sont les messages DHCPv6 emis par le client DHCPv6 de PC-2 ? Vers quelles adresse destination ? Ont ils fait l'objet d'une réponse ?<br />
<br />
Observer la '''non prise en compte des requêtes de PC-2''' sur le serveur DHCPv6, en exécutant la commande d'affichage des baux dhcpv6 sur '''SRV-3''':<br />
root@SRV-3::c3:~$ '''cat /var/lib/dhcp/dhcpd6.leases'''<br />
<br />
Aucun bail n'est actif. Nous constatons que le serveur DHCPv6 ne reçoit pas de requêtes. Pourquoi ?<br />
<br />
Le serveur DHCPv6, n'est pas sur le même réseau que PC-2, nous devons activer le relai DHCPv6 sur R2, voyons cela ci-après;<br />
<br />
=== Configurer le relai DHCPv6 sur R2 ===<br />
<br />
Sur ''' R2''' : <br />
r2# '''exit'''<br />
vyos@r2:~$ '''configure''' <br />
[edit]<br />
vyos@r2# '''set service dhcpv6‐relay listen-interface eth0 address fd75:e4d9:cb77:2::2 '''<br />
vyos@r2# '''set service dhcpv6-relay upstream-interface eth3 address fd75:e4d9:cb77:3::c3 '''<br />
vyos@r2# '''commit '''<br />
vyos@r2:~$<br />
<br />
''' R2 ''' est maintenant configuré avec la fonction de relai. La première commande permettent de désigner l'interface où le logiciel de relayage doit être en écoute, ici eth0 (pour recevoir les requêtes du client), et la deuxième commande permet de relayer en Unicast la requête sur eth3 vers le serveur SRV-3. <br />
<br />
Relancer maintenant le client DHCPv6 de PC-2, puis vérifier les adresses de son interface eth0.<br />
root@PC-2::c2:~# '''dhclient -6 eth0'''<br />
root@PC-2::c2:~# '''ifconfig eth0 '''<br />
PC-2 dispose maintenant d'une adresse routable (ULA). Quelle est sa valeur ? Quelle est la valeur de l'identifiant d'interface de cette adresse ? <br />
Dans la capture wireshark, quels ont été les échanges DHCPv6 ?<br />
<br />
Après avoir relevé l'adresse ULA de PC-1, tester la connectivité avec '''PC-1''' depuis '''PC-2'''.<br />
root@PC-2::c2:~# '''ping6 -c 5 ''adresse IPv6 ULA de PC-1'' '''<br />
<br />
Vous pouvez tester la stabilité de l'adresse IPv6 obtenue par DHCPv6 en simulant une déconnexion puis une reconnexion au réseau de l'interface <tt>eth0</tt> :<br />
root@PC-2::c2:~# '''ifconfig eth0 down'''<br />
root@PC-2::c2:~# '''ifconfig eth0 up '''<br />
root@PC-2::c2:~# '''dhclient -6 eth0'''<br />
root@PC-2::c2:~# '''ifconfig eth0'''<br />
root@PC-2::c2:~# '''route -A inet6'''<br />
<br />
== Etape 4 : Configuration du serveur de noms ==<br />
<br />
Lors de cette étape, vous allez mettre en oeuvre un service de nommage pour la plateforme. Ce service va permettre d'utiliser des noms à la place des ''longues'' adresses IPv6 lorsque vous devez désigner une machine distante comme, par exemple, lors d'un test d'accessibilité.<br />
<br />
Le service de nommage sera basé sur le logiciel Bind, très communément utilisé dans l'Internet. Ce logiciel offre les fonctions de serveur de noms, ainsi que de serveur de résolution récursif. Notre plateforme n'étant pas connectée à l'Internet et ne pouvant pas être liée à l'arbre récursif racine du service de nommage, nous utiliserons une zone TLD (''Top Level Domain'') de nommage propre <tt>*.tp</tt>. Le serveur de résolution sera le même serveur que celui pour les noms. Ces fonctions seront mises en oeuvre sur '''SRV-3'''.<br />
<br />
Le serveur Bind installé sur '''SRV-3''' possède différents fichiers définissant : <br />
* le nommage direct dans la zone <tt>*.tp</tt> ;<br />
* le nommage inversé pour la zone correspondant au préfixe de la plateforme <tt>fd75:e4d9:cb77::/48</tt>.<br />
Cette étape consiste donc à renseigner les adresses et les noms dans ces fichiers afin d'établir les correspondances qui pourront être ensuite utilisées par toutes les machines de la plateforme.<br />
<br />
=== Configurer le nommage direct ===<br />
<br />
Il s'agit ici d'indiquer les correspondances entre des noms pour les machines de la plateforme et leurs adresses IPv6. Ces correspondances utilisent des noms de la zone <tt>*.tp</tt>. C'est donc dans le fichier désigné dans la configuration du serveur de nom Bind pour cette zone qu'il faut renseigner ces correspondances. <br />
<br />
'''Note'''. - Chaque zone possède un numéro de série appelé, dans la configuration, <tt>serial</tt>. Il s'apparente à un numéro de version permettant de repérer les informations les plus à jour pour la zone. Il est donc nécessaire d'incrémenter ce numéro <tt>serial</tt> à chaque modification du fichier de la zone.<br />
<br />
Sur '''SRV-3''', modifier le fichier <tt> /etc/bind/db.tp</tt> :<br />
root@SRV-3::c3:~$# '''nano -w /etc/bind/db.tp'''<br />
<br />
''''Rappel : '''' ''Dans l'éditeur <tt>nano</tt> vous pouvez alors parcourir le fichier à l'aide du curseur et l'éditer à l'endroit voulu. L'appui simultané sur <CTRL-O> (touche contrôle, simultanément à la lettre 'o') permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur. ''<br />
<br />
Modifier : <br />
* incrémenter la valeur du numéro de série,<br />
* ajuster les adresse de pc1 et pc2 au valeur des adresses ULA qu'ils se sont alloués par auto-configuration.<br />
...<br />
...<br />
'''2019060601''' ; serial <br />
... <br />
...<br />
'''pc1 IN AAAA ''adresse_PC1(Utiliser ifconfig sur PC-1, fd75:e4d9:cb77:1::x)'' '''<br />
'''pc2 IN AAAA ''adresse_PC2(Utiliser ifconfig sur PC-2, fd75:e4d9:cb77:2::x)'' '''<br />
srv IN AAAA fd75:e4d9:cb77:3::c3<br />
r1-eth1 IN AAAA fd75:e4d9:cb77::1<br />
r2-eth1 IN AAAA fd75:e4d9:cb77::2<br />
...<br />
<br />
Exemple sur la modification du fichier /etc/bind/db.tp :<br />
...<br />
...<br />
20190606'''01'''; serial<br />
...<br />
...<br />
pc1 IN AAAA fd75:e4d9:cb77:1:68f7:7bff:fe8f:a80d<br />
pc2 IN AAAA fd75:e4d9:cb77:2::29<br />
srv IN AAAA fd75:e4d9:cb77:3::c3<br />
r1-eth1 IN AAAA fd75:e4d9:cb77::1<br />
r2-eth1 IN AAAA fd75:e4d9:cb77::2<br />
<br />
Lancer le logiciel de serveur de nom BIND : <br />
root@SRV-3::c3:~$# '''named-checkconf -z'''<br />
root@SRV-3::c3:~$# '''named -c /etc/bind/named.conf'''<br />
root@SRV-3::c3:~$# '''service bind9 restart'''<br />
<br />
Pour tester la configuration que vous venez d'effectuer, il faut maintenant interroger le serveur de nom pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que <tt>host</tt> ou <tt>dig</tt>.<br />
<br />
Tester la configuration en local sur '''SRV-3''' en interrogeant le serveur de nom local sur les noms pc1.tp, pc2.tp, ... :<br />
root@SRV-3::c3:~$# '''host pc1.tp ::1'''<br />
root@SRV-3::c3:~$# '''host pc2.tp ::1'''<br />
root@SRV-3::c3:~$# '''host srv.tp ::1'''<br />
Le premier argument de la commande <tt>host</tt> indique le nom à rechercher, le second le serveur à interroger (ici l'adresse IPv6 correspondant à ''localhost'').<br />
<br />
Pour que la résolution de nom soit disponible depuis les autres commandes du système, il est nécessaire que l'adresse du serveur soit renseignée au niveau du système. Sous Linux, cette configuration se fait dans le fichier <tt>/etc/resolv.conf</tt>. Normalement, ce fichier doit indiquer l'adresse d'un serveur de résolution récursif. Mais notre plateforme n'étant pas reliée à l'Internet, nous utiliserons directement le serveur de noms que nous venons de configurer.<br />
<br />
Vérifier la configuration du serveur de noms pour le système PC-2 :<br />
root@PC-2::c2:~$# '''cat /etc/resolv.conf'''<br />
search tp.<br />
nameserver fd75:e4d9:cb77:3::c3<br />
<br />
Cette configuration permet d'utiliser le serveur de noms SRV-3 depuis les autres commandes du système.<br />
<br />
Vérifier la disponibilité de la résolution de nom à partir de l'outil <tt>ping6</tt> :<br />
root@PC-2::c2:~$# '''ping6 -c 5 r2-eth1.tp'''<br />
root@PC-2::c2:~$# '''ping6 -c 5 r1-eth1.tp'''<br />
root@PC-2::c2:~$# '''ping6 -c 5 pc1.tp'''<br />
<br />
Les commandes entrées sur '''PC-2''' peuvent maintenant utiliser des noms à la place des adresses IPv6.<br />
<br />
=== Configurer le nommage inversé ===<br />
<br />
Pour calculer les noms inversés à partir des adresses IPv6, il est possible d'utiliser l'utilitaire '''sipcalc'''. Cet outil est disponible sur PC-2.<br />
<br />
root@PC-2::c2:~$# '''sipcalc -a ''@IPv6(PC-1,R1,R2,PC-2)'' '''<br />
<br />
Exemple : <br />
<br />
root@PC-2::c2:~# '''sipcalc -a fd75:e4d9:cb77:1:68f7:7bff:fe8f:a80d'''<br />
-[ipv6 : fd75:e4d9:cb77:1:68f7:7bff:fe8f:a80d] - 0<br />
<br />
[IPV6 INFO]<br />
Expanded Address - fd75:e4d9:cb77:0001:68f7:7bff:fe8f:a80d<br />
Compressed address - fd75:e4d9:cb77:1:68f7:7bff:fe8f:a80d<br />
Subnet prefix (masked) - fd75:e4d9:cb77:1:68f7:7bff:fe8f:a80d/128<br />
Address ID (masked) - 0:0:0:0:0:0:0:0/128<br />
Prefix address - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff<br />
Prefix length - 128<br />
Address type - Unassigned<br />
Network range - fd75:e4d9:cb77:0001:68f7:7bff:fe8f:a80d -<br />
fd75:e4d9:cb77:0001:68f7:7bff:fe8f:a80d<br />
<br />
[V4INV6]<br />
Expanded v4inv6 address - fd75:e4d9:cb77:0001:68f7:7bff:254.143.168.13<br />
Compr. v4inv6 address - fd75:e4d9:cb77:1:68f7:7bff:254.143.168.13<br />
<br />
[IPV6 DNS]<br />
Reverse DNS (ip6.arpa) -<br />
'''d.0.8.a.f.8.e.f.f.f.b.7.7.f.8.6.1.0.0.0'''.7.7.b.c.9.d.4.e.5.7.d.f.ip6.arpa.<br />
<br />
En vous aidant de l'utilitaire <tt>sipcalc</tt> modifier le fichier correspondant à la zone de nommage inversé <tt>/etc/bind/db.tp.ipv6.rev</tt> :<br />
root@SRV-3::c3:~$# '''nano -w /etc/bind/db.tp.ipv6.rev'''<br />
<br />
'''Note'''. - Le paramètre '''-w''' de la commande nano est nécessaire pour s'assurer que chaque ressource ''record'' soit bien définie sur une seule ligne (Sans le '''-w''', l'éditeur insérera des sauts de ligne qui empêcheront le service ''named'' de fonctionner correctement).<br />
<br />
''''Rappel : '''' ''Dans l'éditeur <tt>nano</tt> vous pouvez alors parcourir le fichier à l'aide du curseur et l'éditer à l'endroit voulu. L'appui simultané sur <CTRL-O> (touche contrôle, simultanément à la lettre 'o') permet de sauvegarder le fichier, et <CTRL-X> de quitter l'éditeur. ''<br />
<br />
Modifier :<br />
Modifier : <br />
* incrémenter la valeur du numéro de série,<br />
* ajuster les adresses des '''parties inverses correspondantes aux champs SID et IID''' de pc1 et pc2 (''cf la partie affichée en gras dans l'exemple <tt>sipcalc</tt> précédent''), en effet le préfixe ULA inverse commun à ces adresses est déjà renseigné, grâce à la clause $ORIGIN).<br />
<br />
<br />
...<br />
...<br />
'''2015102200''' ; serial<br />
...<br />
...<br />
'''<l’adresse_pc1_REVERSE> IN PTR pc1.tp.'''<br />
'''<l’adresse_pc2_REVERSE> IN PTR pc2.tp.'''<br />
'''1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r1-eth1.tp.'''<br />
'''2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r2-eth1.tp.'''<br />
<br />
Exemple sur la modification du fichier <tt>/etc/bind/db.tp.ipv6.rev</tt> :<br />
...<br />
...<br />
20151022'''01''' ; serial<br />
...<br />
...<br />
$ORIGIN 7.7.b.c.9.d.4.e.5.7.d.f.ip6.arpa.<br />
'''d.0.8.a.f.8.e.f.f.f.b.7.7.f.8.6.1.0.0.0 IN PTR pc1.tp.'''<br />
'''9.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR pc2.tp.'''<br />
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r1-eth1.tp.<br />
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r2-eth1.tp.<br />
<br />
'''Note'''. - Le "'''.'''" final à la fin de chaque RR (''Ressource Record'') de type PTR est nécessaire. Ainsi noter bien <tt>d.0.8.a.f.8.e.f.f.f.b.7.7.f.8.6.1.0.0.0 IN PTR pc1.tp'''''POINT-FINAL'''''</tt> <br />
<br />
'''Note'''. - Le fichier de la zone pour le nommage inversé contient une directive,<br />
$ORIGIN 7.7.b.c.9.d.4.e.5.7.d.f.ip6.arpa.<br />
permettant d'éviter de noter de manière redondante les éléments communs aux noms inversés.<br />
<br />
<!--<br />
Relancer BIND. <br />
root@SRV-3::c3:~$# '''named-checkconf -z'''<br />
root@SRV-3::c3:~$# '''killall named'''<br />
root@SRV-3::c3:~$# '''named -c /etc/bind/named.conf'''<br />
root@SRV-3::c3:~$# '''service bond9 restart'''<br />
--><br />
Relancer BIND. <br />
root@SRV-3::c3:~$# '''named-checkconf -z'''<br />
root@SRV-3::c3:~$# '''named -c /etc/bind/named.conf'''<br />
root@SRV-3::c3:~$# '''service bind9 restart'''<br />
<br />
Tester la configuration en local sur PC-2.<br />
root@PC-2::c2:~$# '''dig -x ''adresse_PC-1'' '''<br />
Vous pouvez également ajouter le paramètre <tt>+short</tt> pour un affichage plus concis.<br />
root@PC-2::c2:~$# '''dig -x ''adresse_PC-1'' +short '''<br />
Tester également les autres enregistrements inversés que vous avez référencés dans la zone contenue dans le fichier fichier <tt>/etc/bind/db.tp.ipv6.rev</tt> <br />
root@PC-2::c2:~$# '''dig -x ''adresse_PC-2'' +short '''<br />
<br />
== Etape 5 : Distribution des informations d'accès au service de noms par DHCPv6 ==<br />
<br />
Votre plateforme comporte maintenant un serveur permettant d'utiliser des noms à la place des adresses IPv6. Pour que ce serveur puisse être utilisé par les autres machines de la plateforme, le système de chaque machine peut être configuré manuellement avec l'adresse du serveur. Mais certaines de ces machines (notamment '''PC-1''') utilisent la configuration automatique des paramètres réseau. Pour être cohérent, l'adresse du serveur de résolution récursif doit donc être, elle aussi, configurée automatiquement sur '''PC-1'''.<br />
<br />
Il existe plusieurs méthodes pour effectuer cette configuration automatiquement, dont le RFC 6106, permettant d'inclure l'adresse dans les annonces de routeur, et DHCPv6. C'est cette dernière méthode que vous allez mettre en oeuvre. Vous allez réutiliser le serveur DHCPv6 configuré dans l'étape 2 pour qu'il transmette aussi l'adresse du serveur de résolution récursif. Pour que '''PC-1''' puisse atteindre ce serveur, la configuration d'un relai DHCPv6 sur '''R1''' est alors nécessaire.<br />
<br />
<center><br />
[[image:MoocSession5_act36_autoconf2_20190604.png|400px|thumb|center|Figure 6: .Localisation des éléments du service DHCPv6.]]<br />
</center><br />
<br />
=== Configurer le serveur DHCPv6 ===<br />
<br />
Le serveur DHCPv6 sur '''SRV-3''' doit être configuré pour transmettre l'adresse du serveur de résolution ainsi que pour accepter les requêtes relayées par R1 depuis son interface <tt>eth1</tt> connectée au réseau d'infrastructure le reliant à R1.<br />
<br />
Sur SRV-3, observer la configuration du serveur DHCPv6 ainsi:<br />
root@SRV-3::c3:～$ '''cat /etc/dhcp/dhcpd6.conf'''<br />
<br />
=== Configurer le relai DHCPv6 ===<br />
<br />
Sur R1, activer le relai DHCPv6 :<br />
vyos@r1:～$ '''configure'''<br />
vyos@r1# '''set service dhcpv6‐relay listen-interface eth0 address fd75:e4d9:cb77:1::1 '''<br />
vyos@r1# '''set service dhcpv6‐relay upstream-interface eth1 address fd75:e4d9:cb77:3::c3 '''<br />
vyos@r1# '''commit'''<br />
vyos@r1:～$<br />
<br />
'''R1''' est maintenant configuré avec la fonction de relai. La première commande permet de désigner l'interface où le logiciel de relayage doit être en écoute, ici <tt>eth0</tt> (pour recevoir les requêtes du client) et la deuxième commande permet de relayer en Unicast les requêtes sur <tt>eth1</tt> vers le serveur.<br />
<br />
Configurer les annonces de routeur pour le réseau PC1-R1.<br />
vyos@r1:～$ '''vtysh'''<br />
r1# '''configure terminal'''<br />
r1(config)# '''interface eth0'''<br />
r1(config-if)# '''ipv6 nd other-config-flag'''<br />
r1(config-if)# '''end'''<br />
r1# ''' '''<br />
<br />
Les annonces de '''R1''' contiennent maintenant une indication que les autres paramètres réseau (dont l'adresse du serveur de résolution) doivent être récupérés par DHCPv6.<br />
<br />
=== Récupérer et tester l'obtention du DNS depuis PC1 ===<br />
<br />
Sur PC, lancer la requête DHCPv6 par la commande : <br />
root@PC-1::c1:~$# '''dhclient -6 eth0'''<br />
<br />
Vérifier ensuite les paramètres réseau obtenus par PC1.<br />
<br />
root@PC-1::c1:~$# '''ifconfig'''<br />
root@PC-1::c1:~$# '''cat /etc/resolv.conf'''<br />
(''Normalement'' nameserver ''doit être celui de SRV-3'') <br />
<br />
Tester maintenant la configuration en local sur PC1.<br />
root@PC-1::c1:~$# '''dig -t AAAA pc1.tp'''<br />
root@PC-1::c1:~$# '''dig -x ''adresse_PC-1'' '''<br />
root@PC-1::c1:~$# '''ping6 -c 5 r2-eth1.tp'''<br />
<br />
=== Arrêt/Pause du simulateur ===<br />
Au besoin vous pouvez aussi figer l'exécution des équipements avec le bouton Pause ''"Suspend All devices"'', voire arrêter les équipements avec le bouton Stop ''"Stop All devices"''. <br />
<br />
L'état des équipements est sauvegardé en quittant. Pour quitter proprement GNS3, faire <tt>CTRL+Q</tt> ou faire, avec le menu déroulant ''File'' et l'action ''Quit''.<br />
<br />
== Conclusion==<br />
Cette activité a été très complète. On remarquera que le travail de configuration du réseau a porté sur la configuration des routeurs. Les hôtes sont auto-configurés et ne nécessitent aucune activité particulière. Nous avons vu également comment déployer le service de nommage. Il est important de souligner que ce dernier se configure de la même manière en IPv4 qu'en IPv6. Il vous appartient maintenant à adapter vos compétences acquises aux besoins de fonctionnement de votre réseau en IPv6.</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20514MOOC:Compagnon Act14-s72023-01-09T09:06:56Z<p>Jlandru: </p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
azerty [[#cas particulier des liaisons point à point]]<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br />
<!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--><br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
* [https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows| IPv6 on Windows]<br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Corrections_s8&diff=20495MOOC:Corrections s82023-01-06T17:33:50Z<p>Jlandru: /* Seq2 */</p>
<hr />
<div>Remplacer les QCM à réponses multiples par des systèmes de questions à réponse simple (ex: Ajouter une proposition vraie et ajouter une proposition "toutes les propositions sont vraies")<br />
<br />
<br />
== Seq0 ==<br />
A02Q04 : "adresse IP" => "adresse IP publique"<br />
<br />
Doc compagnon A02 : Donner une définition de datagramme<br />
<br />
== Seq1 ==<br />
A11E01 : Revoir le calcul (prise en compte des années bissextiles)<br />
''20221212; JL : remplacement des valeurs calculées sur la base de 365,25 jours/an au lieu de 365 dans la version précédente''<br />
<br />
A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul.<br />
<br />
''20221212; JL : Dans l'indice il est déjà indiqué qu' "il n'y a pas d'adresse réservée dans un sous-réseau".<br />
Ajout au doc compagnon d'un nota au paragraphe "Identification locale : l'IID (Interface IDentifier)" de l'activité A14'' <br />
<br />
Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast<br />
<br />
''20221212; JL : Act13, les passages concernés sont à présent en "gras".<br />
(cf ''définition du multicast'' et ''explication groupe réservé 1, adresse <tt>ff02::1</tt>)''<br />
<br />
Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?<br />
''20221213; JL : Ajout d'un "hors texte" au parargraphe "Préfixes de sous-réseaux (SID Subnet IDentifier)"<br />
du doc compagnon de l'activité A14.<br />
Doc Compagnon A13 :<br />
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.<br />
''20221214; JL : Ajout d'un exemple affichant les adresses LLA et ULA de l'interface eth0 de l'hôte cos<br />
et les adresses multicast sur lesquelles l'interface est à l'écoute''<br />
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe<br />
''20221214; JL : redondances supprimées dans l'annexe et renvoi au paragraphe "Structure de l'adresse multicast" pour le format général.''<br />
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?<br />
''20221214; JL : corrigé''<br />
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.<br />
''20221214; JL : corrigé''<br />
<br />
Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101<br />
'''''TODO'''''<br />
<br />
Doc Compagnon A14 : <br />
* donner un exemple de construction de l'IID à partir de l'adresse MAC<br />
''20230106; JL reformulation de certaines parties du paragraphe et ajout d'un exemple extrait de la commande <tt>ifconfig</tt>'' <br />
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)<br />
'''''TODO'''''<br />
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)<br />
''20230106; JL : Ajout d'une rubrique "Ressources complémentaires" précédant la rubrique "Pour aller plus loin" avec le pointeur sur la calculatrice CIDR. Ajout d'un hors texte au paragraphe "Représentation des subdivisions" renvoyant à la cette ressource.''<br />
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :<br />
** Adresse IPv6 de type "Public" pour les flux entrants,<br />
** Adresse IPv6 de type "Temporaire" pour les flux sortants.<br />
''20230106; JL : réécriture du paragraphe "Valeur temporaire aléatoire". "Public" est ambigu (quid des contextes privatifs ULA) j'ai utlisé "adresse principale" pour les flux entrants (en renvoyant sur le paragraphe IID opaque stable). J'ai conservé l'illustration de l'antique windows XP qui reste valide et cohérente relativement au nouveau contenu du paragraphe.''<br />
<br />
Toutes deux ont un IID généré pseudo-aléatoirement.<br />
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows<br />
''20230106; JL :Ajout de cette URL dans les références bibliographiques''<br />
<br />
== Seq2 ==<br />
<br />
Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation<br />
''20230104; BS : création d'un nouvel exercice portant sur la fragmentation. Cf mail de Bruno pour validation''<br />
Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon) pour les questions<br />
A23Q6<br />
A23Q7<br />
A23Q8<br />
<br />
== Seq3 ==<br />
<br />
S3E02 : Reformuler la question ?<br />
<br />
TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?<br />
<br />
== Seq4 ==<br />
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)<br />
<br />
Questions A44 : Attention à l'acronyme ALG : <br />
* A44Q01 : "Application Level Gateway"<br />
* A44Q06 : "Application Layer Gateway"</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Corrections_s8&diff=20494MOOC:Corrections s82023-01-06T17:29:50Z<p>Jlandru: /* Seq1 */</p>
<hr />
<div>Remplacer les QCM à réponses multiples par des systèmes de questions à réponse simple (ex: Ajouter une proposition vraie et ajouter une proposition "toutes les propositions sont vraies")<br />
<br />
<br />
== Seq0 ==<br />
A02Q04 : "adresse IP" => "adresse IP publique"<br />
<br />
Doc compagnon A02 : Donner une définition de datagramme<br />
<br />
== Seq1 ==<br />
A11E01 : Revoir le calcul (prise en compte des années bissextiles)<br />
''20221212; JL : remplacement des valeurs calculées sur la base de 365,25 jours/an au lieu de 365 dans la version précédente''<br />
<br />
A12E02 : Rappeler (doc compagnon ou dans indice) que l'IID peut être nul.<br />
<br />
''20221212; JL : Dans l'indice il est déjà indiqué qu' "il n'y a pas d'adresse réservée dans un sous-réseau".<br />
Ajout au doc compagnon d'un nota au paragraphe "Identification locale : l'IID (Interface IDentifier)" de l'activité A14'' <br />
<br />
Bien indiquer dans le doc compagnon qu'il n'y a pas d'adresse de broadcast<br />
<br />
''20221212; JL : Act13, les passages concernés sont à présent en "gras".<br />
(cf ''définition du multicast'' et ''explication groupe réservé 1, adresse <tt>ff02::1</tt>)''<br />
<br />
Doc compagnon : expliquer les conséquences d'un subnet au delà des 64 bits ?<br />
''20221213; JL : Ajout d'un "hors texte" au parargraphe "Préfixes de sous-réseaux (SID Subnet IDentifier)"<br />
du doc compagnon de l'activité A14.<br />
Doc Compagnon A13 :<br />
* Donner des exemples de construction des adresses multicast sollicité, afin de rendre plus facile la question A13E04.<br />
''20221214; JL : Ajout d'un exemple affichant les adresses LLA et ULA de l'interface eth0 de l'hôte cos<br />
et les adresses multicast sur lesquelles l'interface est à l'écoute''<br />
* Attention une redondance dans le doc compagnon sur le multicast sollicité entre le chapitre A13 et son annexe<br />
''20221214; JL : redondances supprimées dans l'annexe et renvoi au paragraphe "Structure de l'adresse multicast" pour le format général.''<br />
* L'exemple pour l'adresse multicast Embedded-RP du point de rendez-vous est 2001:660:3307:125::3 alors qu'à la page suivante on indique son préfixe comme étant 2001:660:3007:125/64 et l'adresse multicast dérivée ff7x:340:2001:660:3007:125:aabb:ccdd. Le 3 de 3307 du point de rendez-vous ne devrait-il pas être un 0?<br />
''20221214; JL : corrigé''<br />
* Aussi, dans cette section, le format pour les identifiants de groupe aabb:ccdd peut laisser croire que les deux symboles hexadécimaux qui composent un octet doivent être les mêmes, alors qu'il s'agit uniquement de marques de positions des quartets. Ça peut perturber les lecteurs qui ne sont pas familiers avec l'hexadécimal et qui pourraient penser que 11aa:77ee est un identifiant de groupe valide alors que 12ab:78ef ne l'est pas.<br />
''20221214; JL : corrigé''<br />
<br />
Vidéo A13 partie 1 : Au niveau du cours A13 partie 1 à la minute 7:00, le fd de l'adresse locale unique est représenté 11110001 en binaire au lieu de 11111101<br />
'''''TODO'''''<br />
<br />
Doc Compagnon A14 : <br />
* donner un exemple de construction de l'IID à partir de l'adresse MAC<br />
''20230106; JL reformulation de certaines parties du paragraphe et ajout d'un exemple extrait de la commande <tt>ifconfig</tt>'' <br />
* nouvelle structure pour les adresses multicast IPv6 ? (RFC3306 et 7371)<br />
'''''TODO'''''<br />
* Donner un pointeur vers une calculette subnet (exemple : https://fr.rakko.tools/tools/27/)<br />
''20230106; JL : Ajout d'une rubrique "Ressources complémentaires" précédant la rubrique "Pour aller plus loin" avec le pointeur sur la calculatrice CIDR. Ajout d'un hors texte au paragraphe "Représentation des subdivisions" renvoyant à la cette ressource.''<br />
* Etendre la mise en oeuvre pour Windows. J'ai lu la page 63. Il faudrait la modifier pour utiliser la terminologie Microsoft :<br />
** Adresse IPv6 de type "Public" pour les flux entrants,<br />
** Adresse IPv6 de type "Temporaire" pour les flux sortants.<br />
''20230106; JL : réécriture du paragraphe "Valeur temporaire aléatoire". "Public" est ambigu (quid des contextes privatifs ULA) j'ai utlisé "adresse principale" pour les flux entrants (en renvoyant sur le paragraphe IID opaque stable). J'ai conservé l'illustration de l'antique windows XP qui reste valide et cohérente relativement au nouveau contenu du paragraphe.''<br />
<br />
Toutes deux ont un IID généré pseudo-aléatoirement.<br />
Cette ressource est plus claire il me semble : https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows<br />
''20230106; JL :Ajout de cette URL dans les références bibliographiques''<br />
<br />
== Seq2 ==<br />
<br />
Exercice A24 : Remplacer l'extension RH0 par une extension de fragmentation<br />
<br />
Refaire A23 : QUIZ DOCUMENT COMPAGNON (car doublon) pour les questions<br />
A23Q6<br />
A23Q7<br />
A23Q8<br />
<br />
== Seq3 ==<br />
<br />
S3E02 : Reformuler la question ?<br />
<br />
TP A36 : l'étape 1 contient déjà des configurations, revoir le sujet ?<br />
<br />
== Seq4 ==<br />
Doc compagnon A42 / Tunnel configuré : revoir l'adressage des points d'entrée de tunnel (/64 ou /127 ?)<br />
<br />
Questions A44 : Attention à l'acronyme ALG : <br />
* A44Q01 : "Application Level Gateway"<br />
* A44Q06 : "Application Layer Gateway"</div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20493MOOC:Compagnon Act14-s72023-01-06T17:19:24Z<p>Jlandru: /* Références bibliographiques */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br />
<!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--><br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
* [https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows| IPv6 on Windows]<br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20492MOOC:Compagnon Act14-s72023-01-06T17:16:03Z<p>Jlandru: /* Valeur stable opaque */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br />
<!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--><br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20491MOOC:Compagnon Act14-s72023-01-06T17:15:18Z<p>Jlandru: /* Valeur stable opaque */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
<!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--><br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20490MOOC:Compagnon Act14-s72023-01-06T17:14:42Z<p>Jlandru: /* Valeur temporaire aléatoire */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20489MOOC:Compagnon Act14-s72023-01-06T17:10:42Z<p>Jlandru: /* Valeur temporaire aléatoire */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20488MOOC:Compagnon Act14-s72023-01-06T17:09:40Z<p>Jlandru: /* Valeur stable opaque */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID opaque (ne révélant pas d'information) stable, utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20487MOOC:Compagnon Act14-s72023-01-06T17:06:27Z<p>Jlandru: /* Valeur temporaire aléatoire */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID opaque (ne révélant pas d'information) stable, utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20486MOOC:Compagnon Act14-s72023-01-06T17:02:39Z<p>Jlandru: /* Valeur temporaire aléatoire */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID opaque (ne révélant pas d'information) stable, utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA étant purement locales et non routables, elles sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandruhttp://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20485MOOC:Compagnon Act14-s72023-01-06T17:01:53Z<p>Jlandru: /* Valeur temporaire aléatoire */</p>
<hr />
<div>__NOTOC__<br />
<!-- = Activité 14 : L'utilisation des adresses sur une interface = --><br />
= Activité 14 : Plan d'adressage IPv6 unicast =<br />
<!-- {{Approfondissement}} --><br />
== Introduction ==<br />
Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br />
Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br />
Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br />
Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br />
</center><br />
<br />
Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage<ref>RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']</ref>. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br />
<br />
== Adressage multiple des interfaces ==<br />
<br />
En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br />
</center><br />
<br />
Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br />
L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br />
<br />
== Nécessité d'organiser un plan d'adressage ==<br />
L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br />
<br />
== Politique d'assignation des adresses ==<br />
Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br />
* /48 (65536 sous-réseaux) dans le cas général,<br />
* /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br />
* /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br />
<br />
Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br />
<br />
== Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br />
<br />
{{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § "Cas particulier des liaisons point à point" ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br />
<br />
Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br />
<br />
Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br />
<br />
<center><br />
[[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br />
</center><br />
<br />
=== Représentation des subdivisions ===<br />
Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br />
{{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1ère adresse, dernière adresse, nombre d'adresses,...) d'après sa longueur, vous pouvez vous aidez d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br />
Nous supposons que le préfixe pour notre activité est <tt>2001:db8:cafe::/48</tt>. Le préfixe est obtenu :<br />
* soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br />
* soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br />
Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de <tt>2001:db8:cafe::/64</tt> à <tt>2001:db8:cafe:ffff::/64</tt>).<br />
<br />
=== Convention de notation binaire du champ SID ===<br />
Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br />
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).<br><br />
<br>Exemple : <br />
<center><br />
<tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt><br><br />
ou<br><br />
<tt>2001:db8:cafe:ltbb::/64</tt><br />
</center><br />
<br />
* Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;<br>''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br />
* Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br />
* Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br />
** B : bit non défini et assignable ;<br />
** L : bit assigné à l'identification de la localisation du sous-réseau ;<br />
** T : bit assigné à l'identification du type de sous-réseau.<br />
<br />
Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur <tt>{LLLLTTTTBBBBBBBB}</tt> produira des préfixes IPv6 du type <tt>2001:db8:ltbb::/64</tt>. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière <tt>{TTTTLLLLBBBBBBBB}</tt>, cela produira un préfixe de type <tt>2001:db8:tlbb::/64</tt>.<br />
<br />
Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br />
<br />
=== Cas particulier des liaisons point à point ===<br />
Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br />
À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br />
* /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br />
* /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br />
* /120 permet de s'affranchir des adresses anycast réservées.<br />
* /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br />
<br />
Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br />
<br />
== Identification locale : l'IID (Interface IDentifier) ==<br />
<br />
Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br />
<br />
Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br />
<br />
'''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs "tout à zéro" et "tout à 1" sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : <tt>2001:db8:c0ca:c01a::/64</tt> ; les adresses <tt>2001:db8:c0ca:c01a::/64</tt> et <tt>2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64</tt> sont valides et potentiellement assignables à une interface.''<br />
<br />
Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br />
<br />
* manuelle,<br />
* basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br />
* temporaire aléatoire [RFC 8981],<br />
* stable opaque [RFC 7217] <br />
* cryptographique [RFC 3972].<br />
<br />
==== Identifiant manuel ====<br />
Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br />
<br />
''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br />
<br />
Il existe plusieurs techniques plus ou moins mnémotechniques :<br />
<br />
* Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br />
<center> <br />
<tt>2001:db8:1234:1::1<br><br />
2001:db8:1234:1::2</tt><br />
</center><br />
<br />
* Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br />
<center><br />
<tt>2001:db8:1234:1::7B</tt><br><br />
</center><br />
ou plus simplement<br><br />
<center><br />
<tt>2001:db8:1234:1::123</tt><br />
</center><br />
<br />
* Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br />
<center><br />
<tt>2001:db8:1234:1::192.0.2.123</tt><br />
</center><br />
<br />
==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br />
<br />
<!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br />
identifiant d'interface est que l'unicité de cette valeur est<br />
presque toujours assurée. En plus, cette valeur est stable tant que<br />
la carte réseau de la machine n'est pas changée. Par contre, ces<br />
valeurs sont difficilement mémorisables. --><br />
Les caractéristiques des adresses matérielles de niveau 2 : <br />
* unicité garantie sur le lien local ;<br />
* stabilité tant que la carte réseau est inchangére ;<br />
sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br />
<br />
Ces identifiants d'interfaces étant stables dans le temps, à<br />
chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br />
mais garde le même identifiant d'interface. Ce dernier pourrait donc<br />
servir à tracer les déplacements d'un individu<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br />
<!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --><br />
<br />
Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br />
<br />
===== Identificateur EUI-64 =====<br />
<br />
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br />
<br />
Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :<br />
** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br />
** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br />
</center><br />
<br />
Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit <tt>u</tt> comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br />
</center><br />
<br />
===== Identificateur MAC-48 =====<br />
<br />
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée <tt>0xfffe</tt>, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br />
<br />
<center><br />
[[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br />
</center><br />
<br />
Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : <tt>52:54:00:8A:50:A5</tt>. L'adresse LLA <tt>fe80::5054:ff:fe8a:50a5</tt> allouée automatiquement à l'initialisation de l'interface dispose de l'IID <tt>'''5054:ff:fe8a:50a5'''</tt> déduit de l'adresse MAC en insérant les 16 bits réservés <tt>ff:fe</tt> entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit <tt>u</tt> traduit l'octet de poids fort de la valeur <tt>0x5'''2'''</tt> en <tt>0x5'''0'''</tt>. <br />
<br />
cos:~$ ifconfig eth2<br />
eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br />
inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br />
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br />
<br />
===== Cas Particuliers =====<br />
<br />
Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit <tt>u</tt> positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br />
<br />
===== Opacité des identifiants d'interface =====<br />
Les bits <tt>u</tt> et <tt>g</tt> n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit <tt>u</tt> conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br />
<br />
==== Valeur temporaire aléatoire ====<br />
<br />
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il serait alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br />
<br />
Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br />
continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br />
<br />
La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br />
* Une adresse principale avec un IID opaque (ne révélant pas d'information) stable, utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs "publics" de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br />
* Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br />
'''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA étant purement locales et non routables, elles sont moins sujettes à la traçabilité.''<br />
<br />
<!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications "serveur"). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --><br />
Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.<br><br />
<br />
En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses.<br />
<br />
<center><br />
[[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br />
</center><br />
<br />
==== Valeur stable opaque ====<br />
<br />
L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br />
<br />
L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br />
<br />
==== Cryptographique ====<br />
<br />
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br />
<br />
== Conclusion ==<br />
<br />
Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br />
<br />
L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br />
La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br />
<br />
== Références bibliographiques ==<br />
<references /><br />
<br />
== Ressources complémentaires ==<br />
* Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br />
<br />
== Pour aller plus loin==<br />
<br />
RFC et leur analyse par S. Bortzmeyer :<br />
* RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br />
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br />
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br />
* RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br />
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br />
* RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br />
* RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br />
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br />
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br />
* RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br />
* RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br />
* RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br />
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br />
<br />
= Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br />
<br />
Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br />
<br />
=== Réseau à plat ===<br />
Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.<br><br />
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br />
<br />
=== Correspondance directe entre les identifiants IPv4 et IPv6 ===<br />
Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br />
<br />
==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br />
Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C <tt>192.168.0.0/24</tt> à <tt>192.168.255.0/24</tt> ou que l'on a « subnetté » en /24 le réseau de classe A <tt>10.0.0.0</tt> ou l'un des 16 classe B <tt>172.16.0.0</tt> à <tt>172.31.0.0</tt>), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br />
<br />
<br />
<center>[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br />
</center><br />
Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4<sup>e</sup> octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 <tt>192.168.1.123</tt> peut être adressé <tt>2001:db8:cafe:1::123</tt> en IPv6.<br><br />
Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe < /24) ou plus réduite (préfixe > /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br />
* un préfixe IPv4 /28, par exemple les hôtes <tt>172.16.5.14/28</tt> et <tt>172.16.5.18/28</tt> sont dans des sous-réseaux IPv4 distincts : le sous-réseau <tt>172.16.5.0/28</tt> pour le premier et le sous-réseau <tt>172.16.5.16/28</tt> pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes <tt>2001:db8:cafe:5::14/64</tt> et <tt>2001:db8:cafe:5::18/64</tt> sont tous les deux dans le sous-réseau <tt>2001:db8:cafe:5::/64</tt>.<br />
* Un préfixe IPv4 /23, par exemple les hôtes <tt>10.0.8.250/23</tt> et <tt>10.0.9.5/23</tt> sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : <tt>2001:db8:cafe:8::250/64</tt> et <tt>2001:db8:cafe:9::5/64</tt><br />
On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 <tt>10.0.23.0/24</tt> est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br />
<br />
==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br />
Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 <tt>192.168.1.234</tt> pourrait être adressée en IPv6 <tt>2001:db8:cafe:deca::192.168.1.234</tt>. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique <tt>2001:db8:cafe:deca::c0a8:1ea</tt>, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite <tt>192.168.1.234</tt> en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br />
<br />
=== Plan d'adressage structuré ===<br />
Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.<br><br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br />
</center><br />
<br />
==== Structuration basique du plan d'adressage ====<br />
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center> <br><br />
<br />
Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br />
<br />
==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br />
Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br />
<br />
===== Localisation d'abord =====<br />
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br />
===== Type d'usage d'abord =====<br />
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br />
L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br />
Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br />
<center><br />
[[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br />
</center><br />
<br />
==== Détermination de l'espace nécessaire au plan d'adressage ====<br />
Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br />
# Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br />
# Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br />
# Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br />
# Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br />
Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br />
<center><br />
[[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br />
</center><br />
<br />
===== Exemple 1 : sous-réseaux basés sur la localisation =====<br />
* nombre de localisations : 3<br />
* backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br />
* réseaux non localisés (tunnels VPN) : 1<br />
* extension future : 2<br />
'''total : 7 sous-réseaux''' => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br />
* nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br />
* backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br />
* usages futurs : 4 sous-reseaux<br />
'''total : 10 sous-réseaux''' => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br />
<center><tt>2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64</tt></center><br />
<br />
===== Hiérarchisation à 2 niveaux =====<br />
Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br />
Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br />
<center><tt>2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64</tt>,</center><br />
il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br />
Inversement, privilégier le type d'usage sur la localisation<br />
<center><tt>2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64</tt>,</center><br />
réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br />
<br />
===== Latitude =====<br />
Dans l'exemple précédent, 4 bits sont utilisés pour les types<br />
de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br />
(2 puissance 9) sous-réseaux possibles par type et par site. Cela<br />
sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br />
faille 2048 tunnels VPN par site pour accueillir les connexions<br />
sécurisées des personnels nomades. On pourrait envisager de<br />
modifier les tailles de champs de structuration primaire et<br />
secondaire, mais cela nécessiterait une reconfiguration globale de<br />
l'architecture. Une autre option consiste à répartir les tunnels<br />
sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br />
manière, on conserve une politique de sécurité simple et cohérente.<br />
<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="30%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''Type''' <br />
! scope="col" width="90%" align="center" | '''Usage'''<br />
<br />
|- style="background:silver"<br />
| '''0''' || '''Backbone, infrastructure'''<br />
|-<br />
| '''1''' || '''Serveurs'''<br />
|- style="background:silver"<br />
| 2 || Réservé expansion future<br />
|-<br />
| 3 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''4''' || '''Personnels'''<br />
|-<br />
| '''5''' || '''Étudiants'''<br />
|- style="background:silver"<br />
| '''6''' || '''Invités'''<br />
|-<br />
| 7 || Réservé expansion future<br />
|- style="background:silver"<br />
| '''8''' || '''VPN'''<br />
|-<br />
| '''9''' || '''VPN'''<br />
|- style="background:silver"<br />
| '''a''' || '''VPN'''<br />
|-<br />
| '''b''' || '''VPN'''<br />
|- style="background:silver"<br />
| c || Réservé expansion future<br />
|-<br />
| d || Réservé expansion future<br />
|- style="background:silver"<br />
| e || Réservé expansion future<br />
|-<br />
| f || Réservé expansion future<br />
|} <br />
</center><br />
<br />
===== Lisibilité =====<br />
Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br />
<center><tt>2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64</tt></center><br />
<center><tt>2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64</tt></center><br />
soit, en notation canonique, des adresses respectivement<br />
<center><tt>2001:db8:cafe:'''wx'''yz::/64</tt></center><br />
<center><tt>2001:db8:cafe:'''xw'''yz::/64</tt></center><br />
avec les "nibbles" '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br />
<br />
===== Extensibilité =====<br />
Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br />
Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br />
<center><tt>2001:db8:cafe:{LLL*****TT*****B}::/64</tt></center><br />
pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br />
<center><tt>2001:db8:cafe:{LLL*****TT**BBBB}::/64</tt></center><br />
Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br />
<center><tt>2001:db8:cafe:{LLL****TTT**BBBB}::/64</tt></center><br />
Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64</tt></center><br />
Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br />
<center><tt>2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64</tt></center><br />
'''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''<br><br />
'''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br />
<br><br />
<br />
=== Identification des sous-réseaux d'après les VLAN ===<br />
<br />
==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br />
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br />
<br />
==== Mise en correspondance VLAN-ID et SID ====<br />
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br />
<br />
* '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br />
<tt>2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64</tt><br />
</center><br />
<center><br />
ou<br />
</center><br />
<center><br />
VLAN-ID sur les bits de poids faible du SID<br />
<tt>2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64</tt><br />
</center><br />
<br />
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br />
<br />
* '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 <tt>2001:db8:cafe:4321::/64</tt> sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br />
<br />
Tableau récapitulatif des deux approches.<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="10%" align="center" | '''VLAN-ID''' <br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme décimale'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids faible'''<br />
! scope="col" width="30%" align="center" | '''IPv6 vlan-id forme hexadécimale poids fort'''<br />
<br />
|- align="center" style="background:silver"<br />
| '''1''' || <tt>2001:db8:cafe:000'''1'''::/64</tt> || <tt>2001:db8:cafe:0'''001'''::/64</tt> || <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''12''' || <tt>2001:db8:cafe:00'''12'''::/64</tt> || <tt>2001:db8:cafe:0'''00c'''::/64</tt> || <tt>2001:db8:cafe:'''00c'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| '''2783''' || <tt>2001:db8:cafe:'''2783'''::/64</tt> || <tt>2001:db8:cafe:0'''adf'''::/64</tt> || <tt>2001:db8:cafe:'''adf'''0::/64</tt><br />
<br />
|- align="center"<br />
| '''4094''' || <tt>2001:db8:cafe:'''4094'''::/64</tt> || <tt>2001:db8:cafe:0'''ffe'''::/64</tt> || <tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br />
<br />
==== Identification des VLAN selon la localisation ou le type d'usage ====<br />
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br />
<br />
* '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br />
<center><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 4 bits (1 quartet) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
localisation {W} sur 8 bits (2 quartets) privilégiée<br><br />
<tt>2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64</tt><br><br />
<br />
Inversement, si on privilégie le type d'usage<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 4 bits (1 quartet) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64</tt><br><br />
ou<br><br />
VLAN-ID sur les bits de poids fort du SID<br><br />
type d'usage {V} sur 8 bits (2 quartets) privilégié<br><br />
<tt>2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64</tt><br><br />
</center><br />
Quelques exemples illustratifs de la forme hexadécimale <br />
(localisation sur 1 quartet, type d'usage sur 2 quartets)<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" colspan="2" width="20%"| '''VLAN-ID'''<br />
! scope="col" colspan="2" width="20%"| '''localisation'''<br />
! scope="col" colspan="2" width="20%"| '''Type d'usage'''<br />
! scope="col" rowspan="2" width="40%"| '''IPv6 (VLAN-ID hexadécimal)'''<br />
|- align="center"<br />
| décimal || hexa || décimal || hexa || décimal || hexa<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| <tt>2001:db8:cafe:'''001'''0::/64</tt><br />
<br />
|- align="center"<br />
| 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br />
<tt>2001:db8:cafe:'''211'''0::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br />
<tt>2001:db8:cafe:'''ffe'''0::/64</tt><br />
<br />
|} <br />
</center><br />
<br />
* '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br />
<center> <br />
<tt>2001:db8:cafe:1025::/64</tt><br><br />
VLAN 1025, localisation (1) type d'usage (025) <br><br />
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (10) type d'usage (25)<br><br />
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets<br><br />
ou<br><br />
VLAN 1025, localisation (102) type d'usage (5) <br><br />
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet<br><br />
</center><br />
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br />
<center> <br />
{| border="0" class="wikitable alternance centre" width="90%"<br />
|- align="center"<br />
<br />
! scope="col" width="20%"| '''VLAN-ID'''<br />
! scope="col" width="20%"| '''localisation'''<br />
! scope="col" width="20%"| '''Type d'usage'''<br />
! scope="col" width="40%"| '''IPv6(VLAN-ID forme décimale)'''<br />
<br />
|- align="center" style="background:silver"<br />
| 0001 || 00 || 01 || <tt>2001:db8:cafe:'''0001'''::/64</tt><br />
<br />
|- align="center"<br />
| 0529 || 05 || 29 || <tt>2001:db8:cafe:'''0529'''::/64</tt><br />
<br />
|- align="center" style="background:silver"<br />
| 4094 || 40 || 94 || <tt>2001:db8:cafe:'''4094'''::/64</tt><br />
<br />
|}<br />
</center></div>Jlandru