Latest revision as of 09:14, 14 September 2024

Activité 13  : Familles d'adresses IPv6

Introduction

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. Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.

Types d'adresses

IPv6 définit trois types d'adresses : unicast, multicast, anycast.

• 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 :
  
  • globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;
    
  • localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;
    
  • 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.

Figure 1 : L'adressage unicast (communication de type 1 vers 1).

• 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 "général" 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.

Figure 2 : L'adressage multicast (communication de type 1 vers n).

• 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 "plus proche" 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.

Figure 3 : L'adressage anycast (communication de type 1 parmi n).

Identification des types d'adresses

Le type d'une adresse IPv6 est identifié par ses bits de poids fort.

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 0::/8 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.

Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.

Les adresses anycast ne sont pas distinguées des adresses unicast de quelque portée (globale, locale, lien) que ce soit.

L'adressage unicast

Structure de l'adresse unicast

Le plan d'adressage agrégé actuellement en vigueur est défini dans le RFC 3587. Il s'inspire des recommandations de la politique d'allocation d'adresse des autorités régionales (RIR Regional Internet Registry), définie dans le document ripe-267 et dans le RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48 bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.

Les adresses IPv6 peuvent être agrégées avec des préfixes de longueur quelconque, de manière similaire aux mécanismes mis en œuvre dans les architectures CIDR (Classeless InterDomain Routing) d'IPv4.

Un nœud peut avoir une connaissance minimale de la structuration interne de l'adresse, en fonction de son rôle dans l'interconnexion. Un hôte ou un routeur n'a ainsi pas la même vision de la structure de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast comme un simple mot binaire de 128 bits, sans aucune structure particulière telle que présentée dans la figure 4.

Figure 4 : Structure minimale de l'adresse IPv6.

Un premier niveau de hiérarchisation découpe l'adresse en deux parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé pour acheminer le paquet à travers le réseau, et un identifiant d'interface qui sera utilisé sur le dernier saut pour remettre le 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.

Figure 5 : Hiérarchisation à deux niveaux logiques.

Différents types d'adresse unicast

L'adresse non spécifiée

L'adresse 0:0:0:0:0:0:0:0 ou ::/128 est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée à un nœud. Elle indique l'absence d'adresse. Elle est utilisée comme adresse source par les paquets d'initialisation lors de l'auto-configuration d'une station. Elle ne doit jamais être utilisée comme adresse de destination d'un paquet.

L'adresse de bouclage (loopback)

L'adresse unicast 0:0:0:0:0:0:0:1 ou ::1/128 est appelée adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1 d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à lui-même. Elle ne doit jamais être affectée à une interface. Elle est considérée comme ayant une étendue de type "lien-local" et doit être vue comme une adresse unicast de "lien-local" de l'interface virtuelle de bouclage (loopback interface). Elle ne doit jamais être utilisée comme adresse source ou destination d'un paquet circulant sur le réseau ou, plus exactement, un paquet circulant hors de la machine. Un paquet reçu sur une interface avec une telle adresse de destination doit être détruit.

Les adresses unicast globales (GUA : Global Unicast Address)

Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ». Les adresses unicast globales sont issues du plan d'adressage agrégé, proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire 0b0010^[1], soit 2000::/3 en notation IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc une adresse unicast globale.

Le RFC 3587 définit la structure d'adressage IPv6 définie dans le RFC 4291 en précisant les tailles de chacun des blocs. Il est géré hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :

• une topologie publique (appelée Global Prefix) codée sur 48 bits, allouée par le fournisseur d'accès ;
• 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 ;
• un identifiant d'interface sur 64 bits (appelé Interface ID) distinguant les différentes machines sur le lien.

Figure 6 : Format général de l'adresse unicast globale.

À part le préfixe 2002::/16 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^[2] qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un /56. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

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).

• Le préfixe 2002::/16 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).
• Le préfixe 2001:db8::/32 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.
• Le préfixe 2001:5::/32 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.
• Le préfixe 2001:10::/28 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)
• Le préfixe 2001:20::/28 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.
• Le préfixe 2001:1::1/128 adresse anycast du protocole PCP (Port Control Protocol) réservé par le RFC 7723 (Port Control Anycast Address).
• Le préfixe 3ffe::/16 é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 3fff::/20 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 2001:db8::/32 reste réservé et valable, il n'est donc pas nécessaire de modifier les documentations existantes.

Le plan agrégé 2000::/3 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 (2000::/3) 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.

La plage 2001::/16 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^[2].

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 :

Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).

Les adresses unicast locales

Il y a deux types d'adresse unicast qui sont utilisées localement :

• les adresses locales de lien, dites "lien-local" que nous noterons aussi LLA (Link Local Address) ;
• les adresses unicast locales uniques notées ULA (Unique Local unicast Address).

Les adresses locales de lien (LLA : Link Local Address)

