MOOC:Compagnon Act13-s7 - Revision history

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-14T08:14:32Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-14T08:12:48Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Pour aller plus loin */

2024-09-13T19:05:40Z

‎Pour aller plus loin

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-13T19:03:26Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-13T18:59:26Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-13T17:50:02Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Les adresses unicast globales (GUA : Global Unicast Address) */

2024-09-13T17:46:20Z

‎Les adresses unicast globales (GUA : Global Unicast Address)

Jlandru: /* Activité 13 : Familles d'adresses IPv6 */

2024-09-13T17:41:29Z

‎Activité 13 : Familles d'adresses IPv6

Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */

2024-03-04T14:09:48Z

‎Correspondance avec les adresses de multicast de niveau 2

Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */

2024-03-04T14:07:12Z

‎Correspondance avec les adresses de multicast de niveau 2

@@ Line 193: / Line 193: @@
 '''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'').
-{{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".}}
+{{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".}}
 * 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).

@@ Line 193: / Line 193: @@
 '''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'').
-{{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".}}
+{{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".}}
 * 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).
@@ Line 202: / Line 202: @@
 * 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'').
 * 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.
-* 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.
+* '''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.
 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.

@@ Line 516: / Line 516: @@
 * RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]
 * RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]
 = Annexe : Le multicast en IPv6 =

@@ Line 193: / Line 193: @@
 '''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'').
-{{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" }}
+{{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".}}
 * 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).

@@ Line 193: / Line 193: @@
 '''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'').
-{{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).}}
+{{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" }}
 * 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).
@@ Line 202: / Line 202: @@
 * 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'').
 * 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.
-* 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.
+* 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.
 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.

@@ Line 703: / Line 703: @@
 == Correspondance avec les adresses de multicast de niveau 2 ==
-{{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (multicast) 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 derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.
+{{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.
-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 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 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 utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.
+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.
 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>.}}
 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.