Difference between revisions of "MOOC:Compagnon Act13-s7"

From Livre IPv6

(Les adresses unicast locales)
(25 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
 
= Activité 13  : Les adresses unicast =
 
= Activité 13  : Les adresses unicast =
+
{{Decouverte}}
 
== Introduction ==
 
== 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.
 
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.
Line 10: Line 10:
 
IPv6 définit trois types d'adresses : unicast, multicast, anycast.
 
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 datagramme 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 datagramme est remis à un seul noeud de destination. Une adresse unicast peut également indiquer une  portée qui peut être : <br>
+
* Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le datagramme 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 datagramme est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une  portée qui peut être : <br>
 
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br>
 
** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;<br>
 
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Unicast Local) ;<br>
 
** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Unicast Local) ;<br>
Line 18: Line 18:
 
</center>
 
</center>
 
   
 
   
* 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 datagramme 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 datagramme 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 datagramme émis par la source.
+
* 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 datagramme 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 datagramme 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 datagramme émis par la source.
 
<center>  
 
<center>  
 
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]
 
[[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]
 
</center>
 
</center>
 
   
 
   
* 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 datagramme anycast à un membre du groupe et non pas à tous comme pour le multicast.  La sélection du membre qui réceptionnera le datagramme 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 repliqué 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 noeuds du groupe reçoit le datagramme.
+
* 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 datagramme anycast à un membre du groupe et non pas à tous comme pour le multicast.  La sélection du membre qui réceptionnera le datagramme 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 repliqué 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 datagramme.
 
<center>
 
<center>
 
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]
 
[[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]
Line 59: Line 59:
 
|}
 
|}
 
</center>
 
</center>
Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. 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.
+
Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. 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.
  
 
<center>
 
<center>
Line 121: Line 121:
 
Les adresses IPv6 peuvent être agrégées avec des préfixes de
 
Les adresses IPv6 peuvent être agrégées avec des préfixes de
 
longueur quelconque, de manière similaire aux mécanismes mis en
 
longueur quelconque, de manière similaire aux mécanismes mis en
oeuvre dans les architectures CIDR (''Classeless InterDomain Routing'')
+
œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')
 
d'IPv4.
 
d'IPv4.
  
Un noeud peut avoir une connaissance minimale de la structuration
+
Un nœud peut avoir une connaissance minimale de la structuration
 
interne de l'adresse, en fonction de son rôle dans l'interconnexion.
 
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
 
Un hôte ou un routeur n'a ainsi pas la même vision de la structure
de l'adresse. Au minimum, un noeud peut considérer l'adresse unicast
+
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
 
comme un simple mot binaire de 128 bits, sans aucune structure
 
particulière telle que présentée dans la figure 4.
 
particulière telle que présentée dans la figure 4.
Line 145: Line 145:
 
=== L'adresse non spécifiée ===
 
=== L'adresse non spécifiée ===
 
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
 
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
à un noeud. Elle indique l'absence d'adresse. Elle est utilisée
+
à un nœud. Elle indique l'absence d'adresse. Elle est utilisée
 
comme adresse source par les paquets d'initialisation lors de
 
comme adresse source par les paquets d'initialisation lors de
 
l'auto-configuration d'une station. Elle ne doit jamais être
 
l'auto-configuration d'une station. Elle ne doit jamais être
Line 151: Line 151:
  
 
=== L'adresse de bouclage (loopback) ===  
 
=== L'adresse de bouclage (loopback) ===  
l'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée
+
L'adresse unicast <tt>0:0:0:0:0:0:0:1</tt> ou <tt>::1/128</tt> est appelée
 
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1
 
adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1
d'IPv4. Elle est utilisée par un noeud pour s'envoyer des paquets à
+
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
 
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
 
est considérée comme ayant une étendue de type "lien-local" et doit
Line 175: Line 175:
 
hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :
 
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 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.
+
* 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.
+
* un identifiant d'interface sur 64 bits (appelé Interface ID) distinguant les différentes machines sur le lien.
 
<center>
 
<center>
 
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]
 
[[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]
 
</center>  
 
</center>  
A 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.
+
À 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.
 
   
 
   
 
Il est maintenant admis que le préfixe attribué par un opérateur
 
Il est maintenant admis que le préfixe attribué par un opérateur
Line 190: Line 190:
 
régionales ne peuvent leur refuser.
 
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)
+
'''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 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 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 mecansime 6RD. Les mécanismes d'intégration seront présentés dans la séquence 4).
 
* 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 mecansime 6RD. Les mécanismes d'intégration seront présentés dans la séquence 4).
 
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation.''' Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.
 
* '''Le préfixe <tt>2001:db8::/32</tt> est réservé pour la documentation.''' Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.
 
* 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'identitfication des adresses.
 
* 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'identitfication des adresses.
* 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'identitfication des adresses, déprécié au profit d'ORCHIDv2
+
* 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
* 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'identitfication des adresses.
+
* 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.
 
* 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>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>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.
Line 204: Line 205:
 
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" />.
 
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" />.
 
   
 
   
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) :
+
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) :
 
<center>
 