Les adresses "lien-local", sont des adresses dont l'étendue de 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. Les adresses "lien-local" sont analogues aux adresses APIPA^[3] (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).

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.

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".

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.

La figure 8 représente le préfixe d'identification qui est fe80::/10. L'adresse "lien-local" a le format suivant : préfixe fe80::/64 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.

Figure 8 : Format de l'adresse lien-local.

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 "%". Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.

Les adresses locales uniques (ULA : Unique Local unicast Address)

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).

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. 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.

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 :

• Prefix (7 bits) : fc00::/7 préfixe identifiant les adresses IPv6 locales (ULA) ;
• 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 fd00::/8) ;
• Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (Globally Unique Prefix) ;
• Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;
• Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.

Figure 9 : Format de l'adresse unicast locale.

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 10.0.0.0/8) é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.

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.

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é, fc00::/7, 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.

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 :

• préfixe globalement unique (très forte probabilité d'unicité) ;
• un préfixe bien connu fc00::/7 facilitant le filtrage aux frontières du site ;
• limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;
• indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;
• indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;
• 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.

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).

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 :

1. prendre l'heure courante dans le format 64 bits du protocole NTP ;
2. 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 ;
3. concaténer l'heure et l'identifiant d'interface pour créer une clé ;
4. calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;
5. prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;
6. préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8^e bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».

L'outil en ligne disponible à l'URL 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.

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 fc00::/7.

Portée de l'adresse unicast

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é".

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.

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.

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.

L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.

L'adressage multicast

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.

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.

Structure de l'adresse multicast

Les adresses multicast IPv6 sont dérivées du préfixe ff00::/8. 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].

Figure 1 : Format général de l'adresse multicast.

Le champ drapeaux (flags) spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ drapeaux, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :

