Adresse IPv6

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche
Décomposition d'une adresse IPv6 en sa forme binaire

Une adresse Internet Protocol Version 6 ( adresse IPv6 ) est une étiquette numérique utilisée pour identifier et localiser une interface réseau d'un ordinateur ou un nœud de réseau participant à un réseau informatique utilisant IPv6 . Les adresses IP sont incluses dans l'en- tête du paquet pour indiquer la source et la destination de chaque paquet. L'adresse IP de la destination est utilisée pour prendre des décisions sur le routage des paquets IP vers d'autres réseaux.

IPv6 est le successeur de la première infrastructure d'adressage d' Internet , le protocole Internet version 4 (IPv4). Contrairement à IPv4, qui définissait une adresse IP comme une valeur de 32 bits, les adresses IPv6 ont une taille de 128 bits. Par conséquent, en comparaison, IPv6 a un espace d'adressage considérablement élargi .

Méthodes d'adressage

Les adresses IPv6 sont classées selon les principales méthodologies d'adressage et de routage courantes dans les réseaux : adressage unicast, adressage anycast et adressage multicast. [1]

Une adresse unicast identifie une seule interface réseau. Le protocole Internet délivre les paquets envoyés à une adresse de monodiffusion à cette interface spécifique.

Une adresse anycast est attribuée à un groupe d'interfaces, appartenant généralement à différents nœuds. Un paquet envoyé à une adresse anycast est livré à une seule des interfaces membres, généralement l'hôte le plus proche, selon la définition de distance du protocole de routage. Les adresses Anycast ne sont pas facilement identifiables, elles ont le même format que les adresses unicast et ne diffèrent que par leur présence sur le réseau en plusieurs points. Presque n'importe quelle adresse unicast peut être utilisée comme adresse anycast.

Une adresse de multidiffusion est également utilisée par plusieurs hôtes qui acquièrent la destination de l'adresse de multidiffusion en participant au protocole de distribution de multidiffusion parmi les routeurs du réseau. Un paquet envoyé à une adresse de multidiffusion est distribué à toutes les interfaces qui ont rejoint le groupe de multidiffusion correspondant. IPv6 n'implémente pas l' adressage de diffusion . Le rôle traditionnel de la diffusion est subsumé par l'adressage multidiffusion au groupe multidiffusion lien-local de tous les nœuds ff02 :: 1 . Cependant, l'utilisation du groupe de tous les nœuds n'est pas recommandée et la plupart des protocoles IPv6 utilisent un groupe de multidiffusion lien-local dédié pour éviter de perturber chaque interface du réseau.

Formats d'adresse

Une adresse IPv6 se compose de 128 bits. [1] Pour chacune des principales méthodologies d'adressage et de routage, divers formats d'adresse sont reconnus en divisant les 128 bits d'adresse en groupes de bits et en utilisant des règles établies pour associer les valeurs de ces groupes de bits à des caractéristiques d'adressage spéciales.

Format d'adresse unicast et anycast

Les adresses unicast et anycast sont généralement composées de deux parties logiques : un préfixe réseau 64 bits utilisé pour le routage et un identifiant d'interface 64 bits utilisé pour identifier l'interface réseau d'un hôte.

Format d'adresse unicast général (la taille du préfixe de routage varie)
morceaux 48 (ou plus) 16 (ou moins) 64
champ préfixe de routage identifiant de sous-réseau identifiant d'interface