<center>
 
[[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).]]
 
[[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).]]
Line 210: Line 211:
  
 
=== Les adresses unicast locales ===
 
=== Les adresses unicast locales ===
Il y a deux types d'adresse unicast qui sont utilisées localement:
+
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 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 unicast locales uniques notées ULA (''Unique Local unicast Address'').
 
   
 
   
 
==== Les adresses locales de lien (''LLA : Link Local Address'') ====
 
==== Les adresses locales de lien (''LLA : Link Local Address'') ====
Line 283: Line 284:
 
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 oeuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.
 
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 oeuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes <tt>fc00::/7</tt>.
  
 +
<!--
 
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====
 
==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====
  
Line 296: Line 298:
 
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt>
 
* <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt>
  
Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 96 à 127), 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.
+
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.
  
 
===== Les adresses IPv4 imbriquées historiques =====
 
===== Les adresses IPv4 imbriquées historiques =====
Line 309: Line 311:
  
 
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====
 
===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====
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 3 '').
+
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 '').
  
 
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.
 
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.
Line 345: Line 347:
 
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.  
 
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.  
  
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>) partagé entre tous FAI.
+
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.
  
 
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
 
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
Line 354: Line 356:
 
  |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |
 
  |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |
 
  +---------------+--------------+-----------+------------------------+
 
  +---------------+--------------+-----------+------------------------+
  |<--- 6rd delegated prefix --->|                                     
+
  |<==  6rd delegated prefix ==>|                                     
 
   
 
   
  
Line 375: Line 377:
 
* Auquel est accolé le code réservé 0xfe,
 
* Auquel est accolé le code réservé 0xfe,
 
* Suivi de l'adresse IPv4 de l'interface.
 
* Suivi de l'adresse IPv4 de l'interface.
 +
 +
-->
  
 
== Conclusion ==
 
== Conclusion ==
Line 405: Line 409:
 
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]
 
* RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]
 
* RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]
 
* 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]

Revision as of 11:07, 6 June 2019


Activité 13  : Les adresses unicast

Vous suivez une activité de découverteGrad cap.png

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 datagramme 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 datagramme 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 (Unicast Local) ;
    • 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 traitée) 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 datagramme 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 datagramme 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 datagramme é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 datagramme anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le datagramme 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 repliqué 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 datagramme.
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.

Type Préfixe binaire d'identification Notation IPv6
Non spécifié 00...0 ::/128
Adresse de bouclage (Loopback) 00...1 ::1/128
Multicast 1111 1111 ff00::/8
Unicast lien local 1111 1110 10 fe80::/10
Unique Local unicat Address (ULA) 1111 1101 fd00::/8
Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) 001 2000::/3
(soit toute adresse commençant par 2 ou 3)

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. 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.

Préfixe IPv6 Allouer Référence
0000::/8 Réservé pour la transition et loopback RFC 3513
0100::/8 Réservé RFC 3513
0200::/7 Réservé (ex NSAP) RFC 4048
0400::/6 Réservé (ex IPX) RFC 3513
0800::/5 Réservé RFC 3513
1000::/4 Réservé RFC 3513
2000::/3 Unicast Global RFC 3513
4000::/3 Réservé RFC 3513
6000::/3 Réservé RFC 3513
8000::/3 Réservé RFC 3513
a000::/3 Réservé RFC 3513
c000::/3 Réservé RFC 3513
E000::/4 Réservé RFC 3513
f000::/5 Réservé RFC 3513
F800::/6 Réservé RFC 3513
fc00::/7 Unique Local Unicast RFC 4193
fe00::/9 Réservé RFC 3513
fe80::/10 Lien-local RFC 3513
fec0::/10 Réservé RFC 3879
ff00::/8 Multicast RFC 3513

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.

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.

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 datagramme à travers le réseau, et un identifiant d'interface qui sera utilisé sur le dernier saut pour remettre le datagramme à 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 3513 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).

Adresses à usage documentaire

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 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 mecansime 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. 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'identitfication 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
  • 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 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 (fournisseur 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 (boostrap) 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 (8e bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».

Le script, sous licence libre GPL, développé par Hartmut Goebel, disponible à l'URL http://forschung.goebel-consult.de/ipv6/createLULA.py, peut vous générer une série de préfixes conformes en utilisant une des adresses MAC ethernet de votre machine.

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 oeuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes fc00::/7.


Conclusion

Nous venons d'approfondir le rôle des différentes adresses IPv6. Nous avons découvert les différents types d'adresses IPv6, leurs allocations, ainsi que la structure détaillée des préfixes réseau et sous-réseau. Les adresses unicast peuvent avoir une portée limitée au lien-local, ou bien routable sur un réseau local ou de site, voire une portée globale si les adresses sont routables sur l'internet. Les adresses multicast permettent d'atteindre un ensemble de correspondants à l'écoute des services spécifiés, ce qui est bien plus efficace que l'ancien modèle de diffusion mis en oeuvre en IPv4.

Références bibliographiques

  1. Notation binaire. Les nombres en octal, en hexadécimal et en binaire.
  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 :

Personal tools