• 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 ;
• le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;
• 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] ;
• le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ étendue (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 durée de vie (Time To Live (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :

• 0 - reserved
• 1 - node-local
• 2 - link-local
• 3 - realm-local
• 4 - admin-local
• 5 - site-local
• 8 - organisation-local
• e - global
• f - reserved

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é).

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.

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.

Adresses de multicast de voisinage nécessaires à la gestion d'IPv6

diffusion restreinte : tous les nœuds du lien

L'identifiant de groupe à la valeur réservée "1" concerne tous les nœuds. Il est limité aux étendues "interface locale" ff01::1 et "lien local" ff02::1. 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.

diffusion restreinte : tous les routeurs du lien

Le groupe d'identifiant multicast à la valeur réservée "2" diffuse à l'ensemble des routeurs. Il est limité aux étendues "interface locale" ff01::2, "lien local" ff02::2 et "site local" ff05::2. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.

diffusion restreinte : l'adresse multicast sollicité

Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de "multicast sollicité".

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 ff02::1 (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.

L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé ff02::1:ff00:0 /104 aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format Solicited-node address.

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.

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.

Figure 7 : Format de l'adresse "multicast sollicité".

Dans l'exemple suivant l'hôte cos s'est vu assigner l'adresses LLA fe80::5054:ff:fe1d:534c/64 et l'ULA fd7e:1ec0:3111:80:5:0:400:0/64 sur l'interface eth0

cos:~$ ip -6 addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp1s0
    inet6 fd7e:1ec0:3111:80:5:0:400:0/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe1d:534c/64 scope link 
       valid_lft forever preferred_lft forever

La commande ip -6 maddr show eth0 affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse ff01::1 (toutes les interfaces de l'hôte), l'addresse ff02::1 (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité ff02::1:ff1d:534c et ff02::1:ff00:0 construites en concaténant le préfixe réservé ff02::1:ff aux trois derniers octets des IID respectivement de l'adresse LLA fe80::5054:ff:fe1d:534c/64 ainsi que de l'adresse ULA fd7e:1ec0:3111:80:5:0:400:0/64.

cos:~$ ip -6 maddr show eth0
2:      eth0
        inet6 ff02::1:ff00:0
        inet6 ff02::1:ff1d:534c
        inet6 ff02::1
        inet6 ff01::1

conclusion

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.

Références bibliographiques

1. ↑ Notation binaire. Que signifie «0b».
2. ↑ ^{2.0 2.1} IANA. IPv6 Global Unicast Address Assignments
3. ↑ Wikipédia. Automatic Private Internet Protocol Addressing

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 1546 Host Anycasting Service
• RFC 1918 Address Allocation for Private Internets Analyse
• RFC 3587 IPv6 Global Unicast Address Format
• RFC 3849 IPv6 Address Prefix Reserved for Documentation Analyse
• RFC 3879 Deprecating Site Local Addresses Analyse
• RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses Analyse
• RFC 4048 RFC 1888 Is Obsolete
• RFC 4193 Unique Local IPv6 Unicast Addresses Analyse
• RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture
• RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses
• RFC 6177 IPv6 Address Assignment to End Sites Analyse
• RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space Analyse
• RFC 6890 Special-Purpose IP Address Registries Analyse
• RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) Analyse
• RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing Analyse
• RFC 7723 Port Control Protocol (PCP) Anycast Addresses Analyse
• RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block Analyse
• RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block Analyse
• RFC 8190 Updates to the Special-Purpose IP Address Registries Analyse
• RFC 9637 Expanding the IPv6 Documentation Space Analyse

Annexe : Le multicast en IPv6

Introduction

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^[1]. Multicast IP est présenté en détail par cet article de Cisco ^[2]. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast^[3] uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.

Communication multicast

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. 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.

Le service de communication multicast se rend selon 2 modèles :

• 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 ;
• 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.

Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :

• choix de l'adresse multicast pour la session ;
• description et annonce de la session multicast à tous les participants ;
• gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (Multicast Listener Discovery) ;
• construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (Protocol Independant Multicast).

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.

Formats des adresses multicast IPv6

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.

Format général

Le format détaillé des adresses multicast est présenté ci dessus au paragraphe "Structure de l'adresse multicast"

Adresses multicast IPv6 permanentes

Une adresse multicast IPv6 avec le bit T du champ drapeaux à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.

Figure 2 : Format de l'adresse multicast permanente.

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 ff00::/12.

Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :

• des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;
• des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.

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).

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^[4] de l'ensemble des adresses multicast réservées.

• L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : ff0x:0:0:0:0:0:0:0 avec x variant de '0' à 'f'.
• 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).

• 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").

Adresses multicast IPv6 temporaires

Les adresses multicast temporaires sont des adresses multicast IPv6 dont le 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. Exemple : l'adresse multicast site-local ff15::999 sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site. 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).

Adresses multicast temporaires générales

Ce sont des adresses avec tous les bits du champ drapeaux à 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.

Figure 3 : Format général de l'adresse multicast temporaire.

Adresses multicast temporaires dérivées d'un préfixe unicast IPv6

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.

Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.

• res (reserved) : tous les bits de ce champ doivent être positionnés à 0.
• Plen (prefix length) : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.
• prefix : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.
• group-ID : ce champ de 32 bits contient l'identifiant de groupe.

Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (2001:660::/32). Le champ prefix prend la valeur 2001:0660, et le champ Plen, la valeur 0x20 (32 en décimal). Les adresses multicast IPv6 à choisir seront de type ff3x:20:2001:660::a34b:c56d ; a34b:c56d étant le group-ID choisi dans l'exemple, et x une des valeurs valides de la portée (scope). Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.

Adresses multicast Embedded-RP

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.

Figure 5 : Format de l'adresse multicast temporaire embedded-RP.

Ainsi, pour un point de rendez-vous qui possède l'adresse 2001:660:3007:125::3, une adresse multicast correspondante peut être dérivée de la façon suivante :

• res (Reservé) : les 4 bits de ce champ sont positionnés à 0.
• RPad : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.
• Plen (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 0x40 (soit 64 en décimal).
• prefix (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est 2001:660:3007:125
• group-ID : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre "Identifiant de groupe".

Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme ff7x:340:2001:660:3007:125:a1b2:c3d4 ; a1b2:c3d4 étant le group-ID choisi dans cet exemple, et x une des valeurs valides de la portée (scope).

Les adresses multicast SSM

Les adresses SSM (Source Specific Multicast) sont décrites également dans le RFC 3306. Si le préfixe ff3x::/32 a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe ff3x::/96 doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs Plen et prefix sont positionnés à 0. La figure 6 représente ce format.

Figure 6 : Format de l'adresse multicast SSM.

Correspondance avec les adresses de multicast de niveau 2

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.

Par exemple, à l'adresse multicast IPv6 ff0e:30:2001:660:3001:4002:ae45:2C56 correspondra l'adresse MAC 33-33-AE-45-2C-56. 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 group-ID à 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.

Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.

Récapitulatif des types d'adresses multicast

Le tableau suivant récapitule les préfixes associés aux différents types d'adresses multicast décrit précédemment.

(x : une des valeurs valides de la portée (scope))

Conclusion

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.

Références bibliographiques

1. ↑ Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. Internet Multicast Today
2. ↑ Cisco (2002). White paper. IP Multicast Technology Overview White paper Cisco.
3. ↑ Wikipedia. Le multicast IPv6
4. ↑ IANA IPv6 Multicast Address Space Registry
5. ↑ IGMP snooping, [1]
6. ↑ Bridge IGMP / MLD snooping [2]
7. ↑ MLD snooping. [3]

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 2375 IPv6 Multicast Address Assignments
• RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses
• RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses
• RFC 3569 An Overview of Source-Specific Multicast (SSM)
• RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
• RFC 4291 IP Version 6 Addressing Architecture Analyse
• RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
• RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses
• RFC 7371 Updates to the IPv6 Multicast Addressing Architecture
• RFC 7346 IPv6 Multicast Address Scopes