Le préfixe réseau (le préfixe de routage combiné avec l' ID de sous-réseau ) est contenu dans les 64 bits les plus significatifs de l'adresse. La taille du préfixe de routage peut varier ; une taille de préfixe plus grande signifie une taille d'ID de sous-réseau plus petite. Les bits du champ d' identification de sous-réseau sont disponibles pour l'administrateur réseau pour définir des sous-réseaux au sein du réseau donné. L' identifiant d'interface 64 bits est soit automatiquement généré à partir de l'adresse MAC de l'interface à l' aide du format EUI-64 modifié , obtenu à partir d'un serveur DHCPv6 , établi automatiquement de manière aléatoire ou attribué manuellement.

Les adresses locales uniques sont des adresses analogues aux adresses de réseau privé IPv4 .

Format d'adresse locale unique
morceaux sept 1 40 16 64
champ préfixe L Aléatoire identifiant de sous-réseau identifiant d'interface

Le champ de préfixe contient la valeur binaire 1111110. Le bit L est un pour les adresses affectées localement ; la plage d'adresses avec L mis à zéro n'est actuellement pas définie. Le champ aléatoire est choisi au hasard une fois, au début du préfixe de routage / 48 .

Une adresse lien-local est également basée sur l'identifiant d'interface, mais utilise un format différent pour le préfixe réseau.

Format d'adresse lien-local
morceaux dix 54 64
champ préfixe des zéros identifiant d'interface

Le champ de préfixe contient la valeur binaire 1111111010. Les 54 zéros qui suivent font que le préfixe réseau total est le même pour toutes les adresses lien-local ( fe80:: / 64 préfixe d'adresse lien-local ), ce qui les rend non routables.

Format d'adresse multidiffusion

Les adresses de multidiffusion sont formées selon plusieurs règles de formatage spécifiques, selon l'application.

Format d'adresse général de multidiffusion
morceaux 8 4 4 112
champ préfixe flg sc identifiant de groupe

Pour toutes les adresses de multidiffusion, le champ de préfixe contient la valeur binaire 11111111.

Actuellement, trois des quatre bits d'indicateur dans le champ flg sont définis ; [1] le bit d'indicateur le plus significatif est réservé pour une utilisation future.

Indicateurs d'adresse multidiffusion [2]
bit drapeau Signification quand 0 Signification quand 1
8 réservé réservé réservé
9 R (Rendez-vous) [3] Point de rendez-vous non intégré Point de rendez-vous intégré
dix P (préfixe) [4] Sans informations de préfixe Adresse basée sur le préfixe du réseau
11 T (transitoire) [1] Adresse multicast bien connue Adresse multicast attribuée dynamiquement

Le champ de portée à quatre bits ( sc ) est utilisé pour indiquer où l'adresse est valide et unique.

De plus, le champ scope est utilisé pour identifier des adresses de multidiffusion spéciales, comme le nœud sollicité .

Format d'adresse de multidiffusion de nœud sollicité
morceaux 8 4 4 79 9 24
champ préfixe flg sc des zéros ceux adresse de monodiffusion

Le champ sc(ope) contient la valeur binaire 0010 (lien local). Les adresses multidiffusion de nœud sollicité sont calculées en fonction des adresses unicast ou anycast d'un nœud. Une adresse de multidiffusion de nœud sollicité est créée en copiant les 24 derniers bits d'une adresse unicast ou anycast sur les 24 derniers bits de l'adresse de multidiffusion.

Format d'adresse de multidiffusion basé sur le préfixe de monodiffusion [3] [4]
morceaux 8 4 4 4 4 8 64 32
champ préfixe flg sc res rigide plein préfixe réseau identifiant de groupe

Les adresses de multidiffusion à portée de lien utilisent un format comparable. [5]

Représentation

Une adresse IPv6 est représentée par huit groupes de quatre chiffres hexadécimaux , chaque groupe représentant 16 bits [a] Les groupes sont séparés par des deux-points ( :) . Voici un exemple d'adresse IPv6 :

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Les normes offrent une flexibilité dans la représentation des adresses IPv6. La représentation complète de huit groupes à quatre chiffres peut être simplifiée par plusieurs techniques, éliminant des parties de la représentation. En général, les représentations sont raccourcies autant que possible. Cependant, cette pratique complique plusieurs opérations courantes, à savoir la recherche d'une adresse spécifique ou d'un modèle d'adresse dans des documents texte ou des flux, et la comparaison d'adresses pour déterminer l'équivalence. Pour atténuer ces complications, l'IETF a défini un format canonique pour le rendu des adresses IPv6 dans le texte : [8]

  • Les chiffres hexadécimaux sont toujours comparés de manière insensible à la casse, mais les recommandations de l'IETF suggèrent l'utilisation de lettres minuscules uniquement. Par exemple, 2001:db8::1 est préféré à 2001:DB8::1 ;
  • Les zéros non significatifs dans chaque champ de 16 bits sont supprimés, mais chaque groupe doit conserver au moins un chiffre. Par exemple, 2001:0db8::0001:0000 est rendu sous la forme 2001:db8::1:0 ;
  • La plus longue séquence de champs consécutifs contenant uniquement des zéros est remplacée par deux deux-points ( :: ). Si l'adresse contient plusieurs exécutions de champs entièrement nuls de la même taille, pour éviter les ambiguïtés, c'est le plus à gauche qui est compressé. Par exemple, 2001:db8:0:0:1:0:0:1 est rendu sous la forme 2001:db8::1:0:0:1 plutôt que sous la forme 2001:db8:0:0:1::1 . :: n'est pas utilisé pour représenter un seul champ tout à zéro. Par exemple, 2001:db8:0:0:0:0:2:1 est raccourci en 2001:db8::2:1 , mais 2001:db8:0000:1:1:1:1:1 est rendu comme 2001 :db8:0:1:1:1:1:1 .

Ces méthodes peuvent conduire à des représentations très courtes pour les adresses IPv6. Par exemple, l'adresse localhost (loopback), 0:0:0:0:0:0:0:1 , et l'adresse IPv6 non spécifiée, 0:0:0:0:0:0:0:0 , sont réduites à ::1 et :: , respectivement.

Lors de la transition d'Internet d'IPv4 à IPv6, il est courant de fonctionner dans un environnement d'adressage mixte. Pour de tels cas d'utilisation, une notation spéciale a été introduite, qui exprime les adresses IPv6 mappées IPv4 et compatibles IPv4 en écrivant les 32 bits les moins significatifs d'une adresse dans la notation décimale à points IPv4 familière , tandis que les 96 bits les plus significatifs sont écrits au format IPv6. Par exemple, l'adresse IPv6 mappée IPv4 ::ffff:c000:0280 est écrite comme ::ffff:192.0.2.128 , exprimant ainsi clairement l'adresse IPv4 d'origine qui a été mappée sur IPv6.

Réseaux

Un réseau IPv6 utilise un bloc d'adresses qui est un groupe contigu d'adresses IPv6 d'une taille qui est une puissance de deux . Le premier ensemble de bits des adresses est identique pour tous les hôtes d'un réseau donné et est appelé l'adresse du réseau ou le préfixe de routage .

Les plages d'adresses réseau sont écrites en notation CIDR . Un réseau est désigné par la première adresse du bloc (se terminant uniquement par des zéros), une barre oblique (/) et une valeur décimale égale à la taille en bits du préfixe. Par exemple, le réseau écrit comme 2001:db8:1234:: / 48 commence à l'adresse 2001:db8:1234:0000:0000:0000:0000:0000 et se termine à 2001:db8:1234:ffff:ffff:ffff:ffff :ffff .

Le préfixe de routage d'une adresse d'interface peut être directement indiqué avec l'adresse en utilisant la notation CIDR. Par exemple, la configuration d'une interface avec l'adresse 2001:db8:a::123 connectée au sous-réseau 2001:db8:a:: / 64 s'écrit 2001:db8:a::123 / 64 .

Tailles des blocs d'adresses

La taille d'un bloc d'adresses est spécifiée en écrivant une barre oblique (/) suivie d'un nombre en décimal dont la valeur est la longueur du préfixe réseau en bits. Par exemple, un bloc d'adresse avec 48 bits dans le préfixe est indiqué par / 48 . Un tel bloc contient 2 128 − 48 = 2 80 adresses. Plus la valeur du préfixe réseau est petite, plus le bloc est grand : un bloc / 21 est 8 fois plus grand qu'un bloc / 24 .

Adresses IPv6 littérales dans les identifiants de ressources réseau

Les caractères deux-points (:) dans les adresses IPv6 peuvent entrer en conflit avec la syntaxe établie des identifiants de ressources, tels que les URI et les URL . Les deux-points sont traditionnellement utilisés pour terminer le chemin de l'hôte avant un numéro de port . [9] Pour atténuer ce conflit, les adresses IPv6 littérales sont placées entre crochets dans ces identifiants de ressources, par exemple :

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

Lorsque l'URL contient également un numéro de port, la notation est :

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

où le 443 final est le numéro de port de l'exemple.

Adresses IPv6 littérales délimitées (avec index de zone)

Pour les adresses avec une portée autre que globale (comme décrit au § Portées d'adresses ), et en particulier pour les adresses lien-local, le choix de l'interface réseau pour l'envoi d'un paquet peut dépendre de la zone à laquelle appartient l'adresse ; La même adresse peut être valide dans différentes zones et être utilisée par un hôte différent dans chacune de ces zones. Même si une seule adresse n'est pas utilisée dans différentes zones, les préfixes d'adresse pour les adresses dans ces zones peuvent toujours être identiques, ce qui rend le système d'exploitation incapable de sélectionner une interface sortante en fonction des informations de la table de routage (qui est préfixe- basé).

Afin de résoudre l'ambiguïté des adresses textuelles, unl'index de la zone doit être ajouté à l'adresse. L'index de zone est séparé de l'adresse par unsigne de pourcentage(%). [10] Bien que les index de zone numériques doivent être pris en charge universellement, l'index de zone peut également être une chaîne dépendante de la mise en œuvre. L'adresse lien-local

fe80::1ff:fe23:4567:890a

pourrait s'exprimer par

fe80::1ff:fe23:4567:890a%eth2

ou:

fe80::1ff:fe23:4567:890a%3

Le premier (utilisant un nom d' interface ) est courant sur la plupart des systèmes d'exploitation de type Unix (par exemple, BSD , Linux , macOS ). Cette dernière (utilisant un numéro d'interface) est la syntaxe standard sur Microsoft Windows , mais comme la prise en charge de cette syntaxe est obligatoire, elle est également disponible sur d'autres systèmes d'exploitation.

Les systèmes d'exploitation basés sur BSD (y compris macOS) prennent également en charge une syntaxe alternative non standard, dans laquelle un index de zone numérique est codé dans le deuxième mot de 16 bits de l'adresse. Par exemple:

fe80:3::1ff:fe23:4567:890a

Dans tous les systèmes d'exploitation mentionnés ci-dessus, l'index de zone pour les adresses lien-local fait en fait référence à une interface, et non à une zone. Comme plusieurs interfaces peuvent appartenir à la même zone (par exemple lorsqu'elles sont connectées au même réseau), en pratique deux adresses avec des identifiants de zone différents peuvent en fait être équivalentes et faire référence au même hôte sur le même lien.

Lorsqu'il est utilisé dans des identificateurs de ressources uniformes (URI), l'utilisation du signe pourcentage provoque un conflit de syntaxe, il doit donc être échappé via percent-encoding , [11] par exemple :

http://[fe80::1ff:fe23:4567:890a %25 eth0]/

Adresses IPv6 littérales dans les noms de chemin UNC

Dans les systèmes d'exploitation Microsoft Windows , les adresses IPv4 sont des identificateurs d'emplacement valides dans les noms de chemin UNC ( Uniform Naming Convention ). Cependant, les deux-points sont un caractère non autorisé dans un nom de chemin UNC. Ainsi, l'utilisation d'adresses IPv6 est également illégale dans les noms UNC. Pour cette raison, Microsoft a mis en place un algorithme de transcription pour représenter une adresse IPv6 sous la forme d'un nom de domaine utilisable dans les chemins UNC. À cette fin, Microsoft a enregistré et réservé le domaine de second niveau ipv6-literal.net sur Internet (bien qu'ils aient abandonné le domaine en janvier 2014 [12] ). Les adresses IPv6 sont transcrites en tant que nom d'hôte ou nom de sous-domaine dans cet espace de noms, de la manière suivante :

2001:db8:85a3:8d3:1319:8a2e:370:7348

s'écrit comme

2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

Cette notation est automatiquement résolue localement par le logiciel Microsoft, sans aucune requête aux serveurs de noms DNS.

Si l'adresse IPv6 contient un index de zone, il est ajouté à la partie adresse après un caractère "s" :

fe80::1ff:fe23:4567:890a%3

s'écrit comme

fe80--1ff-fe23-4567-890a s3 .ipv6-literal.net

Champs d'adresse

Chaque adresse IPv6, à l'exception de l'adresse non spécifiée ( :: ), a une "portée", [10] qui spécifie dans quelle partie du réseau elle est valide.

Monodiffusion

Pour les adresses de monodiffusion , deux portées sont définies : lien-local et global.

Les adresses lien-local et l' adresse de bouclage ont une portée lien-local , ce qui signifie qu'elles ne peuvent être utilisées que sur un seul réseau directement connecté (lien). Toutes les autres adresses (y compris les adresses locales uniques ) ont une portée globale (ou universelle ), ce qui signifie qu'elles sont (ou pourraient être) globalement routables et peuvent être utilisées pour se connecter à des adresses avec une portée globale n'importe où, ou à des adresses avec une portée lien-local sur le réseau directement connecté. Les paquets avec une source ou une destination dans une étendue ne peuvent pas être acheminés vers une autre étendue. [13]

Les adresses locales uniques ont une portée mondiale, mais elles ne sont pas administrées à l'échelle mondiale. En conséquence, seuls les autres hôtes du même domaine administratif (par exemple, une organisation) ou d'un domaine administratif coopérant sont capables d'atteindre de telles adresses, s'ils sont correctement acheminés. Comme leur portée est globale, ces adresses sont valides en tant qu'adresse source lors de la communication avec toute autre adresse de portée globale, même s'il peut être impossible d'acheminer les paquets de la destination vers la source.

Anycast

Les adresses Anycast sont syntaxiquement identiques et indiscernables des adresses unicast. Leur seule différence est administrative. Les étendues pour les adresses anycast sont donc les mêmes que pour les adresses unicast.

Multidiffusion

Pour les adresses multicast , les quatre bits de poids faible du second octet d'adresse ( ff0 s :: ) identifient la portée de l'adresse , c'est-à-dire le domaine dans lequel le paquet multicast doit être propagé. Les portées prédéfinies et réservées [1] sont :

Valeurs d'étendue
Évaluer Nom de l'étendue Remarques
0x0 réservé
0x1 interface locale La portée locale de l'interface ne couvre qu'une seule interface sur un nœud et n'est utile que pour la transmission en boucle de la multidiffusion.
0x2 lien-local La portée lien-local s'étend sur la même région topologique que la portée unicast correspondante.
0x3 domaine local La portée de domaine local est définie comme plus grande que la portée de lien local, automatiquement déterminée par la topologie du réseau et ne doit pas être plus grande que les portées suivantes. [14]
0x4 admin-local La portée Admin-local est la plus petite portée qui doit être configurée administrativement, c'est-à-dire qu'elle ne dérive pas automatiquement de la connectivité physique ou d'une autre configuration non liée à la multidiffusion.
0x5 site-local La portée site-local est destinée à couvrir un seul site appartenant à une organisation.
0x8 organisation-locale La portée locale de l'organisation est destinée à couvrir tous les sites appartenant à une seule organisation.
0xe global La portée globale couvre tous les nœuds accessibles sur Internet - elle est illimitée.
0xf réservé

Toutes les autres étendues ne sont pas attribuées et sont disponibles pour les administrateurs pour définir des régions supplémentaires.

Espace d'adressage

Allocation générale

La gestion du processus d'attribution des adresses IPv6 est déléguée à l' Internet Assigned Numbers Authority (IANA) [15] par l' Internet Architecture Board et l' Internet Engineering Steering Group . Sa fonction principale est l'attribution de grands blocs d'adresses aux registres Internet régionaux (RIR), qui ont la tâche déléguée d'attribution aux fournisseurs de services réseau et aux autres registres locaux. L'IANA a maintenu la liste officielle des attributions de l'espace d'adressage IPv6 depuis décembre 1995. [16]

Seul un huitième de l'espace d'adressage total est actuellement alloué pour une utilisation sur Internet , 2000 :: / 3 , afin de fournir une agrégation de routes efficace , réduisant ainsi la taille des tables de routage Internet ; le reste de l'espace d'adressage IPv6 est réservé pour une utilisation future ou à des fins particulières. L'espace d'adressage est attribué aux RIR en grands blocs de / 23 à / 12 . [17]

Les RIR attribuent des blocs plus petits aux registres Internet locaux qui les distribuent aux utilisateurs. Ce sont généralement des tailles allant de / 19 à / 32 . [18] [19] [20] Les adresses sont généralement distribuées en blocs de taille / 48 à / 56 aux utilisateurs finaux. [21]

Les enregistrements d'attribution de monodiffusion mondiale peuvent être trouvés sur les différents RIR ou sur d'autres sites Web. [22]

Les adresses IPv6 sont attribuées aux organisations dans des blocs beaucoup plus grands par rapport aux attributions d'adresses IPv4 - l'allocation recommandée est un bloc / 48 qui contient 2 80 adresses, soit 2 48 ou environ2,8 × 10 14 fois plus grand que l'ensemble de l'espace d'adressage IPv4 de 2 32 adresses et environ7,2 × 10 16 fois plus grand que les / 8 blocs d'adresses IPv4, qui sont les plus grandes allocations d'adresses IPv4. Le pool total, cependant, est suffisant pour l'avenir prévisible, car il y a 2 128 (exactement 340 282 366 920 938 463 463 374 607 431 768 211 456) soit environ3,4 × 10 38 (340 billions de billions de billions) adresses IPv6 uniques.

Chaque RIR peut diviser chacun de ses multiples / 23 blocs en 512 / 32 blocs, généralement un pour chaque FAI ; un FAI peut diviser son bloc / 32 en 65 536 / 48 blocs, typiquement un pour chaque client ; [23] les clients peuvent créer 65 536/64 réseaux à partir de leur bloc/48 assigné, chacun ayant 2 64 ( 18 446 744 073 709 551 616) adresses. En revanche, l'ensemble de l'espace d'adressage IPv4 n'a que 2 32 (exactement 4 294 967 296 ou environ4,3 × 10 9 ) adresses.

De par sa conception, seule une très petite fraction de l'espace d'adressage sera réellement utilisée. Le grand espace d'adressage garantit que les adresses sont presque toujours disponibles, ce qui rend totalement inutile l'utilisation de la traduction d'adresses réseau (NAT) à des fins de conservation des adresses. NAT a été de plus en plus utilisé pour les réseaux IPv4 afin d'atténuer l'épuisement des adresses IPv4 .

Allocation spéciale

Pour permettre les changements de fournisseur sans renumérotation, l'espace d'adressage indépendant du fournisseur - attribué directement à l'utilisateur final par les RIR - est extrait de la plage spéciale 2001:678 :: / 29 .

Les points d'échange Internet (IXP) se voient attribuer des adresses spéciales parmi les plages 2001:7f8 :: / 32 , 2001:504 :: / 30 et 2001:7fa :: / 32 [24] pour la communication avec leurs FAI connectés .

Les serveurs de noms racine ont reçu des adresses dans la plage 2001:7f8:: / 29 . [25]

Adresses anycast réservées

L'adresse la plus basse dans chaque préfixe de sous-réseau (l'identificateur d'interface défini uniquement sur des zéros) est réservée en tant qu'adresse anycast « routeur de sous-réseau ». [1] Les applications peuvent utiliser cette adresse lorsqu'elles parlent à l'un des routeurs disponibles, car les paquets envoyés à cette adresse sont livrés à un seul routeur.

Les 128 adresses les plus élevées dans chaque préfixe de sous-réseau / 64 sont réservées pour être utilisées comme adresses anycast. [26] Ces adresses ont généralement les 57 premiers bits de l'identificateur d'interface mis à 1, suivis de l'ID anycast de 7 bits. Les préfixes pour le réseau, y compris les sous-réseaux, doivent avoir une longueur de 64 bits, auquel cas le bit universel/local doit être défini sur 0 pour indiquer que l'adresse n'est pas globalement unique. L'adresse avec la valeur 0x7e dans les 7 bits les moins significatifs est définie comme une adresse anycast d'agents d'accueil mobiles IPv6 . L'adresse avec la valeur 0x7f (tous les bits 1) est réservée et ne peut pas être utilisée. Aucune autre affectation de cette plage n'est effectuée, les valeurs 0x00 à 0x7d sont donc également réservées.

Adresses spéciales

Il existe un certain nombre d'adresses ayant une signification particulière dans IPv6. [27] Ils représentent moins de 2 % de l'ensemble de l'espace d'adressage :

Blocs d'adresses spéciaux
Bloc d'adresse (CIDR) Première adresse Dernière adresse Nombre d'adresses Usage Objectif
::/0 :: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 128 Routage Route par défaut (pas de route spécifique)
::/128 :: :: 1 Logiciel Adresse non précisée
::1/128 ::1 ::1 1 Héberger Adresse de bouclage - une interface virtuelle qui boucle tout le trafic vers lui-même, l' hôte local
::ffff:0:0/96 ::ffff:0.0.0.0 ::ffff:255.255.255.255 2 128 − 96 = 2 32 =4 294 967 296 Logiciel Adresses mappées IPv4
::ffff:0:0:0/96 ::ffff:0:0.0.0.0 ::ffff:0:255.255.255.255 2 32 Logiciel Adresses traduites IPv4
64:ff9b ::/96 64:ff9b ::0.0.0.0 64:ff9b ::255.255.255.255 2 32 Internet mondial Traduction IPv4/IPv6 [28]
64:ff9b:1::/48 64:ff9b:1::0.0.0.0 64:ff9b:1:ffff:ffff:ffff:255.255.255.255 2 80 Internets privés Traduction IPv4/IPv6 [29]
100 ::/64 100 :: 100 ::ffff:ffff:ffff:ffff 2 64 Routage Ignorer le préfixe [30]
2001:0000 ::/32 2001 :: 2001 ::ffff:ffff:ffff:ffff:ffff:ffff 2 96 Internet mondial Tunnelier de Teredo [31]
2001:20 ::/28 2001:20 :: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff 2 100 Logiciel ORCHIDv2 [32]
2001:db8::/32 2001:db8 :: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 2 96 Documentation Adresses utilisées dans la documentation et exemple de code source [33]
2002 ::/16 2002 :: 2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 112 Internet mondial Le schéma d'adressage 6to4 (obsolète) [34]
fc00 ::/7 fc00 :: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 121 Internets privés Adresse locale unique [35]
fe80 ::/64 de fe80 ::/10 fe80 :: fe80::ffff:ffff:ffff:ffff 2 64 Lien Adresse lien-local
ff00 ::/8 ff00 :: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 120 Internet mondial Adresse de multidiffusion

Adresses de monodiffusion

Itinéraire par défaut

  • :: / 0 — L'route par défaut(correspondant à 0.0.0.0 / 0 en IPv4) pour les adresses de destination (monodiffusion, multidiffusion et autres) non spécifiées ailleurs dans une table de routage.

Adresse non précisée

  • :: / 128 — L'adresse avec tous les bits à zéro est appelée l'adresse non spécifiée(correspondant à 0.0.0.0 / 32 en IPv4).
    Cette adresse ne doit jamais être attribuée à une interface et doit être utilisée uniquement dans un logiciel avant que l'application n'ait appris l'adresse source de son hôte appropriée pour une connexion en attente. Les routeurs ne doivent pas transmettre de paquets avec une adresse non spécifiée.
    Les applications peuvent être à l'écoute sur une ou plusieurs interfaces spécifiques pour les connexions entrantes, qui sont affichées dans les listes de connexions Internet actives par une adresse IP spécifique (et un numéro de port, séparés par deux points). Lorsque l'adresse non spécifiée s'affiche, cela signifie qu'une application écoute les connexions entrantes sur toutes les interfaces disponibles.

Adresses locales

  • ::1 / 128 — L'bouclageest une adresse unicastlocalhost(correspondant à 127.0.0.1 / 8 en IPv4).
    Si une application dans un hôte envoie des paquets à cette adresse, la pile IPv6 bouclera ces paquets sur la même interface virtuelle.
  • fe80 :: / 10 — Les adresses dans le préfixe lien-local ne sont valides et uniques que sur un seul lien (comparable aux adresses de configuration automatique 169.254.0.0 / 16 d'IPv4).
    Dans ce préfixe, un seul sous-réseau est alloué (54 bits zéro), ce qui donne un format effectif de fe80 :: / 64 . Les 64 bits les moins significatifs sont généralement choisis comme adresse matérielle d'interface construite auformatEUI-64 modifiéUneadresse lien-localest requise sur chaque interface compatible IPv6. En d'autres termes, les applications peuvent s'appuyer sur l'existence d'une adresse lien-local même en l'absence de routage IPv6.

Adresses locales uniques

  • fc00 :: / 7Les adresses locales uniques(ULA) sont destinées à la communication locale [35] (comparable auxadresses privées IPv4 10.0.0.0 / 8 , 172.16.0.0 / 12 et 192.168.0.0 / 16 ).
    Ils ne sont routables qu'au sein d'un ensemble de sites coopérants. Le bloc est divisé en deux moitiés. La moitié inférieure du bloc ( fc00:: / 8 ) était destinée aux préfixes alloués globalement, mais une méthode d'allocation n'a pas encore été définie. La moitié supérieure ( fd00 :: / 8) est utilisé pour les adresses "probabiliquement uniques" dans lesquelles le préfixe / 8 est combiné avec un nombre pseudo -aléatoire de 40 bits généré localement pour obtenir un préfixe privé / 48 . La façon dont un tel numéro de 40 bits est choisi n'a qu'une chance négligeable que deux sites qui souhaitent fusionner ou communiquer entre eux utilisent le même numéro de 40 bits, et donc utilisent le même préfixe / 48 . [35]

Transition depuis IPv4

  • ::ffff:0:0 / 96 — Ce préfixe est utilisé pourles mécanismes de transition IPv6et désigné commeadresse IPv6 mappée IPv4.
    À quelques exceptions près, ce type d'adresse permet l'utilisation transparente des protocoles de lacouche transportinterface de programmation d'applicationréseau IPv6. Les applications serveur n'ont besoin d'ouvrir qu'un seulsocketpour gérer les connexions des clients utilisant les protocoles IPv6 ou IPv4. Les clients IPv6 seront gérés nativement par défaut et les clients IPv4 apparaîtront comme des clients IPv6 à leur adresse IPv6 mappée IPv4. La transmission est gérée de la même manière ; les sockets établis peuvent être utilisés pour transmettre des datagrammes IPv4 ou IPv6, sur la base de la liaison à une adresse IPv6 ou à une adresse mappée IPv4.
  • ::ffff:0:0:0 / 96 — Un préfixe utilisé pourles adresses traduites en IPv4.
    Ceux-ci sont utilisés par leprotocole Stateless IP/ICMP Translation (SIIT). [36]
  • 64:ff9b :: / 96 — Le préfixe "bien connu".
    Les adresses avec ce préfixe sont utilisées pour la traduction automatique IPv4/IPv6. [28]
  • 64:ff9b:1:: / 48 — Un préfixe pour les adresses IPv4/IPv6 traduites localement.
    Les adresses avec ce préfixe peuvent être utilisées pour plusieurs mécanismes de traduction IPv4/IPv6 commeNAT64etSIIT. [29]
  • 2002 :: / 16 — Ce préfixe était utilisé pour6to4(une adresse du réseau IPv4 192.88.99.0 / 24 était également utilisée).
    Le schéma d'adressage 6to4 est obsolète. [34]

Adresses spéciales

L'IANA a réservé un soi-disant bloc d'adresses 'Sub-TLA ID' pour les affectations spéciales [27] [37] de 2001 :: / 23 (divisé en 64 préfixes de réseau 2001:0000 :: / 29 à 2001:01f8 :: / 29 ). Trois affectations de ce bloc sont actuellement attribuées :
  • 2001 :: / 32 — Utilisé pour letunnel Teredo.
  • 2001:2 :: / 48 — Utilisé pour l'analyse comparativeIPv6 (correspondant à 198.18.0.0 / 15 pour l'analyse comparative d'IPv4).
    Affecté au groupe de travail sur la méthodologie de benchmarking (BMWG). [38]
  • 2001: 20 :: / 28 - ORCHIDv2 (identifiants de hachage cryptographiques routables superposés). [32]
    Il s'agit d'adresses IPv6 non routées utilisées pour les identifiants cryptographiques de hachage.

Documentation

  • 2001:db8:: / 32 — Ce préfixe est utilisé dans la documentation [33] (correspondant à 192.0.2.0 / 24 , 198.51.100.0 / 24 et 203.0.113.0 / 24 en IPv4.) [39]
    Les adresses doivent être utilisées partout où un exemple d'adresse IPv6 est donné ou des scénarios de mise en réseau modèles sont décrits.

Jeter

  • 100 :: / 64 — Ce préfixe est utilisé pour supprimer le trafic. [30]

Adresses obsolètes et obsolètes

Adresses multicast

Les adresses de multidiffusion ff0x ::x est n'importe quelle valeur hexadécimale sont réservées [1] et ne doivent pas être attribuées à un groupe de multidiffusion. L' Internet Assigned Numbers Authority (IANA) gère les réservations d'adresses. [40]

Certaines adresses de multidiffusion IPv6 courantes sont les suivantes :

Adresse La description Champs d'application disponibles
ff0X :: 1 Adresse de tous les nœuds, identifiez le groupe de tous les nœuds IPv6 Disponible en scope 1 (interface-local) et 2 (link-local) :
  • ff01 :: 1 → Tous les nœuds de l'interface-local
  • ff02 :: 1 → Tous les nœuds du lien local
ff0X :: 2 Tous les routeurs Disponible en scope 1 (interface-local), 2 (link-local) et 5 (site-local) :
  • ff01 :: 2 → Tous les routeurs de l'interface-local
  • ff02 :: 2 → Tous les routeurs du lien local
  • ff05 :: 2 → Tous les routeurs du site local
ff02 :: 5 OSPFIGP 2 (lien local)
ff02 :: 6 Routeurs désignés OSPFIGP 2 (lien local)
ff02 :: 9 Routeurs RIP 2 (lien local)
ff02 ::a Routeurs EIGRP 2 (lien local)
ff02 :: d Tous les routeurs PIM 2 (lien local)
ff02 :: 1a Tous les routeurs RPL 2 (lien local)
ff0X :: fb mDNSv6 Disponible dans toutes les portées
ff0X :: 101 Tous les serveurs NTP Disponible dans toutes les portées
ff02 :: 1: 1 Nom du lien 2 (lien local)
ff02 :: 1: 2 Tous les agents DHCP ( DHCPv6 ) 2 (lien local)
ff02 :: 1: 3 Résolution de noms de multidiffusion lien-local 2 (lien local)
ff05 :: 1: 3 Tous les serveurs DHCP ( DHCPv6 ) 5 (site local)
ff02 :: 1: ff00: 0/104 Adresse de multidiffusion du nœud sollicité . Voir ci-dessous 2 (lien local)
ff02::2:ff00:0/104 Requêtes d'informations sur les nœuds 2 (lien local)

Adresse de multidiffusion de nœud sollicité

Les 24 bits les moins significatifs de l' ID de groupe d' adresses multidiffusion du nœud sollicité sont remplis avec les 24 bits les moins significatifs de l'adresse unicast ou anycast de l'interface. Ces adresses permettent une résolution d'adresse de couche liaison via le protocole NDP ( Neighbor Discovery Protocol ) sur la liaison sans perturber tous les nœuds du réseau local. Un hôte doit rejoindre un groupe de multidiffusion de nœud sollicité pour chacune de ses adresses monodiffusion ou anycast configurées.

Configuration automatique des adresses sans état

Au démarrage du système, un nœud crée automatiquement une adresse lien-local sur chaque interface compatible IPv6, même si les adresses globalement routables sont configurées manuellement ou obtenues via des "protocoles de configuration" (voir ci-dessous). Il le fait indépendamment et sans aucune configuration préalable par autoconfiguration d'adresse sans état (SLAAC), [41] en utilisant un composant du Neighbor Discovery Protocol . Cette adresse est sélectionnée avec le préfixe fe80:: / 64 .

Dans IPv4, les "protocoles de configuration" typiques incluent DHCP ou PPP. Bien que DHCPv6 existe, les hôtes IPv6 utilisent normalement le protocole de découverte de voisin pour créer une adresse de monodiffusion globalement routable : l'hôte envoie des demandes de sollicitation de routeur et un routeur IPv6 répond avec une attribution de préfixe. [42]

Les 64 bits inférieurs de ces adresses sont remplis avec un identifiant d'interface 64 bits au format EUI-64 modifié . Cet identifiant est généralement partagé par toutes les adresses configurées automatiquement de cette interface, ce qui présente l'avantage qu'un seul groupe de multidiffusion doit être joint pour la découverte des voisins. Pour cela, une adresse multicast est utilisée, formée du préfixe réseau ff02::1:ff00:0 / 104 et des 24 bits de poids faible de l'adresse.

EUI-64 modifié

Un identifiant d'interface 64 bits est le plus souvent dérivé de son adresse MAC 48 bits . Une adresse MAC 00-0C-29-0C-47-D5 est transformée en EUI-64 64 bits en insérant FF-FE au milieu : 00-0C-29- FF-FE -0C-47-D5 . Lorsque cet EUI-64 est utilisé pour former une adresse IPv6, il est modifié : [1] la signification du bit Universel/Local (le 7ème bit de poids fort de l'EUI-64, en partant de 1) est inversée, de sorte qu'un 1 signifie désormais universel . Pour créer une adresse IPv6 avec le préfixe réseau 2001:db8:1:2:: / 64 , cela donne l'adresse 2001:db8:1:2:0 20c:29ff:fe0c:47d5 (avec leUniversel/Local, le deuxième bit le moins significatif du quatuor souligné, inversé à 1 dans ce cas car l'adresse MAC est universellement unique).

Détection d'adresse en double

L'attribution d'une adresse IPv6 de monodiffusion à une interface implique un test interne de l'unicité de cette adresse à l'aide de messages de sollicitation de voisin et d'annonce de voisin ( ICMPv6 type 135 et 136). Pendant le processus d'établissement de l'unicité, une adresse a un état provisoire .

Le nœud rejoint l' adresse de multidiffusion du nœud sollicité pour l'adresse provisoire (si ce n'est déjà fait) et envoie des sollicitations de voisin, avec l'adresse provisoire comme adresse cible et l'adresse non spécifiée ( :: / 128 ) comme adresse source. Le nœud rejoint également l'adresse de multidiffusion de tous les hôtes ff02::1 , il pourra donc recevoir des annonces de voisin .

Si un nœud reçoit une sollicitation de voisin avec sa propre adresse provisoire comme adresse cible, alors cette adresse n'est pas unique. Il en va de même si le nœud reçoit une annonce de voisin avec l'adresse provisoire comme source de l'annonce. Ce n'est qu'après avoir établi avec succès qu'une adresse est unique qu'elle peut être attribuée et utilisée par une interface.

Durée de vie de l'adresse

Chaque adresse IPv6 liée à une interface a une durée de vie fixe. Les durées de vie sont infinies, sauf si elles sont configurées sur une période plus courte. Deux durées de vie régissent l'état d'une adresse : la durée de vie préférée et la durée de vie valide . [43] Les durées de vie peuvent être configurées dans les routeurs qui fournissent les valeurs utilisées pour la configuration automatique, ou spécifiées lors de la configuration manuelle des adresses sur les interfaces.

Lorsqu'une adresse est affectée à une interface, elle obtient le statut "préféré", qu'elle conserve pendant sa durée de vie préférée. Après l'expiration de cette durée de vie, le statut devient "obsolète" et aucune nouvelle connexion ne doit être établie à l'aide de cette adresse. L'adresse devient "invalide" après l'expiration de sa durée de vie valide ; l'adresse est supprimée de l'interface et peut être attribuée ailleurs sur Internet .

Remarque : dans la plupart des cas, la durée de vie n'expire pas car les nouvelles annonces de routeur (RA) actualisent les temporisateurs. Mais s'il n'y a plus de RA, la durée de vie préférée finit par s'écouler et l'adresse devient "obsolète".

Adresses temporaires

Les adresses MAC mondialement uniques et statiques, utilisées par la configuration automatique des adresses sans état pour créer des identifiants d'interface, offrent la possibilité de suivre l'équipement de l'utilisateur (dans le temps et les changements de préfixe réseau IPv6) et donc les utilisateurs. [44] Pour réduire la possibilité qu'une identité d'utilisateur soit liée en permanence à une partie d'adresse IPv6, un nœud peut créer des adresses temporaires avec des identifiants d'interface basés sur des chaînes de bits aléatoires variant dans le temps [45] et des durées de vie relativement courtes (heures à jours), après quoi elles sont remplacées par de nouvelles adresses.

Les adresses temporaires peuvent être utilisées comme adresse source pour les connexions d'origine, tandis que les hôtes externes utilisent une adresse publique en interrogeant le système de noms de domaine.

Les interfaces réseau configurées pour IPv6 utilisent des adresses temporaires par défaut dans OS X Lion et les systèmes Apple ultérieurs ainsi que dans Windows Vista , Windows 2008 Server et les systèmes Microsoft ultérieurs.

Adresses générées cryptographiquement

Comme moyen d'améliorer la sécurité du protocole de découverte de voisin, les adresses générées cryptographiquement (ou CGA) ont été introduites en 2005 [46] dans le cadre du protocole Secure Neighbor Discovery (SEND).

Une telle adresse est générée à l'aide de deux fonctions de hachage qui prennent plusieurs entrées. Le premier utilise une clé publique et un modificateur aléatoire ; ce dernier étant incrémenté à plusieurs reprises jusqu'à ce qu'une quantité spécifique de bits zéro du hachage résultant soit acquise. (Comparable avec le champ « preuve de travail » dans le minage de Bitcoin .) La deuxième fonction de hachage prend le préfixe du réseau et la valeur de hachage précédente. Les 64 bits les moins significatifs du deuxième résultat de hachage sont ajoutés au préfixe réseau 64 bits pour former une adresse 128 bits.

Les fonctions de hachage peuvent également être utilisées pour vérifier si une adresse IPv6 spécifique satisfait à l'exigence d'être un CGA valide. De cette façon, la communication peut être établie entre des adresses de confiance exclusivement.

Adresses de confidentialité stables

L'utilisation d'adresses autoconfigurées sans état a de sérieuses implications pour les problèmes de sécurité et de confidentialité, [47] parce que l'adresse matérielle sous-jacente (le plus souvent l' adresse MAC ) est exposée au-delà du réseau local, permettant le suivi des activités des utilisateurs et la corrélation des comptes d'utilisateurs avec d'autres informations. Il permet également des stratégies d'attaque spécifiques au fournisseur et réduit la taille de l'espace d'adressage pour la recherche de cibles d'attaque.

Des adresses de confidentialité stables ont été introduites pour remédier à ces lacunes. Ils sont stables au sein d'un réseau spécifique mais changent lors du passage à un autre, pour améliorer la confidentialité. Ils sont choisis de manière déterministe, mais aléatoire, dans tout l'espace d'adressage du réseau.

La génération d'une adresse de confidentialité stable est basée sur une fonction de hachage qui utilise plusieurs paramètres stables. Il est spécifique à l'implémentation, mais il est recommandé d'utiliser au moins le préfixe réseau, le nom de l'interface réseau, un compteur d'adresses en double et une clé secrète. La valeur de hachage résultante est utilisée pour construire l'adresse finale : généralement, les 64 bits les moins significatifs sont concaténés au préfixe réseau 64 bits, pour donner une adresse 128 bits. Si le préfixe réseau est inférieur à 64 bits, davantage de bits du hachage sont utilisés. Si l'adresse résultante n'entre pas en conflit avec des adresses existantes ou réservées, elle est attribuée à l'interface.

Sélection d'adresse par défaut

Les interfaces réseau compatibles IPv6 ont généralement plusieurs adresses IPv6, par exemple, une adresse lien-local et une adresse globale. Ils peuvent également avoir des adresses temporaires qui changent après l'expiration d'une certaine durée de vie. IPv6 introduit les concepts de portée d'adresse et de préférence de sélection, offrant plusieurs choix pour les sélections d'adresse source et de destination dans la communication avec un autre hôte.

L'algorithme de sélection des préférences publié dans la RFC 6724 sélectionne l'adresse la plus appropriée à utiliser dans les communications avec une destination particulière, y compris l'utilisation d'adresses mappées IPv4 dans les implémentations à double pile . [48] ​​Il utilise une table de préférences configurable qui associe chaque préfixe de routage à un niveau de priorité. Le tableau par défaut a le contenu suivant : [48]

Préfixe Priorité Étiquette Usage
::1/128 50 0 Hôte local
::/0 40 1 Monodiffusion par défaut
::ffff:0:0/96 35 4 Adresse IPv6 mappée IPv4
2002 ::/16 30 2 6à4
2001 ::/32 5 5 Tunnel de Teredo
fc00 ::/7 3 13 Adresse locale unique
::/96 1 3 Adresses compatibles IPv4 (obsolète)
fec0 ::/10 1 11 Adresse locale du site (obsolète)
3ffe ::/16 1 12 6os (retourné)

La configuration par défaut place la préférence sur l'utilisation d'IPv6 et sélectionne les adresses de destination dans la plus petite portée possible, de sorte que la communication lien-local est préférée aux chemins acheminés globalement lorsqu'ils sont également appropriés. La table de politique de préfixe est similaire à une table de routage, la valeur de priorité jouant le rôle d'un coût de liaison, où une préférence plus élevée est exprimée par une valeur plus grande. Il est préférable que les adresses source aient la même valeur d'étiquette que l'adresse de destination. Les adresses sont mises en correspondance avec les préfixes en fonction de la séquence de bits la plus significative correspondante la plus longue. Les adresses sources candidates sont obtenues à partir du système d'exploitation et les adresses de destination candidates peuvent être interrogées via le système de noms de domaine (DNS).

Pour minimiser le temps d'établissement des connexions lorsque plusieurs adresses sont disponibles pour la communication, l' algorithme Happy Eyeballs a été conçu. Il interroge le système de noms de domaine pour les adresses IPv6 et IPv4 de l'hôte cible, trie les adresses candidates à l'aide de la table de sélection d'adresses par défaut et tente d'établir des connexions en parallèle. La première connexion établie annule les tentatives actuelles et futures de connexion à d'autres adresses.

Système de nom de domaine

Dans le système de noms de domaine , les noms d' hôte sont mappés sur des adresses IPv6 par des enregistrements de ressources AAAA , appelés enregistrements quad-A . [49] Pour la recherche inversée , l'IETF a réservé le domaine ip6.arpa , où l'espace de noms est divisé hiérarchiquement par la représentation hexadécimale à 1 chiffre des unités de quartet (4 bits) de l'adresse IPv6.

Comme dans IPv4, chaque hôte est représenté dans le DNS par deux enregistrements DNS : un enregistrement d'adresse et un enregistrement de pointeur de mappage inversé. Par exemple, un ordinateur hôte nommé derrick dans la zone example.com a l' adresse locale unique fdda:5cc1:23:4::1f . Son enregistrement d'adresse quad-A est

derrick.exemple.com. EN AAAA fdda:5cc1:23:4::1f

et son enregistrement de pointeur IPv6 est

f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. IN PTR derrick.example.com.

Cet enregistrement de pointeur peut être défini dans plusieurs zones, selon la chaîne de délégation d'autorité dans la zone dfip6.arpa.

Le protocole DNS est indépendant de son protocole de couche de transport . Les requêtes et les réponses peuvent être transmises via des transports IPv6 ou IPv4, quelle que soit la famille d'adresses des données demandées.

Champs d'enregistrement AAAA
NOM Nom de domaine
TAPER AAAA (28)
CLASSER Internet (1)
Durée de vie Le temps de vivre en secondes
RLONGUEUR Longueur du champ RDATA
RDATA Adresse IPv6 128 bits, ordre des octets réseau

Notes historiques

Adresses obsolètes et obsolètes

  • Le préfixe site-local fec0 :: / 10 spécifie que l'adresse est valide uniquement au sein du réseau de sites d'une organisation. Il faisait partie de l'architecture d'adressage originale [50] en décembre 1995, mais son utilisation a été dépréciée en septembre 2004 [51] car la définition du terme site était ambiguë, ce qui a conduit à des règles de routage confuses. Les nouveaux réseaux ne doivent pas prendre en charge ce type particulier d'adresse. En octobre 2005, une nouvelle spécification [35] a remplacé ce type d'adresse par des adresses locales uniques .
  • Le bloc d'adresse 200 :: / 7 a été défini comme un préfixe mappé OSI NSAP défini en août 1996, [52] [53] mais a été obsolète en décembre 2004. [54]
  • Le préfixe de valeur zéro 96 bits :: / 96 , initialement connu sous le nom d' adresses compatibles IPv4 , a été mentionné en 1995 [50] mais décrit pour la première fois en 1998. [55] [ échec de la vérification ] Cette plage d'adresses a été utilisée pour représenter IPv4 adresses au sein d'une technologie de transition IPv6. Une telle adresse IPv6 a ses 96 premiers bits (les plus significatifs) mis à zéro, tandis que ses 32 derniers bits sont l'adresse IPv4 qui est représentée. En février 2006, l' Internet Engineering Task Force (IETF) a déconseillé l'utilisation d'adresses compatibles IPv4. [1]La seule utilisation restante de ce format d'adresse est de représenter une adresse IPv4 dans une table ou une base de données avec des membres de taille fixe qui doivent également pouvoir stocker une adresse IPv6.
  • Le bloc d'adresses 3ffe :: / 16 a été attribué à des fins de test pour le réseau 6bone en décembre 1998. [55] Auparavant, le bloc d'adresses 5f00 :: / 8 était utilisé à cette fin. Les deux blocs d'adresses ont été renvoyés au pool d'adresses en juin 2006. [56]
  • En raison de problèmes de fonctionnement avec 6to4 , l'utilisation du bloc d'adresse 2002 :: / 16 diminue, puisque le mécanisme 6to4 est obsolète depuis mai 2015. [34] Bien que le bloc d'adresse IPv4 192.88.99.0 / 24 soit obsolète, 2002 :: / 16 est ne pas.
  • En avril 2007, le bloc d'adresses 2001:10 :: / 28 a été attribué pour Overlay Routable Cryptographic Hash Identifiers (ORCHID). [57] Il était destiné à un usage expérimental. En septembre 2014, une deuxième version d'ORCHID a été spécifiée [32] et avec l'introduction du bloc 2001:20 :: / 28 , le bloc d'origine a été renvoyé à l' IANA .

Divers

  • Pour la recherche DNS inversée , les adresses IPv6 étaient initialement enregistrées dans la zone DNS ip6.int , car il était prévu que le domaine de premier niveau arpa soit retiré. En 2000, l' Internet Architecture Board (IAB) est revenu sur cette intention et a décidé en 2001 qu'arpa devait conserver sa fonction d'origine. Les domaines de ip6.int ont été déplacés vers ip6.arpa [58] et la zone ip6.int a été officiellement supprimée le 6 juin 2006.
  • En mars 2011, l' IETF a affiné les recommandations d'attribution de blocs d'adresses aux sites finaux. [21] Au lieu d'attribuer soit un / 48 , / 64 , ou / 128 (selon les points de vue de l' IAB et de l' IESG de 2001), [59] les fournisseurs de services Internet devraient envisager d'attribuer des blocs plus petits (par exemple a / 56 ) aux utilisateurs finaux. Les politiques des registres régionaux ARIN , RIPE et APNIC encouragent les / 56 affectations le cas échéant. [21]
  • À l'origine, deux propositions existaient pour traduire les noms de domaine en adresses IPv6 : l'une utilisant des enregistrements AAAA, [60] l'autre utilisant des enregistrements A6. [61] Les enregistrements AAAA, la méthode qui a prévalu, sont comparables aux enregistrements A pour IPv4, fournissant un mappage simple du nom d'hôte à l'adresse IPv6. La méthode utilisant des enregistrements A6 utilisait un schéma hiérarchique, dans lequel le mappage des groupes suivants de bits d'adresse était spécifié par des enregistrements A6 supplémentaires, offrant la possibilité de renuméroter tous les hôtes d'un réseau en modifiant un seul enregistrement A6. Comme les avantages perçus du format A6 n'ont pas été jugés supérieurs aux coûts perçus, [62] [63] [64] [65] la méthode est passée au statut expérimental en 2002, [63]et enfin au statut historique en 2012. [65]
  • En 2009, de nombreux résolveurs DNS dans les périphériques et routeurs NAT de réseau domestique se sont avérés traiter de manière incorrecte les enregistrements AAAA. [66] Certains d'entre eux ont simplement abandonné les demandes DNS pour de tels enregistrements, au lieu de renvoyer correctement la réponse DNS négative appropriée. Étant donné que la demande est abandonnée, l'hôte qui envoie la demande doit attendre qu'un délai d'attente se déclenche. Cela provoque souvent un ralentissement lors de la connexion à des hôtes IPv6/IPv4 à double pile, car le logiciel client attendra que la connexion IPv6 échoue avant d'essayer IPv4.

Remarques

  1. ^ Une quantité de 16 bits ou deux octets est parfois aussi appelée un hextet . [6] [7]

Références

  1. ^ un bcdefghi R. Hinden ; _ _ _ _ _ S. Deering (février 2006). Architecture d'adressage IP version 6 . Groupe de travail du réseau. doi : 10.17487/RFC4291 . RFC 4291 . Mis à jour par : RFC  5952 , RFC  6052 , RFC  7136 , RFC  7346 , RFC  7371 , RFC  8064 .
  2. ^ Silvia Hagen (mai 2006). IPv6 Essentials (deuxième éd.). O'Reilly. ISBN 978-0-596-10058-2.
  3. ^ un b P. Savola; B. Haberman (novembre 2004). Intégration de l'adresse du point de rendez-vous (RP) dans une adresse de multidiffusion IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC3956 . RFC 3956 .
  4. ^ un b B. Haberman; D. Thaler (août 2002). Adresses de multidiffusion IPv6 basées sur le préfixe de monodiffusion . Groupe de travail du réseau. doi : 10.17487/RFC3306 . RFC 3306 .
  5. ^ JS. Se garer; MK. Tibia; HJ. Kim (avril 2006). Une méthode pour générer des adresses de multidiffusion IPv6 à portée de liaison . Groupe de travail du réseau. doi : 10.17487/RFC4489 . RFC 4489 .
  6. ^ Graziani, Rick (2012). Principes de base d'IPv6 : une approche simple pour comprendre IPv6 . Cisco presse . p. 55. ISBN 978-0-13-303347-2.
  7. ^ Coffeen, Tom (2014). Planification d'adresses IPv6 : concevoir un plan d'adressage pour l'avenir . O'Reilly Media . p. 170. ISBN 978-1-4919-0326-1.
  8. ^ S. Kawamura; M. Kawashima (août 2010). Une recommandation pour la représentation de texte d'adresse IPv6 . IETF . doi : 10.17487/RFC5952 . ISSN 2070-1721 . RFC 5952 . 
  9. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (janvier 2005). Identifiant de ressource uniforme (URI) : syntaxe générique . Groupe de travail du réseau. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .
  10. ^ un b S.Deering ; B. Haberman; T. Jinmei ; E. Nordmark ; B. Zill (mars 2005). Architecture d'adresse étendue IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC4007 . RFC 4007 .
  11. ^ B. Charpentier; S. Cheshire; R. Hinden (février 2013). Représentation des identificateurs de zone IPv6 dans les littéraux d'adresse et les identificateurs de ressource uniformes . IETF. doi : 10.17487/RFC6874 . RFC 6874 . Met à jour la RFC 3986 . 
  12. ^ "Historique du domaine ipv6-literal.net" . qui.est . Récupéré le 20 octobre 2014 .
  13. ^ "Zones de portée" . Centre de connaissances IBM . 27 septembre 2013 . Récupéré le 13 décembre 2019 . Les paquets qui contiennent une adresse source ou de destination d'une étendue donnée peuvent être acheminés uniquement dans la même zone d'étendue et ne peuvent pas être acheminés entre différentes instances de zone d'étendue.
  14. ^ R Droms (août 2014). Étendues des adresses de multidiffusion IPv6 . IETF . doi : 10.17487/RFC7346 . ISSN 2070-1721 . RFC 7346 . 
  15. ^ Gestion de l'allocation d'adresses IPv6 . Groupe de travail réseau, IETF . Décembre 1995. doi : 10.17487/RFC1881 . RFC 1881 .
  16. ^ Espace d'adressage IPv6 à l'IANA . Iana.org (2010-10-29). Consulté le 2011-09-28.
  17. ^ Attribution d'adresses de monodiffusion IPv6 , IANA
  18. ^ DE-TELEKOM-20050113 db.ripe.net. Récupéré le 28/09/2011.
  19. ^ "Manuel de politique de ressource de nombre d'ARIN : Allocation initiale aux ISPs" .
  20. ^ "Politique d'allocation et d'attribution d'adresses IPv6 RIPE NCC : allocation minimale" .
  21. ^ un bc T. Narten ; G. Houston ; L. Roberts (mars 2011). Attribution d'adresses IPv6 aux sites finaux . IETF . doi : 10.17487/RFC6177 . BCP 157. RFC 6177 .
  22. ^ par exemple . Iana.org. Consulté le 2011-09-28.
  23. ^ "Plans d'adressage IPv6" . ARIN IPv6 Wiki . Récupéré le 15/07/2018 . Tous les clients en obtiennent un / 48 à moins qu'ils ne puissent prouver qu'ils ont besoin de plus de 65 000 sous-réseaux. [...] Si vous avez beaucoup de clients consommateurs, vous voudrez peut-être attribuer des / 56 à des sites de résidences privées.
  24. ^ "Que sont les Bogons?" . Récupéré le 15/11/2021 .
  25. ^ "Espace d'adressage géré par le RIPE NCC" . Récupéré le 22/05/2011 .
  26. ^ D. Johnson; S. Deering (mars 1999). Adresses Anycast de sous-réseau IPv6 réservées . Groupe de travail du réseau. doi : 10.17487/RFC2526 . RFC 2526 .
  27. ^ un b M. Coton; L. Vegoda; B. Haberman (avril 2013). R. Bonica (éd.). Registres d'adresses IP à usage spécifique . IETF . doi : 10.17487/RFC6890 . ISSN 2070-1721 . BCP 153. RFC 6890 .  Obsolètes RFC  4773 , 5156 , 5735 et 5736 . Mis à jour par RFC  8190 .
  28. ^ un b C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (octobre 2010). Adressage IPv6 des traducteurs IPv4/IPv6 . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC6052 . RFC 6052 .
  29. ^ un b T. Anderson (août 2017). Préfixe de traduction IPv4/IPv6 à usage local . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC8215 . RFC 8215 .
  30. ^ un b N. Hilliard; D. Freedman (août 2012). Un préfixe à ignorer pour IPv6 . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC6666 . RFC 6666 .
  31. ^ RFC 4680 
  32. ^ un bc J. Laganier ; F. Dupont (septembre 2014). Un préfixe IPv6 pour les identificateurs de hachage cryptographiques routables superposés version 2 (ORCHIDv2) . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC7343 . RFC 7343 .
  33. ^ un b G. Huston; R. Seigneur ; P. Smith (juillet 2004). Préfixe d'adresse IPv6 réservé à la documentation . Groupe de travail du réseau. doi : 10.17487/RFC3849 . RFC 3849 .
  34. ^ un bc O. Troan (mai 2015). B. Carpenter (éd.). Dépréciation du préfixe Anycast pour les routeurs relais 6to4 . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC7526 . BCP 196. RFC 7526 .
  35. ^ un bcd R. Hinden ; B. Haberman (octobre 2005). Adresses de monodiffusion IPv6 locales uniques . Groupe de travail du réseau. doi : 10.17487/RFC4193 . RFC 4193 .
  36. ^ C. Bao; X.Li; F. Baker ; T.Anderson; F. Gont (juin 2016). Algorithme de traduction IP/ICMP sans état . doi : 10.17487/RFC7915 . RFC 7915 .
  37. ^ R. Hinden; S. Cerf ; R. Fink; T. Hain (septembre 2000). Affectations initiales d'ID de sous-TLA IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC2928 . RFC 2928 .
  38. ^ C. Popoviciu; A. Hamza ; G. Van de Velde; D. Dugatkin (mai 2008). Méthodologie d'analyse comparative IPv6 pour les périphériques d'interconnexion réseau . Groupe de travail du réseau. doi : 10.17487/RFC5180 . RFC 5180 .
  39. ^ J. Arkko; M. Coton ; L. Vegoda (janvier 2010). Blocs d'adresses IPv4 réservés à la documentation . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC5737 . ISSN 2070-1721 . RFC 5737 . 
  40. ^ Adresses de multidiffusion de la version 6 du protocole Internet IANA .
  41. ^ S. Thomson; T. Narten; T. Jinmei (septembre 2007). Configuration automatique de l'adresse sans état IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC4862 . RFC 4862 .
  42. ^ T. Narten; E. Nordmark ; W. Simpson; H. Holiman (septembre 2007). Découverte de voisin pour IP version 6 (IPv6) . Groupe de travail du réseau. doi : 10.17487/RFC4861 . RFC 4861 .
  43. ^ Iljitsch van Beijnum (2006). "Internes IPv6" . Le journal du protocole Internet . Vol. 9, non. 3. p. 16–29.
  44. ^ Les implications sur la vie privée de l'adressage IPv6 sans état . Portail.acm.org (2010-04-21). Consulté le 2011-09-28.
  45. ^ T. Narten; R. Draves; S. Krishnan (septembre 2007). Extensions de confidentialité pour la configuration automatique des adresses sans état dans IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC4941 . RFC 4941 .
  46. ^ T. Aura (mars 2005). Adresses générées cryptographiquement (CGA) . Groupe de travail réseau IETF . doi : 10.17487/RFC3972 . RFC 3972 .
  47. ^ F. Gont (avril 2014). Une méthode pour générer des identifiants d'interface sémantiquement opaques avec la configuration automatique d'adresse sans état IPv6 (SLAAC) . IETF . doi : 10.17487/RFC7217 . ISSN 2070-1721 . RFC 7217 . 
  48. ^ un b D. Thaler; R. Draves; A.Matsumoto; T. Chown (septembre 2012). D. Thaler (éd.). Sélection d'adresse par défaut pour le protocole Internet version 6 (IPv6) . IETF . doi : 10.17487/RFC6724 . ISSN 2070-1721 . RFC 6724 . 
  49. ^ S. Thomson; C. Huitema; V. Ksinant ; M. Souissi (octobre 2003). Extensions DNS pour prendre en charge la version IP 6 . Groupe de travail du réseau. doi : 10.17487/RFC3596 . RFC 3596 .
  50. ^ un b R. Hinden; S. Deering (décembre 1995). Architecture d'adressage IP version 6 . Groupe de travail du réseau. doi : 10.17487/RFC1884 . RFC 1884 .
  51. ^ C. Huitema; B. Carpenter (septembre 2004). Abandon des adresses locales du site . Groupe de travail du réseau. doi : 10.17487/RFC3879 . RFC 3879 .
  52. ^ G. Houston (août 2005). Modifications proposées au format du registre IANA IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC4147 . RFC 4147 .
  53. ^ J. Lié; B. Charpentier ; D.Harrington; J.Houldsworth; A. Lloyd (août 1996). NSAP OSI et IPv6 . Groupe de travail du réseau. doi : 10.17487/RFC1888 . RFC 1888 . Obsolète par RFC 4048.
  54. ^ B. Carpenter (avril 2005). RFC 1888 est obsolète . doi : 10.17487/RFC4048 . RFC 4048 .
  55. ^ un b R. Hinden; R. Fink; J. Postel (décembre 1998). Allocation d'adresse de test IPv6 . doi : 10.17487/RFC2471 . RFC 2471 . Obsolète par RFC 3701.
  56. ^ R. Fink; R. Hinden (mars 2004). 6bone (allocation d'adresses de test IPv6) . Groupe de travail du réseau. doi : 10.17487/RFC3701 . RFC 3701 .
  57. ^ P. Nikander; J. Laganier; F. Dupont (avril 2007). Un préfixe IPv6 pour les identificateurs de hachage cryptographiques routables superposés (ORCHID) . Groupe de travail du réseau. doi : 10.17487/RFC4843 . RFC 4843 .
  58. ^ R. Bush (août 2001). Délégation de IP6.ARPA . doi : 10.17487/RFC3152 . RFC 3152 . Obsolète par RFC 3596
  59. ^ IAB ; IESG (septembre 2001). Recommandations IAB/IESG sur l'attribution d'adresses IPv6 aux sites . doi : 10.17487/RFC3177 . RFC 3177 .
  60. ^ S. Thomson; C. Huitema (décembre 1995). Extensions DNS pour prendre en charge la version IP 6 . Groupe de travail du réseau. doi : 10.17487/RFC1886 . RFC 1886 . Obsolète par RFC 3596.
  61. ^ M. Crawford; C. Huitema (juillet 2000). Extensions DNS pour prendre en charge l'agrégation et la renumérotation d'adresses IPv6 . doi : 10.17487/RFC2874 . RFC 2874 .
  62. ^ Comparaison de AAAA et A6 (avons-nous vraiment besoin de A6?) , Jun-ichiro itojun Hagino, (juillet 2001)
  63. ^ un b R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain (août 2002). Représentation des adresses IPv6 (Internet Protocol version 6) dans le système de noms de domaine (DNS) . Groupe de travail du réseau. doi : 10.17487/RFC3363 . RFC 3363 . .
  64. ^ R. Austein (août 2002). Compromis dans la prise en charge du système de noms de domaine (DNS) pour la version 6 du protocole Internet (IPv6) . Groupe de travail du réseau. doi : 10.17487/RFC3364 . RFC 3364 .
  65. ^ un b S. Jiang; D. Conrad; B. Carpenter (mars 2012). Déplacer A6 vers le statut historique . IETF . doi : 10.17487/RFC6536 . RFC 6536 .
  66. ^ Y. Morishita; T. Jinmei (mai 2005). Mauvais comportement courant face aux requêtes DNS pour les adresses IPv6 . doi : 10.17487/RFC4074 . RFC 4074 .

Liens externes